rich1.0npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nhttps://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nnjumphttps://nostr.ae📅 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