From: Antoine Riard <antoine.riard@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
security@ariard•me,
"lightning-dev\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Date: Mon, 6 Nov 2023 18:45:21 +0000 [thread overview]
Message-ID: <CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com> (raw)
In-Reply-To: <ZUXyICh45JP6OnDu@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 5076 bytes --]
> I think you are misunderstanding a key point to my OP_Expire proposal:
because
> the ability to spend the preimage branch of the HTLC goes away when the
refund
> branch becomes available, replacing cycling or any similar technique
becomes
> entirely irrelevant.
> The situation where Carol prevents Bob from learning about the preimage
in time
> simply can't happen: either Carol collects the HTLC with knowledge of the
> preimage, by spending it in a transaction mined prior to the expiration
time
> and ensuring that Bob learns the preimage from the blockchain itself. Or
the
> HTLC expires and Bob can use the refund branch at his leisure.
I think I understand the semantic of the OP_Expire proposal overall
correctly, however I'm not sure it prevents replacing cycling or any
similar adversarial technique, as the forwarding node might be the attacker
in some scenario.
Consider the following: you have Alice, Bob, Caroll sharing lightning
channels.
Alice forwards a HTLC of 1 BTC to Caroll by the intermediary of Bob.
On the Bob-Caroll link, the HTLC expires at block 100.
According to OP_Expire semantics, Caroll shouldn't be able to claim the
htlc-preimage spends on the Bob-Caroll link, after block 100.
However, this situation offers the ability to Bob the routing node to steal
HTLC payment between Alice and Caroll.
Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob
does _not_ send back his signature for the updated channel state.
Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC
output with the preimage. Her commitment transaction propagation in network
mempools is systematically "replaced cycled out" by Bob.
At block 100, Caroll cannot claim the payment sent to her by Alice.
Bob claims the htlc-refund path on the Bob-Caroll link and claims the
htlc-preimage path on the Alice-Bob link, as such making a gain of 1 BTC.
If Caroll is a lightning mobile client, it is easy for Bob to claim
publicly that the lack of success in signature exchange to update channels
state is a liveliness mistake of her own.
Assuming this advanced scenario is correct, I'm not sure the OP_Expire
proposal is substantially fixing all the adversarial replacement cycling
situations.
Best,
Antoine
Le sam. 4 nov. 2023 à 07:26, Peter Todd <pete@petertodd•org> a écrit :
> On Fri, Nov 03, 2023 at 05:25:24AM +0000, Antoine Riard wrote:
> > > To be clear, are you talking about anchor channels or non-anchor
> channels?
> > > Because in anchor channels, all outputs other than the anchor outputs
> > provided
> > > for fee bumping can't be spent until the commitment transaction is
> mined,
> > which
> > > means RBF/CPFP isn't relevant.
> >
> > I think the distinction is irrelevant here as pre-anchor channel if I
> have
> > one spendable HTLC output spend and I gain knowledge of my counterparty
> > commitment transaction from networks mempools, the spend is malleable and
> > can be used as a CPFP. If you assume anchor channels, you have 2 anchor
> > outputs as long both parties have balance outputs or pending HTLCs.
> >
> > Though pre-anchor, legacy channels the counterparty commitment
> transaction
> > will have to be attached with a fee under min mempool fee for the
> > replacement cycling to happen, and let network congestion happen.
>
> I think you are misunderstanding a key point to my OP_Expire proposal:
> because
> the ability to spend the preimage branch of the HTLC goes away when the
> refund
> branch becomes available, replacing cycling or any similar technique
> becomes
> entirely irrelevant.
>
> The situation where Carol prevents Bob from learning about the preimage in
> time
> simply can't happen: either Carol collects the HTLC with knowledge of the
> preimage, by spending it in a transaction mined prior to the expiration
> time
> and ensuring that Bob learns the preimage from the blockchain itself. Or
> the
> HTLC expires and Bob can use the refund branch at his leisure.
>
> > I think the more interesting case is a future world with package relay
> > deployed at the p2p level and anchor output on the lightning-side. Here
> the
> > most advanced replacement as illustrated in the test can happen (where
> > commitment has an anchor output - see L125).
>
> Again, with OP_Expire, whether or not package relay or anything similar
> exists
> is irrelevant. Replacement cycling is totally useless because there is a
> defined time window in which the HTLC can be spent with the preimage, after
> which only the refund branch can be used.
>
> Indeed, with OP_Expire Lightning nodes will no longer need to monitor
> mempools
> for preimages at all. If the preimage is used, it is guaranteed to end up
> in
> the chain, and the Lightning node is guaranteed to see it provided they
> have
> access to up-to-date blockchain data.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
[-- Attachment #2: Type: text/html, Size: 6028 bytes --]
next prev parent reply other threads:[~2023-11-06 18:45 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 [this message]
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 ` [bitcoin-dev] Fwd: " Antoine Riard
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+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
--cc=security@ariard$(echo .)me \
/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