<oembed><type>rich</type><version>1.0</version><author_name>npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw</author_name><author_url>https://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2019-03-07&#xA;📝 Original message:&gt; * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.&#xA;&gt; This includes OP_CODESEPARATORs in unexecuted branches of if statements,&#xA;&gt; similar to other disabled opcodes, but unlike OP_RETURN.&#xA;&gt;&#xA;&#xA;OP_CODESEPARATOR is the only mechanism available that allows users to sign&#xA;which particular branch they are authorizing for within scripts that have&#xA;multiple possible conditions that reuse the same public key.  Because of&#xA;P2SH you cannot know that no one is currently using this feature.&#xA;Activating a soft-fork as describe above means these sorts of funds would&#xA;be permanently lost.  It is not acceptable to risk people&#39;s money like this.&#xA;&#xA;I suggest an alternative whereby the execution of OP_CODESEPARATOR&#xA;increases the transactions weight suitably as to temper the vulnerability&#xA;caused by it.  Alternatively there could be some sort of limit (maybe 1) on&#xA;the maximum number of OP_CODESEPARATORs allowed to be executed per script,&#xA;but that would require an argument as to why exceeding that limit isn&#39;t&#xA;reasonable.&#xA;&#xA;-- &#xA;Russell O&#39;Connor&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190307/0f0ed246/attachment.html&gt;</html></oembed>