{"type":"rich","version":"1.0","author_name":"npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","author_url":"https://nostr.ae/npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-10-02\n📝 Original message:Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e \n\u003e On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:\n\u003e\u003e\u003e b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114\n\u003e\u003e\u003e but now I think it doesn’t interact well with signature aggregation, and\n\u003e\u003e\u003e I worry that it would have some other unexpected effects. c. Generalised\n\u003e\u003e\u003e NOP method: user has to provide the returned value, so even VERIFY-type\n\u003e\u003e\u003e code could do anything\n\u003e\u003e \n\u003e\u003e I see no reason to do either. Gate new behavior based on script execution\n\u003e\u003e flags, which are set based on the script version.  Script versions not\n\u003e\u003e understood are treated as \"return true\" to begin with.  The interpreter\n\u003e\u003e isn't even going to try to decode the script according to the old rules,\n\u003e\u003e let alone try to execute it, so there's no reason for the old soft-fork\n\u003e\u003e compatability tricks.\n\u003e\u003e \n\u003e\u003e The new soft-fork trick is that you increment the script version number.\n\u003e\u003e That is all.\n\u003e \n\u003e This breaks parallel softfork deployments.\n\nIf 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.\n\nSjors\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171002/99d0f6a0/attachment.sig\u003e"}