Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EDF7B6C for ; Fri, 24 May 2019 20:59:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31B26F4 for ; Fri, 24 May 2019 20:59:16 +0000 (UTC) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OKxEm5020425 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 24 May 2019 16:59:15 -0400 Received: by mail-ed1-f52.google.com with SMTP id a8so16058425edx.3 for ; Fri, 24 May 2019 13:59:15 -0700 (PDT) X-Gm-Message-State: APjAAAVzfYg+iypldIdwOg9FfmhSPiV3Y0z8fV8A558TVe3dosAsnk8u zvsedbQtCLADdaZFPv+2uuuMBp6s+bMLioVpSiU= X-Google-Smtp-Source: APXvYqy58/fNSBTKHimBY2HWHj3hAKE7orAVmGS1K9pT8rOOsHHu13Tp920srNlxNDSwgzcLST8TVSPk+xZeklZpmds= X-Received: by 2002:a17:906:5a08:: with SMTP id p8mr67168122ejq.276.1558731554297; Fri, 24 May 2019 13:59:14 -0700 (PDT) MIME-Version: 1.0 References: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk> In-Reply-To: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk> From: Jeremy Date: Fri, 24 May 2019 13:59:03 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009820cc0589a87822" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 25 May 2019 12:07:05 +0000 Subject: Re: [bitcoin-dev] Safety of committing only to transaction outputs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 20:59:18 -0000 --0000000000009820cc0589a87822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Johnson, As noted on the other thread, witness replay-ability can be helped by salting the taproot key or the taproot leaf script at the last stage of a congestion control tree. I also think that chaperone signatures should be opt-in; there are cases where we may not want them. OP_COSHV is compatible with an additional checksig operation. There are also other mechanisms that can improve the safety. Proposed below= : OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the inputs is a particular value. The top-level of a congestion control tree can check that the inputs match the desired inputs for that spend, and default to requiring N of N otherwise. This is replay proof! This is useful for other applications too. OP_CHECKFEEVERIFY -- allowing an explicit commitment to the exact amount of fee limits replay to txns which were funded with the exact amount of the prior. If there's a mismatch, an alternative branch can be used. This is a generally useful mechanism, but means that transactions using it must have all inputs/outputs set. Best, Jeremy -- @JeremyRubin On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This is a meta-discussion for any approach that allows the witness > committing to only transaction outputs, but not inputs. > > We can already do the following things with the existing bitcoin script > system: > * commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with > optional SIGHASH_ANYONECANPAY > * commit to only inputs but not outputs: SIGHASH_NONE with optional > SIGHASH_ANYONECANPAY > * not commit to any input nor output: not using any sigop; using a trivia= l > private key; using the SIGHASH_SINGLE bug in legacy script > > The last one is clearly unsafe as any relay/mining node may redirect the > payment to any output it chooses. The witness/scriptSig is also replayabl= e, > so any future payment to this script will likely be swept immediately > > SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but th= e > signature is not replayable > > But it=E2=80=99s quite obvious that not committing to outputs are inheren= tly > insecure > > The existing system doesn=E2=80=99t allow committing only to outputs, and= we now > have 3 active proposals for this function: > > 1. CAT and CHECKSIGFROMSTACK (CSFS): > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.h= tml > 2. ANYPREVOUT (aka NOINPUT): > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.h= tml > 3. CHECKOUTPUTSHASHVERIFY (COHV): > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.h= tml > > With outputs committed, redirecting payment is not possible. On the other > hand, not committing to any input means the witness is replayable without > the consent of address owner. Whether replayability is acceptable is > subject to controversy, but the ANYPREVOUT proposal fixes this by requiri= ng > a chaperone signature that commits to input. However, if the rationale fo= r > chaperone signature stands, it should be applicable to all proposals list= ed > above. > > A more generic approach is to always require a =E2=80=9Csafe" signature t= hat > commits to at least one input. However, this interacts poorly with the > "unknown public key type=E2=80=9D upgrade path described in bip-tapscript= ( > https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki), > since it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown type sig=E2= =80=9D into a =E2=80=9Csafe sig=E2=80=9D. > But we could still use a new =E2=80=9Cleaf version=E2=80=9D every time we= introduce new > sighash types, so we could have a new definition for =E2=80=9Csafe sig=E2= =80=9D. I expect > this would be a rare event and it won=E2=80=99t consume more than a coupl= e leaf > versions. By the way, customised sighash policies could be done with > CAT/CSFS. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000009820cc0589a87822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Johnson,

As note= d on the other thread, witness replay-ability can be helped by salting the = taproot key or the taproot leaf script at the last stage of a congestion co= ntrol tree.

I also think that chaperone signatures should be opt-in; = there are cases where we may not want them. OP_COSHV is compatible with an = additional checksig operation.

There are also other mechanisms that c= an improve the safety. Proposed below:

OP_CHECKINPUTSHASHVERIFY -- al= low checking that the hash of the inputs is a particular value. The top-lev= el of a congestion control tree can check that the inputs match the desired= inputs for that spend, and default to requiring N of N otherwise. This is = replay proof! This is useful for other applications too.

OP_CHECK= FEEVERIFY -- allowing an explicit commitment to the exact amount of fee lim= its replay to txns which were funded with the exact amount of the prior. If= there's a mismatch, an alternative branch can be used. This is a gener= ally useful mechanism, but means that transactions using it must have all i= nputs/outputs set.

Best,

Jeremy


On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bi= tcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
= This is a meta-discussion for any approach that allows the witness committi= ng to only transaction outputs, but not inputs.

We can a= lready do the following things with the existing bitcoin script system:
* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, = with optional SIGHASH_ANYONECANPAY
* commit to only inputs but no= t outputs: SIGHASH_NONE with optional SIGHASH_ANYONECANPAY
* not = commit to any input nor output: not using any sigop; using a trivial privat= e key; using the SIGHASH_SINGLE bug in legacy script

The last one is clearly unsafe as any relay/mining node may redirect the= payment to any output it chooses. The witness/scriptSig is also replayable= , so any future payment to this script will likely be swept immediately

SIGHASH_NONE with ANYONECANPAY also allows redirectio= n of payment, but the signature is not replayable

= But it=E2=80=99s quite obvious that not committing to outputs are inherentl= y insecure

The existing system doesn=E2=80=99t all= ow committing only to outputs, and we now have 3 active proposals for this = function:


<= /div>
With outputs committed, redirecting payment is not possible. On t= he other hand, not committing to any input means the witness is replayable = without the consent of address owner. Whether replayability is acceptable i= s subject to controversy, but the ANYPREVOUT proposal fixes this by requiri= ng a chaperone signature that commits to input. However, if the rationale f= or chaperone signature stands, it should be applicable to all proposals lis= ted above.

A more generic approach is to always re= quire a =E2=80=9Csafe" signature that commits to at least one input. H= owever, this interacts poorly with the "unknown public key type=E2=80= =9D upgrade path described in bip-tapscript (https= ://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki), sinc= e it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown type sig=E2=80=9D = into a =E2=80=9Csafe sig=E2=80=9D. But we could still use a new =E2=80=9Cle= af version=E2=80=9D every time we introduce new sighash types, so we could = have a new definition for =E2=80=9Csafe sig=E2=80=9D. I expect this would b= e a rare event and it won=E2=80=99t consume more than a couple leaf version= s. By the way, customised sighash policies could be done with CAT/CSFS.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009820cc0589a87822--