Delivery-date: Tue, 19 Mar 2024 07:32:09 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 66.111.4.25 as permitted sender) client-ip=66.111.4.25;
Feedback-ID: i525146e8:Fastmail
Date: Tue, 19 Mar 2024 14:24:46 +0000
From: Peter Todd <pete@petertodd.org>
To: Martin =?utf-8?Q?Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Anyone can boost - a more efficient alternative to
 anchor outputs
Message-ID: <ZfmgLhETBEDql85w@petertodd.org>
References: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="h6eixIpcyZQz10r2"
Content-Disposition: inline
In-Reply-To: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--h6eixIpcyZQz10r2
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2024 at 10:47:26AM +0100, Martin Habov=C5=A1tiak wrote:
> Hello everyone,
>=20
> For a while I was thinking that anchor outputs/CPFP are wasteful and I
> believe I have finally found a better way of doing them. I wrote up a
> document describing the solution here:
> https://gist.github.com/Kixunil/6ae6f787db36d0d5ed3220f5bcece7f7

FYI I believe that Jeremy Rubin proposed essentially the same idea before o=
n
this mailing list, using the term "Transaction Sponsorship" to describe it.

> At first sight this looks broken because of the pinning problem.
> Today, if ANYONECANSPEND output is used an attacker could boost a
> transaction of someone else in a way that would make it stuck in the
> mempool.

To be clear, this issue exists because we don't currently do
replace-by-fee-rate with a reasonably low minimum fee-rate ratio.

Correct me if I'm wrong, but I believe at the moment the only significant
transaction pinning attack remaining for ANYONECANSPEND, spending confirmed
outputs, is Rule #3 pinning.

> This is because of policy rules protecting the network against DoS attack=
s,
> so apparently the rules cannot be relaxed.
> The rules are designed specifically to impose cost on attackers.

I disagree re: DoS attacks. We already have plenty of free-relay attacks. R=
BFR
does not significantly change that situation.

RBFR is running live right now on Libre Relay nodes on mainnet. If these
free-relay attacks were actually serious, I'd suggest that people demonstra=
te
them!

> The reason why anyone can boost is not actually broken is that multiple
> independent transactions can boost the same transaction.

Note that introducing this mechanism with a soft-fork will also create enti=
rely
new smart contracting facilities, unrelated to boosting/sponsorship.

For example, I believe that Ark could make use of this mechanism to more
efficiently replace their connector output scheme.

> Notably, such boosting service would *not* be trustless but non-delivery
> could be easily proven using LN invoice and preimage.
> Perhaps it is possible to make the service trustless but that's probably
> not worth the effort given how low the amounts are.

To reduce trust you could do an automated, multiple round, signing scheme w=
here
the service signs transations with higher and higher fee-rates in exchange =
for
most funds over LN. The minimum amount the sender would need to front would=
 be
the cost of the additional ~32 bytes required. Though arranging this idea w=
ith
multiple people at once could be tricky.

> ## Known downsides
>=20
> ### This requires a soft fork
>=20
> Soft forks can be contentious and difficult to deploy.

I'd suggest you find other use-cases for this mechanism, eg Ark, and presen=
t it
as a solution to a bunch of problems at once. I'm not sure that the fee pay=
ment
alone is sufficient incentive.

You don't mention it below. But another downside is you provide an easy way=
 for
arbitrary third parties to get a particular transaction mined. I raised thi=
s
issue the last time it was discussed on this list, giving the example of my
OpenTimestamps calendars: it would be annoying if people could easily get
out-of-date timestamp txs mined by just paying a bit of money. While this i=
s
always *possible*, implementing a mechanism that makes doing this easy has
downsides. On balance though, if it enables things like Ark, you'll help ma=
ke
the argument that the upsides are worth it.

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

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/ZfmgLhETBEDql85w%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX5oCwACgkQLly11TVR
Lzfqkw//TWUnJK8/YYgI5Fa+/+8jLF/4TsKKLHOD5mEWb3xBenBVHGJyV4hCiv/S
faQiH5qiQLXAAaTuQm4gYifJ/IXXbgAbpGfU6YnlqsyM95kDjb0MZjeqNcrkDN72
jluiaitFZv7IFQ/5EFwBrqE1FjMgUd3a7U8xXKiVFqKnufSWUxnVPlqd7fB/tZV6
cf66Ww/MmUtVHIZ1K6GF39FHDkhhbH0PM/gIo6LYKLPQqhCe8Ik6FgRYfleQHMOV
DjvNJ1z3rPGlPffZHbCyG1I2zXt9zEDpHNRXA+a1oboafIEZqcHItLN3lsvoCp5i
F6kuK1Vvgw1q3jfng5fCWVeCSaWoa5sKgXHBSJf98OWpQIPk3JBX4LP+VEebW9Al
1wOQ/AeJjILYYLkDecl7rizrLSgCNh+sY97QSnGyZgAWqs+NsIOGNjlLFacpoMXT
ZoAvVidHBBNthea+WzXM98e2St0tAkt6lX/L9Ndwr78CJL/UUZcs4LWtPgALDRPg
pZgUtnyd2cfrdWj3t+U5WumWRj3xkzrF7vPwRS8Yk6jfUmx5FnycRYzLt/CZGn6T
7NtlQHaZ3twO8I+HgSQEPmDOZ5r/Ui5u2xHQVXirgcWKtUMsM7g7x/sNpwMA/CTR
KYtHdMmI/IWj/q/zTC9rtO+vsZgnk11r9HV52S2QvOVfcleI+vI=
=QwdO
-----END PGP SIGNATURE-----

--h6eixIpcyZQz10r2--