📅 Original date posted:2016-09-01
📝 Original message:
Restriction for segwit OP_IF argument as a policy has got a few concept ACK. I would like to have more people to ACK or NACK, especially the real users of OP_IF. I think Lightning network would use that at lot.
Pull request: https://github.com/bitcoin/bitcoin/pull/8526
more related discussion could be found at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html
It does have impact if your script uses the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts.
>
> On August 16, 2016 at 1:53 PM Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
> Author: Johnson Lau <jl2012 at xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2016-08-17
>
> Abstract
>
> This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.
>
> The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.
>
> Specification
>
> In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.
>
> This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.
>
> Compatibility
>
> This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).
>
> Implementation
>
> https://github.com/bitcoin/bitcoin/pull/8526
>
> Copyright
>
> This work is placed in the public domain.
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
>
> iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss
> aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk
> wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n
> 0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt
> L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP
> wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX
> HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl
> FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c
> QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==
> =lLIZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160901/8e47cd9f/attachment.html>;
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-09 12:46:40
in reply to nevent1q…hdhr
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-09 12:46:40Event JSON
{
"id": "c17df73313f4326e14664502771e1f862cb928c23f7df1b3dbb07d8bb5e52e8d",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686314800,
"kind": 1,
"tags": [
[
"e",
"07694f230a0c2b0c3016a6e1593042c73bacf964f1821d6fb7df4df613865b86",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2016-09-01\n📝 Original message:\nRestriction for segwit OP_IF argument as a policy has got a few concept ACK. I would like to have more people to ACK or NACK, especially the real users of OP_IF. I think Lightning network would use that at lot.\n\nPull request: https://github.com/bitcoin/bitcoin/pull/8526\n\nmore related discussion could be found at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html\n\nIt does have impact if your script uses the combination of \"OP_SIZE OP_IF\" or \"OP_DEPTH OP_IF\". With this policy/softfork, you need to use \"OP_SIZE OP_0NOTEQUAL OP_IF\" or \"OP_DEPTH OP_0NOTEQUAL OP_IF\", or reconstruct your scripts.\n\n\u003e \n\u003e On August 16, 2016 at 1:53 PM Johnson Lau via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e \n\u003e A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:\n\u003e https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki\n\u003e https://github.com/bitcoin/bitcoin/pull/8526\n\u003e \n\u003e BIP: x\n\u003e Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH\n\u003e Author: Johnson Lau \u003cjl2012 at xbt.hk\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2016-08-17\n\u003e \n\u003e Abstract\n\u003e \n\u003e This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.\n\u003e \n\u003e Motivation\n\u003e \n\u003e OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.\n\u003e \n\u003e The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.\n\u003e \n\u003e Specification\n\u003e \n\u003e In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.\n\u003e \n\u003e This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.\n\u003e \n\u003e Compatibility\n\u003e \n\u003e This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).\n\u003e \n\u003e Implementation\n\u003e \n\u003e https://github.com/bitcoin/bitcoin/pull/8526\n\u003e \n\u003e Copyright\n\u003e \n\u003e This work is placed in the public domain.\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e Comment: GPGTools - https://gpgtools.org\n\u003e \n\u003e iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss\n\u003e aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk\n\u003e wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n\n\u003e 0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt\n\u003e L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP\n\u003e wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX\n\u003e HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl\n\u003e FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c\n\u003e QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==\n\u003e =lLIZ\n\u003e -----END PGP SIGNATURE-----\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160901/8e47cd9f/attachment.html\u003e",
"sig": "4be38c98450860d1adbdeb4f38a45fc129b54d3bf7a2de1cf6f93a37baeb91c6c4c587ac2b2b12bbd49e00bed0ee3e10dd69a31e24ea67b60040b0df95ae9ed6"
}