Date: Sat, 19 Sep 2020 09:37:16 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200919133716.d5ofags2tprlvpqm@ganymede>
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="2q76l6a6fd2jepv6"
Content-Disposition: inline
In-Reply-To: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
 TXID Dependencies for Fee Sponsoring
Precedence: list


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

On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to replace
> CPFP and RBF for increasing fees on transactions in the mempool that
> should be more robust against attacks.

Interesting idea!  This is going to take a while to think about, but I
have one immediate question:

> To prevent garbage sponsors, we also require that:
>=20
> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fe=
e rate
>=20
> We allow one Sponsor to replace another subject to normal replacement
> policies, they are treated as conflicts.

Is this in the reference implementation?  I don't see it and I'm
confused by this text.  I think it could mean either:

1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
   one input in common (which is part of the "normal replacement policies")

2. A can be replaced by B even if they don't have any inputs in common
   as long as they do have a Sponsor Vector in common (while otherwise
   using the "normal replacement policies").

In the first case, I think Mallory can prevent Bob from
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
sponsor before he does; since Bob has no control over Mallory's inputs,
he can't replace Mallory's sponsor tx.

In the second case, I think Mallory can use an existing pinning
technique to make it expensive for Bob to fee bump.  The normal
replacement policies require a replacement to pay an absolute higher fee
than the original transaction, so Mallory can create a 100,000 vbyte
transaction with a single-vector sponsor at the end pointing to Bob's
transaction.  This sponsor transaction pays the same feerate as Bob's
transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.  In order
for Bob to replace Mallory's sponsor transaction with his own sponsor
transaction, Bob needs to pay the incremental relay feerate (10
nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).

Thanks,

-Dave

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

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

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9mCYwACgkQ2dtBqWwi
adOspg/+JFtCGY4wV9MP4WOoM85Oyzff1VViM6sC+boiTfQJ+vMvxYqiNvJe07lZ
G5YGVjs3VwAX8ss7L0PT7uQ9dtYP5PHwJCgY3LUIDEcmbauV9oEiv/1DoNZeq8Kn
79mZ7uHexdpRRXSf1El9muQPVB6wtUrj02IiHR+mEh+/sGcgIpDrP8n3x6XVNkDF
sIiBxRvjci0pZREIZ+kXkfpShyl7Tx2pNHUf1eDMPQiJHxgQ6k2RgOcy3Cqjcbh4
P4MYAz2zvUPQU4ZF5/F4MaXundySbQL38FAiQ83hYMXnrTeGMncS2+YofbZLrqp/
a7UG7/79ITcivYBVLd3chg6dS20ba5o6sHqp1IdApz9i1sEYKYBvWIz/8MvqwN81
VXgxnBQIlxUVsb95RW8ei14zG5gpFRqr7RXI8P7XGLvMDQZfi2dGMwcifbdfMcWy
mZ7FKRzhsWQeXvmPO9MVW6ZET/bDHo3tOnPrlHBFhi5d5ihWPdyfyvf+om2gDITj
Tz/AkGD0M6Z50DOmHG8kgHGIZYbqzsy0hr/hLdKnUmnjBdMY4faMDz49k6FdRq0F
/sKEZfixt2CZzDNkQqLEU0k05y9Ri4sqF8Bu6ajI9Y5NsExmBpAp5ryK7dKfhM/w
Y+I0P05PE5dJm2gwO9jJSWZE783ftRy5m5oIbmEnmTw/PpMWVDo=
=D9WZ
-----END PGP SIGNATURE-----

--2q76l6a6fd2jepv6--