From: Antoine Riard <antoine.riard@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>,
security@ariard•me
Subject: Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Date: Tue, 7 Nov 2023 15:44:21 +0000 [thread overview]
Message-ID: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com> (raw)
In-Reply-To: <iBopsZOx5TRDjjfxSLo9GLa00c7Jk0uMSae6_EPsPjnd10Aa87-lxVIZnL37GwEM3ppemBAxCwkv7r4w5AfDjLkKo0OhIpdB0jK0_OTRqf4=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
Hi Zeeman,
> Neither can Bob replace-recycle out the commitment transaction itself,
because the commitment transaction is a single-input transaction, whose
sole input requires a signature from
> Bob and a signature from Carol --- obviously Carol will not cooperate on
an attack on herself.
The replacement cycling happens on the commitment transaction spend itself,
not the second stage, which is effectively locked until block 100.
If the commitment transaction is pre-signed with 0 sat / vb and all the
feerate / absolute fee is provided by a CPFP on one of the anchor outputs,
Bob can replace the CPFP itself. After replacement of its child, the
commitment transaction has a package feerate of 0 sat / vb and it will be
trimmed out of the mempool.
This is actually the scenario tested here on the nversion = 3 new mempool
policy branch (non-deployed yet):
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
As of today commitment transactions might not propagate if dynamic mempool
min fee is above pre-signed commitment transaction, which is itself unsafe.
I think this behavior can currently be opportunistically exploited by
attackers.
In a post-package relay world, I think this is possible. And that
replacement cycling attacks are breaking future dynamic fee-bumping of
pre-signed transactions concerns me a lot.
Best,
Antoine
Le mar. 7 nov. 2023 à 11:12, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
> Good morning Antoine,
>
>
> > 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.
>
> I think this is impossible?
>
> In this scenario, there is an HTLC offered by Bob to Carol.
>
> Prior to block 100, only Carol can actually create an HTLC-success
> transaction.
> Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock
> says "wait till block 100".
>
> Neither can Bob replace-recycle out the commitment transaction itself,
> because the commitment transaction is a single-input transaction, whose
> sole input requires a signature from Bob and a signature from Carol ---
> obviously Carol will not cooperate on an attack on herself.
>
> So as long as Carol is able to get the HTLC-success transaction confirmed
> before block 100, Bob cannot attack.
> Of course, once block 100 is reached, `OP_EXPIRE` will then mean that
> Carol cannot claim the fund anymore.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 3462 bytes --]
next prev parent reply other threads:[~2023-11-07 15:44 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 [this message]
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+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.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