[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[jonnybravo0311]

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??   And the higher the diff was set the higher the p2 diff would become ?

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 ?   So that would mean their hit all 3000 odd shares at once YES??   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 ??  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

[fire000]

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??   And the higher the diff was set the higher the p2 diff would become ?

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 ?   So that would mean their hit all 3000 odd shares at once YES??   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 ??  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/   

[jonnybravo0311]

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??   And the higher the diff was set the higher the p2 diff would become ?

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 ?   So that would mean their hit all 3000 odd shares at once YES??   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 ??  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

Setting /# has value, but that value is of diminishing returns.  Let's say we want to find a share every hour.  To do so, we can easily figure out what to set our difficulty to with the following formula:

Code:

Difficulty * 2**32 / hashrate = 3600

As you can see, as your hash rate goes up, your difficulty must correspondingly go up to maintain the 3600 second share time.  You can also see that if I maintain a steady hash rate, but keep increasing my difficulty, the time to find a share is also increased.  Let's see a couple of examples.  Right now, p2pool's minimum share difficulty is 5738910.21.  Let's assume I've got 10TH/s.  Plugging those numbers in to the formula, I find it would take me 0.685 hours to find a share.  Now, let's say I increase my share difficulty to 10,000,000.  It would take me 1.193 hours to find a share.  Increase that share difficulty to 10,000,000,000 and it will take me 1193.046 hours (49.71 days).

[sconklin321]

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??   And the higher the diff was set the higher the p2 diff would become ?

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 ?   So that would mean their hit all 3000 odd shares at once YES??   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 ??  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.

[fire000]

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??   And the higher the diff was set the higher the p2 diff would become ?

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 ?   So that would mean their hit all 3000 odd shares at once YES??   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 ??  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]

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]

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 ??    will leave there for a bit longer hitting a block value also the node diff it rising pretty fast

[fire000]

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]

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.

[fire000]

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]

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...

[fire000]

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]

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.

[fire000]

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]

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

[fire000]

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]

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....   

[jonnybravo0311]

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).

[squashpile]

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).

[fire000]

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