[bitcoin-dev] Version 1 witness programs (first draft)

Luke Dashjr luke at dashjr.org
Mon Oct 2 02:56:27 UTC 2017

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.


More information about the bitcoin-dev mailing list