From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
Date: Tue, 8 Feb 2022 14:58:50 +1000 [thread overview]
Message-ID: <20220208045850.GA6538@erisian.com.au> (raw)
In-Reply-To: <CAFXO6=+WFUueqDh21NTZzA5EcSQjX2owFn0+dr0ua_BRLfV4QQ@mail.gmail.com>
On Mon, Feb 07, 2022 at 11:16:26AM +0000, Gloria Zhao wrote:
> @aj:
> > I wonder sometimes if it could be sufficient to just have a relay rate
> > limit and prioritise by ancestor feerate though. Maybe something like:
> > - instead of adding txs to each peers setInventoryTxToSend immediately,
> > set a mempool flag "relayed=false"
> > - on a time delay, add the top N (by fee rate) "relayed=false" txs to
> > each peer's setInventoryTxToSend and mark them as "relayed=true";
> > calculate how much kB those txs were, and do this again after
> > SIZE/RATELIMIT seconds
> > - don't include "relayed=false" txs when building blocks?
The "?" was me not being sure that point is a good suggestion...
Miners might reasonably decide to have no rate limit, and always relay,
and never exclude txs -- but the question then becomes is whether they
hear about the tx at all, so rate limiting behaviour could still be a
potential problem for whoever made the tx.
> Wow cool! I think outbound tx relay size-based rate-limiting and
> prioritizing tx relay by feerate are great ideas for preventing spammers
> from wasting bandwidth network-wide. I agree, this would slow the low
> feerate spam down, preventing a huge network-wide bandwidth spike. And it
> would allow high feerate transactions to propagate as they should,
> regardless of how busy traffic is. Combined with inbound tx request
> rate-limiting, might this be sufficient to prevent DoS regardless of the
> fee-based replacement policies?
I think you only want to do outbound rate limits, ie, how often you send
INV, GETDATA and TX messages? Once you receive any of those, I think
you have to immediately process / ignore it, you can't really sensibly
defer it (beyond the existing queues we have that just build up while
we're busy processing other things first)?
> One point that I'm not 100% clear on: is it ok to prioritize the
> transactions by ancestor feerate in this scheme? As I described in the
> original post, this can be quite different from the actual feerate we would
> consider a transaction in a block for. The transaction could have a high
> feerate sibling bumping its ancestor.
> For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB). If
> we just received C, it would be incorrect to give it a priority equal to
> its ancestor feerate (3sat/vB) because if we constructed a block template
> now, B would bump A, and C's new ancestor feerate is 5sat/vB.
> Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
> also exclude C when building blocks, we're missing out on good fees.
I think you're right that this would be ugly. It's something of a
special case:
a) you really care about C getting into the next block; but
b) you're trusting B not being replaced by a higher fee tx that
doesn't have A as a parent; and
c) there's a lot of txs bidding the floor of the next block up to a
level in-between the ancestor fee rate of 3sat/vB and the tx fee
rate of 5sat/vB
Without (a), maybe you don't care about it getting to a miner quickly.
If your trust in (b) was misplaced, then your tx's effective fee rate
will drop and (because of (c)), you'll lose anyway. And if the spam ends
up outside of (c)'s range, either the rate limiting won't take effect
(spam's too cheap) and you'll be fine, or you'll miss out on the block
anyway (spam's paying more than your tx rate) and you never had any hope
of making it in.
Note that we already rate limit via INVENTORY_BROADCAST_MAX /
*_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
per 10 minutes for outbound connections. This would be a weight based
rate limit instead-of/in-addition-to that, I guess.
As far as a non-ugly approach goes, I think you'd have to be smarter about
tracking the "effective fee rate" than the ancestor fee rate manages;
maybe that's something that could fall out of Murch and Clara's candidate
set blockbuilding ideas [0] ?
Perhaps that same work would also make it possible to come up with
a better answer to "do I care that this replacement would invalidate
these descendents?"
[0] https://github.com/Xekyo/blockbuilding
> > - keep high-feerate evicted txs around for a while in case they get
> > mined by someone else to improve compact block relay, a la the
> > orphan pool?
> Replaced transactions are already added to vExtraTxnForCompact :D
I guess I was thinking that it's just a 100 tx LRU cache, which might
not be good enough?
Maybe it would be more on point to have a rate limit apply only to
replacement transactions?
> For wallets, AJ's "All you need is for there to be *a* path that follows
> the new relay rules and gets from your node/wallet to perhaps 10% of
> hashpower" makes sense to me (which would be the former).
Perhaps a corollarly of that is that it's *better* to have the mempool
acceptance rule only consider economic incentives, and have the spam
prevention only be about "shall I tell my peers about this?"
If you don't have that split; then the anti-spam rules can prevent you
from getting the tx in the mempool at all; whereas if you do have the
split, then even if the bitcoind anti-spam rules are blocking you at
every turn, you can still send your tx to miners by some other route,
and then they can add it to their mempool directly without any hassle.
Cheers,
aj
next prev parent reply other threads:[~2022-02-08 4:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 13:42 Gloria Zhao
2022-01-28 1:35 ` Jeremy
2022-01-30 22:53 ` Antoine Riard
2022-01-31 15:57 ` Bastien TEINTURIER
2022-02-01 1:56 ` Anthony Towns
2022-02-05 13:21 ` Michael Folkson
2022-02-07 10:22 ` Bastien TEINTURIER
2022-02-07 11:16 ` Gloria Zhao
2022-02-08 4:58 ` Anthony Towns [this message]
2022-03-09 15:09 ` Gloria Zhao
2022-03-11 16:22 ` Billy Tetrud
2022-03-12 8:18 ` Billy Tetrud
2022-03-14 10:29 ` Gloria Zhao
2022-03-15 1:43 ` Billy Tetrud
2022-03-17 2:02 ` Antoine Riard
2022-03-17 15:59 ` Billy Tetrud
[not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` [bitcoin-dev] Improving RBF policy Bram Cohen
2022-02-01 0:08 ` Eric Voskuil
2022-02-01 8:32 ` Bram Cohen
2022-02-01 19:44 ` Eric Voskuil
2022-02-01 0:42 ` Antoine Riard
2022-02-01 2:47 [bitcoin-dev] Improving RBF Policy Prayank
2022-02-01 9:30 ` Bastien TEINTURIER
2022-02-02 10:21 ` Anthony Towns
2022-02-09 17:57 lisa neigut
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=20220208045850.GA6538@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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