path: root/a9/981835009f6407381b1c46905691c8aea9b6c6

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E6978C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:59:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E1DC640A7A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:59:32 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id k-boBV89mlKe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:59:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [IPv6:2a00:1450:4864:20::62b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8B4C340587
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:59:29 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id dr20so11383754ejc.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 08:59:29 -0700 (PDT)
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=8PTUctrSdi2nyfzWoVhZE9Al53e1Zz5+IdrQvNqoqlk=;
 b=eO9N0kz+vUj3VmpYEVXTHgSLWoyxgh1pf8bzvJe19nT1iZ93tjGytpEe87OTbaea56
 FdSVpvMu/nevBCOK2r14wGq5KlGGlfSsz7ghg+u5gP4TwS87Rb0lbkDtSSWpIu3Byhzk
 Ktnhzx1dnqweNYg7CB3/qi3S5Q4AiMKJ4Gn6j8Hf0fQ90JqHX+6g5Q6AqosHNpFTdJDb
 EPnZSMJAQChi/Qq05MZV035Sql8bWRrGx6Ynkcw32w2tQNOicq+If3+XVhqMJlPun3EP
 Azs8FW2Hf4P4Vk5L7kngCa/XTCZgXY4DgRWMt7x2KVvwspx4KbVVdZeZ+L1jT7PvousB
 r6AQ==
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=8PTUctrSdi2nyfzWoVhZE9Al53e1Zz5+IdrQvNqoqlk=;
 b=ggmlVw9ARYSn+DW7GoRTbHzv4kZOogHScVC4M3FmJ3r/8G1OP7W+vaO92NcpBaxF/R
 2ALW9yuWiwgewdAqFfjSDHyPYvjk1VAqR4mu2wSXvY7W5caVufEREauoSI52RzN8qi4A
 jlPquOHxwpA6sHJ20LfUI7z6d95Nz73yGrs1I3Hlv9+GNw0KfyoK2aLjuoCsz+H3lIMF
 9cKP3khEw25EUovCfZIL8nqMg/8bpu4VaCNhdJkQ+kO6MdqAzmlDBemNBdZrxt8eyGLr
 kQnxRPWlHZAle6RKmlOuBrH05FzAqiAPSaY/wGwMsJItzCIzicZ0Aanuf+3NQHUbyGBW
 H52A==
X-Gm-Message-State: AOAM533DMs7ZYeDoTBoIDDPuotgQ8QjI4cDhyo7lE/VZJgP/st3YJrtf
 r2OYw+M/PQBQex+s2vLnxWz04ADlaBOQJaVXa98v9hVX
X-Google-Smtp-Source: ABdhPJxy0nCMuSNb30SPxBhpu60qeOkFhajDmR2MOoh99SO5XVMoEMQeX7zAsfD9pA1AL05UAK0KmBv7j0o2gCab94o=
X-Received: by 2002:a17:906:9741:b0:6da:c274:6b18 with SMTP id
 o1-20020a170906974100b006dac2746b18mr4982668ejy.207.1647532767250; Thu, 17
 Mar 2022 08:59:27 -0700 (PDT)
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>
 <CALZpt+EOJW_Dmq_+2oNhmQF3x4KJ-qaM7=XGEYnt0JkWsPjh7g@mail.gmail.com>
In-Reply-To: <CALZpt+EOJW_Dmq_+2oNhmQF3x4KJ-qaM7=XGEYnt0JkWsPjh7g@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 17 Mar 2022 10:59:11 -0500
Message-ID: <CAGpPWDYma7KNVZo9LSfonvCornP7UipLZxREUSunZ2_Ec30dWA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000590e4405da6c1d69"
X-Mailman-Approved-At: Thu, 17 Mar 2022 16:16:52 +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: Thu, 17 Mar 2022 15:59:33 -0000

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

@Antoine
>  B overrides A and starts to replace package A in the network mempools
nearest to Alice. I think those peers won't have bandwidth saving from
adopting a replacement staggering strategy.

That's an interesting point, but even with that fact, the method would be
effective at limiting spam. While yes, considering just a single unit of
potential spam, only the nodes that didn't relay the spam in the first
place would save bandwidth. However, the point is not to prevent a single
unit, but to prevent thousands of units of spam. Even if in the situation
you describe Bob and Alice sent 100 replacement transaction per seconds, it
would lead to only 1 transaction sent by Bob's peers and only 2
transactions sent by Alice's peers (within a given stagger/cooldown
window). That seems pretty effective to me.

