Bitcoin Forum
December 05, 2016, 10:33:30 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 [500] 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029984 times)
sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
August 09, 2014, 01:38:34 PM
 #9981

think ya missed the point above will try this a different way....    Lets look at the current hash on the pool

http://p2pool.info/

and lets say the top 10-15 users were set all to the current BTC block as their diff which via the manual override would they not control the share diff on P2 as they would hitting most of the blocks and grabbing all the shares due to the diff setting on their miners of the btc block?Huh?   And the higher the diff was set the higher the p2 diff would become Huh?

OK. Provide me a proof and I'll take your concerns seriously.



It a bit hard to gave proof without a farm lol.....     But if that manual diff override is able to be set at the current block diff eg 19.7g   and a user hit at that diff they in theory would be the only share for that block as the system would have to credit them all the shares to gave them the full pay out right Huh?   So that would mean their hit all 3000 odd shares at once YES?Huh?   Now if this was applied to all these 10 -15 miners which would be hitting a high number of the blocks they would send the diff flying due to rapid hitting of them shares


As the higher you lift that manual diff above the min share value the higher your payout is per share as it worth more than the min share eg lets say the min diff share is atm 6mil  and worth .010   to the miner<<<<    a share that was set at 12mil via the manual diff would be worth twice more than a 6mil share to a miner so their share would be .020 as they have hit x 2 min shares so they basically put 2 shares in at once which in theory effects diff straight up as the p2 would have to adjust for them 2 shares at once rather than 1
Short answer is your theory is incorrect.  Even if a miner sets their share difficulty to 19.7G other miners are still finding shares and adding them to the chain.  When any miner finds a block... Either the miner who set his difficulty to 19.7G or one who hasn't, the block finder gets 0.125BTC for that share.

But what about the share value the user has set  a 19.7 g share is worth more than a 6mil one in terms of payout....    If a user was to set at 19.7 g   They would have to be credited all shares for the round to match the shares worth Huh??  eg the same as the example above re the 6mil to 12 mil share
They wouldn't.  The miner who sets his share difficulty to 19.7G will only have a single share on the chain - the one that found the block of BTC.  That share is paid out at 1/200 of the block reward (1/200 of 25BTC is 0.125BTC).  The remaining shares on the chain are given the other 199/200 of the reward.  Here's the payout code that proves this:
Code:
weights, total_weight, donation_weight = tracker.get_cumulative_weights(previous_share.share_data['previous_share_hash'] if previous_share is not None else None,
max(0, min(height, net.REAL_CHAIN_LENGTH) - 1),
65535*net.SPREAD*bitcoin_data.target_to_average_attempts(block_target),
)
assert total_weight == sum(weights.itervalues()) + donation_weight, (total_weight, sum(weights.itervalues()) + donation_weight)

