Author: Mark Friedenbach 2018-01-09 22:57:34
Published on: 2018-01-09T22:57:34+00:00
The author argues that new bitcoin consensus features should follow the UNIX philosophy of being small, modular, incremental, and reusable changes that can be combined and used even in ways unforeseen even by their creators, creating a platform for unrestricted innovation. The author uses the example of Merklized Abstract Syntax Trees (MAST) to support this argument, stating that there is currently no production use of MAST and therefore it is premature to provide a templated, special-cased MAST before it sees wide use. Instead, the proper sequence of events should be to enable features in a generic way, and then to create specialized templates to save space for common constructions.The author also points out the drawbacks of templating new features, using P2SH as an example which only provides 80 bits of security to a multi-party construction. The author argues that had they been designing BIP 16 now they probably would have used double-SHA256 instead of RIPEMD160, and had they been using single-use tail-call semantics instead of BIP 16, recognition of its limitations would have resulted in them immediately defining a longer '3...' address which used HASH256 instead, and they would have immediately benefited from the fix.The author believes that the situation is similar with MAST, where even if they have a better idea of what the MAST constructions will look like, nobody uses MAST in production yet, and there are bound to be implementation issues in rolling it out or unique variants they do not have the foresight to see now. Therefore, providing a templated, special-cased MAST now would lock in the protocol that they anticipate people using without having any production experience or ecosystem-wide review.Finally, the author argues that even if they had perfect foresight into how a feature will be used, which they don't, they would want to enable permission-less innovation with the generic construct, even if using it comes with a 40-byte or so witness hit. The author makes the argument that by using modularity and composition of powerful but simple tools like MERKLEBRANCHVERIFY and single tail-call recursion to construct MAST they enable a complex and desirable feature while minimizing changes to the consensus code, review burden, and acquired technical debt.
Updated on: 2023-06-12T23:42:02.468451+00:00