Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add extra commitment to prevent asicboost? #6

Closed
chjj opened this Issue Apr 5, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@chjj
Copy link
Member

commented Apr 5, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Apr 5, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

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

This comment has been minimized.

Copy link

commented Apr 6, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 6, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Apr 6, 2017

Solved with Fedor's PR: #7

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.