Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 757. (Read 2591916 times)

Actually, you can just try it or read the following commit message:


A little bug in connection with that: in the graphs I now have two entries for my miner, one "minername" and one "minername+10".

No because the process is this
1) your miner tells p2pool daemon what difficulty share it would like to look for (it must be min diff or higher)
2) p2pool PUTS THE DESIRED SHARE TARGET DIFFICULTY INTO THE COINBASE.
3) p2pool creates the block header (which contains a merkle root hash and thus coinbase hash and thus the coinbase values including the desired difficulty
4) miner hashes nonces using values from #3 and finds a share (say it happens to be a difficulty 80,000 share).
5) miner can only submit it ias the difficulty requested in #1 because every other node verifies the work done by every node.
6) if miner "cheats" and alters the share difficulty then the hash is invalid.  Changing the coinbase changes the block header and the new block header combined w/ nonce doesn't produce a valid share hash.

One thing to add: only step #1 is new.  Steps #2 to #6 have always existed and must exist to prevent cheating as a client could always hack the code.  Proper difficulty reporting can never be based on the client.

Once again since it seems difficult point (bolder part is the most important).

When you request a difficulty X p2pool doesn't trust you at all.  It assumes you likely will try to cheat (as it should in an untrusted environment).  So p2pool PUTS THE REQUESTED SHARE DIFFICULTY INTO THE COINBASE.  Thus the difficulty you requested becomes part of the hash and part of the share when found.  Once found a share is ONLY useful at that difficulty.  If you increased the difficulty then the coinbase changes and thus the merkle root and thus the block header.  So the nonce you found doesn't produce a valid share.

p2pool nodes assume every other node is cheating.  They don't trust anything another node says until they verify it. Yet that means for every single share found every single other node "rebuilds" the share from scratch (just like a conventional pool does) to ensure the share is valid.  If you alter the coinbase after the fact then the share is invalid and it gets rejected by every node.

One thing I would add is that this protection HAS ALWAYS EXISTED IN p2pool.  Remember p2pool difficulty is consantly varying and each share can have different difficulty anyways.  The only valid method to protect the network is for each node to rebuild and verify the shares submitted. 

The target difficulty is apparently encoded in the coinbase to stop people from doing that.

Still, you could have 10 miners, which all mine with 10MH/s and requesting different difficulty work. Like 600, 700, 1000, 10000 etc. These 10 miners would together have 100MH/s hashing power.
Besides those 10, you have one big miner (or farm) which hashes with big hashing power. When a block is found, the block is forwarded to one of the 10 miners, depending on which target was solved. If the solved block has a 1150 difficulty, it is forwarded to the "I requested 1000 difficulty"-miner, who receives the payout.

So, I believe the stated solution works only for people who use one miner only.

Ente

I had read it, but apparently misunderstood it. Sorry.

So basically 9x650 + 1x13000 == 10x650 if you have diff set at 650, got it.

This was just discussed at length.  Go back a page or two, or skip right to the conclusion.

9*650 + 1x130000 = 18850
18850 / 650 = 29
29 * 0.002 = 0.058

Why does Person A get 0.02?

Lets assume a diff=650 is worth something like ~0.002 BTC

Person A has default settings (diff~650) and starts hashing.
Person A finds 10 shares with diff > 650 (eg. 9x ~650 and one share ~13000) in 24h
There is one block found just now.
Person A get a payout of 0.02 BTC.

Person B sets diffuculty to 6500 and has same hasrate as person A
Person B found 1 shares > 6500 (eg. ~13000 ) in 24h
Person B gets a payout of ~0.02BTC

Person C is cheating and starts hashing.
Person C finds a share with difficulty 13000.
Person C connects and sets difficulty to 13000 and submits share.
Person C starts hashing with a new address.
Person C finds a share with difficulty 650.
Person C connects and sets difficulty to 650 and submits share.
Person C starts hashing with a new address.
Person C finds 8 more diff 650 shares in the same way.
Person C gets payed out to 10 different addresses 9x ~0.002 BTC and 1x ~0.04 BTC.

Only solution that comes to my mind is, that a user (identified by address) needs a history of maybe 12h before he can change his difficulty.

