get Blocks forged by Pool daily



  • so I've been messing around with the API trying to find a solution for a little problem I have.
    I'd like to get an more accurate number of Blocks forged by or in a pool on a daily basis!?
    Reason for that being a comparison of pool payout schemes.
    I know there is a number on http://util.burst-team.us:8888/pool for the last 10 days. But as it says on the bottom, its inaccurate because it only takes the current Reward Assignment of each miner and then pulls all the blocks they forged in the last 10 days. With all the "pool jumping" going on this can get quite inaccurate!
    I'd like to do the same but an at least a daily basis! No problem doing that manually on a small pool but not on, for example burst.ninja!-)
    I would have to:

    http://localhost:8125/burst?requestType=getAccountsWithRewardRecipient&account=12468105956737329840
    

    and then

    http://localhost:8125/burst?requestType=getAccountBlockIds&account=10718900860795585473&timestamp=71040909
    

    for each and every miner on that pool! (daily!)
    and mayby get the current timestamp to be used the next day.

    http://localhost:8125/burst?requestType=getTime
    

    Is there anybody willing and able to help me automating this? Its my first attempt doing anything like this!-/

    A script, Exel-Macro (LibreOffice), google script, API marshalling anything?!!
    ( @LithStud hint hint!- ) (thanks @gpedro )

    Its not something I'd call very useful for widespread use. So very quick and very dirty is just fine!
    I'd be very thankful.... ah, yes Bounties seams the way its done around here!-)
    lets say 10K Burst !?



  • @nixxda for some reason your tag wasn't right so i will just put it here again... xD
    @LithStud



  • @nixxda i have wrote some code in the latest version of my pool software that records block winner. and who they are assigned to in csv format. and it will record for every block from the time i start running it.

    currently the data it outputs looks like this
    Height _____ Winner ___________ Reward Assignment ______ reward
    25833 BURST-BXN8-5FJB-7HCR-778F9 BXN8-5FJB-7HCR-778F9 9025
    25904 BURST-4TXV-RV3F-XBAV-AGZMK 4TXV-RV3F-XBAV-AGZMK 9025
    25976 BURST-3N7E-CX8T-K6AM-D6Q4N 3N7E-CX8T-K6AM-D6Q4N 9025
    26014 BURST-YZFP-7YH7-G2CQ-3WLF5 L28E-WSYC-F4N3-B82AC 9025
    26048 BURST-ZDAQ-Q2H3-DLM9-G2FAE ZDAQ-Q2H3-DLM9-G2FAE 9025

    im hoping to update my pool tonight with this change so i can give you a link afterwards to where you can download the csv if you want mate



  • @nixxda Lexicon seems to be on it ;)
    For general knowledge i will look it up whats on the api front :)



  • thank you @Lexicon ! One thing less to worry about!-)
    Although I hope you also came to the conclusion that this pool payout comparison is going to be "splitting hairs" in the end.
    But I seam to have gotten a bad case of "statistics addiction" lately!-)


  • admin

    Moved to Help&Support > Development and API usage



  • @luxe thanks! did not even now about this one!


  • admin

    @nixxda I'm just editing, guess a main section development is even better ... so i made that.


  • admin

    @nixxda

    I know there is a number on http://util.burst-team.us:8888/pool for the last 10 days. But as it says on the bottom, its inaccurate because it only takes the current Reward Assignment of each miner and then pulls all the blocks they forged in the last 10 days.

    That is correct, and the solution would be even more complicated, even if you do not track it per 10 days, but per day ... it is still not accurate.

    So what would be needed is to exactly track at what block miners did reward assignment to another pool, so that found blocks of that miner can be always counted for the correct pool.
    I thought about make it in that detail level, but skipped it due no time and to much request to api :-) Maybe in the future.

    Btw. that 10 days could be made adjustable by settings or change and compile it yourself.
    https://github.com/de-luxe/burstcoin-observer/blob/master/src/main/java/burstcoin/observer/service/PoolService.java#L71



  • @nixxda looked up into available api calls and the thing you want isnt really cost effective, as it would put unnecessary strain on a wallet client (or even worse public server). While it is possible you would need to scan whole chain to agregate statistics. If lets say to start from just this point in time and go on further. You could write a deamon who would record found block and what poo/user found it. Or if just one pool then like Lexicon is duing pool itself does similar records (i suppose it can just record all blocks not just found in that pool).


  • admin

    @luxe The ninja pools log each time they forge a block, but there are variable entries per block, but it would be possible to parse it out of the log


  • admin

    @nixxda Every statistic collecting code can use its local own wallet, no issue stressing that :-)

    @haitch sure, but it is all in the blockchain, too. All reward assignment transactions and every block knows it's miner ... it's not the pools accounts in a block as generator.
    So if you build a lookup of every miner, on what block he was assigned to what pool, you can find out how many blocks a pool got in a given amount of time.
    The observer works stupid other way round, it counts blocks for every miner in the given time. And based of current rewardAssignment counts it for the pools.



  • @luxe I realize that one should do it after every round! But polling the Wallet for 680something getAccountBlockIds might be a bit much!?
    and only to check if the last block went to this pool!?
    and it needs another step of automation because I cant do it after every round!!-)
    running it once or twice a day manually is plenty i think!

    I'm writing to slow (and I'm currently the MC Server Support Team for the kids.....)
    just saw the other answers!

    Yes Logs! @luxe can you give away a "snipped" of those Logs in one week from now?
    its not as cool as scripting API requests but I'll split the bounty for doing this work!-)


  • admin

    @luxe You'd have to look up every block on a day, see who mined it, then back track to where there assignment was. If you only look at the current miners you'll miss any miner that's no longer there - so the only way I see to do it is to look at every block for that day and link it to a pool.


  • admin

    @haitch yes

    @nixxda i have no logs that was @haitch ... and wouldn't you need logs of all pools? blockchain is the better source i guess.



  • @haitch but you cant search for Reward assignment with a timestamp?


  • admin

    @nixxda No, you can not (as far as i know) ... you have to scan all pools incoming or miners outgoing transactions, identify reward assignment transactions and build a lookup :-)

    If a miner was on a pool for a month, and changed pool in the day you want to track, you can only find his previous pool by searching for his previous reward assignment, that was a month ago ...

    So the perfect way would be to collect all data since block 0 into a database and update that with every new block ... problem here, what if you run into a fork ... all you data would be corrupted :-)


  • admin

    @nixxda You can start at block X for the Day - get the account that forged it, then get that accounts transactions of type 20 ( http://localhost:8125/burst?requestType=getAccountTransactions&account=17250039689296678890&type=20 ) then parse that to figure out where they were when the block was forged.



  • I think I understand it now.
    Rather then checking for Assignment and then Blocks do it the other way around and check every Block for Assignment!?
    And have a list of "Block at Pool" for all Blocks you've checked in the end.
    nice!

    I'm down to ~360 doing it manually!-) and perfect!



  • @Lexicon finally time to fully digest your answer!
    and if I understand that right your doing exactly what we have been talking about down here and not only for your pool!?
    sorry didn't get that at first!
    What I dont understand is the Reward at the end! way back?? but you can't really "backtest" only log at current time?!