Re: [bitcoin-dev] Improving RBF Policy

[Billy Tetrud via bitcoin-dev]

@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 the
> 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 all
> 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’s transaction, i.e.,
> > an attacker can censor somebody’s 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'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’t 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-sensitive
> 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-chain
> HTLC deadline ("the deadline for received 

Re: [bitcoin-dev] Improving RBF Policy

[Antoine Riard via bitcoin-dev]

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 the
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 all
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’s transaction, i.e.,
> an attacker can censor somebody’s 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'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’t 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-sensitive
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-chain
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, the
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 out
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 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.

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 transaction
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 less
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 sounds
really similar to "flood" attack affecting LN previously researched on
[0]. What worries me more with this "exhaust" is that if we introduce
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, 

Re: [bitcoin-dev] Improving RBF Policy

[Billy Tetrud via bitcoin-dev]

Hi Gloria,

It seems you're responding to what I wrote on github. Happy to respond, but
perhaps we should keep it there so the conversation is kept linearly
together?

I'm curious what you think of my thoughts on what you brought up most
recently in this thread about rate limiting / staggered window dos
protection stuff.

Cheers,
BT


On Mon, Mar 14, 2022 at 5:29 AM Gloria Zhao  wrote:

> Hi Billy,
>
> > We should expect miners will be using a more complex, more optimal way
> of determining what blocks they're working on [...] we should instead run
> with the assumption that miners keep all potentially relevant transactions
> in their mempools, including potentially many conflicting transctions, in
> order to create the most profitable blocks. And therefore we shouldn't put
> the constraint on normal non-mining full nodes to do that same more-complex
> mempool behavior or add any complexity for the purpose of denying
> transaction replacements.
>
> > I think a lot of the complexity in these ideas is because of the attempt
> to match relay rules with miner
> inclusion rules.
>
> I think the assumption that miners are using a completely different
> implementation of mempool and block template building is false. IIUC, most
> miners use Bitcoin Core and perhaps configure their node differently (e.g.
> larger mempool and different minfeerates), but also use `getblocktemplate`
> which means the same ancestor package-based mining algorithm.
>
> Of course, I'm not a miner, so if anybody is a miner or has seen miners'
> setups, please correct me if I'm wrong.
>
> In either case, we would want our mining algorithm to result in block
> templates that are as close as possible to perfectly incentive compatibile.
>
> Fundamentally, I believe default mempool policy (which perhaps naturally
> creates a network-wide transaction relay policy) should be as close to the
> mining code as possible. Imagine node A only keeps 1 block's worth of
> transactions, and node B keeps a (default) 300MB mempool. The contents of
> node A's mempool should be as close as possible to a block template
> generated from node B's mempool. Otherwise, node A's mempool is not very
> useful - their fee estimation is flawed and compact block relay won't do
> them much good if they need to re-request a lot of block transactions.
> Next, imagine that node B is a miner. It would be very suboptimal if the
> mining code was ancestor package-based (i.e. supports CPFP), but the
> mempool policy only cared about individual feerate, and evicted low-fee
> parents despite their high-fee children. It's easy to see why this would be
> suboptimal.
> Attempting to match mempool policy with the mining algorithm is also
> arguably the point of package relay. Our mining code uses ancestor packages
> which is good, but we only submit transactions one at a time to the
> mempool, so a transaction's high-fee children can't be considered until
> they are all already in the mempool. Package relay allows us to start
> thinking about ancestor packages immediately when evaluating transactions
> for submission to the mempool.
>
> The attempt to match policy with miner inclusion rules is deliberate and
> necessary.
>
> > I want to echo James O'Beirne's opinion on this that this may be the
> wrong path to go down (a path of more complexity without much gain). He
> said: "Special consideration for "what should be in the next block" and/or
> the caching of block templates seems like an imposing dependency, dragging
> in a bunch of state and infrastructure to a question that should be solely
> limited to mempool feerate aggregates and the feerate of the particular txn
> package a wallet is concerned with."
>
> It seems that I under-explained the purpose of building/caching block
> templates in my original post, since both you and James have the same
> misunderstanding. Since RBF's introduction, we have improved to an ancestor
> package-based mining algorithm. This supports CPFP (incentive compatible)
> and it is now common to see more complex "families" of transactions as
> users fee-bump transactions (market is working, yay). On the other hand, we
> no longer have an accurate way of determining a transaction's "mining
> score," i.e., the feerate of this transaction's ancestor package when it is
> included in a block template using our current mining algorithm.
>
> This limitation is a big blocker in proposing new fee/feerate RBF rules.
> For example, if we say "the transaction needs a better feerate," this is
> obviously flawed, since the original transactions may have very
> high-feerate children, and the replacement transaction may have low feerate
> parents. So what we really want is "the transaction needs to be more
> incentive compatible to mine based on our mining algorithm," but we have no
> way of getting that information right now.
>
> In my original post, I [described 4 heuristics to get transaction's
> "mining score"][1] using the current data cached in the mempool (e.g. 

Re: [bitcoin-dev] Improving RBF Policy

[Gloria Zhao via bitcoin-dev]

Hi Billy,

> We should expect miners will be using a more complex, more optimal way of
determining what blocks they're working on [...] we should instead run with
the assumption that miners keep all potentially relevant transactions in
their mempools, including potentially many conflicting transctions, in
order to create the most profitable blocks. And therefore we shouldn't put
the constraint on normal non-mining full nodes to do that same more-complex
mempool behavior or add any complexity for the purpose of denying
transaction replacements.

> I think a lot of the complexity in these ideas is because of the attempt
to match relay rules with miner
inclusion rules.

I think the assumption that miners are using a completely different
implementation of mempool and block template building is false. IIUC, most
miners use Bitcoin Core and perhaps configure their node differently (e.g.
larger mempool and different minfeerates), but also use `getblocktemplate`
which means the same ancestor package-based mining algorithm.

Of course, I'm not a miner, so if anybody is a miner or has seen miners'
setups, please correct me if I'm wrong.

In either case, we would want our mining algorithm to result in block
templates that are as close as possible to perfectly incentive compatibile.

Fundamentally, I believe default mempool policy (which perhaps naturally
creates a network-wide transaction relay policy) should be as close to the
mining code as possible. Imagine node A only keeps 1 block's worth of
transactions, and node B keeps a (default) 300MB mempool. The contents of
node A's mempool should be as close as possible to a block template
generated from node B's mempool. Otherwise, node A's mempool is not very
useful - their fee estimation is flawed and compact block relay won't do
them much good if they need to re-request a lot of block transactions.
Next, imagine that node B is a miner. It would be very suboptimal if the
mining code was ancestor package-based (i.e. supports CPFP), but the
mempool policy only cared about individual feerate, and evicted low-fee
parents despite their high-fee children. It's easy to see why this would be
suboptimal.
Attempting to match mempool policy with the mining algorithm is also
arguably the point of package relay. Our mining code uses ancestor packages
which is good, but we only submit transactions one at a time to the
mempool, so a transaction's high-fee children can't be considered until
they are all already in the mempool. Package relay allows us to start
thinking about ancestor packages immediately when evaluating transactions
for submission to the mempool.

The attempt to match policy with miner inclusion rules is deliberate and
necessary.

> I want to echo James O'Beirne's opinion on this that this may be the
wrong path to go down (a path of more complexity without much gain). He
said: "Special consideration for "what should be in the next block" and/or
the caching of block templates seems like an imposing dependency, dragging
in a bunch of state and infrastructure to a question that should be solely
limited to mempool feerate aggregates and the feerate of the particular txn
package a wallet is concerned with."

It seems that I under-explained the purpose of building/caching block
templates in my original post, since both you and James have the same
misunderstanding. Since RBF's introduction, we have improved to an ancestor
package-based mining algorithm. This supports CPFP (incentive compatible)
and it is now common to see more complex "families" of transactions as
users fee-bump transactions (market is working, yay). On the other hand, we
no longer have an accurate way of determining a transaction's "mining
score," i.e., the feerate of this transaction's ancestor package when it is
included in a block template using our current mining algorithm.

This limitation is a big blocker in proposing new fee/feerate RBF rules.
For example, if we say "the transaction needs a better feerate," this is
obviously flawed, since the original transactions may have very
high-feerate children, and the replacement transaction may have low feerate
parents. So what we really want is "the transaction needs to be more
incentive compatible to mine based on our mining algorithm," but we have no
way of getting that information right now.

In my original post, I [described 4 heuristics to get transaction's "mining
score"][1] using the current data cached in the mempool (e.g. max ancestor
feerate of descendant set), as well as why they don't work. As such, the
best way to calculate a transaction's mining score AFAICT is to grab all of
the related transactions and build a mini "block template" with them. The
[implementation][2] I sent last week also cuts out some of the fluff, so
the pseudocode looks like this:

// Get ALL connected entries (ancestors, descendants, siblings, cousins,
coparents, etc.)
vector cluster = mempool.GetAllTransactionsRelatedTo(txid);
sort(cluster, ancestorfeerate);

// For 

Re: [bitcoin-dev] Improving RBF Policy

[Billy Tetrud via bitcoin-dev]

In reading through more of the discussion, it seems the idea I presented
above might basically be a reformulation of t-bast's rate-limiting idea
presented in this comment
.
Perhaps he could comment on whether that characterization is accurate.

On Fri, Mar 11, 2022 at 10:22 AM Billy Tetrud 
wrote:

> 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 

Re: [bitcoin-dev] Improving RBF Policy

[Billy Tetrud via bitcoin-dev]

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

detailing
my thought process on that. The summary is that as 

Re: [bitcoin-dev] Improving RBF Policy

[Gloria Zhao via bitcoin-dev]

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’s transaction, i.e.,
an attacker can censor somebody’s 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'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’t 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 “recycle” fees. In the scenario
where we prioritize relay based on feerate, users could potentially be
placed higher in the queue, ahead of other users’ transactions, multiple
times, without ever adding more fees to the transaction. Again, maybe this
isn’t a huge deal in practice if we set the parameters right, but it seems…
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 = 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 “mining score”
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’t be in the ancestor nor
descendant sets), and builds a “block template” 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 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_comment_id=4058140#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  wrote:

> On Mon, Feb 07, 2022 at 11:16:26AM +, 

Re: [bitcoin-dev] Improving RBF Policy

[lisa neigut via bitcoin-dev]

Changing the way that RBF works is an excellent idea. Bitcoin is overdue
for revisiting these rules. Thanks to @glowzo et al for kicking off the
discussion.

I've been thinking about RBF for a very long time[1], and it's been fun to
see other people's thoughts on the topics. Here's my current thinking about
this, and proposal for how we should update the rules.

### Changing the Rules? How to Change Them
Regarding how to change them, Bram and aj are right -- we should move to a
model where transaction relay candidates are evaluated on their net
increase in fees per byte paid, and remove the requirement that the gross
fee of the preceding transaction is met or exceeded.

Our current ruleset is over complicated because it attempts to solve two
problems at once: the miner's best interests (highest possible fee take)
and relay policy.

I believe this is a mistake and the mempool should change its goals.
Instead, the mempool relay design for RBFs should be built around 1)
increasing the the per-byte fees paid of a transaction and 2) providing a
simple policy for applications building on top of bitcoin, such that
knowledge of the mempool is not required for successfully issuing
relay-able RBF transactions.

(A simple "must increase the per-byte feerate" heuristic for RBF relay
candidates has the nice benefit of being easy to program to on the
application side, and only requires knowledge of the previous candidate
transaction, not the entire mempool or any previous tx's relative position
within it.)

Finally, when blockspace is competitive , this simple policy ensures that
the per-byte value of every subsequent relayed transaction increases the
per-byte value of pending bytes for the next block. This provides a measure
of DoS protection and ensures that every relayed byte is more valuable (to
the miner/network) than the last.

*The only time that RBF is critical for relay is during full block periods
-- if there's not enough transactions to fill a block, using RBF to ensure
that a transaction is mined in a timely manner is moot. As such, RBF rules
should not be concerned with low-block environments.

### Mempools and Relay
The mempool currently serves two masters: the profit motive of the miner
and the relay motive of a utxo holder. It is in the interest of a user to
send the miner a high per-byte tx, such that it might end up in the next
block. It is in the miner's best interest to include the highest per-byte
set of transactions in their block template.

There is some conflation here in the current RBF policies between what is
in the mempool and what is considered a candidate for the block template.
If a miner has already included a more profitable package of txs into their
block template than a more valuable per-byte tx that the network has
relayed to them, it should be the responsibility of the block template
constructor to reject the new proposed tx, not the nodes relaying the
transaction to said miner.

This is a policy that the miner can (and should) implement at the level of
the template construction, however.

