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.
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 316. (Read 2591971 times)
August 09, 2014, 11:25:45 AM
August 09, 2014, 09:55:19 AM
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
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
August 09, 2014, 09:50:16 AM
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
August 09, 2014, 09:45:58 AM
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
August 09, 2014, 09:43:45 AM
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.
August 09, 2014, 09:37:27 AM
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
August 09, 2014, 09:10:08 AM
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
?? will leave there for a bit longer hitting a block value also the node diff it rising pretty fast August 09, 2014, 08:58:48 AM
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
August 09, 2014, 08:45:08 AM
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 ?
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 sharesAs 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
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 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
August 09, 2014, 08:38:34 AM
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 ?
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 sharesAs 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
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 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.
August 09, 2014, 08:35:57 AM
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 ?
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 sharesAs 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
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 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
Code:
Difficulty * 2**32 / hashrate = 3600
August 09, 2014, 08:19:06 AM
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 ?
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 sharesAs 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
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 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/
August 09, 2014, 08:14:55 AM
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 ?
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 sharesAs 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
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 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
August 09, 2014, 08:04:32 AM
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 ?
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 sharesAs 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
But what about the share value the user has set at a diff of 19.7 g it is worth more than a normal 6mil one in terms of payout.... If a user was to set at 19.7 g = a 25 btc value They would have to be credited all shares for the round to match the shares worth that they had set via the manual diff
?? eg the same as the example above re the 6mil to 12 mil share where ya set a higher diff the share value rises in terms of payout value of the shares vs a lower share put in August 09, 2014, 07:53:27 AM
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 ?
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 sharesAs 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
August 09, 2014, 05:59:22 AM
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 ?
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 sharesAs 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
August 09, 2014, 05:49:09 AM
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 ?
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.
August 09, 2014, 05:29:34 AM
Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!! 
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
there a major flaw in the P2 system
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
Lmao not trolling lol just asking a bloodly good question what to stop a couple farms from taking over the p2 network
? Based on that flaw as if I am right here and that manual diff setting will allow for the current btc block value to be set (so grabbing all the shares for the block) they in theory could over run the P2 network to the point they play with the share value and lift that to the point no smaller miner could hit over a short space of time if this is correct......No. The only time that p2pool is at risk from the actions of a large miner is if that miner has > 50% of the p2pool network, regardless of share difficulty.
If you are asking for information, please do so in a less inflammatory way.
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 ? August 09, 2014, 05:14:44 AM
Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
there a major flaw in the P2 system
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
Lmao not trolling lol just asking a bloodly good question what to stop a couple farms from taking over the p2 network
? Based on that flaw as if I am right here and that manual diff setting will allow for the current btc block value to be set (so grabbing all the shares for the block) they in theory could over run the P2 network to the point they play with the share value and lift that to the point no smaller miner could hit over a short space of time if this is correct......No. The only time that p2pool is at risk from the actions of a large miner is if that miner has > 50% of the p2pool network, regardless of share difficulty.
If you are asking for information, please do so in a less inflammatory way.
August 09, 2014, 04:39:33 AM
Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
there a major flaw in the P2 system
WTF do you care? You're not mining here anyway, stop trolling this thread & concentrate on your own pool, shills/fake accounts are a sad ghash.io tactic.
Ignored & Sod off.
Lmao not trolling lol just asking a bloodly good question what to stop a couple farms from taking over the p2 network
? Based on that flaw as if I am right here and that manual diff setting will allow for the current btc block value to be set (so grabbing all the shares for the block) they in theory could over run the P2 network to the point they play with the share value and lift that to the point no smaller miner could hit or would have a hard time hitting over a short space of time if this is correct...... Jump to: