Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 44585C0032 for ; 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 ; 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 ; 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 ; 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 ; 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: In-Reply-To: From: Antoine Riard Date: Wed, 15 Nov 2023 17:53:57 +0000 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> No, that's not a general underlying issue. You= 9;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 g= et detected or mined. There's
> probably tweaks we can do to impr= ove this security. But the general principle
> there is certainly tru= e.

I see your point in saying we have two separate i= ssues, one the on-chain inclusion of "expired" 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 "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 specifi= ed period of time, the proof is no longer convincing.

<= 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.

> For a lightning channel to be economical at all i= n a general routing
> environment, the highest likely fee has to be s= mall enough for it to represent
> a small percentage of the total val= ue tied up in the Lightning channel. Tying
> up a small percentage of= the overall capacity for future fee usage is not a
> significant exp= ense.

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.

> That attack d= oesn't make sense. HTLCs go to fees at a certain feerate. In a
> = normal environment where there is a constant supply of fee paying transacti= ons,
> the profit for the miner is not the total HTLC value, but the = increase in
> feerate compared to the transactions they had to give u= p 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 transactio= n more interesting than the marginal known transaction in a miner block tem= plate. If there is an environment where you'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'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 atta= cks.

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

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).

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

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.

> D= o you have a concrete attack?
=

I don't have a concrete attack with sufficien= t testing to say with a satisfying level of certainty that I have a concret= e attack.

> No, you are missing the point. RBF = replacements can use SIGHASH_NOINPUT to sign
> HTLC refund transactio= ns, removing the need for a set of different HTLC refund
> transactio= ns for each different feerate of the commitment transaction.
=
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.

> I'm maki= ng 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=C2=A0from Lightning is always going to be hopelessly inse= cure when you can't at
> least somewhat trust your counterparty. = If your usage of LN-Symmetry is
> sufficiently secure, you probably d= on't have to worry about them playing fee
> games with you either= .

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

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

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.
Here low-hashrate capability can be understood as "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= ".
--00000000000000b883060a349727--