> I wonder if a "diff-only" strategy.. would be more interesting

I think a diff-only relay strategy is definitely interesting. But its
completely orthogonal. A diff only strategy isn't really a spam reduction
mechanism, but rather a relay optimization that reduces bandwidth on all
relay. Both can be done - seems like it could be argued that both should be
done.

>> For example, some nth bit of nSequence with nVersion 3 means "this
transaction won't have more than X vbytes of descendants"
>what if the pinning transaction has a parent with a junk feerate ?

I think you're right that this scheme would also be susceptible to pinning.

One thing I've identified as pretty much always suboptimal in any kind of
policy is cliffs. Hard cut offs very often cause problems. You see this in
welfare cliffs where the cliff disincentivizes people from earning more
money for example. Its almost always better to build in a smooth gradient.

Rate limiting where a node would relay replacement transaction data up to a
certain point and then stop is a cliff like this. The descendant byte limit
is a cliff like this. If such things were to be actually done, I'd
recommend building in some kind of gradient where, say, every X vbytes of
descendents requires Y additional feerate, or something to that effect.
That way you can always add more descendents as long as you're willing to
pay a higher and higher feerate for them. However, I think simply removing
the absolute feerate rule is a better solution to that kind of RBF pinning.



On Thu, Mar 17, 2022 at 4:32 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Mempoololic Anonymous fellow,
>
> > 2. Staggered broadcast of replacement transactions: within some time
> > interval, maybe accept multiple replacements for the same prevout, but
> only
> > relay the original transaction.
>
> If the goal of replacement staggering is to save on bandwidth, I'm not
> sure it's going to be effective if you consider replacement done from a
> shared-utxo. E.g, Alice broadcasts a package to confirm her commitment,
> relay is staggered until T. At the same time, Bob broadcasts a package to
> confirm his version of the commitment at a slightly better feerate, relay
> is staggered until T.
>
> At T, package A gradually floods from Alice's peers and package B does th=
e
> same from Bob's peers. When there is an intersection. B overrides A and
> starts to replace package A in the network mempools nearest to Alice. I
> think those peers won't have bandwidth saving from adopting a replacement
> staggering strategy.
>
> Or maybe that's something completely different if you have in mind ? I
> think it's worth more staggering detail to guess if it's robust against a=
ll
> the replacement propagations patterns.
>
> Though if we aim to save on replacement bandwidth I wonder if a
> "diff-only" strategy, assuming some new p2p mechanism, would be more
> interesting (as discussed in the recent "Thoughts on fee bumping thread")=
.
>
> > 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 transact=
ion, i.e.,
> > an attacker can censor somebody=E2=80=99s transaction from ever being a=
nnounced
> 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?
>
> I think I share the concern too about an attacker exhausting a node
> transaction relay ressources to prevent another person's transaction to
> propagate, especially if the transaction targeted is a L2's time-sensitiv=
e
> one. In that latter context, an attacker would aim to delay the relay of =
a
> time-sensitive transaction (e.g a HTLC-success) to the miners, until the
> timelock expires. The malicious delay period should swallow the go-to-cha=
in
> HTLC deadline ("the deadline for received HTLCs this node fulfilled" in
> bolt 2 parlance), in that current example 18 blocks.
>
> Let's say we allocate 10 MB of bandwidth per-block period. Once the 10 MB
> are exhausted, there is no more bandwidth allocated until the next block =
is
> issued. If the top mempool feerate is 1 sat/vb, such naive design would
> allow an attacker to buy all the p2p network bandwidth period for 0.1 BTC=
.
> If an attacker aims to jam a HTLC transaction for the 18 blocks period, t=
he
> cost is of 1,8 BTC. If the attacker is a LN counterparty to a HTLC worth
> more than 1.8 BTC, the attack sounds economically profitable.
>
> Worst, the p2p network bandwidth is a public resource while a HTLC is a
> private, off-chain contract. An attacker could be counterparty to many
> HTLCs, where each HTLC individual value is far inferior to the global p2p
> bandwidth cost but the sum, only known to the attacker, is superior to.
> Therefore, it sounds to me that p2p network bandwidth might be attractive
> if the stealing are batched.
>
> Is the attacker scenario described credible ? Are the numbers sketched ou=
t
> realistic ?
>
> If yes, I think one design insight for eventual transaction relay rate
> limiting would be to make them "dynamic", and not naively fixed for a
> period. By making them dynamic, an attacker would have to compete with th=
e
> effective feerate proposed by the victim transaction. E.g, if the
> HTLC-success feerate is of 10 sat/vb, an attacker would have to propose a
> stream of malicious transaction of more than 10 sat/vb during the whole
> HTLC deadline period for the transaction-relay jamming to be effective.
>
> Further, the attack might be invisible from the victim standpoint, the
> malicious flow of feerate competitive transactions can be hard to
> dissociate from an honest one. Thus, you can expect the
> HTLC transaction issuer to only slowly increase the feerate at each block=
,
> and those moves to be anticipated by the attacker. Even if the transactio=
n
> issuer adopts a scorched-earth approach for the latest blocks of the
> deadline, the absolute value of the HTLC burnt in fees might still be les=
s
> than the transaction relay bandwidth exhaustion paid by the attacker
> because the attack is batched by the attacker.
>
> I'm not sure if this reasoning is correct. Though if yes, the issue sound=
s
> really similar to "flood&loot" attack affecting LN previously researched =
on
> [0]. What worries me more with this "exhaust&loot" is that if we introduc=
e
> bounded transaction relay rate limiting, it sounds a cheaper public
> ressource to buy than the mempool..
>
> [0] https://arxiv.org/pdf/2006.08513.pdf
>
> Anyway, I would say it's worthy to investigate more transaction relay rat=
e
> limiting designs and especially carefully weigh the implications for L2s.
> Those ones might have to adjust their fee-bumping and transaction
> rebroadcast strategies in consequence.
>
> > 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 packag=
e
> > contains a very large and high-fee descendant.
>
> Hey, what if the pinning transaction has a parent with a junk feerate ?
>
> Let's say you have commitment tx for a HTLC of value 500000 sats, with to=
p
> mempool feerate of 50 sat/vbyte. The commitment tx is pinned by a malicio=
us
> tx of size 1000 vbytes, matching top mempool feerate. This malicious tx h=
as
> a second unconfirmed parent (in addition to the commitment) of size
> MAX_STANDARD_TX_WEIGHT offering a 1 sat/vb. I think the pinning transacti=
on
> ancestor score would be less than 2 sat/vb and thus considered irrelevant
> for block template inclusion ? At the same time, as the pinning transacti=
on
> is attached with a top mempool feerate, the honest user wouldn't be able =
to
> replace it with a better-feerate proposal ? Unless adopting a
> scorched-earth approach,  although economically I don't think this
> fee-bumping strategy is safe in case of batch-pinning.
>
> It might be fixable if we make one additional requirement "The child
> transaction subject to the user-elected descendant limit must have only o=
ne
> unconfirmed parent" (here the commitment
> transaction) ? Though I'm not even sure of the robustness of this fix. Th=
e
> commitment transaction itself could be used as a junk parent to downgrade
> the pinning transaction ancestor score. E.g, using a revoked commitment
> transaction with `max_accepted_htlcs` on both sides, pre-signed with a
> feerate of 1 sat/vb. We might restrict the maximum number of pending HTLC=
s
> network-wise to make the worst commitment transaction size reasonable,
> though not sure if my LN colleagues are going to like the idea..
>
> Is that reasoning correct and conform to our Ancestor Set Based algorithm
> approach ? Maybe more details are needed.
>
> > 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=9Cmi=
ning
> 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 o=
ur current mining
> > algorithm. The mining score of a transaction is the ancestor feerate at
> > which it is included.
>
> I don't have a strong opinion there yet, though if we make this "block
> template" construction the default one, I would be really conservative to
> avoid malicious child attachment on multi-party transactions downgrading
> the block inclusion efficiency.
>
> Antoine
>
> Le mer. 9 mars 2022 =C3=A0 10:37, Gloria Zhao via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> 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 operat=
or,
>> 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 amoun=
t
>> 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 o=
nly
>> relay the original transaction.
>>
>> Looking to solicit feedback on these ideas and the concept in general. I=
s
>> 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 t=
his
>> 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 transacti=
on, i.e.,
>> an attacker can censor somebody=E2=80=99s transaction from ever being an=
nounced 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 thous=
and
>> dollars to prevent anyone from hearing about a transaction for a few hou=
rs.
>> 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. I=
n 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, =
multiple
>> times, without ever adding more fees to the transaction. Again, maybe th=
is
>> isn=E2=80=99t a huge deal in practice if we set the parameters right, bu=
t 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 thr=
ead
>> (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 b=
it
>> of nSequence with nVersion 3 means "this transaction won't have more tha=
n 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 f=
rom
>> 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 usin=
g our current
>> mining algorithm. The mining score of a transaction is the ancestor feer=
ate
>> 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 th=
is
>> as the priority value. And for RBF, we probably want to require that a
>> replacement have a higher mining score than the original transactions. T=
his
>> 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?permalin=
k_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
>>> 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=3Dfalse"
>>> > > - on a time delay, add the top N (by fee rate) "relayed=3Dfalse" tx=
s 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
>>> spammers
>>> > from wasting bandwidth network-wide. I agree, this would slow the low
>>> > feerate spam down, preventing a huge network-wide bandwidth spike. An=
d
>>> 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 sen=
d
>>> 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 th=
e
>>> > 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 end=
s
>>> 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 hop=
e
>>> 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 candida=
te
>>> 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
>>>
>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>@<span style=3D"color:rgb(32,33,36);font-size:0.875re=
m;letter-spacing:0.2px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-=
serif;white-space:nowrap">Antoine</span></div>&gt;=C2=A0

B overrides A and starts to replace package A in the network mempools neare=
st to Alice. I think those peers won&#39;t have bandwidth saving from adopt=
ing a replacement staggering strategy.<div><br></div><div>That&#39;s an int=
eresting point, but even with that fact, the method would be effective at l=
imiting spam. While yes, considering just a single unit of potential spam, =
only the nodes that didn&#39;t relay the spam in the first place would save=
 bandwidth. However, the point is not to prevent a single unit, but to prev=
ent thousands of units of spam. Even if in the situation you describe Bob a=
nd Alice sent 100 replacement transaction per seconds, it would lead to onl=
y 1 transaction sent by Bob&#39;s peers and only 2 transactions sent by Ali=
ce&#39;s peers (within a given stagger/cooldown window). That seems pretty =
effective to me.=C2=A0</div><div><br></div><div>&gt; I wonder if a &quot;di=
ff-only&quot; strategy.. would be more interesting</div><div><br></div><div=
>I think a diff-only relay strategy is definitely interesting. But its comp=
letely orthogonal. A diff only strategy isn&#39;t really a spam reduction m=
echanism, but rather a relay optimization that reduces bandwidth on all rel=
ay. Both can be done - seems like it could be argued that both should be do=
ne.=C2=A0</div><div><br></div><div>&gt;&gt;=C2=A0<span style=3D"color:rgb(8=
0,0,80)">For example, some nth bit of=C2=A0</span><span style=3D"color:rgb(=
80,0,80)">nSequence with nVersion 3 means &quot;this transaction won&#39;t =
have more than X=C2=A0</span>vbytes<span style=3D"color:rgb(80,0,80)"> of d=
escendants&quot;</span></div><div><span style=3D"color:rgb(80,0,80)">&gt;</=
span>what if the pinning transaction has a parent with a junk feerate ?</di=
v><div><br></div><div>I think you&#39;re right that this scheme would also =
be susceptible=C2=A0to pinning.=C2=A0</div><div><br></div><div>One thing I&=
#39;ve identified as pretty much always suboptimal in any kind of policy is=
 cliffs. Hard cut offs very often cause problems. You see this in welfare c=
