From: Peter Todd <pete@petertodd•org>
To: "Martin Habovštiak" <martin.habovstiak@gmail•com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Anyone can boost - a more efficient alternative to anchor outputs
Date: Tue, 19 Mar 2024 14:24:46 +0000 [thread overview]
Message-ID: <ZfmgLhETBEDql85w@petertodd.org> (raw)
In-Reply-To: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3916 bytes --]
On Tue, Mar 19, 2024 at 10:47:26AM +0100, Martin Habovštiak wrote:
> Hello everyone,
>
> 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 on
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 attacks,
> 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. RBFR
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 demonstrate
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 entirely
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 where
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 with
multiple people at once could be tricky.
> ## Known downsides
>
> ### This requires a soft fork
>
> Soft forks can be contentious and difficult to deploy.
I'd suggest you find other use-cases for this mechanism, eg Ark, and present it
as a solution to a bunch of problems at once. I'm not sure that the fee payment
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 this
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 is
always *possible*, implementing a mechanism that makes doing this easy has
downsides. On balance though, if it enables things like Ark, you'll help make
the argument that the upsides are worth it.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZfmgLhETBEDql85w%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-03-19 14:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 9:47 Martin Habovštiak
2024-03-19 14:10 ` 'Fabian' via Bitcoin Development Mailing List
2024-03-19 14:24 ` Peter Todd [this message]
2024-03-25 1:36 ` David A. Harding
2024-03-27 12:20 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZfmgLhETBEDql85w@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=martin.habovstiak@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox