domob wrote:I don't know too much about what exactly the benefits and (more importantly) the implementation challenges for P2Pool "MMv2" are.
Well, forrestv seems to be of the opinion that it is necessary to allow "non-solo" p2pool mining. As for the challenges I think it is relatively easy to implement* but more about "getting it right" and testing.
But I agree that we should try to keep it as simple as possible for now and the upcoming deadline, and I believe that the suggestion made above (force blocks to be merge-mined and use their nonce to keep the data) is what we should do.
That might be the wise thing to do
*I looked a bit into how the link to the PoW via the sha256 midstate is done. The principle is quite simple: you hash the first part of data, remember an intermediate value, then later continue from it with the second part of data. It is like stopping in between sha256 digest chunks and continuing later. If only the second part changes you don't need to hash everything again and again. It is also used for mining in some way. With merged mining the advantage is that you only need to store the midstate and the second part of the coinbase transaction in the Namecoin block header. This helps keep p2pool bandwidth low.
You need to have a modified sha256 that can output an unpadded midstate and also be initialized with it. IIUC it only works with 64byte blocks (sha256 digest size). Then you can do this:
Code: Select all
import sha256 # https://github.com/Rav3nPL/p2pool-yac/blob/master/p2pool/bitcoin/sha256.py
h = sha256.sha256(16 * "abcdefgh" + 16 * "ijkl")
print "h:", h.length, h.hexdigest()
h0 = sha256.sha256(16 * "abcdefgh")
midstate = h0.state
h1 = sha256.sha256(16 * "ijkl", _=(midstate, '', 1024))
print "h0 midst & h1:", h1.length, h1.hexdigest()
# >>> h: 1024 e0c966e85c4beb151661ef2ef4159ce654550e12a4edb399cb34ea77a3d86991
# >>> h0 midst & h1: 1024 e0c966e85c4beb151661ef2ef4159ce654550e12a4edb399cb34ea77a3d86991