liffs where the cliff disincentivizes people from earning more money for ex=
ample. Its almost always better to build in a smooth gradient.=C2=A0</div><=
div><br></div><div>Rate limiting where a node would relay replacement trans=
action data up to a certain point and then stop is a cliff like this. The d=
escendant byte limit is a cliff like this. If such things were to be actual=
ly done, I&#39;d recommend building in some kind of gradient where, say, ev=
ery X vbytes of descendents requires Y additional feerate, or something to =
that effect. That way you can always add more descendents as long as you&#3=
9;re willing to pay a higher and higher feerate for them. However, I think =
simply removing the absolute feerate rule is a better solution to that kind=
 of RBF pinning.</div><div><br></div><div><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 17, 2022 at=
 4:32 AM Antoine Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>Hi Mempoololic Anonymous fellow,<br><br>&gt; 2. =
Staggered broadcast of replacement transactions: within some time<br>&gt; i=
nterval, maybe accept multiple replacements for the same prevout, but only<=
br>&gt; relay the original transaction.<br><br>If the goal of replacement s=
taggering is to save on bandwidth, I&#39;m not sure it&#39;s going to be ef=
fective if you consider replacement done from a shared-utxo. E.g, Alice bro=
adcasts a package to confirm her commitment, relay is staggered until T. At=
 the same time, Bob broadcasts a package to confirm his version of the comm=
