From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Fwd: OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Date: Wed, 15 Nov 2023 17:53:57 +0000 [thread overview]
Message-ID: <CALZpt+ERdc5XFyiAyc-3KpU=5Wh1KZTfsNNsLn_Nj60OwqjXTg@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5708 bytes --]
> 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".
[-- Attachment #2: Type: text/html, Size: 6757 bytes --]
next prev parent reply other threads:[~2023-11-15 17:54 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 16:57 [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10 ` Matt Morehouse
2023-10-17 1:11 ` Antoine Riard
2023-10-20 10:47 ` Peter Todd
2023-10-20 11:18 ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17 7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34 ` ZmnSCPxj
2023-10-17 18:34 ` Antoine Riard
2023-10-20 10:31 ` Peter Todd
2023-10-20 11:03 ` Peter Todd
2023-10-20 18:35 ` Matt Morehouse
2023-10-20 21:05 ` Matt Corallo
2023-10-21 0:15 ` Peter Todd
2023-10-21 1:03 ` Matt Corallo
2023-10-21 1:25 ` Peter Todd
2023-10-21 1:55 ` Matt Corallo
2023-10-21 2:43 ` Peter Todd
2023-10-23 16:09 ` Matt Corallo
2023-10-17 17:47 ` Antoine Riard
2023-10-17 18:47 ` Antoine Riard
2023-10-18 0:17 ` Matt Corallo
2023-10-18 2:57 ` Antoine Riard
2023-10-19 8:12 ` Bastien TEINTURIER
2023-10-19 16:23 ` Matt Morehouse
2023-10-19 17:22 ` Antoine Riard
2023-10-19 17:53 ` Matt Morehouse
2023-10-19 19:33 ` Antoine Riard
2023-10-21 0:18 ` Olaoluwa Osuntokun
2023-11-17 22:36 ` Antoine Riard
2023-10-19 18:02 ` Matt Corallo
2023-10-20 6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05 ` Antoine Riard
2023-10-27 0:43 ` Peter Todd
2023-11-02 4:46 ` Antoine Riard
2023-10-21 0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21 8:58 ` David A. Harding
2023-10-21 10:31 ` Peter Todd
2023-10-22 8:30 ` vjudeu
2023-10-23 11:10 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45 ` Peter Todd
2023-11-02 5:24 ` [bitcoin-dev] " Antoine Riard
2023-11-02 6:26 ` Peter Todd
2023-11-02 17:07 ` Matt Morehouse
2023-11-03 5:27 ` Antoine Riard
2023-11-03 5:25 ` Antoine Riard
2023-11-04 7:26 ` Peter Todd
2023-11-06 18:45 ` Antoine Riard
2023-11-07 11:11 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44 ` Antoine Riard
2023-11-08 0:51 ` [bitcoin-dev] " Peter Todd
2023-11-08 2:06 ` Peter Todd
2023-11-13 2:18 ` Antoine Riard
2023-11-14 19:50 ` Peter Todd
[not found] ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53 ` Antoine Riard [this message]
2023-10-22 4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23 8:49 ` David A. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+ERdc5XFyiAyc-3KpU=5Wh1KZTfsNNsLn_Nj60OwqjXTg@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox