From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C17851072 for ; Thu, 23 May 2019 20:54:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CB4F6C5 for ; Thu, 23 May 2019 20:54:08 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558644846; cv=none; d=zoho.com; s=zohoarc; b=Mc/qV5BQsV9M3SkN0jUgZqmwPmWZ+xq10+UuHr3beXzDR/K48uxmY1PdXJJCrMpEwWkmyRsgwDH5JV2fq/GitXXDpGLa5gPdKFBsAXfrUQNpk6RJVD1mLMUQCn8ddZGT+5y6KvOKSRLdXvpdgncuhUneLbZ2rMW25AYjZc3Y8Bg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558644846; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=XC+N5EEtRccW/Dm6nxaZ5Gv4vc2iGCTYJd3QnUb9F8k=; b=G4kpUx2h68QFb9tjCsuLDslFykqJ+gLpiZYGve6pAFotHx8rqkRf1NcIk/m4NErYwm7BEGuSGVqY5CZrLimwV25ZK6wavFRx/R6eYHJBFad0GHUw9t4S2qPtgGyjrkQnAxkS1z2fNPZdgjGisEw06NmaPViWcDIn3Q+Dklo7NK8= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [192.168.1.2] (1-64-133-115.static.netvigator.com [1.64.133.115]) by mx.zohomail.com with SMTPS id 1558644844866730.8742251385539; Thu, 23 May 2019 13:54:04 -0700 (PDT) From: Johnson Lau Content-Type: multipart/alternative; boundary="Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk> Date: Fri, 24 May 2019 04:54:01 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3445.104.11) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Fri, 24 May 2019 14:39:19 +0000 Subject: [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: Thu, 23 May 2019 20:54:09 -0000 --Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = trivial 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 = replayable, so any future payment to this script will likely be swept = immediately SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but = the signature is not replayable But it=E2=80=99s quite obvious that not committing to outputs are = inherently 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.ht= ml = 2. ANYPREVOUT (aka NOINPUT): = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.ht= ml = 3. CHECKOUTPUTSHASHVERIFY (COHV): = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.ht= ml = 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 requiring a chaperone signature that commits to input. However, = if the rationale for chaperone signature stands, it should be applicable = to all proposals listed above. A more generic approach is to always require a =E2=80=9Csafe" signature = that 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 couple leaf versions. By the way, customised sighash policies = could be done with CAT/CSFS.= --Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 trivial 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 = replayable, so any future payment to this script will likely be swept = immediately

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

But it=E2=80=99s quite obvious that not = committing to outputs are inherently 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-Ma= y/016946.html
2. ANYPREVOUT (aka = NOINPUT): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma= y/016929.html
3. CHECKOUTPUTSHASHVERIFY = (COHV): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma= y/016934.html

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 requiring a chaperone signature that commits to input. = However, if the rationale for chaperone signature stands, it should be = applicable to all proposals listed above.

A more generic approach is to always = require a =E2=80=9Csafe" signature that 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.med= iawiki), 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 couple leaf versions. By the way, customised sighash = policies could be done with CAT/CSFS.
= --Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330--