Is it the responsibility of the mempool to provide the best "historical"
block opportunity for a miner (e.g. the highest paying block given all txs
it's ever seen)? I would say no, that the ability of a utxo owner to
re-state the spend condition of a pending transaction is more important,
from a use-case perspective, and that the mempool should concern itself
solely with relaying increasingly more profitable bytes to miners. Let the
miners concern themselves with deciding what the best policy for their own
block construction is, and the mempool with relaying the highest value
bytes for the network. Net-net, this will benefit everyone as it becomes
easier for users to re-submit txs with increasingly greater feerates,
creating more active competition for available blockspace as more
applications are able to include it as a feature (and it works, reliable,
as a relay mechanism).

### Packages and RBF
Packages make the increasing per-byte rule less of a guarantee that
increasing the per-byte value of a single transaction will net a given
miner more fees than including the entire package.

Let's decompose this a bit. It's helpful to think of tx packages as
'composable txs'. Basically when you consider a 'package' it is actually a
large tx with sub-components, the individual txs. As a 'composed tx', you
can calculate the per-byte feerate of the entire set. This is the number
that you, as someone issuing an RBF, would need to beat in order to move
your tx up in the pending block queue.

RBF, however, is a transaction level policy: it allows you to replace any
*one* component of a package, or tree, with the side effect of possibly
invalidating other candidate txs. If the 'composed tx' (aka package) had a
net per-byte value that was higher than the new replacement transaction
because of a leaf tx that had an outsized per-byte feerate, then it would
be more profitable for the miner to have mined the entire 

Re: [bitcoin-dev] Improving RBF Policy

[Anthony Towns via bitcoin-dev]

On Mon, Feb 07, 2022 at 11:16:26AM +, Gloria Zhao wrote:
> @aj:
> > I wonder sometimes if it could be sufficient to just have a relay rate
> > limit and prioritise by ancestor feerate though. Maybe something like:
> > - instead of adding txs to each peers setInventoryTxToSend immediately,
> >   set a mempool flag "relayed=false"
> > - on a time delay, add the top N (by fee rate) "relayed=false" txs to
> >   each peer's setInventoryTxToSend and mark them as "relayed=true";
> >   calculate how much kB those txs were, and do this again after
> >   SIZE/RATELIMIT seconds

> > - don't include "relayed=false" txs when building blocks?

The "?" was me not being sure that point is a good suggestion...

Miners might reasonably decide to have no rate limit, and always relay,
and never exclude txs -- but the question then becomes is whether they
hear about the tx at all, so rate limiting behaviour could still be a
potential problem for whoever made the tx.

> Wow cool! I think outbound tx relay size-based rate-limiting and
> prioritizing tx relay by feerate are great ideas for preventing spammers
> from wasting bandwidth network-wide. I agree, this would slow the low
> feerate spam down, preventing a huge network-wide bandwidth spike. And it
> would allow high feerate transactions to propagate as they should,
> regardless of how busy traffic is. Combined with inbound tx request
> rate-limiting, might this be sufficient to prevent DoS regardless of the
> fee-based replacement policies?

I think you only want to do outbound rate limits, ie, how often you send
INV, GETDATA and TX messages? Once you receive any of those, I think
you have to immediately process / ignore it, you can't really sensibly
defer it (beyond the existing queues we have that just build up while
we're busy processing other things first)?

> One point that I'm not 100% clear on: is it ok to prioritize the
> transactions by ancestor feerate in this scheme? As I described in the
> original post, this can be quite different from the actual feerate we would
> consider a transaction in a block for. The transaction could have a high
> feerate sibling bumping its ancestor.
> For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB). If
> we just received C, it would be incorrect to give it a priority equal to
> its ancestor feerate (3sat/vB) because if we constructed a block template
> now, B would bump A, and C's new ancestor feerate is 5sat/vB.
> Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
> also exclude C when building blocks, we're missing out on good fees.

I think you're right that this would be ugly. It's something of a
special case:

 a) you really care about C getting into the next block; but
 b) you're trusting B not being replaced by a higher fee tx that
doesn't have A as a parent; and
 c) there's a lot of txs bidding the floor of the next block up to a
level in-between the ancestor fee rate of 3sat/vB and the tx fee
rate of 5sat/vB

Without (a), maybe you don't care about it getting to a miner quickly.
If your trust in (b) was misplaced, then your tx's effective fee rate
will drop and (because of (c)), you'll lose anyway. And if the spam ends
up outside of (c)'s range, either the rate limiting won't take effect
(spam's too cheap) and you'll be fine, or you'll miss out on the block
anyway (spam's paying more than your tx rate) and you never had any hope
of making it in.

Note that we already rate limit via INVENTORY_BROADCAST_MAX /
*_INVENTORY_BROADCAST_INTERVAL; which gets to something like 10,500 txs
per 10 minutes for outbound connections. This would be a weight based
rate limit instead-of/in-addition-to that, I guess.

As far as a non-ugly approach goes, I think you'd have to be smarter about
tracking the "effective fee rate" than the ancestor fee rate manages;
maybe that's something that could fall out of Murch and Clara's candidate
set blockbuilding ideas [0] ?

Perhaps that same work would also make it possible to come up with
a better answer to "do I care that this replacement would invalidate
these descendents?"

[0] https://github.com/Xekyo/blockbuilding

> > - keep high-feerate evicted txs around for a while in case they get
> >   mined by someone else to improve compact block relay, a la the
> >   orphan pool?
> Replaced transactions are already added to vExtraTxnForCompact :D

I guess I was thinking that it's just a 100 tx LRU cache, which might
not be good enough?

Maybe it would be more on point to have a rate limit apply only to
replacement transactions?

> For wallets, AJ's "All you need is for there to be *a* path that follows
> the new relay rules and gets from your node/wallet to perhaps 10% of
> hashpower" makes sense to me (which would be the former).

Perhaps a corollarly of that is that it's *better* to have the mempool
acceptance rule only consider economic incentives, and have the spam
prevention only be about "shall I tell my peers about this?"

If you don't have 

Re: [bitcoin-dev] Improving RBF Policy

[Gloria Zhao via bitcoin-dev]

Hi everyone,

Thanks for giving your attention to the post! I haven't had time to write
responses to everything, but sending my thoughts about what has been most
noteworthy to me:

@jeremy:
> A final point is that a verifiable delay function could be used over,
e.g., each of the N COutpoints individually to rate-limit transaction
replacement. The VDF period can be made shorter / eliminated depending on
the feerate increase.

Thanks for the suggestion! In general, I don't think rate limiting by
outpoint/prevout is a safe option, as it is particularly dangerous for L2
applications with shared prevouts. For example, the prevout that LN channel
counterparties conflict on is the output from their shared funding tx. Any
kind of limit on spending this prevout can be monopolized by a spammy
attacker. For example, if you only allow 1 per minute, the attacker will
just race to take up that slot every minute to prevent the honest party's
transaction from being accepted.
This is similar to the pinning attack based on monopolizing the
transaction's descendant limit, except we can't carve out an exemption
because we wouldn't know whose replacement we're looking at.

@tbast:
> The way I understand it, limiting the impact on descendant transactions
is only important for DoS protection, not for incentive compatibility.

> I believe it's completely ok to require increasing both the fees and
feerate if we don't take descendants into account, because you control your
ancestor set - whereas the descendant set may be completely out of your
control.

Ignoring descendants of direct conflicts would certainly make our lives
much easier! Unfortunately, I don't think we can do this since they can be
fee bumps, i.e., in AJ's example. Considering descendants is important for
both incentive compatibility and DoS.
If the replacement transaction has a higher feerate than its direct
conflict, but the direct conflict also has high feerate descendants, we
might end up with lower fees and/or feerates by accepting the replacement.

@aj:
> I wonder sometimes if it could be sufficient to just have a relay rate
limit and prioritise by ancestor feerate though. Maybe something like:
>
> - instead of adding txs to each peers setInventoryTxToSend immediately,
>   set a mempool flag "relayed=false"
>
> - on a time delay, add the top N (by fee rate) "relayed=false" txs to
>   each peer's setInventoryTxToSend and mark them as "relayed=true";
>   calculate how much kB those txs were, and do this again after
>   SIZE/RATELIMIT seconds
>
> - don't include "relayed=false" txs when building blocks?

Wow cool! I think outbound tx relay size-based rate-limiting and
prioritizing tx relay by feerate are great ideas for preventing spammers
from wasting bandwidth network-wide. I agree, this would slow the low
feerate spam down, preventing a huge network-wide bandwidth spike. And it
would allow high feerate transactions to propagate as they should,
regardless of how busy traffic is. Combined with inbound tx request
rate-limiting, might this be sufficient to prevent DoS regardless of the
fee-based replacement policies?

One point that I'm not 100% clear on: is it ok to prioritize the
transactions by ancestor feerate in this scheme? As I described in the
original post, this can be quite different from the actual feerate we would
consider a transaction in a block for. The transaction could have a high
feerate sibling bumping its ancestor.
For example, A (1sat/vB) has 2 children: B (49sat/vB) and C (5sat/vB). If
we just received C, it would be incorrect to give it a priority equal to
its ancestor feerate (3sat/vB) because if we constructed a block template
now, B would bump A, and C's new ancestor feerate is 5sat/vB.
Then, if we imagine that top N is >5sat/vB, we're not relaying C. If we
also exclude C when building blocks, we're missing out on good fees.

> - 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

@ariard
> Deployment of Taproot opens interesting possibilities in the
vaults/payment channels design space, where the tapscripts can commit to
different set of timelocks/quorum of keys. Even if the pre-signed states
stay symmetric, whoever is the publisher, the feerate cost to spend can
fluctuate.

Indeed, perhaps with taproot we may legitimately have
same-txid-different-witness transactions as a normal thing rather than rare
edge case. But as with everything enabled by taproot, I wouldn't count our
tapscript eggs until a concrete use case hatches and/or an application
actually implements it.

> How this new replacement rule would behave if you have a parent in the
"replace-by-feerate" half but the child is in the "replace-by-fee" one ?

Thanks for considering my suggestion! This particular scenario is not
possible, since a child cannot be considered for the next block without its
parent. But if 

Re: [bitcoin-dev] Improving RBF Policy

[Bastien TEINTURIER via bitcoin-dev]

Good morning,

> The tricky question is what happens when X arrives on its own and it
> might be that no one ever sends a replacement for B,C,D)

It feels ok to me, but this is definitely arguable.

It covers the fact that B,C,D could have been fake transactions whose
sole purpose was to do a pinning attack: in that case the attacker would
have found a way to ensure these transactions don't confirm anyway (or
pay minimal/negligible fees).

If these transactions were legitimate, I believe that their owners would
remake them at some point (because these transactions reflect a business
relationship that needed to happen, so it should very likely still
happen). It's probably hard to verify because the new corresponding
transactions may have nothing in common with the first, but I think the
simplifications it offers for wallets is worth it (which is just my
opinion and needs more scrutiny/feedback).

> But if your backlog's feerate does drop off, *and* that matters, then
> I don't think you can ignore the impact of the descendent transactions
> that you might not get a replacement for.

That is because you're only taking into account the current backlog, and
not taking into account the fact that new items will be added to it soon
to replace the evicted descendants. But I agree that this is a bet: we
can't predict the future and guarantee these replacements will come.

It is really a trade-off, ignoring descendents provides a much simpler
contract that doesn't vary from one mempool to another, but when your
backlog isn't full enough, you may lose some future profits if
transactions don't come in later.

> I think "Y% higher" rather than just "higher" is only useful for
> rate-limiting, not incentive compatibility. (Though maybe it helps
> stabilise a greedy algorithm in some cases?)

That's true. I claimed these policies only address incentives, but using
a percentage increase addresses rate-limiting a bit as well (I couldn't
resist trying to do at least something for it!). I find it a very easy
mechanism to implement, while choosing an absolute value is hard (it's
always easier to think in relatives than absolutes).

> This is why I think it is important to understand the rationales for
introducing the rules in the first place

I completely agree. As you mentioned, we are still in brainstorming
phase, once (if?) we start to converge on what could be better policies,
we do need to clearly explain each policy's expected goal. That will let
future Bastien writing code in 2030 clearly highlight why the 2022 rules
don't make sense anymore!

Cheers,
Bastien

Le sam. 5 févr. 2022 à 14:22, Michael Folkson 
a écrit :

