Bitcoin Forum
December 11, 2016, 02:37:57 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 449 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 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035326 times)
CartmanSPC
Legendary
*
Offline Offline

Activity: 1148



View Profile WWW
August 08, 2014, 06:10:07 PM
 #9961

Someone go mine on http://minefast.coincadence.com with address/0 and see what it returns for your p2pool share diff.

You can see the result by going to your address details page here and looking at what is says under "Miner Share Difficulty":
http://minefast.coincadence.com/miner.php?id=[address]

Ex:
http://minefast.coincadence.com/miner.php?id=1Po4Fa4drFtaDZ2Rr51mVs26L9bADJqZBG


1481423877
Hero Member
*
Offline Offline

Posts: 1481423877

View Profile Personal Message (Offline)

Ignore
1481423877
Reply with quote  #2

1481423877
Report to moderator
1481423877
Hero Member
*
Offline Offline

Posts: 1481423877

View Profile Personal Message (Offline)

Ignore
1481423877
Reply with quote  #2

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

Posts: 1481423877

View Profile Personal Message (Offline)

Ignore
1481423877
Reply with quote  #2

1481423877
Report to moderator
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 06:33:13 PM
 #9962

I've done precisely that on my own node.  Which is why I started this whole thing to begin with... I want somebody to show me where in the code this happens.

Setting difficulty to /0:
Code:
2014-08-08 14:20:45.767005 New work for worker! Difficulty: 565.596240 Share difficulty: 5424434.245682 Total block value: 25.242381 BTC including 1461 transactions
Setting difficulty to /10000000:
Code:
2014-08-08 14:22:44.088361 New work for worker! Difficulty: 506.191697 Share difficulty: 10000044.116454 Total block value: 25.008233 BTC including 73 transactions

As you can see, it is obviously treating /0 the same as /1, /2, /256, /anything_under_p2pool_minimum.

So... now that I've spent freaking hours looking at this and arguing that it behaves differently, it has finally dawned on me why.  I'm thinking in terms of the RAW number value that is set.

Yes, the number is indeed set to 2**256-1 if you set your difficulty as /0.  However, that 2**256-1 means it's the EASIEST share, not the hardest.

Hopefully this answers it once and for all for everyone (ok, well it clears it up for me anyway), and I'm sorry I spent pages of this thread figuring that out.

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.
CartmanSPC
Legendary
*
Offline Offline

Activity: 1148



View Profile WWW
August 08, 2014, 06:40:33 PM
 #9963

It's all good man...were all here to help and support each other  Grin

jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 08, 2014, 06:48:41 PM
 #9964

It's all good man...were all here to help and support each other  Grin
You want to know when if finally clicked?  When I was evaluating that method.  I coded my own version and just printed results.  As expected, when I passed "0" to it, it gave me back the 2**256-1.  However, when I passed "1" to it, it then gave me some very large number as well.  When I saw that result, at first I didn't believe it, so I looked at it again, and like that proverbial lightbulb going on, I said to myself, "you freaking idiot, the larger the number the easier the share."

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.
bryonp
Member
**
Offline Offline

Activity: 77


View Profile
August 08, 2014, 11:56:57 PM
 #9965

O M G

After all that, can you advise what would be the right way to go???
/0   /1
or just leave it alone???
All of this on the ants??

Thanks...

mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 09, 2014, 12:28:00 AM
 #9966

O M G

After all that, can you advise what would be the right way to go???
/0   /1
or just leave it alone???
All of this on the ants??

Thanks...



I recommend leaving it alone.

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.
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
August 09, 2014, 01:20:46 AM
 #9967

so basically as said miles back in this whole topic lol

fire000/s0br - please go back to bigging up your own pool instead of trolling here. P2pool pays, unlike your mining.BitcoinAffiliatenetwork.com one:

I haven't been paid out by the pool for several days now, I sent a PM to s0ber last night to have a look at my account to see what's happening so far I have no reply from s0ber nor I have received any payments from the pool since 6th of AUG. Hey S0ber is the pool hacked?  

Peace  Wink

Don't feed the troll peeps.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 07:06:14 AM
 #9968

so basically as said miles back in this whole topic lol

fire000/s0br - please go back to bigging up your own pool instead of trolling here.
Quote
P2pool pays, unlike your mining.BitcoinAffiliatenetwork.com
one:

I haven't been paid out by the pool for several days now, I sent a PM to s0ber last night to have a look at my account to see what's happening so far I have no reply from s0ber nor I have received any payments from the pool since 6th of AUG. Hey S0ber is the pool hacked?  

Peace  Wink

Don't feed the troll peeps.

Right to state something here as this guy wants to look at one comment only in there lol a number of user have reported they are been paid with no issues BUT you will also notice the admin in following comments the admin had rewritten the payout system and the USER named above has been paided as they also state themsleves SO NICE TRY

Now to the second part of this

P2pool pays unlike you mining xxxxxxx one

A simple look at stats p2 vs xxxxx pool shows that in fact the xxxxx pool is outdoing P2 earning wise as it is hitting blocks at a better strike rate than p2 with just under the hash rate of the p2 pool  PS has been testing this for a few days now hence knowning what my DIFF 1 share rate is between the two miners P2 is NO where match a normal pool share rate ya may want to look at ya diff 1 shares vs ya diiff a shares if using an ant miner    

The diff 1 shares are what ya miner is mining at on a diff 1 (the correct earning rate for ya hash)    the diffa is the shares you have been paid for you will notice that diffa number in most cases well under the diff1 number due to the high share diff on p2 when it should read very close to the diff 1 number Smiley  which in turn is seeing normal pools killing p2 for earnings as ya not hitting paying shares on p2 enough to line up to the diff1 on your miner.    

To put this in sample form if your miner was to hit say 16 mil diff1 shares a day that diffA rate needs to be around that 16 mil as well if it is say 6.5 mil  only your rig had under paid for the day (happens alot on p2)   if it 16 mil you are on par with the rigs earnings .............   ESP on small rigs


Also hardy call it trolling when it was a fact state re the /0 command that it defaults to the min share diff as highlighted in the posts above this one so no matter if you use the /0 command or not it will make no diffence in you rig share unless set above the min share diff point as also highlighted above and stated pages back by myself...    So nice try....    These are just cold hard facts which anyone can test and see the results 1st hand


fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 09:03:32 AM
 #9969

just thinking about this /0 command I have a question re it if one was to set that at say 19.7 g so basically the current BTC diff how does that treat the payouts........    Cause in theory if a user was to hit  a 19.7g share (a btc block) there would only be 1 share to that block and the user should see the whole payout themselfs plus payout from the next few blocks due to the ppnls as the shares return to normal.....    so how does p2 treat this Huh?

As if my line is correct here there a major flaw in the P2 system which could see any big farm or a couple bring the P2 down by setting the manual overwrite to the BTC block value so therefore killing off the other normal shares for the block to the point ya would have to be hitting a btc block to be paid.........  or close to it if there was say 6 farms on p2 hitting blocks in a string as they would be grabbing all the shares and pushing that share value flying if they were set to the block value as their share rate
cathoderay
Sr. Member
****
Offline Offline

Activity: 379


Welcome to dogietalk.bs


View Profile
August 09, 2014, 09:19:21 AM
 #9970

Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!  Grin

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.

Have you been a victim of dogie insults, neg-rep'd for no reason or been falsely accused by him? If so, air your experiences here:  https://bitcointalk.org/index.php?topic=905210.0
Avoid manipulative Exchanges - Localbitcoins.com
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 09:39:33 AM
 #9971

Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!  Grin

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 Huh?  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......
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
August 09, 2014, 10:14:44 AM
 #9972

Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!  Grin

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


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 10:29:34 AM
 #9973

Woke up this morning to a nice little earner - that's 5 blocks inside 24 hours.....GET IN!!!  Grin

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 Huh?  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?Huh?   And the higher the diff was set the higher the p2 diff would become Huh?
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
August 09, 2014, 10:49:09 AM
 #9974

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.


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
fire000
Member
**
Offline Offline

Activity: 98


View Profile
August 09, 2014, 10:59:22 AM
 #9975

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
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 12:53:27 PM
 #9976

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.

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, 01:04:32 PM
 #9977

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  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 Huh??  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
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 01:14:55 PM
 #9978

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

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, 01:19:06 PM
 #9979

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/   
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 09, 2014, 01:35:57 PM
 #9980

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

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.
Pages: « 1 ... 449 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 ... 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!