itment at a slightly better feerate, relay is staggered until T.<br><br>At =
T, package A gradually floods from Alice&#39;s peers and package B does the=
 same from Bob&#39;s peers. When there is an intersection. B overrides A an=
d starts to replace package A in the network mempools nearest to Alice. I t=
hink those peers won&#39;t have bandwidth saving from adopting a replacemen=
t staggering strategy.<br><br>Or maybe that&#39;s something completely diff=
erent if you have in mind ? I think it&#39;s worth more staggering detail t=
o guess if it&#39;s robust against all the replacement propagations pattern=
s.<br><br>Though if we aim to save on replacement bandwidth I wonder if a &=
quot;diff-only&quot; strategy, assuming some new p2p mechanism, would be mo=
re interesting (as discussed in the recent &quot;Thoughts on fee bumping th=
read&quot;).<br><br>&gt; A lingering concern that I have about this idea is=
 it would then be<br>&gt; possible to impact the propagation of another per=
son=E2=80=99s transaction, i.e.,<br>&gt; an attacker can censor somebody=E2=
=80=99s transaction from ever being announced by<br>&gt; a node if they sen=
d enough transactions to fill up the rate limit.<br>&gt; Obviously this wou=
ld be expensive since they&#39;re spending a lot on fees, but<br>&gt; I ima=
gine it could be profitable in some situations to spend a few thousand<br>&=
gt; dollars to prevent anyone from hearing about a transaction for a few ho=
urs.<br>&gt; This might be a non-issue in practice if the rate limit is gen=
erous and<br>&gt; traffic isn=E2=80=99t horrendous, but is this a problem?<=
br><br>I think I share the concern too about an attacker exhausting a node =
transaction relay ressources to prevent another person&#39;s transaction to=
 propagate, especially if the transaction targeted is a L2&#39;s time-sensi=
