Feedback-ID: i525146e8:Fastmail
Date: Wed, 8 Nov 2023 00:51:31 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <ZUrbk9a9jiL87pxd@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Pi2QqCtP9yCVsVtf"
Content-Disposition: inline
In-Reply-To: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com>
 <CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com>
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
Precedence: list


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

On Mon, Nov 06, 2023 at 06:45:21PM +0000, Antoine Riard wrote:
> > 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.
>=20
> > 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 t=
he
> > 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.
>=20
> 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 attack=
er
> in some scenario.

<snip>

> Assuming this advanced scenario is correct, I'm not sure the OP_Expire
> proposal is substantially fixing all the adversarial replacement cycling
> situations.

What you are describing here is a completely different problem than what
OP_Expire aims to solve.

The problem that OP_Expire aims to solve is the fact that Carol could preve=
nt
Bob from learning about the preimage in time, while still getting a chance =
to
use the preimage herself. OP_Expire thoroughly solves that problem by ensur=
ing
that the preimage is either broadcast in the blockchain in a timely fashion=
, or
becomes useless.

The problem you are describing, as Zmm points out below, doesn't actually e=
xist
in Bitcoin right now. But it could exist if we adopted v3 package relay, wh=
ich
as I've pointed out elsewhere, is inferior to using RBF.


On Tue, Nov 07, 2023 at 03:44:21PM +0000, Antoine Riard wrote:
> Hi Zeeman,
>=20
> > 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.
>=20
> The replacement cycling happens on the commitment transaction spend itsel=
f,
> not the second stage, which is effectively locked until block 100.
>=20
> 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.
>=20
> This is actually the scenario tested here on the nversion =3D 3 new mempo=
ol
> policy branch  (non-deployed yet):
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>=20
> As of today commitment transactions might not propagate if dynamic mempool
> min fee is above pre-signed commitment transaction, which is itself unsaf=
e.
> I think this behavior can currently be opportunistically exploited by
> attackers.

Yes, obviously it can be. For starters, you can easily end up in a situation
where the commitment transaction simply can't get mined, an obvious problem.

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

Well the answer here is pretty clear: v3 package relay with anchors is brok=
en.

My suggestion of pre-signing RBF replacements, without anchor outputs, and =
with
all outputs rendered unspendable with 1 CSV, is clearly superior: there are
zero degrees of freedom to the attacker, other than the possibility of
increasing the fee paid or broadcasting a revoked commitment. The latter of
course risks the other party punishing the fraud.

This does have the practical problem that a set of refund transactions will
also need to be signed for each fee variant. But, eg, signing 10x of each i=
sn't
so burdensome. And in the future that problem could be avoided with
SIGHASH_NOINPUT, or replacing the pre-signed refund transaction mechanism w=
ith
a covenant.

Using RBF rather than CPFP with package relay also has the advantage of bei=
ng
more efficient, as no blockspace needs to be consumed by the anchor outputs=
 or
transactions spending them. Of course, there are special circumstances where
BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, eg by
reducing the replacement relay fee, or by delta-encoding transaction update=
s.


As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing both=
 it
and OP_Expire could make sense.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmVK25EACgkQLly11TVR
Lzd6ZRAAgpGQmGngE/Wnz87IeQiSZnlR9l4AVHMrx1GUqU1id7DoV+WMytwLqEz5
fMQ4Cj1tKnc3ELKWJgOuXNaeHi9hu1yzBxYAoaLBqVujHJ56H8kjVGX3NPfhfjxf
5pn5kOXQBnosm5++3H5k9MvxgGvXE4LkXKszFXEVRw5Yaal33J1HYJzSpKbHcrxN
f7WjGePzOSjrTRR5wPbIS/Yr1AXzyXsVqi4dQY1i7T4g5UvcxcByDUuYLEiWb1mH
WjvG5dZ/FiMKLKPMLib/pPvwcx3xs6fFNEq1ketdBS7B1l+Ddqfju/5jyjtnJPl/
nwiA9Dl8vSUGJFxIlen3fg/d+FSZWuQUYmLLnABsoU6xi7q1xWYr9MCLvLAq06G9
eX718SAh1xyeRpZyIvdS5OK9JP9m918yZtZ6/fysnlwYV27YhtvkLG3ceBy2tvW1
GQRwfWtsNaZAJ0EKlSiFxDznE6U4J1dQKf52PTM6QkDTElAVEEroWjzgNa6MRnB0
tDpryrlaNe9G3RJusAJTanTbU8Esmr7I6T1mFvl2u75FATn1lWNOkVuIKp+xIYGj
tDQDIZ/dDKPAaW7DzUNh10RWdw+TPeweu3q0Q29CRa6xeSRfmdAS9oV2FxclQXbW
jIcprbbk0dSlHGNb8yycQfMUrsMnApkB90dcIYLb03TasFt3Y7Q=
=edNz
-----END PGP SIGNATURE-----

--Pi2QqCtP9yCVsVtf--