From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4079AC0881 for ; 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 ; 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 ; 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 ; Wed, 27 Nov 2019 21:54:37 +0000 (UTC) Received: by mail-qk1-f173.google.com with SMTP id a137so19135567qkc.7 for ; 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" Date: Wed, 27 Nov 2019 16:29:32 -0500 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi all,

I&#= 39;d like to revisit an old topic from last year about the data signed in t= apscript 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.=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).

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 https://bitcoin.stackexchang= e.com/a/85665/49364).

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.

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.

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.

As= a side benefit, we get to eliminate CODESEPARATOR, removing a fairly awkwa= rd opcode from this script version.
--000000000000f47b0205985ab14a--