{"type":"rich","version":"1.0","author_name":"npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9","author_url":"https://nostr.ae/npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-10-01\n📝 Original message:So there are 3 proposals with similar goal but different designs. I try to summarise some questions below:\n\n1. How do we allow further upgrade within v1 witness? Here are some options:\na. Minor version in witness. (Johnson / Luke) I prefer this way, but we may end up with many minor versions.\nb. 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.\nc. Generalised NOP method: user has to provide the returned value, so even VERIFY-type code could do anything\n\n2. Do we want to allow signature-time commitment of extra scripts?\nI think all proposals allow this, just with different way\na. Tail-call semantics with CHECKSIGFROMSTACK (Mark). I think this is too rigid as it works only with specially designed scriptPubKey\nb. scriptWitCode: extra scripts are put in some fixed location in witness (Johnson). This makes sure static analysability.\nc. Extra-data as script in OP_CHECKSIG (Luke)\n\n3. Do we want to allow static analysis of sigop?\nBIP114 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.\n\n——\nJohnson"}