Add extra commitment to prevent asicboost?

[chjj]

I haven't read this too closely, but if this is actually real we should take preventative measures: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html

We may need to add an extra commitment to the coinbase prevent asicboost.

cc @josephpoon @gasteve

[chjj]

If that's not possible, the other option is, we use Johnson Lau's extension block witness program version idea and just include main chain segwit as part of extension blocks as mentioned here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013994.html

Instead of merely achieving compatibility, we could bundle mainchain segwit with the ext. block deployment. It makes the code a bit more complex to include mainchain segwit as well, but would be worth it, assuming this is true.

[indutny]

I believe that this proposal is not compatible with ASICBOOST, at least according to Greg's suggestion. Correct me if I'm wrong, but Extension Blocks still require commitment over whole tree (both main and extension), which means that re-arrangements of TXs are still as expensive as in SEGWIT.

[Vaesper]

Instead of merely achieving compatibility, we could bundle mainchain segwit with the ext. block deployment.

Perhaps "refactor" on top of Segwit and repropose as post-SW softfork might be easier?

[josephpoon]

Could append some commitment as the last step of the merkle tree, or malleability-fix/commitment-to-witnesses on the main chain yeah.

"Reach Goals":^) Another option would be committed bloom filters! A more secure SPV mode which doesn't do probabilistic disclosure of your addresses to the P2P network sounds like fun. Could do the commitment sooner and add the P2P layer later when it's done.

@Vaesper: Hypothetically, if the community made a decision that a malleability fix on the main chain was preferred, seems more reliable to package it in since it would reuse a lot of the codebase anyway.

[chjj]

Solved with Fedor's PR: #7

Closing.