Date: Thu, 10 Feb 2022 01:58:56 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YgS3sJvg6kG3WnVJ@petertodd.org>
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="4n2c0ZHw8MhhzNdK"
Content-Disposition: inline
In-Reply-To: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
Precedence: list


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

On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> Happy new years devs,
>=20
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>=20
> Transaction fees are an integral part of bitcoin.
>=20
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>=20
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channel=
s,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>=20
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>=20
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".

<snip>

> This type of design works really well for channels because the addition of
> fees to e.g. a channel state does not require any sort of pre-planning
> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> design is naturally immune to pinning issues since you could offer to pay=
 a
> fee for any TXID and the number of fee adding offers does not need to be
> restricted in the same way the descendant transactions would need to be.

So it's important to recognize that fee accounts introduce their own kind of
transaction pinning attacks: third parties would be able to attach arbitrary
fees to any transaction without permission. This isn't necessarily a good
thing: I don't want third parties to be able to grief my transaction engine=
s by
getting obsolete transactions confirmed in liu of the replacments I actually
want confirmed. Eg a third party could mess up OpenTimestamps calendars at
relatively low cost by delaying the mining of timestamp txs.

Of course, there's an obvious way to fix this: allow transactions to design=
ate
a pubkey allowed to add further transaction fees if required. Which Bitcoin
already has in two forms: Replace-by-Fee and Child Pays for Parent.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmIEt6oACgkQLly11TVR
Lzc3dA//dFCCJJh1t/XchnJlTXr4iQrmQAUOEajUnXL/2kUAlBqJ2jvE3tXUg4Lh
SB5jvs4EnC6phhrbphpWxso1v6XL3RGJUf60tUz0h/bO41DyOMGbVX82NtSNNfne
z4qDeVKNKv/Wo9/lHAoSQvH/CrK7AajMqWOZk4Rvok00FLkKAAAvOxBlL+KkZKhL
PYLMfvSXLoTMeiV1EjZZep8qDMh82VB5cOQIWYYiMhB+q0ebx7jpy6A/Z/pqwZfe
NBh2P+Ryw/kCo1e4c/JBI4Cr8Bybl3VgcYdymDgpCyGd2Uldz2X/K3bKCpVaHNQI
Sg9yPf+d9+d02y2gQfAVAH1+2sP540fkitkXBmLuwNRKwDifLjGqseZUdajwndGK
ggSqfcXiH/y0WSzRDOOLW37Jg09q8nNjogreJ9AsqbbCHlf0phCTqtothdpTAV3u
C0+ug/A6sWmGQm28iqYroV03nGIz3vHiMwtfsCIWUMphAS19puZN/cUFqqzE7My0
h/7GT6glhDd4Ybh27/LelhkjKQgtV1hjSBbBRIS1uitr7QyX93gJxYN1FvZYrhdJ
4KW6Ix4cruHqk1p3s3wjRy2444sEDwMHFGj4shFJZEyuinG8yoyzSayF0wxfsPaC
xQSMikGWDRptt3jTwBivmKodFYDMHI3WoJskhLV3fWA6I5Ghp8I=
=2YOz
-----END PGP SIGNATURE-----

--4n2c0ZHw8MhhzNdK--