path: root/7c/3935a4a6c57e143c14bdd4840079ae4f8e615d

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 376F6BC0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
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 <jl2012@xbt.hk>
Message-Id: <BC5F60A5-5E45-4330-82A2-9124C83C232B@xbt.hk>
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: <B4234D7B-B1AA-41C3-B60B-F1E89E90A47D@xbt.hk>
To: Johnson Lau <jl2012@xbt.hk>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
	<B4234D7B-B1AA-41C3-B60B-F1E89E90A47D@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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>=20
>=20
>> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen@gmail.com =
<mailto:rsomsen@gmail.com>> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">On 17 =
Dec 2018, at 11:48 PM, Ruben Somsen &lt;<a =
href=3D"mailto:rsomsen@gmail.com" class=3D"">rsomsen@gmail.com</a>&gt; =
wrote:<br class=3D""><br class=3D"">Hi Johnson,<br class=3D""><br =
class=3D"">The design considerations here seem similar to the ML =
discussion of<br class=3D"">whether Graftroot should be optional [1].<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">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.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><blockquote type=3D"cite" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">While this seems fully compatible with eltoo, =
is there any other proposals require NOINPUT, and is adversely affected =
by either way of tagging?<br class=3D""></blockquote><br class=3D"">As =
far as I can tell it should be compatible with Statechains [2],<br =
class=3D"">since it pretty much mirrors Eltoo in setup.<br class=3D""><br =
class=3D"">My understanding is somewhat lacking, so perhaps I am missing =
the<br class=3D"">mark, but it is not completely clear to me how this =
affects<br class=3D"">fungibility if taproot gets added and the setup =
and trigger tx for<br class=3D"">Eltoo get combined into a single =
transaction. Would the NOINPUT<br class=3D"">spending condition be =
hidden inside the taproot commitment?<br class=3D""></blockquote><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">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.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">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.</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">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.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">(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.)</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">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.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">So the philosophy behind output tagging is =E2=80=9Cavoid =
NOINPUT at all cost, until it is truly unavoidable"</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote></div><br class=3D""><div class=3D"">After =
thinking more carefully, I believe output tagging could have no adverse =
effect on eltoo.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Consider a system without tagging, where you could always =
spend an output with NOINPUT. Under taproot, state update could be made =
in 2 ways:</div><div class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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)</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div></body></html>=

--Apple-Mail=_E74D8E40-FD61-454C-9DBE-DEE637C1307F--