> Thanks for this Bastien (and Gloria for initially posting about this).
>
> I sympathetically skimmed the eclair PR (
> https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable
> transactions fee bumping.
>
> There will continue to be a (hopefully) friendly tug of war on this
> probably for the rest of Bitcoin's existence. I am sure people like Luke,
> Prayank etc will (rightfully) continue to raise that Lightning and other
> second layer protocols shouldn't demand that policy rules be changed if
> there is a reason (e.g. DoS vector) for those rules on the base network.
> But if there are rules that have no upside, introduce unnecessary
> complexity for no reason and make Lightning implementers like Bastien's
> life miserable attempting to deal with them I really hope we can make
> progress on removing or simplifying them.
>
> This is why I think it is important to understand the rationales for
> introducing the rules in the first place (and why it is safe to remove them
> if indeed it is) and being as rigorous as possible on the rationales for
> introducing additional rules. It sounds like from Gloria's initial post we
> are still at a brainstorming phase (which is fine) but knowing what we know
> today I really hope we can learn from the mistakes of the original BIP 125,
> namely the Core implementation not matching the BIP and the sparse
> rationales for the rules. As Bastien says this is not criticizing the
> original BIP 125 authors, 7 years is a long time especially in Bitcoin
> world and they probably weren't thinking about Bastien sitting down to
> write an eclair PR in late 2021 (and reviewers of that PR) when they wrote
> the BIP in 2015.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> --- Original Message ---
> On Monday, January 31st, 2022 at 3:57 PM, Bastien TEINTURIER via
> bitcoin-dev  wrote:
>
> Hi Gloria,
>
> Many thanks for raising awareness on these issues and constantly pushing
> towards finding a better model. This work will highly improve the
> security of any multi-party contract trying to build on top of bitcoin
> (because most multi-party contracts will need to have timeout conditions
> and participants will need to make some transactions confirm before 

Re: [bitcoin-dev] Improving RBF Policy

[Michael Folkson via bitcoin-dev]

Thanks for this Bastien (and Gloria for initially posting about this).

I sympathetically skimmed the eclair PR 
(https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable 
transactions fee bumping.

There will continue to be a (hopefully) friendly tug of war on this probably 
for the rest of Bitcoin's existence. I am sure people like Luke, Prayank etc 
will (rightfully) continue to raise that Lightning and other second layer 
protocols shouldn't demand that policy rules be changed if there is a reason 
(e.g. DoS vector) for those rules on the base network. But if there are rules 
that have no upside, introduce unnecessary complexity for no reason and make 
Lightning implementers like Bastien's life miserable attempting to deal with 
them I really hope we can make progress on removing or simplifying them.

This is why I think it is important to understand the rationales for 
introducing the rules in the first place (and why it is safe to remove them if 
indeed it is) and being as rigorous as possible on the rationales for 
introducing additional rules. It sounds like from Gloria's initial post we are 
still at a brainstorming phase (which is fine) but knowing what we know today I 
really hope we can learn from the mistakes of the original BIP 125, namely the 
Core implementation not matching the BIP and the sparse rationales for the 
rules. As Bastien says this is not criticizing the original BIP 125 authors, 7 
years is a long time especially in Bitcoin world and they probably weren't 
thinking about Bastien sitting down to write an eclair PR in late 2021 (and 
reviewers of that PR) when they wrote the BIP in 2015.

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Monday, January 31st, 2022 at 3:57 PM, Bastien TEINTURIER via bitcoin-dev 
 wrote:

> Hi Gloria,
>
> Many thanks for raising awareness on these issues and constantly pushing
> towards finding a better model. This work will highly improve the
> security of any multi-party contract trying to build on top of bitcoin
> (because most multi-party contracts will need to have timeout conditions
> and participants will need to make some transactions confirm before a
> timeout happens - otherwise they may lose funds).
>
> For starters, let me quickly explain why the current rules are hard to
> work with in the context of lightning (but I believe most L2 protocols
> will have the same issues). Feel free to skip this part if you are
> already convinced.
>
> ## Motivation
>
> The biggest pain point is BIP 125 rule 2.
> If I need to increase the fees of a time-sensitive transaction because
> the feerate has been rising since I broadcast it, I may need to also pay
> high fees just to produce a confirmed utxo that I can use. I'm actually
> paying a high fee twice instead of once (and needlessly using on-chain
> space, our scarcest asset, because we could have avoided that additional
> transaction!).
>
> It also has some annoying "non-determinism".
> Imagine that my transaction has been evicted from my mempool because its
> feerate was too low. I could think "Great, that means I don't have to
> apply BIP 125 restrictions, I can just fund this transaction as if it
> were a new one!". But actually I do, because my transaction could still
> be in miner's mempools and I have no way of knowing it...this means that
> whenever I have broadcast a transaction, I must assume that I will
> always need to abide by whatever replacement rules the network applies.
>
> Fortunately, as far as I understand it, this rule only exists because of
> a previous implementation detail of bitcoin core, so there's simply no
> good reason to keep it.
>
> The second biggest pain point is rule 3. It prevents me from efficiently
> using my capital while it's unconfirmed. Whenever I'm using a big utxo
> to fund a transaction, I will get a big change output, and it would
> really be a waste to be unable to use that change output to fund other
> transactions. In order to be capital-efficient, I will end up creating
> descendant trees for my time-sensitive transactions. But as Gloria
> explained, replacing all my children will cost me an absurdly large
> amount of fees. So what I'm actually planning to do instead is to RBF
> one of the descendants high enough to get the whole tree confirmed.
> But if those descendants' timeouts were far in the future, that's a
> waste, I paid a lot more fees for them than I should have. I'd like to
> just replace my transaction and republish the invalidated children
> independently.
>
> Rule 4 doesn't hurt as much as the two previous ones, I don't have too
> much to say about it.
>
> To be fair to the BIP 125 authors, all of these scenarios were very hard
> to forecast at the time this BIP was created. We needed years to build
> on those rules to get a better understanding of their limitations and if
> 

Re: [bitcoin-dev] Improving RBF Policy

[Anthony Towns via bitcoin-dev]

On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev 
wrote:
> But do you agree that descendants only matter for DoS resistance then,
> not for miner incentives?

There's an edge case where you're replacing tx A with tx X, and X's fee
rate is higher than A's, but you'd be obsoleting descendent txs (B, C,
D...) and thus replacing them with unrelated txs (L, M, N...), and the
total feerate/fees of A+B+C+D... is nevertheless higher than X+L+M+N...

But I think that's probably unusual (transactions D and L are adjacent
in the mempool, that's why L is chosen for the block; but somehow
there's a big drop off in value somewhere between B/C/D and L/M/N),
and at least today, I don't think miners consider it essential to eke
out every possible sat in fee income.

(If, as per your example, you're actually replacing {A,B,C,D} with
{X,Y,Z,W} where X pays higher fees than A and the package in total pays
either the same or higher fees, that's certainly incentive compatible.
The tricky question is what happens when X arrives on its own and it
might be that no one ever sends a replacement for B,C,D)

> The two policies I proposed address miner incentives. I think they're
> insufficient to address DoS issues. But adding a 3rd policy to address
> DoS issues may be a good solution?

>>> 1. The transaction's ancestor absolute fees must be X% higher than the
>>> previous transaction's ancestor fees
>>> 2. The transaction's ancestor feerate must be Y% higher than the
>>> previous transaction's ancestor feerate

Absolute fees only matter if your backlog's feerate drops off. If you've
got 100MB of txs offering 5sat/vb, then exchanging 50kB at 5sat/vb for
1kB at 6sat/vb is still a win: your block gains 1000 sats in fees even
though your mempool loses 245,000 sats in fees.

But if your backlog's feerate does drop off, *and* that matters, then
I don't think you can ignore the impact of the descendent transactions
that you might not get a replacement for.

I think "Y% higher" rather than just "higher" is only useful for
rate-limiting, not incentive compatibility. (Though maybe it helps
stabilise a greedy algorithm in some cases?)

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF policy

[Eric Voskuil via bitcoin-dev]

> On Feb 1, 2022, at 00:32, Bram Cohen  wrote:
> 
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil  wrote:
>> 
>> 
 On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev 
  wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and 
>>> disallowing it is the feature, and that feature is mostly there to appease 
>>> some people's delusions that zeroconf is a thing? It seems a bit overdue to 
>>> disrespect the RBF flag in the direction of always assuming it's on.
>> What flag?
> 
> The opt-in RBF flag in transactions.

Was being facetious. The “disrespect” referred to above assumes respect that 
some implementations have never given.

>>> There are two different common regimes which result in different 
>>> incentivized behavior. One of them is that there's more than a block's 
>>> backlog in the mempool in which case between two conflicting transactions 
>>> the one with the higher fee rate should win. In the other case where there 
>>> isn't a whole block's worth of transactions the one with higher total value 
>>> should win.
>> These are not distinct scenarios. The rational choice is the highest fee 
>> block-valid subgraph of the set of unconfirmed transactions, in both cases 
>> (within the limits of what is computationally feasible of course).
> 
> It's weird because which of two or more conflicting transactions should win 
> can oscillate back and forth depending on other stuff going on in the mempool.

The assumption of RAM storage is an error and unrelated to network protocol. 
There is nothing “going on” in a set of unconfirmed valid transactions. They 
are logically unchanging.

> There's already a bit of that with child pays but this is stranger and has 
> more oddball edge cases about which transactions to route.

There’s really no such thing. The p2p network is necessarily permissionless. A 
person can route whatever he wants. Presumably people will not generally waste 
their own bandwidth by routing what they believe to be unconfirmable. And 
whatever they would retain themselves is their presumption of confirmable.

This decision of what to retain one’s self is just a graph traversal to 
determine the most valuable subset - an optimizing CSP (though generally 
suboptimal due to the time constraint).

Short of DoS, the most profitable model is to retain *all* valid transactions. 
[Note that a spend conflict is not an invalidity. Two valid transactions can be 
confirmed in sibling branch blocks - both valid in some context.]

So the only consideration is low cost storage fill. The fee is a proof of 
spend, which like proof of work (for headers/blocks), is the basis of DoS 
protection (for unconfirmed transactions). The issue with two conflicting 
subgraphs is that one or the other is ultimately unspendable. As such the fee 
on each is non-cumulative and therefore only one (the highest) is providing DoS 
protection. Any subsequent conflicting subgraph must pay not only for itself, 
but for all preceding conflicting subgraphs.

This pays for the storage, which is a trade accepted by the owner of the node 
in order to have a preview of confirmable transactions. This supports both 
mining generation of candidate blocks and rapid validation/confirmation of 
blocks.

It’s a rather straightforward system when considered in terms of how it 
actually works (ie from a consensus standpoint). The only p2p issue is the need 
to package transactions for consideration as a set, as otherwise parents may be 
discarded before children can pay for them. Any set up to a full block is 
entirely reasonable for consideration.

e___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF Policy

[Bastien TEINTURIER via bitcoin-dev]

Hi AJ, Prayank,

> I think that's backwards: we're trying to discourage people from wasting
> the network's bandwidth, which they would do by publishing transactions
> that will never get confirmed -- if they were to eventually get confirmed
> it wouldn't be a waste of bandwith, after all. But if the original
> descendent txs were that sort of spam, then they may well not be
> submitted again if the ancestor tx reaches a fee rate that's actually
> likely to confirm.

But do you agree that descendants only matter for DoS resistance then,
not for miner incentives?

I'm asking this because I think a new set of policies should separate
policies that address the miner incentives from policies that address
the DoS issues.

The two policies I proposed address miner incentives. I think they're
insufficient to address DoS issues. But adding a 3rd policy to address
DoS issues may be a good solution?

I think that rate-limiting p2p as you suggest (and Gloria also mentioned
it) is likely a better way of fixing the DoS concerns than a descendant
rule like BIP 125 rule 5 (which as I mentioned earlier, is problematic
because the descendent set varies from one mempool to another).

I would like to add a small update to my policy suggestions. The X and Y
percentage increase should be met for both the ancestor scores AND the
transaction in isolation. Otherwise I could replace txA with txA' that
uses a new ancestor txB that has a high fee and high feerate, while txA'
has a low fee and low feerate. It's then possible for txB to confirm
without txA', and what would remain then in the mempool would be worse
than before the replacement.

> 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, which seems
> like something wallet providers could construct relatively quickly?

That's true, maybe we can be more optimistic about the timeline for
using an updated set of policies ;)

> Do you think such multi party contracts are vulnerable by design
> considering they rely on policy that cannot be enforced?

It's a good question. Even though these policies cannot be enforced, if
they are rational to apply by nodes, I think it's ok to rely on them.
Others may disagree with that, but I guess it's worth a separate thread.

> Not sure I understand this part because if a transaction is on-chain
> it can't be replaced.

Sorry, that was a bit unclear.

Suppose I have txA that I want to RBF, but I only have unconfirmed utxos
and I can't simply lower its existing outputs to reach my desired
feerate.

I must make one of my unconfirmed utxos confirm asap just to be able to
use it to RBF txA. That means I'll need to pay fees a first time just to
convert one of my unconfirmed utxos to a confirmed one. Then I'll pay
the fees to bump txA. I had to overpay fees compared to just using my
unconfirmed utxo in the first place (and manage more complexity to track
the confirmation of my unconfirmed utxo).

Thanks for your feedback!
Bastien

Le mar. 1 févr. 2022 à 03:47, Prayank  a écrit :

> Hi Bastein,
>
> > This work will highly improve the security of any multi-party contract
> trying to build on top of bitcoin
>
> Do you think such multi party contracts are vulnerable by design
> considering they rely on policy that cannot be enforced?
>
> > For starters, let me quickly explain why the current rules are hard to
> work with in the context of lightning
>
> Using the term 'rules' can be confusing sometimes because it's just a
> policy and different from consensus rules. I wish we could change this in
> the BIP with something else.
>
> > I'm actually paying a high fee twice instead of once (and needlessly
> using on-chain space, our scarcest asset, because we could have avoided
> that additional transaction
>
> Not sure I understand this part because if a transaction is on-chain it
> can't be replaced.
>
> > The second biggest pain point is rule 3. It prevents me from efficiently
> using my capital while it's unconfirmed
>
> > I'm curious to hear other people's thoughts on that. If it makes sense,
> I would propose the following very simple rules
>
> Looks interesting however not sure about X and Y.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF policy

[Bram Cohen via bitcoin-dev]

On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil  wrote:

>
>
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly there to appease
> some people's delusions that zeroconf is a thing? It seems a bit overdue to
> disrespect the RBF flag in the direction of always assuming it's on.
>
> What flag?
>

The opt-in RBF flag in transactions.


> There are two different common regimes which result in different
> incentivized behavior. One of them is that there's more than a block's
> backlog in the mempool in which case between two conflicting transactions
> the one with the higher fee rate should win. In the other case where there
> isn't a whole block's worth of transactions the one with higher total value
> should win.
>
> These are not distinct scenarios. The rational choice is the highest fee
> block-valid subgraph of the set of unconfirmed transactions, in both cases
> (within the limits of what is computationally feasible of course).
>

It's weird because which of two or more conflicting transactions should win
can oscillate back and forth depending on other stuff going on in the
mempool. There's already a bit of that with child pays but this is stranger
and has more oddball edge cases about which transactions to route.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF Policy

[Prayank via bitcoin-dev]

Hi Bastein,

> This work will highly improve the security of any multi-party contract trying 
> to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considering 
they rely on policy that cannot be enforced?

> For starters, let me quickly explain why the current rules are hard to work 
> with in the context of lightning
Using the term 'rules' can be confusing sometimes because it's just a policy 
and different from consensus rules. I wish we could change this in the BIP with 
something else.

> I'm actually paying a high fee twice instead of once (and needlessly using 
> on-chain space, our scarcest asset, because we could have avoided that 
> additional transaction
Not sure I understand this part because if a transaction is on-chain it can't 
be replaced. 

> The second biggest pain point is rule 3. It prevents me from efficiently 
> using my capital while it's unconfirmed
> I'm curious to hear other people's thoughts on that. If it makes sense, I 
> would propose the following very simple rules
Looks interesting however not sure about X and Y.

-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF policy

[Antoine Riard via bitcoin-dev]

> Is it still verboten to acknowledge that RBF is normal behavior and
disallowing it is the feature, and that feature is mostly there to appease
some people's delusions that zeroconf is a thing? It seems a bit overdue to
disrespect the RBF flag in the direction of always assuming it's on.

If you're thinking about the opt-in flag, not the RBF rules, please see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
The latest state of the discussion is here :
https://gnusha.org/bitcoin-core-dev/2021-10-21.log
A gradual, multi-year deprecation sounds to be preferred to ease adaptation
of the affected Bitcoin applications.

Ultimately, I think it might not be the last time we have to change
high-impact tx-relay/mempool rules and a more formalized Core policy
deprecation process would be good.



Le lun. 31 janv. 2022 à 18:15, Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Gloria Zhao wrote:
>
>>
>> This post discusses limitations of current Bitcoin Core RBF policy and
>> attempts to start a conversation about how we can improve it,
>> summarizing some ideas that have been discussed. Please reply if you
>> have any new input on issues to be solved and ideas for improvement!
>>
>
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly there to appease
> some people's delusions that zeroconf is a thing? It seems a bit overdue to
> disrespect the RBF flag in the direction of always assuming it's on.
>
>
>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>   accept replacement transactions which would decrease fee profits
>>   of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
>>
>
> There are two different common regimes which result in different
> incentivized behavior. One of them is that there's more than a block's
> backlog in the mempool in which case between two conflicting transactions
> the one with the higher fee rate should win. In the other case where there
> isn't a whole block's worth of transactions the one with higher total value
> should win. It would be nice to have consolidated logic which handles both,
> it seems the issue has to do with the slope of the supply/demand curve
> which in the first case is gentle enough to keep the one transaction from
> hitting the rate but in the second one is basically infinite.
> ___
> 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

Re: [bitcoin-dev] Improving RBF policy

[Eric Voskuil via bitcoin-dev]

> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev 
>  wrote:


…

> Is it still verboten to acknowledge that RBF is normal behavior and 
> disallowing it is the feature, and that feature is mostly there to appease 
> some people's delusions that zeroconf is a thing? It seems a bit overdue to 
> disrespect the RBF flag in the direction of always assuming it's on.

What flag?

>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>   accept replacement transactions which would decrease fee profits
>>   of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
> 
> There are two different common regimes which result in different incentivized 
> behavior. One of them is that there's more than a block's backlog in the 
> mempool in which case between two conflicting transactions the one with the 
> higher fee rate should win. In the other case where there isn't a whole 
> block's worth of transactions the one with higher total value should win.

These are not distinct scenarios. The rational choice is the highest fee 
block-valid subgraph of the set of unconfirmed transactions, in both cases 
(within the limits of what is computationally feasible of course).

When collecting pooled txs the only issue is DoS protection, which is simply a 
question of what any given miner is willing to pay, in terms of disk space, to 
archive conflicts for the opportunity to optimize block reward.

> It would be nice to have consolidated logic which handles both, it seems the 
> issue has to do with the slope of the supply/demand curve which in the first 
> case is gentle enough to keep the one transaction from hitting the rate but 
> in the second one is basically infinite.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF Policy

[Antoine Riard via bitcoin-dev]

Hi Gloria,

Thanks for this RBF sum up. Few thoughts and more context comments if it
can help other readers.

> For starters, the absolute fee pinning attack is especially
> problematic if we apply the same rules (i.e. Rule #3 and #4) in
> Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
> LN channel. The mempool is rather full, so their pre-negotiated
> commitment transactions' feerates would not be considered high
> priority by miners.  Bob broadcasts his commitment transaction and
> attaches a very large child (100KvB with 100,000sat in fees) to his
> anchor output. Alice broadcasts her commitment transaction with a
> fee-bumping child (200vB with 50,000sat fees which is a generous
> 250sat/vB), but this does not meet the absolute fee requirement. She
> would need to add another 50,000sat to replace Bob's commitment
> transaction.

Solving LN pinning attacks, what we're aiming for is enabling a fair
feerate bid between the  counterparties, thus either forcing the adversary
to overbid or to disengage from the confirmation competition. If the
replace-by-feerate rule is adopted, there shouldn't be an incentive for Bob
to
pick up the first option. Though if he does, that's a winning outcome for
Alice, as one of the commitment transactions confirms and her
time-sensitive second-stage HTLC can be subsequently confirmed.

> It's unclear to me if
> we have a very strong reason to change this, but noting it as a
> limitation of our current replacement policy. See [#24007][12].

Deployment of Taproot opens interesting possibilities in the vaults/payment
channels design space, where the tapscripts can commit to different set of
timelocks/quorum of keys. Even if the pre-signed states stay symmetric,
whoever is the publisher, the feerate cost to spend can fluctuate.

> While this isn't completely broken, and the user interface is
> secondary to the safety of the mempool policy

I think with L2s transaction broadcast backend, the stability and clarity
of the RBF user interface is primary. What we could be worried about is a
too-much complex interface easing the way for an attacker to trigger your
L2 node to issue policy-invalid chain of transactions. Especially, when we
consider that an attacker might have leverage on chain of transactions
composition ("force broadcast of commitment A then commitment B, knowing
they will share a CPFP") or even transactions size ("overload commitment A
with HTLCs").

> * If the original transaction is in the top {0.75MvB, 1MvB} of the
>   mempool, apply the current rules (absolute fees must increase and
> pay for the replacement transaction's new bandwidth). Otherwise, use a
> feerate-only rule.

How this new replacement rule would behave if you have a parent in the
"replace-by-feerate" half but the child is in the "replace-by-fee" one ?

If we allow the replacement of the parent based on the feerate, we might
decrease the top block absolute fees.

If we block the replacement of the parent based on the feerate because the
replacement absolute fees aren't above the replaced package, we still
preclude a pinning vector. The child might be low-feerate junk and even
attached to a low ancestor-score branch.

If I'm correct on this limitation, maybe we could turn off the
"replace-by-fee" behavior as soon as the mempool is fulfilled with a few
blocks ?

> * Rate-limit how many replacements we allow per prevout.

Depending on how it is implemented, though I would be concerned it
introduces a new pinning vector in the context of shared-utxo. If it's a
hardcoded constant, it could be exhausted by an adversary starting at the
lowest acceptable feerate then slowly increasing while still not reaching
the top of the mempool. Same if it's time-based or block-based, no
guarantee the replacement slot is honestly used by your counterparty.

Further, an above-the-average replacement frequency might just be the
reflection of your confirmation strategy reacting to block schedule or
mempools historical data. As long as the feerate penalty is paid, I lean to
allow replacement.

(One solution could be to associate per-user "tag" to the LN transactions,
where each "tag" would have its own replacement slots, but privacy?)

> * Rate-limit transaction validation in general, per peer.

I think we could improve on the Core's new transaction requester logic.
Maybe we could bind the peer announced flow based on the feerate score
(modulo validation time) of the previously validated transactions from that
peer ? That said, while related to RBF, it sounds to me that enhancing
Core's rate-limiting transaction strategy is a whole discussion in itself
[0]. Especially ensuring it's tolerant to the specific requirements of LN &
consorts.

> What should they be? We can do some arithmetic to see what happens if
> you start with the biggest/lowest feerate transaction and do a bunch
> of replacements. Maybe we end up with values that are high enough to
> prevent abuse and make sense for applications/users 

Re: [bitcoin-dev] Improving RBF Policy

[Jeremy via bitcoin-dev]

Gloria,

This is a brilliant post! Great job systematizing many of the issues. Quite
a lot to chew on & I hope other readers of this list digest the post fully.

Three things come to mind as partial responses:

under:

- **DoS Protection**: Limit two types of DoS attacks on the node's
>   mempool: (1) the number of times a transaction can be replaced and
> (2) the volume of transactions that can be evicted during a
> replacement.


I'd more simply put it:

Limiting the amount of work that must be done to consider the replacement

We don't particularly care about goal (1) or goal (2), we care about how
much it costs to do (1) or (2). And there are scenarios where the (1) or
(2) might not be particularly high, but the total work still might be. I
can give you some examples to consider if needed. There are also scenarios
where (1) and (2) might be high, but the cost is low overall. Therefore it
makes sense to be a little more general with what the anti-DoS goal is.




An issue I'd like to toss into the mix is that of iterative / additive
batching. E.g., https://bitcoinops.org/en/cardcoins-rbf-batching/

This is where an business puts a txn in the mempool that pays to N users,
and as they see additional requests for payouts the update it to N+2,
N+2... N+M payouts. This iterative batching can be highly efficient because
the number of transactions per business per 10 minutes is 1 (with variable
number of outputs).

One issue with this approach today is that because of the feerate rule, if
you go from N to N+1 you need to pay 1 sat/byte over the whole txn. Applied
M times, and you have to increase fees quadratically for this approach.
Therefore the less efficient long-chain of batches model ends up being
'rational' with respect to mempool policy and irrational with respect to
"optimally packing blocks with transactions".

If the absolute fee rule is dropped, but feerate remains, one thing you
might see is businesses doing iterative batches with N+2M outputs whereby
they drop 2 outputs for every input they add, allowing the iterative batch
to always increase the fee-rate but possibly not triggering the quadratic
feerate issue since the transaction gets smaller over time.

Another possible solution to this would be to allow relaying "txdiffs"
which only require re-relay of signatures + new/modified outputs, and not
the entire tx.

I think this iterative batching is pretty desirable to support, and so I'd
like to see a RBF model which doesn't make it "unfairly" expensive.

(I'll spare everyone the details on how CTV batching also solves this, but
feel free to ask elsewhere.)

A counterargument to additive batching is that if you instead do non
iterative batches every minute, and you have 100 txns that arrive
uniformly, you'd end up with 10 batches of size 10 on average. The bulk of
the benefit under this model is in the non-batched to batched transition,
and the iterative part only saves on space/fees marginally after that point.



A final point is that a verifiable delay function could be used over, e.g.,
each of the N COutpoints individually to rate-limit transaction
replacement. The VDF period can be made shorter / eliminated depending on
the feerate increase. E.g., always consider a much higher feerate txn
whenever available, for things of equal feerate only consider 1 per minute.
A VDF is like proof-of-work that doesn't parallelize, in case you are
unfamiliar, so no matter how many computers you have it would take about
the same amount of time (you could parallelize across N outputs, of course,
but you're still bound minimally to the time it takes to replace 1 output,
doing all outputs individually just is the most flexible option).


Cheers,

Jeremy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Improving RBF Policy

[Gloria Zhao via bitcoin-dev]

Hi everyone,

This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!

Just in case I've screwed up the text wrapping again, another copy can be
found here: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff

## Background

Please feel free to skip this section if you are already familiar
with RBF.

Nodes may receive *conflicting* unconfirmed transactions, aka
"double spends" of the same inputs. Instead of always keeping the
first transaction, since v0.12, Bitcoin Core mempool policy has
included a set of Replace-by-Fee (RBF) criteria that allows the second
transaction to replace the first one and any descendants it may have.

Bitcoin Core RBF policy was previously documented as BIP 125.
The current RBF policy is documented [here][1]. In summary:

1. The directly conflicting transactions all signal replaceability
   explicitly.

2. The replacement transaction only includes an unconfirmed input if
   that input was included in one of the directly conflicting
transactions.

3. The replacement transaction pays an absolute fee of at least the
   sum paid by the original transactions.

4. The additional fees pays for the replacement transaction's
   bandwidth at or above the rate set by the node's *incremental relay
feerate*.

5. The sum of all directly conflicting transactions' descendant counts
   (number of transactions inclusive of itself and its descendants)
does not exceed 100.

We can split these rules into 3 categories/goals:

- **Allow Opting Out**: Some applications/businesses are unable to
  handle transactions that are replaceable (e.g. merchants that use
zero-confirmation transactions). We (try to) help these businesses by
honoring BIP125 signaling; we won't replace transactions that have not
opted in.

- **Incentive Compatibility**: Ensure that our RBF policy would not
  accept replacement transactions which would decrease fee profits
  of a miner. In general, if our mempool policy deviates from what is
economically rational, it's likely that the transactions in our
mempool will not match the ones in miners' mempools, making our
fee estimation, compact block relay, and other mempool-dependent
functions unreliable. Incentive-incompatible policy may also
encourage transaction submission through routes other than the p2p
network, harming censorship-resistance and privacy of Bitcoin payments.

- **DoS Protection**: Limit two types of DoS attacks on the node's
  mempool: (1) the number of times a transaction can be replaced and
(2) the volume of transactions that can be evicted during a
replacement.

Even more abstract: our goal is to make a replacement policy that
results in a useful interface for users and safe policy for
node operators.

## Motivation

There are a number of known problems with the current RBF policy.
Many of these shortcomings exist due to mempool limitations at the
time RBF was implemented or result from new types of Bitcoin usage;
they are not criticisms of the original design.

### Pinning Attacks

The most pressing concern is that attackers may take advantage of
limitations in RBF policy to prevent other users' transactions from
being mined or getting accepted as a replacement.

 SIGHASH_ANYONECANPAY Pinning

BIP125#2 can be bypassed by creating intermediary transactions to be
replaced together. Anyone can simply split a 1-input 1-output
transaction off from the replacement transaction, then broadcast the
transaction as is. This can always be done, and quite cheaply. More
details in [this comment][2].

In general, if a transaction is signed with SIGHASH\_ANYONECANPAY,
anybody can just attach a low feerate parent to this transaction and
lower its ancestor feerate.  Even if you require SIGHASH\_ALL which
prevents an attacker from changing any outputs, the input can be a
very low amount (e.g. just above the dust limit) from a low-fee
ancestor and still bring down the ancestor feerate of the transaction.

TLDR: if your transaction is signed with SIGHASH\_ANYONECANPAY and
signals replaceability, regardless of the feerate you broadcast at, an
attacker can lower its mining priority by adding an ancestor.

 Absolute Fee

The restriction of requiring replacement transactions to increase the
absolute fee of the mempool has been described as "bonkers." If the
original transaction has a very large descendant that pays a large
amount of fees, even if it has a low feerate, the replacement
transaction must now pay those fees in order to meet Rule #3.

 Package RBF

There are a number of reasons why, in order to enable Package RBF, we
cannot use the same criteria.

For starters, the absolute fee pinning attack is especially
problematic if we apply the same rules (i.e. Rule #3 and #4) in
Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
LN