tive one. In that latter context, an attacker would aim to delay the relay =
of a time-sensitive transaction (e.g a HTLC-success) to the miners, until t=
he timelock expires. The malicious delay period should swallow the go-to-ch=
ain HTLC deadline (&quot;the deadline for received HTLCs this node fulfille=
d&quot; in bolt 2 parlance), in that current example 18 blocks.<br><br>Let&=
#39;s say we allocate 10 MB of bandwidth per-block period. Once the 10 MB a=
re exhausted, there is no more bandwidth allocated until the next block is =
issued. If the top mempool feerate is 1 sat/vb, such naive design would all=
ow an attacker to buy all the p2p network bandwidth period for 0.1 BTC. If =
an attacker aims to jam a HTLC transaction for the 18 blocks period, the co=
st is of 1,8 BTC. If the attacker is a LN counterparty to a HTLC worth more=
 than 1.8 BTC, the attack sounds economically profitable.<br><br>Worst, the=
 p2p network bandwidth is a public resource while a HTLC is a private, off-=
chain contract. An attacker could be counterparty to many HTLCs, where each=
 HTLC individual value is far inferior to the global p2p bandwidth cost but=
 the sum, only known to the attacker, is superior to. Therefore, it sounds =
to me that p2p network bandwidth might be attractive if the stealing are ba=
tched.<br><br>Is the attacker scenario described credible ? Are the numbers=
 sketched out realistic ?<br><br>If yes, I think one design insight for eve=
