path: root/3e/d02b73cc53b1186d64d037b0511c2f05ef46b4

Return-Path: <gloriajzhao@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35D5BC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 15:10:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 114A8610AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 15:10:11 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ME1sPoN7K9ih
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 15:10:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
 [IPv6:2607:f8b0:4864:20::b2b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1C48F60AD7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 15:10:08 +0000 (UTC)
Received: by mail-yb1-xb2b.google.com with SMTP id w16so4924477ybi.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 09 Mar 2022 07:10:07 -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=IcM6tt6doCa9nZFzoKiI7wptGVFqoSU5m3p5lIbC7OE=;
 b=VNn+Lg07740I9VD7DEVG2fFiveqgxx7YgJgLu7uLnsdMQgtrrmKw2i7p7BXFLijMeh
 fI2/iWWd/qaF5iPm36VKIYcF4H9QfuBzAtCGkv35khqbXueFVQU5dYU/ZWPUrIItBUEy
 1h7Qex/hLONB+KVbTXIp3+bthkC6xUcUR1eAZj8T9wNcaC7nuDc80S6Ado8NzdQv7WDU
 f8KIps+wEFqt59FUEdWIWFesDut7gOJ3vOWinsXcdw06wzssJ+N1BGmAC7y/d9j2sDum
 iEA+/ppnjiizpT8AMMwXfTM+lZR4O91j39PPhq6YvecMIINhkw3h/PIG6pocouISORtB
 RytQ==
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=IcM6tt6doCa9nZFzoKiI7wptGVFqoSU5m3p5lIbC7OE=;
 b=6oRG8UrEg3c3nXu3S7DpitljROqOGULvP0PEavYvu2ZmdGww1n7w91XYIWbbYAFMdS
 WadpYD7KSe4a7wZFtr71vVX7DFoDwPPohibjaAEqJanOM6ms9BMPaVXldzThbMpcrCjy
 Mp4pmTG7F+6Ny/BVj00+RWumglvoI4FUFOlXZ/5W/uG7K65ghVRqobjmw+nK4CwS2Zpc
 aRSBIdVRH15+6hxzErHibnvbt7hPwTKchAx3n26vbA7Vn5gDsuqKTGSdRqS5NjqO/XrQ
 n7pHT3OVPQYLxmvheyCPo6qRj+zzmP/jgoTUWXpOvdPzg/emssVkp5h6f8GrB8TzwdhV
 VY4g==
X-Gm-Message-State: AOAM5315TFXRlJ4oNinc2VF19oyq070+rYQc8HNH/ZOkQVKCyKR0L73W
 4wyezj/Km1cWhc1KELeAlbfwaEh2zHTEdCWDRYxZkaZrnx0=
X-Google-Smtp-Source: ABdhPJxQdx6hmG1Xj0DqYOH2vXQUvpL4Sg3JEwoUpMRJgrtsiKLLK+vWkqKI3Pe6IwkKKxaEpnnuDrAYKGdJ7s55B00=
X-Received: by 2002:a05:6902:13c1:b0:613:74e6:a7a6 with SMTP id
 y1-20020a05690213c100b0061374e6a7a6mr79467ybu.141.1646838606865; Wed, 09 Mar
 2022 07:10:06 -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>
In-Reply-To: <20220208045850.GA6538@erisian.com.au>
From: Gloria Zhao <gloriajzhao@gmail.com>
Date: Wed, 9 Mar 2022 15:09:55 +0000
Message-ID: <CAFXO6=KMveswFvYdFCjsvt7a-Af+act4K3p8UrJXGyBO8E1o+w@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000002a26e705d9ca7e35"
X-Mailman-Approved-At: Wed, 09 Mar 2022 15:37:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 09 Mar 2022 15:10:11 -0000

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

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 operator,
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 only
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 this
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 transaction,=
 i.e.,
an attacker can censor somebody=E2=80=99s transaction from ever being annou=
nced 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, but
I imagine 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 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 t=
he 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, 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 i=
t 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 thread
(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 bit 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. It
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 from
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=9Cmining=
 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 nor
descendant sets), and builds a =E2=80=9Cblock template=E2=80=9D using our c=
urrent 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 this
as the priority value. And for RBF, we probably want to require that a
replacement have a higher mining score than the original transactions. This
could be computationally expensive to do all the time; it could be good to
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_c=
omment_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 rat=
e
> > > limit and prioritise by ancestor feerate though. Maybe something like=
:
> > > - instead of adding txs to each peers setInventoryTxToSend immediatel=
y,
> > >   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 spammer=
s
> > 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 th=
e
> > 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 hig=
h
> > 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 t=
o
> > its ancestor feerate (3sat/vB) because if we constructed a block templa=
te
> > 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 abou=
t
> 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 follow=
s
> > 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
>
>

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

<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-l=
imiting), user-elected descendant limit as a short term solution to unblock=
 package RBF, and mining score, all open for feedback:<br><br>One big conce=
