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


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

On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is =
as
> an attack because it's quite expensive for the attacker.=20

It's cheap if:

1. You were planning to consolidate all those UTXOs at roughly that
   feerate anyway.

2. After you no longer need your pinning transaction in the mempool, you
   make an out-of-band arrangement with a pool to mine a small
   conflicting transaction.

> But there are a few simple policies that can eliminate it:
>=20
> 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
> outputs. Restricting this via policy would help, or more flexibly
> limiting the total size of a sponsoring transaction to 1000 bytes.

I think that works (as policy).

> 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
> increase the feerate (perhaps with a constant relay fee bump to prevent
> spam).

I think it'd be hard to find a constant relay fee bump amount that was
high enough to prevent abuse but low enough not to unduly hinder
legitimate users.

> I think 1) is simpler and should allow full use of the sponsor mechanism
> while preventing this class of issue mostly.

Agreed.

Thanks,

-Dave

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

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

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9mPsEACgkQ2dtBqWwi
adP6TxAAonJHGZyqXB0sOZXfcSN7dusHD4lFsh18yGNmgwWk57ZAvnzyh/+AUEGY
naXzxXxlgBrnr43bAROQZg4Lv6tahIxo2JidUOJF0Meok5e8TFAmzuiRXb3WXXOT
9IQsZokwehlO8LifM7Lo1zoTm9xxCPRnKC/IDlhguMUVev6VQu7+y+o/59jpFkZ1
IR9y/Dv3p29MkvRsPW0+xY9TfXHN7Fus9uWLITtUVloDIPVlAsL7jSW3uVyGfLhN
/Rortyfk+vhPTQohiAfkjCV4wg+wuClEUyFzSe5Ox3ePlQ43eQjb3POJRM8ZceoB
JaHkbfc9JEZhswSkBaogkAFXWQZt4tv6wBhZlJRicpR7c22OAlGvpNSx/92PB5TS
V3YVbIcmE1443juDJTJWYM5i+KBUDmElVG7lWAXYYSUxtg+gtGWiZ0i8BxEkF6Mh
jDrFgR8DjKZ/EyIKYp4nJc9vwSDNq7PWpMYCj9SAGjO/a4ljO4xg6ExKRl0Uu3s8
4/Z7pnATBm4yahI3nmYzD+v9i5jw+nNOfhhCaQzDZUPrhYCQFwn5W/f0NU6pSNDC
uIT89cdYPbF+sT9Qw+fv1pC0JO0kx4CfaGJQY6PAEZEa0482/NsxG+TzsMhIpaSd
alKZ0hH94qu9Z0+BGYFp8fB3D8hbUm3S4Ls2TdbueAZXgE167QQ=
=ySgd
-----END PGP SIGNATURE-----

--o5ginote6izy2brv--