ntual transaction relay rate limiting would be to make them &quot;dynamic&q=
uot;, and not naively fixed for a period. By making them dynamic, an attack=
er would have to compete with the effective feerate proposed by the victim =
transaction. E.g, if the HTLC-success feerate is of 10 sat/vb, an attacker =
would have to propose a stream of malicious transaction of more than 10 sat=
/vb during the whole HTLC deadline period for the transaction-relay jamming=
 to be effective.<br><br>Further, the attack might be invisible from the vi=
ctim standpoint, the malicious flow of feerate competitive transactions can=
 be hard to dissociate from an honest one. Thus, you can expect the<br>HTLC=
 transaction issuer to only slowly increase the feerate at each block, and =
those moves to be anticipated by the attacker. Even if the transaction issu=
er adopts a scorched-earth approach for the latest blocks of the deadline, =
the absolute value of the HTLC burnt in fees might still be less than the t=
ransaction relay bandwidth exhaustion paid by the attacker because the atta=
ck is batched by the attacker.<br><br>I&#39;m not sure if this reasoning is=
 correct. Though if yes, the issue sounds really similar to &quot;flood&amp=
;loot&quot; attack affecting LN previously researched on [0]. What worries =
me more with this &quot;exhaust&amp;loot&quot; is that if we introduce boun=
ded transaction relay rate limiting, it sounds a cheaper public ressource t=
o buy than the mempool..<br><br>[0] <a href=3D"https://arxiv.org/pdf/2006.0=
8513.pdf" target=3D"_blank">https://arxiv.org/pdf/2006.08513.pdf</a><br><br=
>Anyway, I would say it&#39;s worthy to investigate more transaction relay =
rate limiting designs and especially carefully weigh the implications for L=
2s. Those ones might have to adjust their fee-bumping and transaction rebro=
adcast strategies in consequence.<br><br>&gt; Suhas and Matt [proposed][0] =
adding a policy rule allowing users to specify<br>&gt; descendant limits on=
 their transactions. For example, some nth bit of<br>&gt; nSequence with nV=
