diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2019-11-27 16:29:32 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-11-27 21:54:38 +0000 |
| commit | 16705a37df1aa2daa8dac2318aa4e4048afe05c4 (patch) | |
| tree | a48d5e0923e2daac60b42e74ec4d97eb9b077bc2 | |
| parent | 19ca489f42c0ad437c4d074b9f688bf0476b62ca (diff) | |
| download | pi-bitcoindev-16705a37df1aa2daa8dac2318aa4e4048afe05c4.tar.gz pi-bitcoindev-16705a37df1aa2daa8dac2318aa4e4048afe05c4.zip | |
[bitcoin-dev] Signing CHECKSIG position in Tapscript
| -rw-r--r-- | c7/3ecb999295da906768f547789e7206c5a09836 | 203 |
1 files changed, 203 insertions, 0 deletions
diff --git a/c7/3ecb999295da906768f547789e7206c5a09836 b/c7/3ecb999295da906768f547789e7206c5a09836 new file mode 100644 index 000000000..ab4d17cde --- /dev/null +++ b/c7/3ecb999295da906768f547789e7206c5a09836 @@ -0,0 +1,203 @@ +Return-Path: <roconnor@blockstream.io> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 4079AC0881 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Nov 2019 21:54:38 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 26C138739E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Nov 2019 21:54:38 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from hemlock.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id UruVP+FUQbT8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Nov 2019 21:54:37 +0000 (UTC) +X-Greylist: delayed 00:16:58 by SQLgrey-1.7.6 +Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com + [209.85.222.173]) + by hemlock.osuosl.org (Postfix) with ESMTPS id 17ECF8739A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Nov 2019 21:54:37 +0000 (UTC) +Received: by mail-qk1-f173.google.com with SMTP id a137so19135567qkc.7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Nov 2019 13:54:37 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=blockstream.io; s=google; + h=mime-version:from:date:message-id:subject:to; + bh=eNPHAyrewBkvkcdrF9zo2Ceq6JRARRwsSlhUm8ijlfQ=; + b=Cw7Lc+z7uLIOlFRN/6PH0hiAThjDtMNbnmPxenZTpHEAqbPC3C11+knQ5PaAujC4ZA + /+b9QxgAGKO9o4n4N6Fyd7yaEl6qipZ9gGmLYt5p20eiGFfkVprImHNfqmrhmwMPsL5T + 4cCYMPpfyGLUkxJpll58gf55o2D6PveLNDzVE= +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:from:date:message-id:subject:to; + bh=eNPHAyrewBkvkcdrF9zo2Ceq6JRARRwsSlhUm8ijlfQ=; + b=OQeeio5jiiY1cE5Kf2OJt6o8KO8TydT/pjzjvnslHr14/jl2QllXPCwXZoEzcJmLAR + 47zXG0GHielpbRRYDJnlrRHcKmFiCVfJH48lHj3QqJyp9OSPN1E2V7tymsO+PDb9T0pO + 7SkyhraoIZMNCGpvwh8GGLS2aouDV3MzAsZT6mjSRkR2mIySOL5j53nFmK8RgAA8GaF7 + U69bl5lVtseeP911k0KzMGOX3nHY31MIyL65/4FnKxzEJh44lCqaITEy2Sj6x7nGfOkW + CMGffI3b8hXpWRiplmCsmbi/wvryKWDA/B9kSPzY1DkPRozwnQ061PxILoiuBPpJs1iD + Zi+A== +X-Gm-Message-State: APjAAAVQwce1sqZr192AdjonBVjQI/oywk9/5PAJXXmuR8xjBl+JeVl+ + pZU8JmeNMQtDbJL7SGGwj9RvXBLU7K4U2lvfUa+Ji6Of +X-Google-Smtp-Source: APXvYqxyDHOr67OhXHshXGgBuOKDKe+0ShEzihQZNtpICGfOYn/Zv1gS8+W4Yjdp4adjUIda/PB97nxussPvICKVB+w= +X-Received: by 2002:a02:b703:: with SMTP id g3mr1793393jam.101.1574890183613; + Wed, 27 Nov 2019 13:29:43 -0800 (PST) +MIME-Version: 1.0 +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Wed, 27 Nov 2019 16:29:32 -0500 +Message-ID: <CAMZUoKm7Y8bRJ+hqmvyPwwTWHaMA7JJc5TZdx7Eufax9G0D=Gg@mail.gmail.com> +To: Pieter Wuille <pieter.wuille@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000f47b0205985ab14a" +Subject: [bitcoin-dev] Signing CHECKSIG position in Tapscript +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 27 Nov 2019 21:54:38 -0000 + +--000000000000f47b0205985ab14a +Content-Type: text/plain; charset="UTF-8" + +Hi all, + +I'd like to revisit an old topic from last year about the data signed in +tapscript signatures < +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016508.html +>. + +The current tapscript proposal requires a signature on the last executed +CODESEPRATOR position. I'd like to propose an amendment whereby instead of +signing the last executed CODESEPRATOR position, we simply always sign the +position of the CHECKSIG (or other signing opcode) being executed. Then we +can deprecate CODESEPARTOR (either by making it OP_SUCCESS, or a nop, or +always fail when executed, or whatever). + +The main motivation for this proposal is to increase robustness against +various signature-copying attacks in Scripts that have multiple spending +conditions. Bitcoin is already robust against attacks where the attacker +attempts to peddle a victim's UTXO as their own and try to copy the +victim's signature from one transaction input to another input. Because +Bitcoin signatures specify which input within a transaction is being signed +for, such attacks fail (see https://bitcoin.stackexchange.com/a/85665/49364 +). + +However, unless CODESEPARATOR is explicitly used, there is no protection +against these sorts of attacks when there are multiple participants that +have signing conditions within a single UTXO (or rather within a single +tapleaf in the tapscript case). As it stands, Bitcoin's signed data only +covers which input is being signed, and not the specific conditions are +being signed for. So for example, if Alice and Bob are engaged in some +kind of multi-party protocol, and Alice wants to pre-sign a transaction +redeeming a UTXO but subject to the condition that a certain hash-preimage +is revealed, she might verify the Script template shows that the code path +to her public key enforces that the hash pre-image is revealed (using a +toolkit like miniscript can aid in this), and she might make her signature +feeling secure that it, if her signature is used, the required preimage +must be revealed on the blockchain. But perhaps Bob has masquated Alice's +pubkey as his own, and maybe he has inserted a copy of Alice's pubkey into +a different path of the Script template. Now Alice's signature can be +copied and used in this alternate path, allowing the UTXO to be redeemed +under circumstances that Alice didn't believe she was authorizing. In +general, to protect herself, Alice needs to inspect the Script to see if +her pubkey occurs in any other branch. Given that her pubkey, in +principle, could be derived from a computation rather that pushed directly +into the stack, it is arguably infeasible for Alice to perform the required +check in general. + +I believe that it would be safer, and less surprising to users, to always +sign the CHECKSIG position by default. This will automatically enforce +conditions with the signature in most cases, rather than requiring users to +proactively try to reason if CODESEPARATOR is required for protection +within their protocol or not, and risk having them leave it out for cost +savings when it ends up being required for security after all. + +I do not believe signing the CHECKSIG position is an undue burden on those +signers who have no conditions they require enforcement for. As it stands, +the tapscript proposal already requires the tapleaf_hash value under the +signature; this CHECKSIG position value is simply more of the same kind of +data. In simple Script templates (e.g. those with only one CHECKSIG +operation) the signed position will be a fixed known value. Complex Script +templates are precisely the situations where you want to be careful about +enforcement of conditions with your signature. + +As a side benefit, we get to eliminate CODESEPARATOR, removing a fairly +awkward opcode from this script version. + +--000000000000f47b0205985ab14a +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>I&#= +39;d like to revisit an old topic from last year about the data signed in t= +apscript signatures <<a href=3D"https://lists.linuxfoundation.org/piperm= +ail/bitcoin-dev/2018-November/016508.html" target=3D"_blank">https://lists.= +linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016508.html</a>>= +.</div></div><br><div class=3D"gmail_quote">The current tapscript proposal = +requires a signature on the last executed CODESEPRATOR position.=C2=A0 I= +9;d like to propose an amendment whereby instead of signing the last execut= +ed CODESEPRATOR position, we simply always sign the position of the CHECKSI= +G (or other signing opcode) being executed. Then we can deprecate CODESEPAR= +TOR (either by making it OP_SUCCESS, or a nop, or always fail when executed= +, or whatever).</div><div class=3D"gmail_quote"><br></div><div class=3D"gma= +il_quote">The main motivation for this proposal is to increase robustness a= +gainst various signature-copying attacks in Scripts that have multiple spen= +ding conditions.=C2=A0 Bitcoin is already robust against attacks where the = +attacker attempts to peddle a victim's UTXO as their own and try to cop= +y the victim's signature from one transaction input to another input.= +=C2=A0 Because Bitcoin signatures specify which input within a transaction = +is being signed for, such attacks fail (see <a href=3D"https://bitcoin.stac= +kexchange.com/a/85665/49364" target=3D"_blank">https://bitcoin.stackexchang= +e.com/a/85665/49364</a>).</div><div class=3D"gmail_quote"><br></div><div cl= +ass=3D"gmail_quote">However, unless CODESEPARATOR is explicitly used, there= + is no protection against these sorts of attacks when there are multiple pa= +rticipants that have signing conditions within a single UTXO (or rather wit= +hin a single tapleaf in the tapscript case).=C2=A0 As it stands, Bitcoin= +9;s signed data only covers which input is being signed, and not the specif= +ic conditions are being signed for.=C2=A0 So for example, if Alice and Bob = +are engaged in some kind of multi-party protocol, and Alice wants to pre-si= +gn a transaction redeeming a UTXO but subject to the condition that a certa= +in hash-preimage is revealed, she might verify the Script template shows th= +at the code path to her public key enforces that the hash pre-image is reve= +aled (using a toolkit like miniscript can aid in this), and she might make = +her signature feeling secure that it, if her signature is used, the require= +d preimage must be revealed on the blockchain.=C2=A0 But perhaps Bob has ma= +squated Alice's pubkey as his own, and maybe he has inserted a copy of = +Alice's pubkey into a different path of the Script template.=C2=A0 Now = +Alice's signature can be copied and used in this alternate path, allowi= +ng the UTXO to be redeemed under circumstances that Alice didn't believ= +e she was authorizing.=C2=A0 In general, to protect herself, Alice needs to= + inspect the Script to see if her pubkey occurs in any other branch.=C2=A0 = +Given that her pubkey, in principle, could be derived from a computation ra= +ther that pushed directly into the stack, it is arguably infeasible for Ali= +ce to perform the required check in general.<br></div><div class=3D"gmail_q= +uote"><br></div><div class=3D"gmail_quote">I believe that it would be safer= +, and less surprising to users, to always sign the CHECKSIG position by def= +ault.=C2=A0 This will automatically enforce conditions with the signature i= +n most cases, rather than requiring users to proactively try to reason if C= +ODESEPARATOR is required for protection within their protocol or not, and r= +isk having them leave it out for cost savings when it ends up being require= +d for security after all.<br></div><div class=3D"gmail_quote"><br></div><di= +v class=3D"gmail_quote">I do not believe signing the CHECKSIG position is a= +n undue burden on those signers who have no conditions they require enforce= +ment for.=C2=A0 As it stands, the tapscript proposal already requires the t= +apleaf_hash value under the signature; this CHECKSIG position value is simp= +ly more of the same kind of data.=C2=A0 In simple Script templates (e.g. th= +ose with only one CHECKSIG operation) the signed position will be a fixed k= +nown value.=C2=A0 Complex Script templates are precisely the situations whe= +re you want to be careful about enforcement of conditions with your signatu= +re.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">As= + a side benefit, we get to eliminate CODESEPARATOR, removing a fairly awkwa= +rd opcode from this script version.</div></div> + +--000000000000f47b0205985ab14a-- + |