rich1.0npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7phttps://nostr.ae/npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pnjumphttps://nostr.ae📅 Original date posted:2017-10-02 📝 Original message:Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven: > > 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. If unknown script versions are treated as "return true", there's no need for versions to be deployed in sequence, right? Maybe they should be called numbered script types, rather than script versions. Sjors -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171002/99d0f6a0/attachment.sig>