From: Peter Todd <pete@petertodd•org>
To: antoine.riard@gmail•com
Cc: bitcoindev@googlegroups.com
Subject: [bitcoindev] Re: OP_Expire mempool behavior
Date: Tue, 19 Mar 2024 15:04:43 +0000 [thread overview]
Message-ID: <Zfmpi/9y4vFMAUtu@petertodd.org> (raw)
In-Reply-To: <ZfEeNcX3ebyuYYRi@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 6303 bytes --]
(replying manually with a cut-n-paste due to a mailing list delivery issue)
> > > > nodes should require higher minimum relay fees for transactions close to
> > > their expiration height to ensure we don’t waste bandwidth on transactions
> > > that have no potential to be mined
>
> I think this concern can be raised on _today_ LN second-stage transactions (HTLC-preimage / HTLC-timeout),
> when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will automatically go to broadcast an
> on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandwidth on transactions that _might_ have
> lower odds to be mined.
That's not really a comparable situation. If the HTLC-timeout transaction
replaces a HTLC-preimage transaction in a mempool, it will do so under ordinary
BIP125 rules, and is thus "paying for" the bandwidth with a higher fee.
Equally, in a replace-by-fee-rate scenario, it would be "paying for" its
bandwidth with a higher fee-rate. Either way, something will confirm.
In the OP_Expire case, we're talking about a transaction that becomes entirely
invalid after a point in time. If the transaction isn't mined with reasonably
high probability (eg >10%, preferably higher) an attacker may be able to
consume bandwidth indefinitely at little to no cost.
> > If you already have a need to make such transactions, you can argue that the
> > marginal cost to also use up that bandwidth is low. But that's already the case
> > with RBF: we allow any transaction to be replaced with RBF for a (by default)
> > 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> > OP_EXPIRE does not change this situation: you're still paying for an additional
> > 1sat/vB cost over the replaced transaction, as eventually one of your
> > replacements will get mined.
>
> I think yes this is indeed more a replacement issue, nothing new introduced by OP_EXPIRE finality time-bounding semantics.
> However, I think it's more an issue if we introduce things like altruistic re-broadcasting.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.html
>
> Certainly, the re-broadcast could favor transactions with higher odds of being mined, which naively should match RBF rules.
Similar to what I wrote above, in altruistic re-broadcasting, the attacker
doing the replacement cycling attack has already paid for the bandwidth
consumed in broadcasting the replaced transaction because they paid fees for
the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR
rules to avoid DoS attacks.
> And by the same way taking time to answer the open questions on this thread from the old mailing list:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.html
>
> > Are you claiming that BIP157 doesn't work well? In my experience it does.
>
> I've not checked recently, though from research memory a while back the numbers of BIP157 services offering peers
> was in the range of ~10 / 100.
>
> One can check by collecting nVersions messages from peers with `NODE_COMPACT_FILTERS`.
I mean, that's still BIP157 working. It's just not supported by every node.
It's easy to learn about lots of addrs from the addr distribution mechanisms,
so I don't think that's a serious issue.
> > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so mempool min fees are very consistent across nodes. I just checked four different long running > nodes I have access to, running a variety of Bitcoin Core versions on different platforms and very different places in the world, and their minfees all agree to well within 1% > In fact, they agree on min fee much *more* closely than the size of their mempools (in terms of # of transactions). Which makes sense when you think about it, as the
> > slope of the supply/demand curve is fairly flat right now.
>
> See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from diverging mempool min fees from the ground iirc.
https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817 is the
only actual data I could find in that link.
I'm very curious as to what those nodes are actually doing. Possibly some
pre-made node distribution is in fact setting non-standard mempool size limits.
Or these are fake spy nodes with unusual behavior.
> > From the point of view of a single node, an attacker can not reuse a UTXO in a replacement cycling attack. The BIP125 rules, in particular rule #4, ensure that each
> > replacement consumes liquidity because each replacement requires a higher fee, at least high enough to "pay for" the bandwidth of the replacement. An attacker trying to > use the same UTXO's to cycle out multiple victim transactions has to pay a higher fee for each victim cycled out. This is because at each step of the cycle, the attacker had > to broadcast a transaction with a higher fee than some other transaction.
>
> This does not stay true with nVersion=3, where a package parent can be signed with a feerate
> under min relay tx fee. See the second test attached in the initial full report email on replacement
> cycling attacks, one can replace the child of the package and the parent is automatically evicted,
> without the "pay for" bandwidth of the replacement fully covered.
>
> This is correct there is a minimal fee basis for each additional victim cycled out, while one can get
> a very advantageous scaling effect by RC'ing the child txn.
If V3 transactions is such that a child tx can be replaced at a cost that
doesn't "pay for" the bandwidth of the parent that is evicted, that is a
straight-forward design flaw/bug in V3 transactions. Fixing that should be
pretty straight forward, at which point the attacker is again paying "fairly"
with fees on each cycle.
--
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/Zfmpi/9y4vFMAUtu%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-03-20 20:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 3:32 [bitcoindev] " Peter Todd
2024-03-16 18:21 ` [bitcoindev] " Antoine Riard
2024-03-19 15:04 ` Peter Todd [this message]
2024-06-20 23:09 ` Antoine Riard
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=Zfmpi/9y4vFMAUtu@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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