Published on: 2017-11-04T07:59:07+00:00
During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.
Updated on: 2023-08-01T21:47:30.334441+00:00