Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 376F6BC0 for ; Tue, 18 Dec 2018 10:48:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 053DC177 for ; Tue, 18 Dec 2018 10:48:49 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545130127; cv=none; d=zoho.com; s=zohoarc; b=jlGgvg1Ojqa3HJavcLtIIja97JkiaCQWKpPg91AXLLozo8aC3D8ySexgzl+/J0v9Q7Hl9ExSLz8UpymMF0+mmkcpGB280RuuacvXPRv/LJIy5I+Kv728gfQcJNgVCki7MAen846B9+Ojfshy1k8Du34L4N9ClCYtLE0B/Pgf7AQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545130127; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=bvRif6JviIusYTO+axxADq32aYLFVrJuF3EJJWBDQao=; b=fQJggyG7nCOp2cMaz+BOSiG5X/Y/VFl2iLXS4na4FL4d2zK8WE+M0UFvw42Qu0sYps4cH7P8YwrLE8brsj26ANseEE9TmBMKa0Z1qcG+tLitLw3lnuIvSqvf+sCLezbZ3HLpKKfV5nSZ6fXr44b2BtpQ5YxDuiUN4CSd2T4PIkU= 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 [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1545130125990803.1182922696652; Tue, 18 Dec 2018 02:48:45 -0800 (PST) From: Johnson Lau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E74D8E40-FD61-454C-9DBE-DEE637C1307F" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 18 Dec 2018 18:48:40 +0800 In-Reply-To: To: Johnson Lau , bitcoin-dev References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,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: Tue, 18 Dec 2018 16:11:00 +0000 Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging 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: Tue, 18 Dec 2018 10:48:51 -0000 --Apple-Mail=_E74D8E40-FD61-454C-9DBE-DEE637C1307F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev = wrote: >=20 >=20 >=20 >> On 17 Dec 2018, at 11:48 PM, Ruben Somsen > wrote: >>=20 >> Hi Johnson, >>=20 >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional [1]. >=20 > Yes, but the =E2=80=9Ctagging=E2=80=9D emphasises more on the = payer=E2=80=99s side: if the payer cannot guarantee that the payee would = never reuse the key, the payer could avoid any NOINPUT-related trouble = by tagging properly. >=20 >>=20 >>> While this seems fully compatible with eltoo, is there any other = proposals require NOINPUT, and is adversely affected by either way of = tagging? >>=20 >> As far as I can tell it should be compatible with Statechains [2], >> since it pretty much mirrors Eltoo in setup. >>=20 >> My understanding is somewhat lacking, so perhaps I am missing the >> mark, but it is not completely clear to me how this affects >> fungibility if taproot gets added and the setup and trigger tx for >> Eltoo get combined into a single transaction. Would the NOINPUT >> spending condition be hidden inside the taproot commitment? >=20 > For the design considerations I mentioned above, the tags must be = explicit and configurable by the payer. So it couldn=E2=80=99t be hidden = in taproot. >=20 > If you don=E2=80=99t care about fungibility, you can always tag your = setup output, and makes it ready for NOINPUT spending. Every update will = need 2 signatures: a NOINPUT to spend the setup output or an earlier = update output, and a NOINPUT to settle the latest update output. >=20 > If you care about fungibility, you can=E2=80=99t tag your setup = output. Every update will need 3 signatures: a SINGLEINPUT (aka = ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier = update output, and a NOINPUT to settle the latest update output. >=20 > (Actually, as soon as you made the first update tx with SINGLEINPUT, = you don=E2=80=99t strictly need to make any SINGLEINPUT signatures in = the later updates again, as the first update tx (or any update with a = SINGLEINPUT signature) could be effectively the trigger tx. While it = makes the settlement more expensive, it also means accidentally missing = a SINGLEINPUT signature will not lead to any fund loss. So security-wise = it=E2=80=99s same as the always-tagging scenario.) >=20 > The most interesting observation is: you never have the need to use = NOINPUT on an already confirmed UTXO, since nothing about a confirmed = UTXO is mutable. And every smart contract must anchor to a confirmed = UTXO, or the whole contract is double-spendable. So the ability to = NOINPUT-spend a setup output should not be strictly needed. In some (but = not all) case it might make the protocol simpler, though. >=20 > So the philosophy behind output tagging is =E2=80=9Cavoid NOINPUT at = all cost, until it is truly unavoidable" >=20 After thinking more carefully, I believe output tagging could have no = adverse effect on eltoo. Consider a system without tagging, where you could always spend an = output with NOINPUT. Under taproot, state update could be made in 2 = ways: a) Making 2 sigs for each update. One sig is a =E2=80=9Cscript path=E2=80=9D= locktime NOINPUT spending of the setup output or an earlier update = output. One sig is a =E2=80=9Ckey path=E2=80=9D relative-locktime = NOINPUT spending of the new update output. In taproot terminology, = =E2=80=9Ckey path=E2=80=9D means direct spending with the scriptPubKey, = and =E2=80=9Cscript path=E2=80=9D means revealing the script hidden in = taproot. Key path spending is always cheaper. b) Making 3 sigs for each update. One sig is a key path SINGLEINPUT (aka = ANYONECANPAY) or NOINPUT spending of the setup output, without any = locktime. One sig is a script path locktime NOINPUT spending of an = earlier update output (if this is not the first update). One sig is a = key path relative-locktime NOINPUT spending of the new update output Note that in b), the first signature could be either SINGLEINPUT or = NOINPUT, and they just work as fine. So SINGLEINPUT should be used to = avoid unnecessary replayability. In the case of uncooperative channel closing, b) is always cheaper than = a), since this first broadcast signature will be a key path signature. = Also, b) has better privacy if no one is cheating (only the last update = is broadcast). The only information leaked in b) is the use of = SINGLEINPUT and the subsequent relative-locktime NOINPUT. However, the = script path signature in a) will leak the state number, which is the = maximum number of updates made in this channel. In conclusion, b) is cheaper and more private, but it is more complex by = requiring 3 sigs per update rather than 2. I think it is an acceptable = tradeoff. (And as I mentioned in my last mail, missing some SINGLEINPUT = sigs is not the end of the world. As long as you find one SINGLEINPUT = sig in your backup, it safely falls back to the trigger tx model) What if we require output tagging? For privacy reason you shouldn=E2=80=99= t tag your setup tx, so the setup output could not be spent with = NOINPUT. Option a) doesn=E2=80=99t work, but b) only requires = SINGLEINPUT and has no problem. So in a fee-minimising and = privacy-maximising eltoo design, output tagging should have no adverse = effect.= --Apple-Mail=_E74D8E40-FD61-454C-9DBE-DEE637C1307F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:



On 17 = Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen@gmail.com> = wrote:

Hi Johnson,

The design considerations here seem similar to the ML = discussion of
whether Graftroot should be optional [1].

Yes, but the =E2=80=9Ctagging=E2=80=9D emphasises more on the = payer=E2=80=99s side: if the payer cannot guarantee that the payee would = never reuse the key, the payer could avoid any NOINPUT-related trouble = by tagging properly.


While this seems fully compatible with eltoo, = is there any other proposals require NOINPUT, and is adversely affected = by either way of tagging?

As = far as I can tell it should be compatible with Statechains [2],
since it pretty much mirrors Eltoo in setup.

My understanding is somewhat lacking, so perhaps I am missing = the
mark, but it is not completely clear to me how this = affects
fungibility if taproot gets added and the setup = and trigger tx for
Eltoo get combined into a single = transaction. Would the NOINPUT
spending condition be = hidden inside the taproot commitment?

For the design considerations I = mentioned above, the tags must be explicit and configurable by the = payer. So it couldn=E2=80=99t be hidden in taproot.

If you don=E2=80=99t care about = fungibility, you can always tag your setup output, and makes it ready = for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to = spend the setup output or an earlier update output, and a NOINPUT to = settle the latest update output.

If you care about fungibility, you can=E2=80=99t tag your = setup output. Every update will need 3 signatures: a SINGLEINPUT (aka = ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier = update output, and a NOINPUT to settle the latest update = output.

(Actually, as = soon as you made the first update tx with SINGLEINPUT, you don=E2=80=99t = strictly need to make any SINGLEINPUT signatures in the later updates = again, as the first update tx (or any update with a SINGLEINPUT = signature) could be effectively the trigger tx. While it makes the = settlement more expensive, it also means accidentally missing a = SINGLEINPUT signature will not lead to any fund loss. So security-wise = it=E2=80=99s same as the always-tagging scenario.)

The most interesting observation = is: you never have the need to use NOINPUT on an already confirmed UTXO, = since nothing about a confirmed UTXO is mutable. And every smart = contract must anchor to a confirmed UTXO, or the whole contract is = double-spendable. So the ability to NOINPUT-spend a setup output should = not be strictly needed. In some (but not all) case it might make the = protocol simpler, though.

So the philosophy behind output tagging is =E2=80=9Cavoid = NOINPUT at all cost, until it is truly unavoidable"


After = thinking more carefully, I believe output tagging could have no adverse = effect on eltoo.

Consider a system without tagging, where you could always = spend an output with NOINPUT. Under taproot, state update could be made = in 2 ways:

a) = Making 2 sigs for each update. One sig is a =E2=80=9Cscript path=E2=80=9D = locktime NOINPUT spending of the setup output or an earlier update = output. One sig is a =E2=80=9Ckey path=E2=80=9D relative-locktime = NOINPUT spending of the new update output. In taproot terminology, = =E2=80=9Ckey path=E2=80=9D means direct spending with the scriptPubKey, = and =E2=80=9Cscript path=E2=80=9D means revealing the script hidden in = taproot. Key path spending is always cheaper.

b) Making 3 sigs for each update. One = sig is a key path SINGLEINPUT (aka ANYONECANPAY) or NOINPUT spending of = the setup output, without any locktime. One sig is a script path = locktime NOINPUT spending of an earlier update output (if this is not = the first update). One sig is a key path relative-locktime NOINPUT = spending of the new update output

Note that in b), the first signature = could be either SINGLEINPUT or NOINPUT, and they just work as fine. So = SINGLEINPUT should be used to avoid unnecessary replayability.

In the case of = uncooperative channel closing, b) is always cheaper than a), since this = first broadcast signature will be a key path signature. Also, b) has = better privacy if no one is cheating (only the last update is = broadcast). The only information leaked in b) is the use of SINGLEINPUT = and the subsequent relative-locktime NOINPUT. However, the script path = signature in a) will leak the state number, which is the maximum number = of updates made in this channel.

In conclusion, b) is cheaper and more = private, but it is more complex by requiring 3 sigs per update rather = than 2. I think it is an acceptable tradeoff. (And as I mentioned in my = last mail, missing some SINGLEINPUT sigs is not the end of the world. As = long as you find one SINGLEINPUT sig in your backup, it safely falls = back to the trigger tx model)

What if we require output tagging? For = privacy reason you shouldn=E2=80=99t tag your setup tx, so the setup = output could not be spent with NOINPUT. Option a) doesn=E2=80=99t work, = but b) only requires SINGLEINPUT and has no problem. So in a = fee-minimising and privacy-maximising eltoo design, output tagging = should have no adverse effect.
= --Apple-Mail=_E74D8E40-FD61-454C-9DBE-DEE637C1307F--