Feedback-ID: i525146e8:Fastmail
Date: Wed, 9 Nov 2022 07:41:30 -0500
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <Y2uf+hRBdLxOl6LT@petertodd.org>
References: <Y2ln2fJ+8+Q0qS0E@petertodd.org> <Y2l1/qXHxyctU9ir@petertodd.org>
 <CALZpt+GgH7B-sSWndNfrMp8qza=LmZQ6BWGGFjFxcutat7Nxww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="7mIKDqQd2eJ71wgz"
Content-Disposition: inline
In-Reply-To: <CALZpt+GgH7B-sSWndNfrMp8qza=LmZQ6BWGGFjFxcutat7Nxww@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning
 with nLockTime
Precedence: list


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

On Mon, Nov 07, 2022 at 05:55:59PM -0500, Antoine Riard wrote:
> Hi Peter,
>=20
> > We can ensure with high probability that the transaction can be cancell=
ed/mined
> > at some point after N blocks by pre-signing a transaction, with nLockTi=
me set
> > sufficiently far into the future, spending one or more inputs of the
> > transaction with a sufficiently high fee that it would replace transact=
ion(s)
> > attempting to exploit Rule #3 pinning (note how the package limits in B=
itcoin
> > Core help here).
>=20
> From my understanding, there are many open questions to such a
> pre-signed high-fee solution aiming to address Rule #3 pinning.
> Determining the high-fee to guarantee replacements with high odds. I
> think it should be superior to current top network mempools sat/vb *
> MAX_STANDARD_TX_WEIGHT, otherwise an adversary can pin the multi-party
> funded transaction on the ground of Core's
> replacement rule ("The replacement transaction's feerate is greater
> than the feerates of all directly conflicting transactions''). Though
> note the difficulty, the sat/vb is an unknown fact at time of
> signatures exchange among the multi-party funded transaction
> participants. Solving this issue probably requires from then to
> overshoot, and adopt a historical worst-case mempool feerate.

First of all, since this is a punishment scenario, overshooting in general =
is a
good thing provided that the bad actor is the one paying for the overshoot.

I may be mistaken on this point. But IIRC rule #6, "The replacement
transaction's feerate is greater than the feerates of all directly conflict=
ing
transactions.", refers to the overall package feerate including all
transactions that would need to be mined.

This is relevant as we have two scenarios for pinning that could try to exp=
loit
rule #6 while pinning, and neither works:

1) A large, low fee rate, transaction is spent by a high fee rate transacti=
on.
In this case the package fee rate of the second tx is still low, because the
low fee rate tx would need to be mined first.

2) A small, high fee rate tx, is spent by a large low fee rate tx. In this =
case
the second low fee rate tx is irrelevant, because the high fee rate tx will=
 get
mined soon, breaking the pin and costing the attacker money.


Now, if my understanding of rule #6 is incorrect, obviously we should fix t=
hat!
It's incentive incompatible to reject a high fee rate replacement that over=
all
pays more in fees (rule #3), on the basis that we expect a *different* mine=
r to
mine the low fee rate tx it spends. Because unless we're expecting the
transaction to somehow get mined by someone else in the near future, why ar=
en't
we mining what pays more money now?

> This "historically-worst" sat/vb introduces two new issues, first I
> think this is an economic lower bound on the funds that can be staked
> in the collaborative transaction. Second I believe this constitutes a
> griefing vector, where a participant could deliberately pin to inflict
> an asymmetric damage, without entering into any fee competition. This
> griefing vector could be leveraged as hard as being triggered by a
> miner-as-participant in so-called miner harvesting attacks.
>=20
> Further, I think this solution relying on nLocktime doesn't solve the
> timevalue DoS inflicted to the participants UTXOs, until the
> pre-signed high-fee transaction is final. If participants prefer to
> save the timevalue of their contributed UTXOs over operation success,
> a better approach could be for them to unilaterally spend after a
> protocol/implementation timepoint (e.g LN's funding timeout recovery
> mechanism).
>=20
> A more workable solution I believe could be simply to rely on
> package-relay, an ephemeral anchor output, and a special replacement
> regime (e.g nVersion=3D3) to allow the multi-party funded transaction
> coordinator to unilateral fee-bump, in a step-by-step approach. I.e
> without making assumptions on the knowledge of network mempools and
> burning directly the worst amount in fees.

Note that if you are considering miner harvesting attacks as part of the th=
reat
model, it's not clear to me that the v3 rules that depend on miners arbitra=
rily
rejecting transactions from their mempools are actually sufficiently incent=
ive
compatible to work.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNrn/cACgkQLly11TVR
LzdTTA//VMoanYSvWIxcN1GpRyLdr9ZXktlQGDqJvJEY/A70MymJCpH3Jm/cv8j4
FhgG70JZrMgXojjfF4PGASLBP7H3I5h0KET8/aIY8zw+55ywekUu5kombXAcAs6A
bENi69hDVFE3yboudb7GCazO99k4WtEiQHByndMroLwgRaHCGWUg0tOQdwFaY1I2
bvPrDoGDLCJIJY4r0PA+JGSdQgxywXUfabsUxRgReqKwWsdWsyD6jXb4WcGFkrL1
Cd7fr9Z1TTIflQbmFswoRKoeuGzPHphmRGT1Zqq77G1ypP6EY8BomWHSt6JnIZTY
ymNUyHjpxBVrV3vsSxFm5Qj4nhnan9pIGZ0NSOHebdyHh/H0lXTtbI9strCpCUye
WG6LomTCA6u2KQZBJbDX4J2bGwKiyI6MzFnIgtE17yrjTj6YSlAg+ZHH3oFk5+NQ
/tAhd81piAL3MJv2vUI3OhuvzDOfPj27/ikAH1R4+KXGZ8hUL7Q3Yx5i6gGWNRmf
a/f4UhkcZbNBgo+k5a9BUsbbkpVX85FvzBdCyh5pDIMMvOqMyFOJ9CWZYHs3P0sS
VTpCkibLPNZbCt4UL/8fZeap7/dhyzkqBaUXtwGo5Sb13eCaaKPkvstAz7wPFR98
l8zoUrTBMgd33cQDJpB1g2CDZ57l7TCvAlzfnJQ7k3otiLAssBo=
=Q2Iw
-----END PGP SIGNATURE-----

--7mIKDqQd2eJ71wgz--