Feedback-ID: i525146e8:Fastmail
Date: Sat, 21 Oct 2023 10:31:05 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Message-ID: <ZTOoadyBiuKnzsgJ@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <d8227003b4a6065414d32a31a7020a93@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Lqg97VChZWNaQLNt"
Content-Disposition: inline
In-Reply-To: <d8227003b4a6065414d32a31a7020a93@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
Precedence: list


--Lqg97VChZWNaQLNt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > So, why can't we make the HTLC-preimage path expire?
>=20
> 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 anyo=
ne
> some time after the HTLC-timeout becomes mineable.
>=20
> 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:
>=20
> 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
>=20
> In English:
>=20
> - 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 per=
form
the replacement cycling attack, with the anyone-can-spend branch the situat=
ion
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 preima=
ge
in time, and thus fail to redeem the received HTLC output.

=46rom Carol's point of view the situation didn't significantly change. Eit=
her
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: t=
he
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 t=
o 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 c=
ases
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 ordin=
al
transactions.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--Lqg97VChZWNaQLNt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmUzqGMACgkQLly11TVR
LzdnNg//ZASXljy3w1Pl34linoqQS/fExNLvCWDCMr0zTCrfIeG5umt+YWqTSjJx
WaXf/w8JybyYkl6aHe4Mvd/9EKplBZCX2/d0UmL493GhHwFoWlt+HJxnvZUlTU1p
gAJr3m/cGPIV20C/Hdv78wAfu2ktrtD8StNa6UYYuU06qjAtS5OcTrPXjo7c593e
Nl35FpNmKtxIP9Z7ecOibhDAvDw9K7TkZiIaYH4+XZDG8E0X0KOyeVQjnMClK3Z+
oyEq2E/bwXSqtxdvFAqywICa7fjIDnc3KnO5xgomj4Rz1/HbgXUZeqS3qDxwCPtc
NZJeaurIRFnOc/Rrcvf3Bo1Rr575KwO4OAS8Wis6BJaweW5aVJ8hCBWQfORk1JH5
CEIPQExaX+DYpmUAQN0zJuQ+fdtPDwy3wtySQYTAe9UPD7vQyUEw0dpN67QZJPH4
D6YIYxN2tAUSRVvQQKU9pOCnyxyDlTgkgE3Ci+MotxQEZUePSufpmQIyHiiM8TtV
+eobV7JP0xYtLaMaaqW5peeHtUd4VxKTzh4mmqSYcDakMs2F6N3lTJCzMde3AJrB
urk0f0pkNeZgUX0hS/rtdPimjdh38tBYih2XfoEfEmBABvBuUpjYMMIFBlpe7BNF
nYp3yXUIvJNl6OqgkiW5TmJMXvzQM11oJkQ+Ae4qTV2PEmgM48A=
=+1cE
-----END PGP SIGNATURE-----

--Lqg97VChZWNaQLNt--