path: root/7f/0f51f2e7d99992a35a11b0669844e2c71df3af

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 824D8C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 16:22:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5927884183
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 16:22:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 44Q4Z0rkMlka
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 16:22:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [IPv6:2a00:1450:4864:20::62c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9E03784111
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 16:22:25 +0000 (UTC)
Received: by mail-ej1-x62c.google.com with SMTP id qa43so20020976ejc.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 08:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=6vUDXL6+BzjAW+4xUfB1RuPU7IHHone8WMq6fSx36/Y=;
 b=fhsAGKSmWB0KknjmFpxbiE73uT7fFQesYvIEze+1HHxNsVFXePFsAYoigJKrQ2yYMx
 SPo+xYS8OEMk/pMWuk+9vQXdrVzv9MQ190iuSJLhqXndF2QHl53Fnc9nUk6xmjzPgehT
 VYWLGMhenDBGud/V6CbFhSYa2FPlN3AlPChc1FKjhJkzDG3kFmNrs/ZI6ziD/Xxv6NlV
 bdORApXheZ+5FG54dQOVeiFPkdCzEWpOMsOL+yQbwBAUPEQeo2oqFKDNSBAw8nh51izm
 QYW8Z6Vdh3XcoQpncntXF4PujD8A99mnfj765/npGaehYKiOWM1X7LR68bM3ADlfq+0a
 cKDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=6vUDXL6+BzjAW+4xUfB1RuPU7IHHone8WMq6fSx36/Y=;
 b=dWb9ClBvpyT2xTJcGYzNi9SQJMW9kAd4ZaKCiSBsMWWsINIZ75WA0ifIMteXk0TIun
 Y9gt/yFsDCU8v9sUudfAlvaxuyTkD5c4Fw1nWRid2BQDLWVvhBVXNMJlR0mpuSYZMYAu
 g0YR4tfNmRHlLplTHY68zqKYdI+e6woLQYYZNICA3llbijlWa27CcYs1Skx5Jed4nneH
 ZuhbNr5nLPiLgSCODe1vQaPRQ6xZhfPvlOY0sRRPZAQNf6AfpIq8XbQSOs7mzVHuCphl
 yq07XWvLtNwio704Ph38lXNuC8BF8bHAOfxHb9A9HF5Nc6MqdSTB8VsfqGC1zGGyAq9G
 GOwQ==
X-Gm-Message-State: AOAM531P8TyBGJD+4h87uFIRpKnTLWO5aaRK9CzyvVslkOp/a2WiRNKH
 Uk92/1dbxQ1RFMXRL29ej7vcpTViwJDC9JOFGj3snM8u
X-Google-Smtp-Source: ABdhPJzrwatdJICHO6mVSfokqvJ2wz6n1kcFhRCprA+DMxDoTku1U8zL94HRvEp9b/YqkKoVee3S4GaX0rz0QrrXs/E=
X-Received: by 2002:a17:906:4fc7:b0:6da:92b2:f572 with SMTP id
 i7-20020a1709064fc700b006da92b2f572mr9209995ejw.184.1647015743480; Fri, 11
 Mar 2022 08:22:23 -0800 (PST)
MIME-Version: 1.0
References: <CAFXO6=LGbaur6XQrE+6a6mAAHXduOCXoWPTgPosxAG59ZkK6Gg@mail.gmail.com>
 <CALZpt+EjqKbhnN_5jy3kvYpMvjN8=iwRzMLSM7yS8_j-WzLrBQ@mail.gmail.com>
 <CACdvm3P1co1HDFKNxpHRe_JX_UPNw_P5qgL5cHCM=Qs+kR=B_A@mail.gmail.com>
 <GlEfqW7mh2W3uHkxDxwb5RSj-O_zbTUi4wa67oRz3erHRM1ykxT0BrcJrqulCOqrRLVJ4Bp8KVSOj0yJGB7rwcFGlZDyMrTsndPFO89hAQc=@protonmail.com>
 <CACdvm3P_-1DPxcWkd1J-PckPF1oRTtVB5zz5e3+VQ0Mko1T=hQ@mail.gmail.com>
 <CAFXO6=+WFUueqDh21NTZzA5EcSQjX2owFn0+dr0ua_BRLfV4QQ@mail.gmail.com>
 <20220208045850.GA6538@erisian.com.au>
 <CAFXO6=KMveswFvYdFCjsvt7a-Af+act4K3p8UrJXGyBO8E1o+w@mail.gmail.com>
In-Reply-To: <CAFXO6=KMveswFvYdFCjsvt7a-Af+act4K3p8UrJXGyBO8E1o+w@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 11 Mar 2022 10:22:07 -0600
Message-ID: <CAGpPWDY5W8G8je7yQRPF12PtVGeaZ9Pi98LacjrAs+RGEWqv_w@mail.gmail.com>
To: Gloria Zhao <gloriajzhao@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000546ada05d9f3bc2d"
X-Mailman-Approved-At: Fri, 11 Mar 2022 16:32:18 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Improving RBF Policy
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2022 16:22:28 -0000

--000000000000546ada05d9f3bc2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Gloria,

>  1. Transaction relay rate limiting

I have a similar concern as yours, that this could prevent higher fee-rate
transactions from being broadcast.

> 2. Staggered broadcast of replacement transactions: within some time
interval, maybe accept multiple replacements for the same prevout, but only
relay the original transaction.

By this do you mean basically having a batching window where, on receiving
a replacement transaction, a node will wait for a period of time,
potentially receiving many replacements for the same transaction (or many
separate conflicting transactions), and only broadcasting the "best" one(s)
at the end of that time window?

Its an interesting idea, but it would produce a problem. Every hop that
replacement transaction takes would be delayed by this staggered window. If
the window were 3 minutes and transactions generally take 20 hops to get to
the majority of miners, a "best-case average" delay might be 3.75 minutes
(noting that among your 8 nodes, its quite likely one of them would have a
window ending much sooner than 3 minutes). Some (maybe 3% of) nodes would
experience delays of more than 20 minutes. That kind of delay isn't great.

However it made me think of another idea: a transaction replacement
broadcast cooldown. What if nodes kept track of the time they broadcasted
the last replacement for a package and had a relay cooldown after the last
replacement was broadcasted? A node receiving a replacement would relay the
replacement immediately if the package its replacing was broadcasted more
than X seconds ago, and otherwise it would wait until the time when that
package was broadcasted at least X seconds ago to broadcast it. Any
replacements it receives during that waiting period would replace as
normal, meaning the unrebroadcasted replacement would never be
broadcasted, and only the highest value replacement would be broadcasted at
the end of the cooldown.

This wouldn't prevent a higher-fee-rate transaction from being broadcasted
(like rate limiting could), but would still be effective at limiting
unnecessary data transmission. Another benefit is that in the
non-adversarial case, replacement transactions wouldn't be subject to any
delay at all (while in the staggered broadcast idea, most replacements
would experience some delay). And in the adversarial case, where a
malicious actor broadcasts a low-as-possible-value replacement just before
yours, the worst case delay is just whatever the cooldown period is. I
would imagine that maybe 1 minute would be a reasonable worst-case delay.
This would limit spam for a transaction that makes it into a block to ~10x
(9 to 1). I don't see much of a downside to doing this beyond just the
slight additional complexity of relay rules (and considering it could save
substantial additional code complexity, even that is a benefit).

All a node would need to do is keep a timestamp on each transaction they
receive for when it was broadcasted and check it when a replacement comes
in. If now-broadcastDate < cooldown, set a timer for cooldown -
(now-broadcastDate) to broadcast it. If another replacement comes in, clear
that timer and repeat using the original broadcast date (since the
unbroadcast transaction doesn't have a broadcast date yet).

I think it might also be useful to note that eliminating "extra data"
caused by careless or malicious actors (spam or whatever you want to call
it) should not be the goal. It is impossible to prevent all spam. What we
should be aiming for is more specific: we should attempt to design a system
where spam is manageable. Eg if our goal is to ensure that a bitcoin node
uses no more than 10% of the bandwidth of a "normal" user, if current
non-spam traffic only requires 1% of a "normal" users's bandwidth, then the
network can bear a 9 to 1 ratio of spam. When a node spins up, there is a
lot more data to download and process. So we know that all full nodes can
handle at least as much traffic as they handle during IBD. What's the
difference between those amounts? I'm not sure, but I would guess that IBD
is at least a couple times more demanding than a fully synced node. So I
might suggest that as long as spam can be kept below a ratio of maybe 2 to
1, we should consider the design acceptable (and therefore more complexity
unnecessary).

The 1 minute broadcast cooldown I mentioned before wouldn't be quite
sufficient to achieve that ratio. But a 3.33 minute cooldown would be.
Whether this is "too much" is something that would have to be discussed, I
suspect a worst-case adversarial 3.33 minute delay would not be "too much".
Doing this could basically eliminate any risk of actual service denial via
replacement transactions.

However, I do think that these DOS concerns are quite overblown. I wrote up=
 a
comment on your rbf-improvements.md
<https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_=
comment_id=3D4093100#gistcomment-4093100>
detailing
my thought process on that. The summary is that as long as the fee-rate
relay rule is maintained, any "spam" is actually paid for, either by the
"first" transaction in the spam chain, or by the "spam" itself. Even
without something like a minimum RBF relay delay limiting how much spam
could be created, the economics of the fee-rate rule already sufficiently
mitigate the issue of spam.
On Wed, Mar 9, 2022 at 9:37 AM Gloria Zhao via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi RBF friends,
>
> Posting a summary of RBF discussions at coredev (mostly on transaction
> relay rate-limiting), user-elected descendant limit as a short term
> solution to unblock package RBF, and mining score, all open for feedback:
>
> One big concept discussed was baking DoS protection into the p2p level
> rather than policy level. TLDR: The fees are not paid to the node operato=
r,
> but to the miner. While we can use fees to reason about the cost of an
> attack, if we're ultimately interested in preventing resource exhaustion,
> maybe we want to "stop the bleeding" when it happens and bound the amount
> of resources used in general. There were two main ideas:
>
> 1. Transaction relay rate limiting (i.e. the one you proposed above or
> some variation) with a feerate-based priority queue
> 2. Staggered broadcast of replacement transactions: within some time
> interval, maybe accept multiple replacements for the same prevout, but on=
ly
> relay the original transaction.
>
> Looking to solicit feedback on these ideas and the concept in general. Is
> it a good idea (separate from RBF) to add rate-limiting in transaction
> relay? And is it the right direction to think about RBF DoS protection th=
is
> way?
>
> A lingering concern that I have about this idea is it would then be
> possible to impact the propagation of another person=E2=80=99s transactio=
n, i.e.,
> an attacker can censor somebody=E2=80=99s transaction from ever being ann=
ounced by
> a node if they send enough transactions to fill up the rate limit.
> Obviously this would be expensive since they're spending a lot on fees, b=
ut
> I imagine it could be profitable in some situations to spend a few thousa=
nd
> dollars to prevent anyone from hearing about a transaction for a few hour=
s.
> This might be a non-issue in practice if the rate limit is generous and
> traffic isn=E2=80=99t horrendous, but is this a problem?
>
> And if we don't require an increase in (i.e. addition of "new") absolute
> fees, users are essentially allowed to =E2=80=9Crecycle=E2=80=9D fees. In=
 the scenario
> where we prioritize relay based on feerate, users could potentially be
> placed higher in the queue, ahead of other users=E2=80=99 transactions, m=
ultiple
> times, without ever adding more fees to the transaction. Again, maybe thi=
s
> isn=E2=80=99t a huge deal in practice if we set the parameters right, but=
 it seems=E2=80=A6
> not great, in principle.
>
> ---------
>
> It's probably also a good idea to point out that there's been some
> discussion happening on the gist containing my original post on this thre=
ad
> (https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).
>
> Suhas and Matt [proposed][0] adding a policy rule allowing users to
> specify descendant limits on their transactions. For example, some nth bi=
t
> of nSequence with nVersion 3 means "this transaction won't have more than=
 X
> vbytes of descendants" where X =3D max(1000, vsizeof(tx)) or something. I=
t
> solves the pinning problem with package RBF where the attacker's package
> contains a very large and high-fee descendant.
>
> We could add this policy and deploy it with package RBF/package relay so
> that LN can use it by setting the user-elected descendant limit flag on
> commitment transactions. (Otherwise package RBF is blocked until we find =
a
> more comprehensive solution to the pinning attack).
>
> It's simple to [implement][1] as a mempool policy, but adds some
> complexity for wallets that use it, since it limits their use of UTXOs fr=
om
> transactions with this bit set.
>
> ---------
>
> Also, coming back to the idea of "we can't just use {individual, ancestor=
}
> feerate," I'm interested in soliciting feedback on adding a =E2=80=9Cmini=
ng score=E2=80=9D
> calculator. I've implemented one [here][2] which takes the transaction in
> question, grabs all of the connected mempool transactions (including
> siblings, coparents, etc., as they wouldn=E2=80=99t be in the ancestor no=
r
> descendant sets), and builds a =E2=80=9Cblock template=E2=80=9D using our=
 current mining
> algorithm. The mining score of a transaction is the ancestor feerate at
> which it is included.
>
> This would be helpful for something like ancestor-aware funding and
> fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
> priority queue for transaction relay, we'd want to use something like thi=
s
> as the priority value. And for RBF, we probably want to require that a
> replacement have a higher mining score than the original transactions. Th=
is
> could be computationally expensive to do all the time; it could be good t=
o
> cache it but that could make mempool bookkeeping more complicated. Also, =
if
> we end up trying to switch to a candidate set-based algorithm for mining,
> we'd of course need a new calculator.
>
> [0]:
> https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink=
_comment_id=3D4058140#gistcomment-4058140
> [1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
> [2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
> [3]: https://github.com/bitcoin/bitcoin/issues/9645
> [4]: https://github.com/bitcoin/bitcoin/issues/15553
>
> Best,
> Gloria
>
> On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns <aj@erisian.com.au> wrote:
>
>> 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 ra=
te
>> > > limit and prioritise by ancestor feerate though. Maybe something lik=
e:
>> > > - instead of adding txs to each peers setInventoryTxToSend
>> immediately,
>> > >   set a mempool flag "relayed=3Dfalse"
>> > > - on a time delay, add the top N (by fee rate) "relayed=3Dfalse" txs=
 to
>> > >   each peer's setInventoryTxToSend and mark them as "relayed=3Dtrue"=
;
>> > >   calculate how much kB those txs were, and do this again after
>> > >   SIZE/RATELIMIT seconds
>>
>> > > - don't include "relayed=3Dfalse" 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 spamme=
rs
>> > 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 t=
he
>> > 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 hi=
gh
>> > 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 w=
e
>> > 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 abo=
ut
>> tracking the "effective fee rate" than the ancestor fee rate manages;
>> maybe that's something that could fall out of Murch and Clara's candidat=
e
>> 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 follo=
ws
>> > 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
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000546ada05d9f3bc2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Gloria,</div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">&gt;=C2=A0

1. Transaction relay rate limiting</div><div dir=3D"ltr"><br></div><div>I h=
ave a similar concern as yours, that this could prevent higher fee-rate tra=
nsactions from being broadcast.=C2=A0</div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr"><div>&gt; 2.=C2=A0<span>Staggered</span>=C2=A0broadcast of repl=
acement transactions: within some time interval, maybe accept multiple repl=
acements for the same prevout, but only relay the original transaction.<br>=
</div></div><br><div>By this do you mean basically having a batching window=
 where, on receiving a replacement transaction, a node will wait for a peri=
od of time, potentially receiving many replacements for the same transactio=
n (or many separate conflicting transactions), and only broadcasting the &q=
uot;best&quot; one(s) at the end of that time window?=C2=A0</div><div><br><=
/div><div>Its an interesting idea, but it would produce a problem. Every ho=
p that replacement transaction takes would be delayed by this staggered win=
dow. If the window were 3 minutes and transactions generally take 20 hops t=
o get to the majority of miners, a &quot;best-case average&quot; delay migh=
t be 3.75 minutes (noting that among your 8 nodes, its=C2=A0quite likely on=
e of them would have a window ending much sooner than 3 minutes). Some (may=
be 3% of) nodes would experience delays of more than 20 minutes. That kind =
of delay isn&#39;t great.=C2=A0</div><div><br></div><div>However it made me=
 think of another idea: a transaction replacement broadcast cooldown. What =
if nodes kept track of the time they broadcasted the last replacement for a=
 package and had a relay cooldown after the last replacement was broadcaste=
d? A node receiving a replacement would relay the replacement immediately i=
f the package its replacing was broadcasted more than X seconds ago, and ot=
herwise it would wait until the time when that package was broadcasted at l=
east X seconds ago to broadcast it. Any replacements it receives during tha=
t waiting period would replace as normal, meaning the unrebroadcasted repla=
cement would never be broadcasted,=C2=A0and only the highest value replacem=
ent would be broadcasted at the end of the cooldown.</div><div><br></div><d=
iv>This wouldn&#39;t prevent a higher-fee-rate transaction from being broad=
casted (like rate limiting could), but would still be effective=C2=A0at lim=
iting unnecessary data transmission. Another benefit is that in the non-adv=
ersarial case, replacement transactions wouldn&#39;t be subject to any dela=
y at all (while in the staggered broadcast idea, most replacements would ex=
perience some delay). And in the adversarial case, where a malicious actor =
broadcasts a low-as-possible-value replacement just before yours, the=C2=A0=
worst case delay is just whatever the cooldown period is. I would imagine t=
hat maybe 1 minute would be a reasonable worst-case delay. This would limit=
 spam for a transaction that makes it into a block to ~10x (9 to 1). I don&=
#39;t see much of a downside to doing this beyond just the slight additiona=
l complexity of relay rules (and considering it could save substantial addi=
tional code complexity, even that is a benefit).=C2=A0</div><div><br></div>=
<div>All a node would need to do is keep a timestamp on each transaction th=
ey receive for when it was broadcasted and check it when a replacement come=
s in. If now-broadcastDate &lt; cooldown, set a timer for cooldown - (now-b=
roadcastDate) to broadcast it. If another replacement comes in, clear that =
timer and repeat using the original broadcast date (since the unbroadcast t=
ransaction doesn&#39;t have a broadcast date yet).=C2=A0</div><div><br></di=
v><div>I think it might also be useful to note that eliminating &quot;extra=
 data&quot; caused by careless or malicious actors (spam or whatever you wa=
nt to call it) should not be the goal. It is impossible to prevent all spam=
. What we should be aiming for is more specific: we should attempt to desig=
n a system where spam is manageable. Eg if our goal is to ensure that a bit=
coin node uses no more than 10% of the bandwidth of a &quot;normal&quot; us=
er, if current non-spam traffic only requires 1% of a &quot;normal&quot; us=
ers&#39;s=C2=A0bandwidth, then the network can bear a 9 to 1 ratio of spam.=
 When a node spins up, there is a lot more data to download and process. So=
 we know that all full nodes can handle at least as much traffic as they ha=
ndle during IBD. What&#39;s the difference between those amounts? I&#39;m n=
ot sure, but I would guess that IBD is at least a couple times more demandi=
ng than a fully synced node. So I might suggest that as long as spam can be=
 kept below a ratio of maybe 2 to 1, we should consider the design acceptab=
le (and therefore more complexity unnecessary).=C2=A0</div><div><br></div><=
div>The 1 minute broadcast cooldown I mentioned before wouldn&#39;t be quit=
e sufficient to achieve that ratio. But a 3.33 minute cooldown would be. Wh=
ether this is &quot;too much&quot; is something that would have to be discu=
ssed,=C2=A0I suspect a worst-case adversarial 3.33 minute delay would not b=
e &quot;too much&quot;. Doing this could basically eliminate any risk of ac=
tual service denial via replacement transactions.=C2=A0</div><div><br></div=
><div>However, I do think that these DOS concerns are quite overblown. I wr=
ote up <a href=3D"https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d37=
83b9ff?permalink_comment_id=3D4093100#gistcomment-4093100" target=3D"_blank=
">a comment on your rbf-improvements.md</a>=C2=A0detailing my thought proce=
ss on that. The summary is that as long as the fee-rate relay rule is maint=
ained, any &quot;spam&quot; is actually paid for, either by the &quot;first=
&quot; transaction in the spam chain, or by the &quot;spam&quot; itself. Ev=
en without something like a minimum RBF relay delay limiting how much spam =
could be created, the economics of the fee-rate rule already sufficiently m=
itigate the issue of spam.=C2=A0<br></div></div><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 9, 2022 at 9:37 AM Gloria=
 Zhao via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div>Hi RBF friends,<br></div><div><br></div><div>Posting a summary of=
 RBF discussions at coredev (mostly on transaction relay rate-limiting), us=
er-elected descendant limit as a short term solution to unblock package RBF=
, and mining score, all open for feedback:<br><br>One big concept discussed=
 was baking DoS protection into the p2p level rather than policy level. TLD=
R: The fees are not paid to the node operator, but to the miner. While we c=
an use fees to reason about the cost of an attack, if we&#39;re ultimately =
interested in preventing resource exhaustion, maybe we want to &quot;stop t=
he bleeding&quot; when it happens and bound the amount of resources used in=
 general. There were two main ideas:<br><br>1. Transaction relay rate limit=
ing (i.e. the one you proposed above or some variation) with a feerate-base=
d priority queue<br>2. Staggered broadcast of replacement transactions: wit=
hin some time interval, maybe accept multiple replacements for the same pre=
vout, but only relay the original transaction.<br><br>Looking to solicit fe=
edback on these ideas and the concept in general. Is it a good idea (separa=
te from RBF) to add rate-limiting in transaction relay? And is it the right=
 direction to think about RBF DoS protection this way?<br><br>A lingering c=
oncern that I have about this idea is it would then be possible to impact t=
he propagation of another person=E2=80=99s transaction, i.e., an attacker c=
an censor somebody=E2=80=99s transaction from ever being announced by a nod=
e if they send enough transactions to fill up the rate limit. Obviously thi=
s would be expensive since they&#39;re spending a lot on fees, but I imagin=
e it could be profitable in some situations to spend a few thousand dollars=
 to prevent anyone from hearing about a transaction for a few hours. This m=
ight be a non-issue in practice if the rate limit is generous and traffic i=
sn=E2=80=99t horrendous, but is this a problem?<br><br>And if we don&#39;t =
require an increase in (i.e. addition of &quot;new&quot;) absolute fees, us=
ers are essentially allowed to =E2=80=9Crecycle=E2=80=9D fees. In the scena=
rio where we prioritize relay based on feerate, users could potentially be =
placed higher in the queue, ahead of other users=E2=80=99 transactions, mul=
tiple times, without ever adding more fees to the transaction. Again, maybe=
 this isn=E2=80=99t a huge deal in practice if we set the parameters right,=
 but it seems=E2=80=A6 not great, in principle.<br></div><div><br></div><di=
v>---------<br></div><div><br></div><div>It&#39;s probably also a good idea=
 to point out that there&#39;s been some discussion happening on the gist c=
ontaining my original post on this thread (<a href=3D"https://gist.github.c=
om/glozow/25d9662c52453bd08b4b4b1d3783b9ff" target=3D"_blank">https://gist.=
github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff</a>).</div><div><br></di=
v><div>Suhas and Matt [proposed][0] adding a policy rule allowing users to =
specify descendant limits on their transactions. For example, some nth bit =
of nSequence with nVersion 3 means &quot;this transaction won&#39;t have mo=
re than X vbytes of descendants&quot; where X =3D max(1000, vsizeof(tx)) or=
 something. It solves the pinning problem with package RBF where the attack=
er&#39;s package contains a very large and high-fee descendant.</div><div><=
br></div><div>We could add this policy and deploy it with package RBF/packa=
ge relay so that LN can use it by setting the user-elected descendant limit=
 flag on commitment transactions. (Otherwise package RBF is blocked until w=
e find a more comprehensive solution to the pinning attack).</div><div><br>=
</div><div>It&#39;s simple to [implement][1] as a mempool policy, but adds =
some complexity for wallets that use it, since it limits their use of UTXOs=
 from transactions with this bit set.<br></div><div><br></div><div>--------=
-</div><div><br></div><div>Also, coming back to the idea of &quot;we can&#3=
9;t just use {individual, ancestor} feerate,&quot; I&#39;m interested in so=
liciting feedback on adding a =E2=80=9Cmining score=E2=80=9D calculator. I&=
#39;ve implemented one [here][2] which takes the transaction in question, g=
rabs all of the connected mempool transactions (including siblings, coparen=
ts, etc., as they wouldn=E2=80=99t be in the ancestor nor descendant sets),=
 and builds a =E2=80=9Cblock template=E2=80=9D using our current mining alg=
orithm. The mining score of a transaction is the ancestor feerate at which =
it is included.<br></div><div><br></div><div>This would be helpful for some=
thing like ancestor-aware funding and fee-bumping in the wallet: [3], [4]. =
I think if we did the rate-limited priority queue for transaction relay, we=
&#39;d want to use something like this as the priority value. And for RBF, =
we probably want to require that a replacement have a higher mining score t=
han the original transactions. This could be computationally expensive to d=
o all the time; it could be good to cache it but that could make mempool bo=
okkeeping more complicated. Also, if we end up trying to switch to a candid=
ate set-based algorithm for mining, we&#39;d of course need a new calculato=
r.<br></div><div><br></div><div>[0]: <a href=3D"https://gist.github.com/glo=
zow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=3D4058140#gistcom=
ment-4058140" target=3D"_blank">https://gist.github.com/glozow/25d9662c5245=
3bd08b4b4b1d3783b9ff?permalink_comment_id=3D4058140#gistcomment-4058140</a>=
<br>[1]: <a href=3D"https://github.com/glozow/bitcoin/tree/2022-02-user-des=
climit" target=3D"_blank">https://github.com/glozow/bitcoin/tree/2022-02-us=
er-desclimit</a></div><div>[2] <a href=3D"https://github.com/glozow/bitcoin=
/tree/2022-02-mining-score" target=3D"_blank">https://github.com/glozow/bit=
coin/tree/2022-02-mining-score</a><br>[3]: <a href=3D"https://github.com/bi=
tcoin/bitcoin/issues/9645" target=3D"_blank">https://github.com/bitcoin/bit=
coin/issues/9645</a><br>[4]: <a href=3D"https://github.com/bitcoin/bitcoin/=
issues/15553" target=3D"_blank">https://github.com/bitcoin/bitcoin/issues/1=
5553</a><br></div><br><div>Best,</div><div>Gloria<br></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 8, 2=
022 at 4:58 AM Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" targe=
t=3D"_blank">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On Mon, Feb 07, 2022 at 11:16:26AM +0000, Glo=
ria Zhao wrote:<br>
&gt; @aj:<br>
&gt; &gt; I wonder sometimes if it could be sufficient to just have a relay=
 rate<br>
&gt; &gt; limit and prioritise by ancestor feerate though. Maybe something =
like:<br>
&gt; &gt; - instead of adding txs to each peers setInventoryTxToSend immedi=
ately,<br>
&gt; &gt;=C2=A0 =C2=A0set a mempool flag &quot;relayed=3Dfalse&quot;<br>
&gt; &gt; - on a time delay, add the top N (by fee rate) &quot;relayed=3Dfa=
lse&quot; txs to<br>
&gt; &gt;=C2=A0 =C2=A0each peer&#39;s setInventoryTxToSend and mark them as=
 &quot;relayed=3Dtrue&quot;;<br>
&gt; &gt;=C2=A0 =C2=A0calculate how much kB those txs were, and do this aga=
in after<br>
&gt; &gt;=C2=A0 =C2=A0SIZE/RATELIMIT seconds<br>
<br>
&gt; &gt; - don&#39;t include &quot;relayed=3Dfalse&quot; txs when building=
 blocks?<br>
<br>
The &quot;?&quot; was me not being sure that point is a good suggestion...<=
br>
<br>
Miners might reasonably decide to have no rate limit, and always relay,<br>
and never exclude txs -- but the question then becomes is whether they<br>
hear about the tx at all, so rate limiting behaviour could still be a<br>
potential problem for whoever made the tx.<br>
<br>
&gt; Wow cool! I think outbound tx relay size-based rate-limiting and<br>
&gt; prioritizing tx relay by feerate are great ideas for preventing spamme=
rs<br>
&gt; from wasting bandwidth network-wide. I agree, this would slow the low<=
br>
&gt; feerate spam down, preventing a huge network-wide bandwidth spike. And=
 it<br>
&gt; would allow high feerate transactions to propagate as they should,<br>
&gt; regardless of how busy traffic is. Combined with inbound tx request<br=
>
&gt; rate-limiting, might this be sufficient to prevent DoS regardless of t=
he<br>
&gt; fee-based replacement policies?<br>
<br>
I think you only want to do outbound rate limits, ie, how often you send<br=
>
INV, GETDATA and TX messages? Once you receive any of those, I think<br>
you have to immediately process / ignore it, you can&#39;t really sensibly<=
br>
defer it (beyond the existing queues we have that just build up while<br>
we&#39;re busy processing other things first)?<br>
<br>
&gt; One point that I&#39;m not 100% clear on: is it ok to prioritize the<b=
r>
&gt; transactions by ancestor feerate in this scheme? As I described in the=
<br>
&gt; original post, this can be quite different from the actual feerate we =
would<br>
&gt; consider a transaction in a block for. The transaction could have a hi=
gh<br>
&gt; feerate sibling bumping its ancestor.<br>
&gt; For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB).=
 If<br>
&gt; we just received C, it would be incorrect to give it a priority equal =
to<br>
&gt; its ancestor feerate (3sat/vB) because if we constructed a block templ=
ate<br>
&gt; now, B would bump A, and C&#39;s new ancestor feerate is 5sat/vB.<br>
&gt; Then, if we imagine that top N is &gt;5sat/vB, we&#39;re not relaying =
C. If we<br>
&gt; also exclude C when building blocks, we&#39;re missing out on good fee=
s.<br>
<br>
I think you&#39;re right that this would be ugly. It&#39;s something of a<b=
r>
special case:<br>
<br>
=C2=A0a) you really care about C getting into the next block; but<br>
=C2=A0b) you&#39;re trusting B not being replaced by a higher fee tx that<b=
r>
=C2=A0 =C2=A0 doesn&#39;t have A as a parent; and<br>
=C2=A0c) there&#39;s a lot of txs bidding the floor of the next block up to=
 a<br>
=C2=A0 =C2=A0 level in-between the ancestor fee rate of 3sat/vB and the tx =
fee<br>
=C2=A0 =C2=A0 rate of 5sat/vB<br>
<br>
Without (a), maybe you don&#39;t care about it getting to a miner quickly.<=
br>
If your trust in (b) was misplaced, then your tx&#39;s effective fee rate<b=
r>
will drop and (because of (c)), you&#39;ll lose anyway. And if the spam end=
s<br>
up outside of (c)&#39;s range, either the rate limiting won&#39;t take effe=
ct<br>
(spam&#39;s too cheap) and you&#39;ll be fine, or you&#39;ll miss out on th=
e block<br>
anyway (spam&#39;s paying more than your tx rate) and you never had any hop=
e<br>
of making it in.<br>
<br>
Note that we already rate limit via INVENTORY_BROADCAST_MAX /<br>
*_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs<br>
per 10 minutes for outbound connections. This would be a weight based<br>
rate limit instead-of/in-addition-to that, I guess.<br>
<br>
As far as a non-ugly approach goes, I think you&#39;d have to be smarter ab=
out<br>
tracking the &quot;effective fee rate&quot; than the ancestor fee rate mana=
ges;<br>
maybe that&#39;s something that could fall out of Murch and Clara&#39;s can=
didate<br>
set blockbuilding ideas [0] ?<br>
<br>
Perhaps that same work would also make it possible to come up with<br>
a better answer to &quot;do I care that this replacement would invalidate<b=
r>
these descendents?&quot;<br>
<br>
[0] <a href=3D"https://github.com/Xekyo/blockbuilding" rel=3D"noreferrer" t=
arget=3D"_blank">https://github.com/Xekyo/blockbuilding</a><br>
<br>
&gt; &gt; - keep high-feerate evicted txs around for a while in case they g=
et<br>
&gt; &gt;=C2=A0 =C2=A0mined by someone else to improve compact block relay,=
 a la the<br>
&gt; &gt;=C2=A0 =C2=A0orphan pool?<br>
&gt; Replaced transactions are already added to vExtraTxnForCompact :D<br>
<br>
I guess I was thinking that it&#39;s just a 100 tx LRU cache, which might<b=
r>
not be good enough?<br>
<br>
Maybe it would be more on point to have a rate limit apply only to<br>
replacement transactions?<br>
<br>
&gt; For wallets, AJ&#39;s &quot;All you need is for there to be *a* path t=
hat follows<br>
&gt; the new relay rules and gets from your node/wallet to perhaps 10% of<b=
r>
&gt; hashpower&quot; makes sense to me (which would be the former).<br>
<br>
Perhaps a corollarly of that is that it&#39;s *better* to have the mempool<=
br>
acceptance rule only consider economic incentives, and have the spam<br>
prevention only be about &quot;shall I tell my peers about this?&quot;<br>
<br>
If you don&#39;t have that split; then the anti-spam rules can prevent you<=
br>
from getting the tx in the mempool at all; whereas if you do have the<br>
split, then even if the bitcoind anti-spam rules are blocking you at<br>
every turn, you can still send your tx to miners by some other route,<br>
and then they can add it to their mempool directly without any hassle.<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000546ada05d9f3bc2d--