📅 Original date posted:2017-10-01
📝 Original message:On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:
> > 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
>
> I see no reason to do either. Gate new behavior based on script execution
> flags, which are set based on the script version. Script versions not
> understood are treated as "return true" to begin with. The interpreter
> isn't even going to try to decode the script according to the old rules,
> let alone try to execute it, so there's no reason for the old soft-fork
> compatability tricks.
>
> The new soft-fork trick is that you increment the script version number.
> That is all.
This breaks parallel softfork deployments.
> > 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)
>
> Propose these as their own script updates. Script versioning makes such
> new features cheap. There's no reason to create some sort of complex
> omnibus overhaul that does everything.
Only if there's common code to implement both versions, which doesn't work if
the changes from A to B to C are drastic. To avoid such drastic changes, the
overall design/layout needs to at least be planned to cover the desired use
cases in advance.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:06:49
in reply to nevent1q…242k
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 18:06:49Event JSON
{
"id": "7abe2bec270a02176aa354d37fdfc9398457e13208afe323d4cbb882bb3557ed",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686161209,
"kind": 1,
"tags": [
[
"e",
"9b9c879c7c4c0058d6eaf17164d815d71eee483d01b14c0d8895961d9935e9fd",
"",
"root"
],
[
"e",
"3f1b7ad4d16ef0218928c61b136d676adb44c5c3e18a4e0c331fb804a942b52f",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2017-10-01\n📝 Original message:On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:\n\u003e \u003e b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114\n\u003e \u003e but now I think it doesn’t interact well with signature aggregation, and\n\u003e \u003e I worry that it would have some other unexpected effects. c. Generalised\n\u003e \u003e NOP method: user has to provide the returned value, so even VERIFY-type\n\u003e \u003e code could do anything\n\u003e \n\u003e I see no reason to do either. Gate new behavior based on script execution\n\u003e flags, which are set based on the script version. Script versions not\n\u003e understood are treated as \"return true\" to begin with. The interpreter\n\u003e isn't even going to try to decode the script according to the old rules,\n\u003e let alone try to execute it, so there's no reason for the old soft-fork\n\u003e compatability tricks.\n\u003e \n\u003e The new soft-fork trick is that you increment the script version number. \n\u003e That is all.\n\nThis breaks parallel softfork deployments.\n\n\u003e \u003e b. scriptWitCode: extra scripts are put in some fixed location in witness\n\u003e \u003e (Johnson). This makes sure static analysability. c. Extra-data as script\n\u003e \u003e in OP_CHECKSIG (Luke)\n\u003e \n\u003e Propose these as their own script updates. Script versioning makes such\n\u003e new features cheap. There's no reason to create some sort of complex\n\u003e omnibus overhaul that does everything.\n\nOnly if there's common code to implement both versions, which doesn't work if \nthe changes from A to B to C are drastic. To avoid such drastic changes, the \noverall design/layout needs to at least be planned to cover the desired use \ncases in advance.\n\nLuke",
"sig": "8a4f32e9b2c291e74642bc05b5b4e8052cdbe83ebaac9769ec33f753be6d0d2d54b04b5001a7920d8a61cce568805b9ebbac13d851372770eff2a8c12ad521b3"
}