From: Peter Todd <pete@petertodd•org>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"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: Sat, 21 Oct 2023 10:31:05 +0000 [thread overview]
Message-ID: <ZTOoadyBiuKnzsgJ@petertodd.org> (raw)
In-Reply-To: <d8227003b4a6065414d32a31a7020a93@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]
On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote:
> On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote:
> > The basic problem here is after the HTLC-timeout path becomes spendable,
> > the
> > HTLC-preimage path remains spendable. That's bad, because in this case
> > we want
> > spending the HTLC-preimage - if possible - to have an urgency attached
> > to it to
> > ensure that it happens before the previous HTLC-timeout is mined.
> >
> > So, why can't we make the HTLC-preimage path expire?
>
> If the goal is to ensure the HTLC-preimage should be mined before an
> upstream HTLC-timeout becomes mineable, then I don't think a consensus
> change is required. We can just make the HTLC-preimage claimable by anyone
> some time after the HTLC-timeout becomes mineable.
>
> For example, imagine that Alice offers Bob an HTLC with a timeout at block
> t+200. Bob offers Carol an HTLC with a timeout at block t+100. The
> Bob-Carol HTLC script looks like this:
>
> If
> # Does someone have the preimage?
> Hash <digest> EqualVerify
> If
> # Carol has the preimage at any time
> <Carol key> CheckSig
> Else
> # Anyone else has the preimage after t+150
> <t+150> CLTV
> EndIf
> Else
> # Bob is allowed a refund after t+100
> <Bob key> CheckSigVerify
> <t+100> CLTV
> EndIf
>
> In English:
>
> - At any time, Carol can spend the output by releasing the preimage
> - After t+100, Bob can spend the output
> - After t+150, anyone with the preimage can spend the output
This is a clever idea. But it doesn't prevent this attack.
Think about it this way: where previously there was one Carol who could perform
the replacement cycling attack, with the anyone-can-spend branch the situation
eventually transforms into a situation where there is an unlimited set of
Carols who can perform the attack and, if they are a miner, benefit from it.
Either way Bob is in a position where they might not learn about the preimage
in time, and thus fail to redeem the received HTLC output.
From Carol's point of view the situation didn't significantly change. Either
they manage to succesfully spend the offered HTLC output after the redeemed
HTLC output times out. Or they fail. Whether or not that failure happens
because Bob got their refund, or someone else spent the offered HTLC output via
the anyone-can-spend path is not relevant to Carol.
Finally, this solution is inferior to OP_Expire in another important way: the
anyone-can-spend branch represents a strict deadline for Bob too. With
OP_Expire, once HTLC preimage branch has expired, Bob can spend the offered
HTLC output at their leisure, as they are the only party with the ability to do
that (assuming of course that we're talking about a valid commitment
transaction, not an illegitmate revoked once).
> [2] Although miners may want to consider running code that allows them to
> rewrite any malleable transactions to pay themselve
With full-RBF _anyone_ can run that code on behalf of miners, modulo edge cases
where the replacement isn't possible due to the RBF anti-DoS rules. Indeed,
people are apparently already doing this to screw over signature-less ordinal
transactions.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-10-21 10:31 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 [this message]
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 ` [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=ZTOoadyBiuKnzsgJ@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
--cc=lightning-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