search

tothemoon-org / extension-blocks

Extension blocks soft-fork specification
40 stars 6 forks source link

spec: add ASICBOOST mitigation #7

Closed indutny closed 7 years ago

indutny commented 7 years ago

Our current commitment scheme is vulnerable to the collision scheme exploited in ASICBOOST devices. It is an open question how this should be handled, but it does sound right to me that we should at least match SEGWIT's behavior to compete with it on fair grounds.

Calculating merkle-root over extension block transactions is not enough, since it still allows "shaking" the TX list in the canonical block without changing the commitment.

indutny commented 7 years ago

Thank you!

chjj commented 7 years ago

Thanks Fedor. Not sure why nobody mentioned this to us on the bitcoin-dev mailing list when I asked for suggestions on how to construct the commitment, but oh well.

chjj commented 7 years ago

We also might want to start requiring the commitment on every block after activation. Mining ext. blocks would still be opt-in, but now all miners would need to upgrade. Shouldn't be an issue assuming 95% activation threshold.

josephpoon commented 7 years ago

While it is not entirely up to us to decide on this aspect of the specification, we believe that this is what the specification could look like with a specific mitigation.

A change to the specification which adds features such as a malleability fix on the canonical block or committed bloom filter SPV validation of both canonical blockchain (main-chain) and extension block may conflict (but incidentally fulfill) this pull request and we may improve the extension block specification as a result of that design conflict. Doing so would result in removing and superseding this pull request as those features are more important.

We had previously discussed with various miners, at a meeting that we are interested in committed bloom filters and they sounded interested in the idea of decentralized proofs as a better SPV mode. Part of the SPV mode may require an additional specific commitment to the hash of a compact mapping of all input TXOs and outputs of transaction position to avoid full-block download in the event of a hit as an optional speed-privacy tradeoff (but required for block creation) for users doing partial observation of the blockchain.

Note that we do not have any personal opinions on this pull request's particular aspect of implementation and it is up to Developers, Miners, Industry, and Users to support whether this is a good idea. Ultimately, activation of the end result of this specification is an indication of miner approval.