ersion 3 means &quot;this transaction won&#39;t have more than X<br>&gt; vb=
ytes of descendants&quot; where X =3D max(1000, vsizeof(tx)) or something. =
It<br>&gt; solves the pinning problem with package RBF where the attacker&#=
39;s package<br>&gt; contains a very large and high-fee descendant.<br><br>=
Hey, what if the pinning transaction has a parent with a junk feerate ? <br=
><br>Let&#39;s say you have commitment tx for a HTLC of value 500000 sats, =
with top mempool feerate of 50 sat/vbyte. The commitment tx is pinned by a =
malicious tx of size 1000 vbytes, matching top mempool feerate. This malici=
ous tx has a second unconfirmed parent (in addition to the commitment) of s=
ize MAX_STANDARD_TX_WEIGHT offering a 1 sat/vb. I think the pinning transac=
tion ancestor score would be less than 2 sat/vb and thus considered irrelev=
ant for block template inclusion ? At the same time, as the pinning transac=
tion is attached with a top mempool feerate, the honest user wouldn&#39;t b=
e able to replace it with a better-feerate proposal ? Unless adopting a sco=
rched-earth approach,=C2=A0 although economically I don&#39;t think this fe=
e-bumping strategy is safe in case of batch-pinning.<br><br>It might be fix=
able if we make one additional requirement &quot;The child transaction subj=
ect to the user-elected descendant limit must have only one unconfirmed par=
ent&quot; (here the commitment<br>transaction) ? Though I&#39;m not even su=
re of the robustness of this fix. The commitment transaction itself could b=
e used as a junk parent to downgrade the pinning transaction ancestor score=
. E.g, using a revoked commitment transaction with `max_accepted_htlcs` on =
both sides, pre-signed with a feerate of 1 sat/vb. We might restrict the ma=
ximum number of pending HTLCs network-wise to make the worst commitment tra=
nsaction size reasonable, though not sure if my LN colleagues are going to =
like the idea..<br><br>Is that reasoning correct and conform to our Ancesto=
r Set Based algorithm approach ? Maybe more details are needed.<br><br>&gt;=
 Also, coming back to the idea of &quot;we can&#39;t just use {individual, =
ancestor}<br>&gt; feerate,&quot; I&#39;m interested in soliciting feedback =
on adding a =E2=80=9Cmining score=E2=80=9D<br>&gt; calculator. I&#39;ve imp=
lemented one [here][2] which takes the transaction in<br>&gt; question, gra=
bs all of the connected mempool transactions (including<br>&gt; siblings, c=
oparents, etc., as they wouldn=E2=80=99t be in the ancestor nor<br>&gt; des=
cendant sets), and builds a =E2=80=9Cblock template=E2=80=9D using our curr=
ent mining<br>&gt; algorithm. The mining score of a transaction is the ance=
stor feerate at<br>&gt; which it is included.<br><br>I don&#39;t have a str=
ong opinion there yet, though if we make this &quot;block template&quot; co=
nstruction the default one, I would be really conservative to avoid malicio=
us child attachment on multi-party transactions downgrading the block inclu=
sion efficiency.<br><br></div>Antoine<br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 9 mars 2022 =C3=A0=C2=
=A010:37, Gloria Zhao via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-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 transac=
tion relay rate-limiting), user-elected descendant limit as a short term so=
lution 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. 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 att=
ack, if we&#39;re ultimately interested in preventing resource exhaustion, =
maybe we want to &quot;stop the bleeding&quot; when it happens and bound th=
e amount of resources used in general. There were two main ideas:<br><br>1.=
 Transaction relay rate limiting (i.e. the one you proposed above or some v=
ariation) with a feerate-based priority queue<br>2. Staggered broadcast of =
replacement transactions: within some time interval, maybe accept multiple =
replacements for the same prevout, but only relay the original transaction.=
<br><br>Looking to solicit feedback on these ideas and the concept in gener=
al. Is it a good idea (separate from RBF) to add rate-limiting in transacti=
on relay? And is it the right direction to think about RBF DoS protection t=
his 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 tra=
nsaction, i.e., an attacker can censor somebody=E2=80=99s transaction from =
ever being announced by a node if they send enough transactions to fill up =
the rate limit. Obviously this would be expensive since they&#39;re spendin=
g 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 transa=
ction for a few hours. This might be a non-issue in practice if the rate li=
mit is generous and traffic isn=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, users are essentially allowed to =E2=80=9Crecycl=
e=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 use=
rs=E2=80=99 transactions, 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 parameters right, but it seems=E2=80=A6 not great, in principle=
.<br></div><div><br></div><div>---------<br></div><div><br></div><div>It&#3=
9;s probably also a good idea to point out that there&#39;s been some discu=
ssion happening on the gist containing my original post on this thread (<a =
href=3D"https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff" ta=
rget=3D"_blank">https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783=
b9ff</a>).</div><div><br></div><div>Suhas and Matt [proposed][0] adding a p=
olicy rule allowing users to specify descendant limits on their transaction=
s. For example, some nth bit of nSequence with nVersion 3 means &quot;this =
transaction won&#39;t have more 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 attacker&#39;s package contains a very large and hig=
h-fee descendant.</div><div><br></div><div>We could add this policy and dep=
loy it with package RBF/package relay so that LN can use it by setting the =
user-elected descendant limit flag on commitment transactions. (Otherwise p=
ackage RBF is blocked until we find a more comprehensive solution to the pi=
nning attack).</div><div><br></div><div>It&#39;s simple to [implement][1] a=
s 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 t=
o the idea of &quot;we can&#39;t just use {individual, ancestor} feerate,&q=
uot; I&#39;m interested in soliciting feedback on adding a =E2=80=9Cmining =
score=E2=80=9D calculator. I&#39;ve implemented one [here][2] which takes t=
he transaction in question, grabs all of the connected mempool transactions=
 (including siblings, coparents, etc., as they wouldn=E2=80=99t be in the a=
ncestor nor descendant sets), and builds a =E2=80=9Cblock template=E2=80=9D=
 using our current mining algorithm. The mining score of a transaction is t=
he ancestor feerate at which it is included.<br></div><div><br></div><div>T=
his would be helpful for something like ancestor-aware funding and fee-bump=
ing in the wallet: [3], [4]. I think if we did the rate-limited priority qu=
eue 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 than the original transactions. This could be c=
omputationally expensive to do all the time; it could be good to cache it b=
ut that could make mempool bookkeeping more complicated. Also, if we end up=
 trying to switch to a candidate set-based algorithm for mining, we&#39;d o=
f course need a new calculator.<br></div><div><br></div><div>[0]: <a href=
=3D"https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permali=
nk_comment_id=3D4058140#gistcomment-4058140" target=3D"_blank">https://gist=
.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=3D=
4058140#gistcomment-4058140</a><br>[1]: <a href=3D"https://github.com/glozo=
w/bitcoin/tree/2022-02-user-desclimit" target=3D"_blank">https://github.com=
/glozow/bitcoin/tree/2022-02-user-desclimit</a></div><div>[2] <a href=3D"ht=
tps://github.com/glozow/bitcoin/tree/2022-02-mining-score" target=3D"_blank=
">https://github.com/glozow/bitcoin/tree/2022-02-mining-score</a><br>[3]: <=
a href=3D"https://github.com/bitcoin/bitcoin/issues/9645" target=3D"_blank"=
>https://github.com/bitcoin/bitcoin/issues/9645</a><br>[4]: <a href=3D"http=
s://github.com/bitcoin/bitcoin/issues/15553" target=3D"_blank">https://gith=
ub.com/bitcoin/bitcoin/issues/15553</a><br></div><br><div>Best,</div><div>G=
loria<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 Anthony Towns &lt;<a href=3D=
"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>&gt; wrot=
e:<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">On Mon, Feb 0=
7, 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>
_______________________________________________<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>
_______________________________________________<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>

--000000000000590e4405da6c1d69--