Page 1 of 1

merged mining v2, MM2

Posted: Mon Jan 04, 2016 4:04 pm
by phelix
There is a hardfork coming up: Changing merge-mining format for BIP9

Maybe we should use it to also implement MM2. This would allow P2Pool mining with reasonable income variance.

https://github.com/p2pool/p2pool/issues/265

https://github.com/forrestv/mm2-spec

Can we reuse code from P2Pool / somewhere else?

Is it worth the effort?

edit: Just read the last meetings notes:
Probably don't worry about P2Pool's MM or other extra stuff, due to engineering effort and the imminent hardfork deadline
Well, it might be we don't get another chance for a long time...

Re: merged mining v2, MM2

Posted: Mon Jan 04, 2016 9:03 pm
by biolizard89
phelix wrote:There is a hardfork coming up: Changing merge-mining format for BIP9

Maybe we should use it to also implement MM2. This would allow P2Pool mining with reasonable income variance.

https://github.com/p2pool/p2pool/issues/265

https://github.com/forrestv/mm2-spec

Can we reuse code from P2Pool / somewhere else?

Is it worth the effort?

edit: Just read the last meetings notes:
Probably don't worry about P2Pool's MM or other extra stuff, due to engineering effort and the imminent hardfork deadline
Well, it might be we don't get another chance for a long time...
My personal take is that something like the P2Pool MM scheme is something that should be done very carefully with a lot of review. That's difficult on the timeline we have for BIP 9 compliance, IMHO.

Re: merged mining v2, MM2

Posted: Mon Jan 04, 2016 11:12 pm
by biolizard89
Also, last I heard, P2Pool was coded in Python, while an implementation for Namecoin would have to be in C++. So unless I'm unaware of something, it wouldn't really be feasible to reuse the code in Namecoin. Curious what Daniel thinks about the topic.

(Sorry for double post.)

Re: merged mining v2, MM2

Posted: Tue Jan 05, 2016 5:38 pm
by domob
I don't know too much about what exactly the benefits and (more importantly) the implementation challenges for P2Pool "MMv2" are. 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.

Re: merged mining v2, MM2

Posted: Fri Jan 08, 2016 5:35 pm
by phelix
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")
h.digest()
print "h:", h.length, h.hexdigest()

h0 = sha256.sha256(16 * "abcdefgh")
h0.digest()
midstate = h0.state

h1 = sha256.sha256(16 * "ijkl", _=(midstate, '', 1024))
h1.digest()
print "h0 midst & h1:", h1.length, h1.hexdigest()

# output:
# >>> h: 1024 e0c966e85c4beb151661ef2ef4159ce654550e12a4edb399cb34ea77a3d86991
# >>> h0 midst & h1: 1024 e0c966e85c4beb151661ef2ef4159ce654550e12a4edb399cb34ea77a3d86991

Re: merged mining v2, MM2

Posted: Fri Jan 08, 2016 7:37 pm
by domob
Ah yes, I recall now - it was about the midstate compression. This seems to be a nice trick and I think it is used by some other coins and applications; but I cannot really comment on its security implications, as I'm not a cryptography expert. I guess that such "hacks" tend to potentially weaken tried crypto basics.

Re: merged mining v2, MM2

Posted: Sat Jan 09, 2016 12:52 pm
by phelix
domob wrote:Ah yes, I recall now - it was about the midstate compression. This seems to be a nice trick and I think it is used by some other coins and applications; but I cannot really comment on its security implications, as I'm not a cryptography expert. I guess that such "hacks" tend to potentially weaken tried crypto basics.
Actually I think this is rather safe. Of course I am no crypto expert.

Just looked up the p2pool Bitcoin hashrate. It seems to be less than 1 block out of 500 :( . So even if we would implement it there would be virtually no benefit for us at this point.