From: Peter Todd <pete@petertodd•org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] OP_Expire mempool behavior
Date: Wed, 13 Mar 2024 03:32:05 +0000 [thread overview]
Message-ID: <ZfEeNcX3ebyuYYRi@petertodd.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
I got a question re: the following comment on delvingbitcoin with regard to
OP_Expire:
> > 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
>
> This seems insufficient to solve the problem, unless the premium is so high
> that it virtually guarantees that the transaction will be mined before it
> expires. However, if the feerate were that high, wouldn’t OP_EXPIRE simply
> waste blockspace? If however the feerate of the transaction is merely
> competitive, the presence of OP_EXPIRE creates a bandwidth-wasting vector: an
> attacker would submit e.g. OP_EXPIRE transactions at the bottom of the top
> block and push them out of the top block with further OP_EXPIRE transactions.
> This way the attacker could issue a constant stream of transactions, but
> never pay for more than a couple barely sliding in at the bottom of the
> block.
-https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8
This "bandwidth-wasting vector" requires the attacker to create actual
fee-paying transactions, with a fee-rate sufficiently high to get mined in the
next block or so. This of course is very expensive by itself.
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.
--
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/ZfEeNcX3ebyuYYRi%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2024-03-13 5:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 3:32 Peter Todd [this message]
2024-03-16 18:21 ` [bitcoindev] " Antoine Riard
2024-03-19 15:04 ` Peter Todd
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=ZfEeNcX3ebyuYYRi@petertodd.org \
--to=pete@petertodd$(echo .)org \
--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