pt discussed was baking DoS protection into the p2p level rather than polic=
y level. TLDR: The fees are not paid to the node operator, but to the miner=
. While we can 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 the bleeding&quot; when it happens and bound the amount of resou=
rces used in general. There were two main ideas:<br><br>1. Transaction rela=
y rate limiting (i.e. the one you proposed above or some variation) with a =
feerate-based priority queue<br>2. Staggered broadcast of replacement trans=
actions: within some time interval, maybe accept multiple replacements for =
the same prevout, but only relay the original transaction.<br><br>Looking t=
o 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 this way?<br><br>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 transaction, i.e., a=
n attacker can censor somebody=E2=80=99s transaction from ever being announ=
ced by a node if they send enough transactions to fill up the rate limit. O=
bviously this would be expensive since they&#39;re spending a lot on fees, =
but I imagine it could be profitable in some situations to spend a few thou=
sand dollars to prevent anyone from hearing about a transaction for a few h=
ours. This might be a non-issue in practice if the rate limit is generous a=
nd traffic isn=E2=80=99t horrendous, but is this a problem?<br><br>And if w=
e don&#39;t require an increase in (i.e. addition of &quot;new&quot;) absol=
ute 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 pot=
entially be placed higher in the queue, ahead of other users=E2=80=99 trans=
actions, multiple 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 param=
eters right, but it seems=E2=80=A6 not great, in principle.<br></div><div><=
br></div><div>---------<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 o=
n the gist containing my original post on this thread (<a href=3D"https://g=
ist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff">https://gist.github=
.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff</a>).</div><div><br></div><div=
>Suhas and Matt [proposed][0] adding a policy rule allowing users to specif=
y descendant limits on their transactions. For example, some nth bit of nSe=
quence with nVersion 3 means &quot;this transaction won&#39;t have more tha=
n X vbytes of descendants&quot; where X =3D max(1000, vsizeof(tx)) or somet=
hing. It solves the pinning problem with package RBF where the attacker&#39=
;s package contains a very large and high-fee descendant.</div><div><br></d=
iv><div>We could add this policy and deploy it with package RBF/package rel=
ay 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).</div><div><br></div>=
<div>It&#39;s simple to [implement][1] as a mempool policy, but adds some c=
omplexity 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&#39;t ju=
st use {individual, ancestor} feerate,&quot; I&#39;m interested in soliciti=
ng 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, grabs a=
ll of the connected mempool transactions (including siblings, coparents, et=
c., as they wouldn=E2=80=99t be in the ancestor nor descendant sets), and b=
uilds 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.<br></div><div><br></div><div>This would be helpful for something =
like ancestor-aware funding and fee-bumping in the wallet: [3], [4]. I thin=
k 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 pro=
bably want to require that a replacement have a higher mining score than th=
e original transactions. This could be computationally expensive to do all =
the time; it could be good to cache it but that could make mempool bookkeep=
ing more complicated. Also, if we end up trying to switch to a candidate se=
t-based algorithm for mining, we&#39;d of course need a new calculator.<br>=
</div><div><br></div><div>[0]: <a href=3D"https://gist.github.com/glozow/25=
d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=3D4058140#gistcomment-4=
058140">https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?per=
malink_comment_id=3D4058140#gistcomment-4058140</a><br>[1]: <a href=3D"http=
s://github.com/glozow/bitcoin/tree/2022-02-user-desclimit">https://github.c=
om/glozow/bitcoin/tree/2022-02-user-desclimit</a></div><div>[2] <a href=3D"=
https://github.com/glozow/bitcoin/tree/2022-02-mining-score">https://github=
.com/glozow/bitcoin/tree/2022-02-mining-score</a><br>[3]: <a href=3D"https:=
//github.com/bitcoin/bitcoin/issues/9645">https://github.com/bitcoin/bitcoi=
n/issues/9645</a><br>[4]: <a href=3D"https://github.com/bitcoin/bitcoin/iss=
ues/15553">https://github.com/bitcoin/bitcoin/issues/15553</a><br></div><br=
><div>Best,</div><div>Gloria<br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 8, 2022 at 4:58 AM Anthon=
y Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, F=
eb 07, 2022 at 11:16:26AM +0000, Gloria 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>

--0000000000002a26e705d9ca7e35--