So there are 3 proposals with similar goal but different designs. I try to summarise some questions below:
1. How do we allow further upgrade within v1 witness? Here are some options: a. Minor version in witness. (Johnson / Luke) I prefer this way, but we may end up with many minor versions. b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114 but now I think it doesn’t interact well with signature aggregation, and I worry that it would have some other unexpected effects. c. Generalised NOP method: user has to provide the returned value, so even VERIFY-type code could do anything 2. Do we want to allow signature-time commitment of extra scripts? I think all proposals allow this, just with different way a. Tail-call semantics with CHECKSIGFROMSTACK (Mark). I think this is too rigid as it works only with specially designed scriptPubKey b. scriptWitCode: extra scripts are put in some fixed location in witness (Johnson). This makes sure static analysability. c. Extra-data as script in OP_CHECKSIG (Luke) 3. Do we want to allow static analysis of sigop? BIP114 and the related proposals are specifically designed to allow static analysis of sigop. I think this was one of the main reason of OP_EVAL not being accepted. This was also the main reason of Ethereum failing to do a DAO hacker softfork, leading to the ETH/ETC split. I’m not sure if we really want to give up this property. Once we do it, we have to support it forever. —— Johnson _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