How would that be different from connecting as 1abcsomething, saying "I'm mining at difficulty 1" and then submitting the diff=650 and diff=1000 shares? Doesn't p2pool take the actual share difficulty into account when calculating payouts?

I hope the custom share difficulty can be set at node level (too)!
What would be sweet would be an option to change it at node level, as well as set a relative difficulty.
With a 10gh/s node, you could for example set the difficulty to "global + 30%", so it adjusts by itself whenever the share difficulty changes.

Now.. What would be the best difficulty for any node? For example 10 share-blocks per bitcoinblock?

If the node adjusts even to that (calculating from own hashing power in relation to whole p2pool as well as p2pool hashing power in relation to whole bitcoin), we would have a working solution for that whole variance problem?

Ente

Can someone explain, how the new "miners can volunteer to raise their share difficulty"-protocol change works? I don't understand how cheating is prevented.

Can't you just mine in secret and for example find a difficulty 1000 share, and then connect to the p2pool network and send: "hey, my address is 1abcsomething and I'm mining difficulty 1000 and here is a share"? And then afterwards mine in secret a difficulty 650 share and connect to the p2pool network and send: "My address is 1xyzsomethingdifferent and I'm mining difficulty 650 and here is a share"?

How can you define a difficulty in advance, if you can simply reconnect with a new identity?

I'm sure I'm missing something here. Please enlighten me

He did say the miners' username, not the node's username, which makes me think it's set at the miner level.

I guess we need a clarification for this ^^ ...

Dia

Hi!

 Since day 27 feb 2012, the patron_sendmany stops working for me... Just now I take notice of it...

 Look:

$ wget -O- http://192.168.10.1:9332/patron_sendmany?total=2.0 | more
--2012-03-06 02:08:05--  http://192.168.1.235:9332/patron_sendmany?total=200
Connecting to 192.168.1.235:9332... connected.
HTTP request sent, awaiting response... 200 OK
Length: 50 [text/plain]
Saving to: `STDOUT'

100%[===============================================================================================================================>] 50          --.-K/s   in 0s     

2012-03-06 02:08:05 (4.23 MB/s) - written to stdout [50/50]

need total argument. go to patron_sendmany/


 For both Bitcoin 9332 and Litecoin 9327 I got this...

 Any tip!?

Thanks!
Thiago

heh yeah I just changed that as you posted

Correction:
you can choose any share difficulty >= target difficulty and they will be valid in the share chain.

So ... what it also means is you can choose a share difficulty of whatever you like whenever you like and matching shares will now always be valid in the share chain ... as long as they are above the currently defined share difficulty.

So ... for him yes and yes for you no and no.

I was refering to the p2pool target not bitcoin target.  Obviously bitcoin diff is in the bitcoin header but that has nothing to do w/ p2pool allowing variable diff shares.

p2pool puts various pieces of data into the coinbase otherwise creating fake shares of higher difficulty would be trivial.

say p2pool difficulty is 500 and thus all shares of diff 500 are worth 500 "points" not 1 share.  I say point because since share diff is always changing p2pool doesn't split reward by # of shares it splits them by weighted workshare = # of shares * share difficulty.   Remember diff is constantly changing thus p2pool can't count all shares as equal otherwise a share when target is 400 = share when target is 500. 


If there was nothing put into the block header one could easily (I mean about 15 seconds of code changing) cheat the entire network by massive proportions.  When you find a share simply modify the share chain data to reflect diff as found not diff as trying.  So if you find a 500 diff share submit it as a 500 diff share.  If you find a 50,000 dif share submit it as a 50,000 dif share (worth 100x as much).  It doesn't take a rocket scientist to realize one could get 99.9999999% of the reward on every single block by cheating.

p2pool prevents this by choosing a share diff BEFORE hashing and encoding this in the coinbase.  Thus if you are looking for a 500 dif share and find one you can't "spoof" the network by sumbitting it as a 50,000 dif share because when validating each node will be unable to recreate the proper block hash and the share will be found invalid.   A share w/ target of 500 not can never be worth more than 500. 

TL/DR version:
Via the coinbase value p2pool encodes the diff of the share being searched.
If you are looking for a share of x diff it is only worth x.