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 EEE86C84 for ; Sat, 25 May 2019 07:53:43 +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 5CED5A9 for ; Sat, 25 May 2019 07:53:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558770820; cv=none; d=zoho.com; s=zohoarc; b=EXACs+OiWfbpD9MQ5g6Z5+r4Q4Efiv9ENNsq4evTvnjFO2wZWRrIId5eavT5h2EDNgyDtvA+woBcdAmtXOSYyLy/Ggp7rkTjBKjV7aGhGahh7xGWZKXsvHq+e+qztORe5tuGzqTtXNw991XGl4CeaHX3CCp43xlkLo+Oz8BzskE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558770820; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=Hs2Y8QZW44hyZZFYTGDwbaNKgSyECPNLMBd9bXQZk+g=; b=S1AOmHN7gtE2WJzCAxNtnkeRkSbnrXX2qbdXaqTZatgxRf6gYSdiDQ/rujAkePj40irKmpoePrc0s9pAYCB7I5frj/U4FqBDgoDOIUb6pn+/ZZ3e7Rl3mI8cN1pgY9ar1G/nmGGtpPTkeKn9alG9jIB3NddpcEKKBzYZhtePi1A= 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 1558770818450679.8265088863286; Sat, 25 May 2019 00:53:38 -0700 (PDT) From: Johnson Lau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 25 May 2019 15:53:34 +0800 In-Reply-To: To: Jeremy References: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk> 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: Sat, 25 May 2019 12:05:39 +0000 Cc: bitcoin-dev 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: Sat, 25 May 2019 07:53:44 -0000 --Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 May 2019, at 4:59 AM, Jeremy wrote: >=20 > Hi Johnson, >=20 > 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. >=20 The salt will be published when it is first spent. Salting won=E2=80=99t = help if the address is reused. > 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. >=20 > There are also other mechanisms that can improve the safety. Proposed = below: >=20 > 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. It is circular dependent: the script has to commit to the txid, and the = txid is a function of script >=20 > 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. >=20 This restricts replayability to input with same value, but is still = replay-able, just like ANYPREVOUT committing to the input value > Best, >=20 > Jeremy > -- > @JeremyRubin = --Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25 May 2019, at 4:59 AM, Jeremy <jlrubin@mit.edu> = wrote:

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.


The salt will be published when it is first spent. = Salting won=E2=80=99t help if the address is reused.

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.

It is circular dependent: the script has to commit = to the txid, and the txid is a function of script



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.


This restricts replayability to input with same = value, but is still replay-able, just like ANYPREVOUT committing to the = input value


Best,

Jeremy
--
@JeremyRubin

= --Apple-Mail=_83376121-14C6-4E7F-8110-0F1D06623EA9--