Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

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 --]