Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-01 📝 Original message:On Monday 02 October 2017 ...
📅 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
📝 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