amounts = dict((script, share_data['subsidy']*(199*weight)//(200*total_weight)) for script, weight in weights.iteritems()) # 99.5% goes according to weights prior to this share
this_script = bitcoin_data.pubkey_hash_to_script2(share_data['pubkey_hash'])
amounts[this_script] = amounts.get(this_script, 0) + share_data['subsidy']//200 # 0.5% goes to block finder
amounts[DONATION_SCRIPT] = amounts.get(DONATION_SCRIPT, 0) + share_data['subsidy'] - sum(amounts.itervalues()) # all that's left over is the donation weight and some extra satoshis due to rounding

if sum(amounts.itervalues()) != share_data['subsidy'] or any(x < 0 for x in amounts.itervalues()):
    raise ValueError()

dests = sorted(amounts.iterkeys(), key=lambda script: (script == DONATION_SCRIPT, amounts[script], script))[-4000:] # block length limit, unlikely to ever be hit

So it the above is true THAT /# command it a waste of time even set above the current share value as it will not PAY higher than the current min share off this theory ??   going to test something on an alt coin to see what happens when the manual diff is set to the block brb and how P2 does treat a block diff in relation to pay out etc

p2pool weights all the shares based on difficulty submitted, so as the share value goes up so does the weight of your share.  That's why you can't calculate your payment based on # shares/total shares, you would need to know your total weighted share vs the total of all weighted shares on the chain.
1480934010
Hero Member
*
Offline Offline

Posts: 1480934010

View Profile Personal Message (Offline)

Ignore
1480934010
Reply with quote  #2

1480934010
Report to moderator
1480934010
Hero Member
*
Offline Offline

Posts: 1480934010

View Profile Personal Message (Offline)

Ignore
1480934010
Reply with quote  #2

1480934010
Report to moderator
1480934010
Hero Member
*
Offline Offline

Posts: 1480934010

View Profile Personal Message (Offline)

Ignore
1480934010
Reply with quote  #2

1480934010
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480934010
Hero Member
*
Offline Offline

Posts: 1480934010

View Profile Personal Message (Offline)

Ignore
1480934010
Reply with quote  #2

1480934010
Report to moderator
1480934010
Hero Member
*
Offline Offline

Posts: 1480934010

View Profile Personal Message (Offline)

Ignore
1480934010
Reply with quote  #2

1480934010
Report to moderator
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 01:45:08 PM
 #9982

think ya missed the point above will try this a different way....    Lets look at the current hash on the pool

http://p2pool.info/

and lets say the top 10-15 users were set all to the current BTC block as their diff which via the manual override would they not control the share diff on P2 as they would hitting most of the blocks and grabbing all the shares due to the diff setting on their miners of the btc block?Huh?   And the higher the diff was set the higher the p2 diff would become Huh?

OK. Provide me a proof and I'll take your concerns seriously.



It a bit hard to gave proof without a farm lol.....     But if that manual diff override is able to be set at the current block diff eg 19.7g   and a user hit at that diff they in theory would be the only share for that block as the system would have to credit them all the shares to gave them the full pay out right Huh?   So that would mean their hit all 3000 odd shares at once YES?Huh?   Now if this was applied to all these 10 -15 miners which would be hitting a high number of the blocks they would send the diff flying due to rapid hitting of them shares


As the higher you lift that manual diff above the min share value the higher your payout is per share as it worth more than the min share eg lets say the min diff share is atm 6mil  and worth .010   to the miner<<<<    a share that was set at 12mil via the manual diff would be worth twice more than a 6mil share to a miner so their share would be .020 as they have hit x 2 min shares so they basically put 2 shares in at once which in theory effects diff straight up as the p2 would have to adjust for them 2 shares at once rather than 1
Short answer is your theory is incorrect.  Even if a miner sets their share difficulty to 19.7G other miners are still finding shares and adding them to the chain.  When any miner finds a block... Either the miner who set his difficulty to 19.7G or one who hasn't, the block finder gets 0.125BTC for that share.

But what about the share value the user has set  a 19.7 g share is worth more than a 6mil one in terms of payout....    If a user was to set at 19.7 g   They would have to be credited all shares for the round to match the shares worth Huh??  eg the same as the example above re the 6mil to 12 mil share
They wouldn't.  The miner who sets his share difficulty to 19.7G will only have a single share on the chain - the one that found the block of BTC.  That share is paid out at 1/200 of the block reward (1/200 of 25BTC is 0.125BTC).  The remaining shares on the chain are given the other 199/200 of the reward.  Here's the payout code that proves this:
Code:
weights, total_weight, donation_weight = tracker.get_cumulative_weights(previous_share.share_data['previous_share_hash'] if previous_share is not None else None,
max(0, min(height, net.REAL_CHAIN_LENGTH) - 1),
65535*net.SPREAD*bitcoin_data.target_to_average_attempts(block_target),
)
assert total_weight == sum(weights.itervalues()) + donation_weight, (total_weight, sum(weights.itervalues()) + donation_weight)

amounts = dict((script, share_data['subsidy']*(199*weight)//(200*total_weight)) for script, weight in weights.iteritems()) # 99.5% goes according to weights prior to this share
this_script = bitcoin_data.pubkey_hash_to_script2(share_data['pubkey_hash'])
amounts[this_script] = amounts.get(this_script, 0) + share_data['subsidy']//200 # 0.5% goes to block finder
amounts[DONATION_SCRIPT] = amounts.get(DONATION_SCRIPT, 0) + share_data['subsidy'] - sum(amounts.itervalues()) # all that's left over is the donation weight and some extra satoshis due to rounding

if sum(amounts.itervalues()) != share_data['subsidy'] or any(x < 0 for x in amounts.itervalues()):
    raise ValueError()

dests = sorted(amounts.iterkeys(), key=lambda script: (script == DONATION_SCRIPT, amounts[script], script))[-4000:] # block length limit, unlikely to ever be hit

So it the above is true THAT /# command it a waste of time even set above the current share value as it will not PAY higher than the current min share off this theory ??   going to test something on an alt coin to see what happens when the manual diff is set to the block brb and how P2 does treat a block diff in relation to pay out etc


The coin I will do a test on will be XJO will dump the payout address here when I have the wallet downloaded I will be setting the miner to a diff of 40 k which is will above the current block diff it will be intersting to see how a P2 treats a share that is set to the block diff manually the pool I will be using is as follows http://xjo.e-pool.net:8930/static/  


The addy for this little test is JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2   it will be intersting to see how it pays out and treats them shares that a block hits when set via a manual diff and how it effects the diff on the p2 node with shares been put in at block value
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 01:58:48 PM
 #9983

hmmm that intersting the 1st block I hit on a diff above the xjo current block diff just sent the nodes diff flying up will see what happens after a few more hits on blocks
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 02:10:08 PM
 #9984

hmmm now I am getting up to speed and through the blocks notice the payout now out doing the a rig the same size as I am on due to the high value shares Huh??    will leave there for a bit longer hitting a block value also the node diff it rising pretty fast
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 02:37:27 PM
 #9985

hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks   which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate.    as stated there a flaw in the p2 system if i can do that by just turn the manual diff up as this test is proving quite well   
jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 02:43:45 PM
 #9986

hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks   which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not.

EDIT: I am watching, and the experiment you're running is quite interesting, especially looking at the predicted payouts for each miner.  Last I saw, miner 1 has a payout over 11, and miner 2 has a payout about 4.5.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 02:45:58 PM
 #9987

hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks   which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not.

It not only the block finder reward at play here as it treating me as it I am solo mining atm in terms of the reward   based on a ppnls payout system over a number of rds  <<<< so it paying the 16 coins over a few rds
jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 02:50:16 PM
 #9988

hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks   which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not.

It not only the block finder reward at play here as it treating me as it I am solo mining atm in terms of the reward   based on a ppnls payout system over a number of rds  <<<< so it paying the 16 coins over a few rds
I edited my post... I'm keeping an eye on your experiment.  It will be quite interesting to see how it plays out over time.  Each share miner 1 is adding to the chain is also a block finder.  Very interesting indeed...

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 02:55:19 PM
 #9989

hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks   which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not.

It not only the block finder reward at play here as it treating me as it I am solo mining atm in terms of the reward   based on a ppnls payout system over a number of rds  <<<< so it paying the 16 coins over a few rds
I edited my post... I'm keeping an eye on your experiment.  It will be quite interesting to see how it plays out over time.  Each share miner 1 is adding to the chain is also a block finder.  Very interesting indeed...

Yep miner 1 is me on the manual diff of 40k which are blocks for that coin but ya can see how I am destorying this guys earnings by JUST setting that diff even running at roughly the same hash as him....  where in theory it should be a 50/50 split but it treating the shares I am putting in as blocks and paying out all shares to me for those blocks been put into the chain as they carry a high weight in terms of vaule and that one share has to pay out as 16 coin over the pplns
squashpile
Full Member
***
Offline Offline

Activity: 125


View Profile WWW
August 09, 2014, 04:25:45 PM
 #9990

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.

SquashPool - 0% Fee - Dedicated P2Pool VPS - Atlanta, GA - SSD - Gig uplink
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 04:30:45 PM
 #9991

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm where the effects of using that diff setting can be seen clear as days and the effect it has on earnings if it set higher that the min share value.
squashpile
Full Member
***
Offline Offline

Activity: 125


View Profile WWW
August 09, 2014, 04:32:55 PM
 #9992

So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this.

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm

SquashPool - 0% Fee - Dedicated P2Pool VPS - Atlanta, GA - SSD - Gig uplink
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 04:36:50 PM
 #9993

So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this.

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm

the /#   needs to be above the current diff on the node for the share....    So for example if the current diff is say 5500000 a share that setting needs to above that number so for example that /#    would need to be set at /5500001 <<<< or higher    the higher that number the more value the share will carry....    


Just a footnote you will hit less shares BUT they carry a higher weigth to them as they are above the min share value and it adjusts the payments to match the value of the shares you are putting as can be seen over on that test
squashpile
Full Member
***
Offline Offline

Activity: 125


View Profile WWW
August 09, 2014, 04:39:02 PM
 #9994

Hey thanks for the info..
So currently I'm showing 5202394.44 share diff on the pool. I should try something like /5203000 and just keep an eye on the current diff for adjustment?


So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this.

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm

the /#   needs to be above the current diff on the node for the share....    So for example if the current diff is say 5500000 a share that setting needs to above that number so for example that /#    would need to be set at /5500001 <<<< or higher    the higher that number the more value the share will carry....   

SquashPool - 0% Fee - Dedicated P2Pool VPS - Atlanta, GA - SSD - Gig uplink
jonnybravo0311
Hero Member
*****
Offline Offline

Activity: 994


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 05:09:05 PM
 #9995

Hey thanks for the info..
So currently I'm showing 5202394.44 share diff on the pool. I should try something like /5203000 and just keep an eye on the current diff for adjustment?


So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this.

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm

the /#   needs to be above the current diff on the node for the share....    So for example if the current diff is say 5500000 a share that setting needs to above that number so for example that /#    would need to be set at /5500001 <<<< or higher    the higher that number the more value the share will carry....   
There's really no need.  In a nutshell, here's the deal:

Setting your share difficulty to anything LESS than the p2pool minimum is pointless.  You can't submit a share to the chain that does not meet the minimum difficulty requirement.
Setting your share difficulty to anything MORE than the p2pool minimum will mean you expect to find fewer shares, but when you do the share is weighted more (i.e. it's worth more).

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
squashpile
Full Member
***
Offline Offline

Activity: 125


View Profile WWW
August 09, 2014, 05:12:35 PM
 #9996

Yeah.. that's what I'm starting to finally come to terms with. Just leave it alone. Just hard watching lucky miners with twice the payouts and less HR. I just need to stop looking I guess.
0.04217808 so far today with under 1TH/s is pretty damn good/lucky.

My best share on one s3 in the last 24hrs is 1.5 million LMAO. My undervolted S1 is better.


Hey thanks for the info..
So currently I'm showing 5202394.44 share diff on the pool. I should try something like /5203000 and just keep an eye on the current diff for adjustment?


So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this.

Pardon my dumb, but how are you setting this diff Fire000? example please?

One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.


via the manual override command example    server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x

do not worry about the address bit as that a non btc address   the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value.....     Now if you hit at the high diff you have set it will carry more weight that the lower default diff....    As can be seen over on the pool I have a miner sitting on atm

the /#   needs to be above the current diff on the node for the share....    So for example if the current diff is say 5500000 a share that setting needs to above that number so for example that /#    would need to be set at /5500001 <<<< or higher    the higher that number the more value the share will carry....    
There's really no need.  In a nutshell, here's the deal:

Setting your share difficulty to anything LESS than the p2pool minimum is pointless.  You can't submit a share to the chain that does not meet the minimum difficulty requirement.
Setting your share difficulty to anything MORE than the p2pool minimum will mean you expect to find fewer shares, but when you do the share is weighted more (i.e. it's worth more).

SquashPool - 0% Fee - Dedicated P2Pool VPS - Atlanta, GA - SSD - Gig uplink
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 10, 2014, 04:05:06 AM
 #9997

after that test last night and letting all the payouts roll into that address there appears to be yet another flaw in the p2 system if one sets to the block diff on a coin....    

if you look at that address above it has been credited 269 coins based on 12 shares I put in which all where blocks now simple maths 12 * 16 = 192 coins    so off that I have been overpaid about 78 coins.... (feel sorry for the other user that was on the node at the time on the same hash rate as I have taken this guys earnings)   <<<<< this can not be the block finders bounus as I was the only share in the block so no matter what the payout = 16 coins as the bonus comes from the block I will rerun the test in the next day or so and screen shot it and gave the miner rig stats so people can see the block finds vs payout address and also will screen shot the node to show what effect it has on other miners on the node running at the same speed etc in terms of their payouts as afew seen last night while I was doing the live test there was a massive different in the payouts between a user putting in shares at the min share rate and myself only putting shares in at blocks via the manual diff setting
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
August 10, 2014, 09:02:38 AM
 #9998

Ure wrong, because not every share have same power - it depends on pool power.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 10, 2014, 09:49:43 AM
 #9999

Ure wrong, because not every share have same power - it depends on pool power.

Wait for the screen shots it will blow people away....   There a flaw in the payout system on the p2 network as a few seen 1st hand last night while I was running the live test as the comments over the last page or so highlight.....  

2 Rigs hashing at the same speed....   there was a massive difference in the payouts 1 was me hashing on the block diff   and the other was joe bloggs the public on a min share diff....    At one stage there the payouts I was getting were well over double the other user so 100 percent higher and at no time in the 6 hour test did my payout fall below the other users most of the time they were between 70 -100 percent higher than that of the other user hashing at the same rate as me..... so in theory it should of been a 50/50 split not what the results showed if even surpised me how much the difference was in the payouts between the miners

Anyone can test this on a ALT coin and see it 1st hand what that manual overwrite does to the p2 in terms of payouts and having it set to only put blocks in as shares vs a user running at the node min diff,


IT also backs the claim up that if a user was to set to the block diff there is only 1 share for that block as the system would have to pay out the block value to the user if they were set to 19.7g and hit as they would have to be paid =25 btc over the ppnls to reward them for that 1 share that they have set as their diff as at 19.7g that equals 25 btc in terms of payout value on that one share....    They also see more that the 25 btc as they collect in the other rds while those shares disappear...   As highlighted in the payout numbers and the earning diffence between the 2 users on the test I did last night on an alt
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 10, 2014, 11:09:00 AM
 #10000

Ure wrong, because not every share have same power - it depends on pool power.

Wait for the screen shots it will blow people away....   There a flaw in the payout system on the p2 network as a few seen 1st hand last night while I was running the live test as the comments over the last page or so highlight.....  

2 Rigs hashing at the same speed....   there was a massive difference in the payouts 1 was me hashing on the block diff   and the other was joe bloggs the public on a min share diff....    At one stage there the payouts I was getting were well over double the other user so 100 percent higher and at no time in the 6 hour test did my payout fall below the other users most of the time they were between 70 -100 percent higher than that of the other user hashing at the same rate as me..... so in theory it should of been a 50/50 split not what the results showed if even surpised me how much the difference was in the payouts between the miners

Was this alt coin using the standard 3 day PPLNS system?  If so, a 6 hour test isn't a fair comparison.  They should even out over time, and I don't think 6 hours is long enough.

Quote
Anyone can test this on a ALT coin and see it 1st hand what that manual overwrite does to the p2 in terms of payouts and having it set to only put blocks in as shares vs a user running at the node min diff,


IT also backs the claim up that if a user was to set to the block diff there is only 1 share for that block as the system would have to pay out the block value to the user if they were set to 19.7g and hit as they would have to be paid =25 btc over the ppnls to reward them for that 1 share that they have set as their diff as at 19.7g that equals 25 btc in terms of payout value on that one share....    They also see more that the 25 btc as they collect in the other rds while those shares disappear...   As highlighted in the payout numbers and the earning diffence between the 2 users on the test I did last night on an alt

That's an interesting theory.  It means if everyone did it, we'd all be solo mining.  It also means until you get that block size share, you won't get anything.  You could go years without a payout.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Pages: « 1 ... 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 [500] 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!