📅 Original date posted:2017-10-01
📝 Original message: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
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 18:06:48
in reply to nevent1q…4haj
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 18:06:48Event JSON
{
"id": "6555e25eb902f330b1f62a997ed5588364cf907639d7a0cbc2380cbc7937533a",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161208,
"kind": 1,
"tags": [
[
"e",
"9b9c879c7c4c0058d6eaf17164d815d71eee483d01b14c0d8895961d9935e9fd",
"",
"root"
],
[
"e",
"a068dfd6cafc62028ed743a1bd591e31d3d5f2fb5d00d6f04821dd952590b9e7",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 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",
"sig": "5b4cd831ef40bf006cb71d0e44a7be882d61678b4af89e8882d895f077217325656fef67f9ad3e059e20d5512b540c77c4e4565c6902dc5e521d21c3c4f3ae8a"
}