Algorithm for Ninja style mining pool block share assignment


  • admin

    @AngryChicken to just read the files, Notepad or Textpad or any other text editor will work. Compiling the code, yeah, that's a whole different challenge.



  • @haitch Yea, you could edit in notepad but then the text assist wouldn't be their to help generating/recommending code. But yea Compiling without an IDE (Which pre installs all the redistributes required to run and compile the code would be a huge pain). I just always recommend using a Full IDE when editing rather than bear bones editors as they provide more than a click to compile.



  • Just to view the files notepad++ is excellent, it will structure and colour the C++ Code to make it more readable.

    https://notepad-plus-plus.org/

    Rich



  • Thanks, @AngryChicken , @haitch and all those who helped in this thread.

    For those interested, I was actually able to see the shares calculation by looking at the javascript of the share-curve.html file in the build subdirectory. I really don't know this language but it was pretty easy to see what was going on.

    It appears that all miner deadlines are summed. Each miner's share is the total of all deadlines submitted/the individual miner's deadline. Then the % share is calculated by the miner's share/total shares.

    I checked this against actual data from random blocks on both burst.ninja and pool.burstcoin.biz. Although not exactly as I determined from this source code, there is a very high correlation. It appears that the actual pools are skewing the rewards curve slightly in favor of the top, best deadlines for each block. Anyway, my curiosity is satisfied, and I thought it best to post this for anyone else to see.


  • admin

    @rds I do recall there was a skew added to the deadlines so that the top deadlines - but the discussion about that was a couple of years ago and I don't recall the details.



  • It's at objects/Block.cpp line 110, the method called Block::recalculate_shares() and here's some simplified pseudo-code to explain it:

    sum_scaled_shares = 0
    
    for each account's best deadline (let's call this "deadline") {
        // because it's possible, but rare, to have a 0 deadline
        // and we don't want a divide by zero error later
        deadline += 1
      
        // deadline raised to the power of 1.2 (1.2 is set in pool's config file)
        scaled_share = pow(deadline, 1.2) 
    
        // SOME_BIG_INT is actually 0x7fffffffffffffff in the code
        scaled_share = SOME_BIG_INT / scaled_share
    
        sum_scaled_shares += scaled_share
    }
    

    So after this loop, each account's slice of the pie will be their "scaled_share" out of "sum_scaled_shares".
    As a dummy run, say you have 3 miners (a, b and c) with 3 deadlines ("0", "123" aka 2 minutes 3 seconds and "8125" aka 2 hours 15 minutes 25 seconds):

    a's "scaled_share" would be:

    0
    +1 = 1
    ^1.2 = 1
    0x7ffffffffffffffff/ = 0x7fffffffffffffff
    

    b's scaled_share would be:

    123
    +1 = 124
    ^1.2 = 325.16666
    0x7fffffffffffffff/ = 0x0064c5df25dc5f6c
    

    c's scaled_share would be:

    8125
    +1 = 8126
    ^1.2 = 49187.2091402907
    0x7fffffffffffffff/ = 0x0000aa8b645dc96b
    

    sum_scaled_shares = 0x7fffffffffffffff + 0x0064c5df25dc5f6c + 0x0000aa8b645dc96b = 0x8065706a8a3a28d6

    so as percentages:

    a: 0x7fffffffffffffff / 0x8065706a8a3a28d6 = 99.6914%
    b: 0x0064c5df25dc5f6c / 0x8065706a8a3a28d6 = 0.3066%
    c: 0x0000aa8b645dc96b / 0x8065706a8a3a28d6 = 0.0020%

    99.6914% + 0.3066% + 0.0020% = 100%



  • @catbref , thanks your pseudo code it much easier to understand.



  • @rds just a curiosity buddy: @catbref was the one writing the ninja code, back in the days, as i've been told... ;D


  • admin

    @gpedro He wrote the whole thing.



  • @catbref , props to you on your work.

    Two observations:

    1. It appears to me that the ^1.2 is the "skew" I referred to above, to reward miners with better deadlines? You said it's in the pool's config file, so each pool could have a different skew as they choose?

    2. When I first read your discussion, I couldn't understand why you used some_big_int to be the numerator for the scaled_share formula instead of sum_scaled_shares. Then I checked out both ways and they yield the same exact % result. Interesting! So then I took out a piece of paper and started scribbling some high school algebra and came to the conclusion some_big_int can actually be any non zero number, big or small, positive or negative, e.g. 1 and the share percentages remain the same. More interesting!!

    So enough discourse, this was very interesting and enlightening for me and I thank you.

    I should also say it is academic for me at this point, as I switched over to solo mining shortly after my original post :)


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.