path: root/c0/2fb1ed82380807e83b09c5fb4622ca9a15a1a7

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 44585C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Nov 2023 17:54:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 201E760F80
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Nov 2023 17:54:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 201E760F80
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=Z8QVQiGp
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tES2RjWc0gc4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Nov 2023 17:54:09 +0000 (UTC)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com
 [IPv6:2607:f8b0:4864:20::d2b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6C28E607F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Nov 2023 17:54:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6C28E607F5
Received: by mail-io1-xd2b.google.com with SMTP id
 ca18e2360f4ac-7a93df91813so267047839f.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Nov 2023 09:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700070848; x=1700675648;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=dnejKjChqKPVvshLL8IRqNKqpMnZRytPdvQqNESbciw=;
 b=Z8QVQiGpl29MrdTp8uqIi06EQHnRKA6+cCJPHjqee/Ja25zOUnjakQzav4+tZyd1Fb
 mV+SusK7W7o+BM1BYHaUC51gQniM3uuV0EIYJ7j9YfHw17l208L8Dr64o4flHFJUcxnH
 xQpuAVbpThePlNK+B7K2YJz75WQ0/9HDa1H12v7NPHy+WPPn14PuOS5h2xb2xHarmqcp
 tyw77Jn/rTPnox59DgltLOUMdTtPiO6HV8t7YzI03kTXk4aIzgu3gvqPIfMRtk7r19PA
 ajXDDtlpzEIa3/OuV1sQqex/laYe8jGpi2HY8SLL4/PRNLslxg5o+6rg1nvUKCFzIzaC
 gVgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700070848; x=1700675648;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=dnejKjChqKPVvshLL8IRqNKqpMnZRytPdvQqNESbciw=;
 b=K85lK4kDkY5ZLJjKT+zIjdBcg374ETUTiViAyuiQTxJ4BoYnTcJDx2JEknAf1CsISd
 ZkVu8hAwNfBDJYIW+LZDqZnn3P6wpKbJz7GTor+Rg5RL/aZRqUQEG3PxXU87voso0xiQ
 d3J15ZV9/pnLd1QMZhWKAJWGwnS36iGRu0VkmSL2t+nUZdx4W20hOQ+U70xHIaT7PY0y
 1S+voIqiDm1D2NIcbSpe04fBWSluIUSvQLr7jXt8Ssi8A+vTL2e7JAz5V9AD1jRB5HbI
 lWrPAJSl6eV6a29m265bFSLVY3Km6vEttAmeu3EoDrTnpvaR8JvYPdCdqK+Ea60VXOcm
 Vb5Q==
X-Gm-Message-State: AOJu0YyYN60Jt8pwFzfszhHnmkDoOz0viTQ9nIE3CaKuqMpwLSJMcLXF
 uCYA/oM7Lpt88z02uudI64KlKrk9iBHCuz0GP+O/TEGoK1E=
X-Google-Smtp-Source: AGHT+IEI4cRo0RCA91UhwdIJ4Vaf+JZqnmBjldfoQfMM+RZpfQBMlZ0eENu+oDmQZuUTUCCn0O0PwaZDP26kWbZ9rpU=
X-Received: by 2002:a05:6e02:1445:b0:359:4f85:b215 with SMTP id
 p5-20020a056e02144500b003594f85b215mr17918984ilo.31.1700070848246; Wed, 15
 Nov 2023 09:54:08 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com>
 <CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com>
 <ZUrbk9a9jiL87pxd@petertodd.org> <ZUrtHyQBOEZTM3Bj@petertodd.org>
 <CALZpt+FEwjwQQWY6TBFuWeZbqC6Ywa7eSTcpqYuQPZ6+6QBzaw@mail.gmail.com>
 <ZVPPbNdmPxahOGqA@petertodd.org>
 <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
In-Reply-To: <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 15 Nov 2023 17:53:57 +0000
Message-ID: <CALZpt+ERdc5XFyiAyc-3KpU=5Wh1KZTfsNNsLn_Nj60OwqjXTg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000000b883060a349727"
X-Mailman-Approved-At: Wed, 15 Nov 2023 19:41:05 +0000
Subject: [bitcoin-dev] Fwd: OP_Expire and Coinbase-Like Behavior: Making
 HTLCs Safer by Letting Transactions Expire Safely
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 15 Nov 2023 17:54:11 -0000

--00000000000000b883060a349727
Content-Type: text/plain; charset="UTF-8"

> No, that's not a general underlying issue. You've found two separate
issues.

> Furthermore, revoked states are clearly different than HTLCs: they're
> fraudulent, and thus in punishment-using protocols they are always
associated
> with high risks of loss if they do in fact get detected or mined. There's
> probably tweaks we can do to improve this security. But the general
principle
> there is certainly true.

I see your point in saying we have two separate issues, one the on-chain
inclusion of "expired" off-chain output spend (e.g the HTLC-preimage), the
other one the usage of revoked or updated or asymmetric states to jam the
confirmation of a valid off-chain state. I do think the second one would
bring a solution to the first one, as you will be always sure that your
counterparty cannot "replay" an "expired" off-chain output at its advantage.

Even for solving the first issue, I'm not sure op_expire is enough, you
need to expire the worthiness of an off-chain revealed witness secret too
(here the preimage). E.g using short-lived proofs, i.e after a specified
period of time, the proof is no longer convincing.

I still think op_exire is interesting on its own, beyond solving any
security issue. E.g for Discreet Log Contract, one can build a time-bounded
sequential claim of the same output fund among a set of counterparties.

> For a lightning channel to be economical at all in a general routing
> environment, the highest likely fee has to be small enough for it to
represent
> a small percentage of the total value tied up in the Lightning channel.
Tying
> up a small percentage of the overall capacity for future fee usage is not
a
> significant expense.

Sure, I still think this introduces the corollary for lightning nodes that
any payment under the highest likely fee now has a probabilistic security,
where the lightning node should make guesses on the worst-level of mempools
feerate that can happen between the timelock duration of said payment.

> That attack doesn't make sense. HTLCs go to fees at a certain feerate. In
a
> normal environment where there is a constant supply of fee paying
transactions,
> the profit for the miner is not the total HTLC value, but the increase in
> feerate compared to the transactions they had to give up to mine the
commitment
> transaction.

The attack makes sense in an environment where the level of HTLC trimmed as
fees on the commitment transaction renders the feerates of this transaction
more interesting than the marginal known transaction in a miner block
template. If there is an environment where you're always guaranteed there
is a constant supply of fee paying transactions paying a better feerate
than the highest-fee rate that trimmed HTLCs can be a commitment
transaction, of course the attack wouldn't be plausible.

In a world where you have a dynamic blockspace demand market and
asymmetries of information, Lightning routing nodes will be always exposed
to such attacks.

> Second, it's obvious that the total trimmed HTLCs should be limited to
what
> would be a reasonable transaction fee. A situation where you have 80% of
the
> channel value going to fees due to a bunch of small HTLCs is obviously
> ridiculous, and to the extent that existing implementations have this
issue,
> should be fixed.

This is the hard thing, the existence of asymmetries of information in what
is a reasonable transaction fee and what is the level of mempools fee rates
at time of broadcast. One could imagine a consensus change where trimmed
HTLCs not worthy at the last X blocks of feerates are automatically
aggregated or trimmed (think median-time-past though for median fee rates
over X blocks).

> Yes, obviously. But as I said above, it just doesn't make sense for
channels to
> be in a situation where closing them costs a significant % of the channel
value
> in fees, so we're not changing the status quo much.

Evaluation of the significant % of the channel value burned in fees in the
worst-case at time of off-chain state commitment is the hard thing.

> Do you have a concrete attack?

I don't have a concrete attack with sufficient testing to say with a
satisfying level of certainty that I have a concrete attack.

> No, you are missing the point. RBF replacements can use SIGHASH_NOINPUT
to sign
> HTLC refund transactions, removing the need for a set of different HTLC
refund
> transactions for each different feerate of the commitment transaction.

See above, I think this solution with RBF replacement is robust on the
assumption you cannot use the commitment transaction to jam the
HTLC-preimage until your HTLC-refund transaction is valid (under
nLocktime). Though my point here was only about the LN-symmetry states, not
second-stage transactions on top of them.

> I'm making no comment on how to do RBF replacements with LN-Symmetry,
which I
> consider to be a broken idea in non-trusted situations anyway
> Removing justice from Lightning is always going to be hopelessly insecure
when you can't at
> least somewhat trust your counterparty. If your usage of LN-Symmetry is
> sufficiently secure, you probably don't have to worry about them playing
fee
> games with you either.

I agree here that LN-symmetry would be better if you can conserve the
punishment ability.

See
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002064.html

On the lack of worries about playing fees games with you, see concern above
if your counterparty is a miner, even one with low-hashrate capability.
Here low-hashrate capability can be understood as "do you have a non-null
chance to mine a block as long as a HTLC-output is committed on an
off-chain state only known among off-chain counterparties e.g".

--00000000000000b883060a349727
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; No, that&#39;s not a general underlying issue. You&#3=
9;ve found two separate issues.<br><div class=3D"gmail_quote"><div dir=3D"l=
tr"><br>&gt; Furthermore, revoked states are clearly different than HTLCs: =
they&#39;re<br>&gt; fraudulent, and thus in punishment-using protocols they=
 are always associated<br>&gt; with high risks of loss if they do in fact g=
et detected or mined. There&#39;s<br>&gt; probably tweaks we can do to impr=
ove this security. But the general principle<br>&gt; there is certainly tru=
e.<br><div><br></div><div>I see your point in saying we have two separate i=
ssues, one the on-chain inclusion of &quot;expired&quot; off-chain output s=
pend (e.g the HTLC-preimage), the other one the usage of revoked or updated=
 or asymmetric states to jam the confirmation of a valid off-chain=C2=A0sta=
te. I do think the second one would bring a solution to the first one, as y=
ou will be always sure that your counterparty cannot &quot;replay&quot; an =
&quot;expired&quot; off-chain output at its advantage.</div><div><br></div>=
<div>Even for solving the first issue, I&#39;m not sure op_expire is enough=
, you need to expire the worthiness of an off-chain revealed witness secret=
 too (here the preimage). E.g using short-lived proofs, i.e after a specifi=
ed period of time, the proof is no longer convincing.</div><div><br></div><=
div>I still think op_exire is interesting on its own, beyond solving any se=
curity issue. E.g for Discreet Log Contract, one can build a time-bounded s=
equential claim of the same output fund among a set of counterparties.</div=
><div><br></div><div>&gt; For a lightning channel to be economical at all i=
n a general routing<br>&gt; environment, the highest likely fee has to be s=
mall enough for it to represent<br>&gt; a small percentage of the total val=
ue tied up in the Lightning channel. Tying<br>&gt; up a small percentage of=
 the overall capacity for future fee usage is not a<br>&gt; significant exp=
ense.<br></div><div><br></div><div>Sure, I still think this introduces the =
corollary for lightning nodes that any payment under the highest likely fee=
 now has a probabilistic security, where the lightning node should make gue=
sses on the worst-level of mempools feerate that can happen between the tim=
elock duration of said payment.</div><div><br></div><div>&gt; That attack d=
oesn&#39;t make sense. HTLCs go to fees at a certain feerate. In a<br>&gt; =
normal environment where there is a constant supply of fee paying transacti=
ons,<br>&gt; the profit for the miner is not the total HTLC value, but the =
increase in<br>&gt; feerate compared to the transactions they had to give u=
p to mine the commitment<br>&gt; transaction.<br></div><div><br></div><div>=
The attack makes sense in an environment where the level of HTLC trimmed as=
 fees on the commitment transaction renders the feerates of this transactio=
n more interesting than the marginal known transaction in a miner block tem=
plate. If there is an environment where you&#39;re always guaranteed there =
is a constant supply of fee paying transactions paying a better feerate tha=
n the highest-fee rate that trimmed HTLCs can be a commitment transaction, =
of course the attack wouldn&#39;t be plausible.</div><div><br></div><div>In=
 a world where you have a dynamic blockspace demand market and asymmetries =
of information, Lightning routing nodes will be always exposed to such atta=
cks.</div><div><br></div><div>&gt; Second, it&#39;s obvious that the total =
trimmed HTLCs should be limited to what<br>&gt; would be a reasonable trans=
action fee. A situation where you have 80% of the<br>&gt; channel value goi=
ng to fees due to a bunch of small HTLCs is obviously<br>&gt; ridiculous, a=
nd to the extent that existing implementations have this issue,<br>&gt; sho=
uld be fixed.<br></div><div><br></div><div>This is the hard thing, the exis=
tence of asymmetries of information in what is a reasonable transaction fee=
 and what is the level of mempools fee rates at time of broadcast. One coul=
d imagine a consensus change where trimmed HTLCs not worthy at the last X b=
locks of feerates are automatically aggregated or trimmed (think median-tim=
e-past though for median fee rates over X blocks).</div><div><br></div><div=
>&gt; Yes, obviously. But as I said above, it just doesn&#39;t make sense f=
or channels to<br>&gt; be in a situation where closing them costs a signifi=
cant % of the channel value<br>&gt; in fees, so we&#39;re not changing the =
status quo much.<br></div><div><br></div><div>Evaluation of the significant=
=C2=A0% of the channel value burned in fees in the worst-case at time of of=
f-chain state commitment is the hard thing.</div><div><br></div><div>&gt; D=
o you have a concrete attack?<span style=3D"color:rgb(80,0,80)"><br></span>=
</div><div><br></div><div>I don&#39;t have a concrete attack with sufficien=
t testing to say with a satisfying level of certainty that I have a concret=
e attack.</div><div><br></div><div>&gt; No, you are missing the point. RBF =
replacements can use SIGHASH_NOINPUT to sign<br>&gt; HTLC refund transactio=
ns, removing the need for a set of different HTLC refund<br>&gt; transactio=
ns for each different feerate of the commitment transaction.<br></div><div>=
<br></div><div>See above, I think this solution with RBF replacement is rob=
ust on the assumption you cannot use the commitment transaction to jam the =
HTLC-preimage until your HTLC-refund transaction is valid (under nLocktime)=
. Though my point here was only about the LN-symmetry states, not second-st=
age transactions on top of them.</div><div><br></div><div>&gt; I&#39;m maki=
ng no comment on how to do RBF replacements with LN-Symmetry, which I</div>=
&gt; consider to be a broken idea in non-trusted situations anyway<div>&gt;=
 Removing justice=C2=A0from Lightning is always going to be hopelessly inse=
cure when you can&#39;t at<br>&gt; least somewhat trust your counterparty. =
If your usage of LN-Symmetry is<br>&gt; sufficiently secure, you probably d=
on&#39;t have to worry about them playing fee<br>&gt; games with you either=
.<br><div><br></div><div>I agree here that LN-symmetry would be better if y=
ou can conserve the punishment ability.</div><div><br></div><div>See=C2=A0<=
a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Ju=
ly/002064.html" target=3D"_blank">https://lists.linuxfoundation.org/piperma=
il/lightning-dev/2019-July/002064.html</a></div><div><div><br></div><div>On=
 the lack of worries about playing fees games with you, see concern above i=
f your counterparty is a miner, even one with low-hashrate capability.</div=
></div></div><div>Here low-hashrate capability can be understood as &quot;d=
o you have a non-null chance to mine a block as long as a HTLC-output is co=
mmitted on an off-chain state only known among off-chain counterparties e.g=
&quot;.</div></div>
</div></div>

--00000000000000b883060a349727--