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
Precedence: list

--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 &lt;<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>&gt;=
.</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&#39;s UTXO as their own and try to cop=
y the victim&#39;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&#39;s pubkey as his own, and maybe he has inserted a copy of =
Alice&#39;s pubkey into a different path of the Script template.=C2=A0 Now =
Alice&#39;s signature can be copied and used in this alternate path, allowi=
ng the UTXO to be redeemed under circumstances that Alice didn&#39;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--