[bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell]

Hi all,

        I want to propose a modification to rules 3, 4 and 5 of BIP 125:

To remind you of BIP 125:
 3. The replacement transaction pays an absolute fee of at least the sum
    paid by the original transactions.

 4. The replacement transaction must also pay for its own bandwidth at
    or above the rate set by the node's minimum relay fee setting.

 5. The number of original transactions to be replaced and their
    descendant transactions which will be evicted from the mempool must not
    exceed a total of 100 transactions.

The new "emergency RBF" rule:

 6. If the original transaction was not in the first 4,000,000 weight
    units of the fee-ordered mempool and the replacement transaction is,
    rules 3, 4 and 5 do not apply.

This means:

1. RBF can be used in adversarial conditions, such as lightning
   unilateral closes where the adversary has another valid transaction
   and can use it to block yours.  This is a problem when we allow
   differential fees between the two current lightning transactions
   (aka "Bring Your Own Fees").

2. RBF can be used without knowing about miner's mempools, or that the
   above problem is occurring.  One simply gets close to the required
   maximum height for lightning timeout, and bids to get into the next
   block.

3. This proposal does not open any significant new ability to RBF spam,
   since it can (usually) only be used once.  IIUC bitcoind won't
   accept more that 100 descendents of an unconfirmed tx anyway.

4. This proposal makes RBF miner-incentive compatible.  Currently the
   protocol tells miners they shouldn't accept the highest bidding tx
   for the good of the network.  This conflict is particularly sharp
   in the case where the replacement tx would be immediately minable,
   which this proposal addresses.

Unfortunately I haven't found time to code this up in bitcoin, but if
there's positive response I can try.

Thanks for reading!
Rusty.

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[rhavar]

+1

From an incentive-compatible point of view, miners should be accepting transactions that increase the amount of fees that can achieved with 4M weight of transactions, so it seems like a pretty sane plan.

One common problem I've run into with RBF is since you're using RBF you probably want to low ball fees. With good coin selection (*cough* coinsayer.com *cough*), it'll use that opportunity to consolidate inputs. But now let's say fees suddenly spike (pretty common), you might want to fee bump your now stuck transaction. But now that fees are high, it doesn't make sense to be consolidating so ideally you'd just replace it with a much smaller transaction (that pays higher fee rate).


So if anything, I think your proposal doesn't go far enough. I think even in "non-emergency" cases, we could get away with removing the requirement to increase the absolute fee (as long as the fee rate is increased); which also makes it incentive compatible if you assume a reasonable fee-market.

I realize it does open potential DoS vectors, but they seem reasonably small.







-Ryan

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 1, 2019 9:41 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I want to propose a modification to rules 3, 4 and 5 of BIP 125:
>
> To remind you of BIP 125:
> 3. The replacement transaction pays an absolute fee of at least the sum
> paid by the original transactions.
>
> 4. The replacement transaction must also pay for its own bandwidth at
> or above the rate set by the node's minimum relay fee setting.
>
> 5. The number of original transactions to be replaced and their
> descendant transactions which will be evicted from the mempool must not
> exceed a total of 100 transactions.
>
> The new "emergency RBF" rule:
>
> 6. If the original transaction was not in the first 4,000,000 weight
> units of the fee-ordered mempool and the replacement transaction is,
> rules 3, 4 and 5 do not apply.
>
> This means:
>
> 1.  RBF can be used in adversarial conditions, such as lightning
>     unilateral closes where the adversary has another valid transaction
>     and can use it to block yours. This is a problem when we allow
>     differential fees between the two current lightning transactions
>     (aka "Bring Your Own Fees").
>
> 2.  RBF can be used without knowing about miner's mempools, or that the
>     above problem is occurring. One simply gets close to the required
>     maximum height for lightning timeout, and bids to get into the next
>     block.
>
> 3.  This proposal does not open any significant new ability to RBF spam,
>     since it can (usually) only be used once. IIUC bitcoind won't
>     accept more that 100 descendents of an unconfirmed tx anyway.
>
> 4.  This proposal makes RBF miner-incentive compatible. Currently the
>     protocol tells miners they shouldn't accept the highest bidding tx
>     for the good of the network. This conflict is particularly sharp
>     in the case where the replacement tx would be immediately minable,
>     which this proposal addresses.
>
>     Unfortunately I haven't found time to code this up in bitcoin, but if
>     there's positive response I can try.
>
>     Thanks for reading!
>     Rusty.
>
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Matt Corallo]

I think this needs significantly improved motivation/description. A few areas I'd like to see calculated out:

1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-miner, I'd think no evicted transactions would be allowed to be in the next block range. This would probably require some significant additional tracking in today's mempool logic.

2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I think we're already not in a great place, but maybe it's worth it or maybe there is some other way to reduce this cost (intuitively it looks like this proposal could make things very, very, very bad).

3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS attack, but it may also be the case that is (a) not worse than other fundamental issues or (b) sufficiently expensive.

4) As I've indicated before, I'm generaly not a fan of such vague protections for time-critical transactions such as payment channel punishment transactions. At a high-level, in this context your counterparty's transactions (not to mention every other transaction in everyone's mempool) are still involved in the decision about whether to accept an RBF, in contrast to previous proposals, which makes it much harder to reason about. As a specific example, if an attacker exploits mempool policy differences they may cause your concept of "top 4M weight" to be bogus for a subeset of nodes, causing propogation to be limited.

Obviously there is also a ton more client-side knowledge required and complexity to RBF decisions here than other previous, more narrowly-targeted proposals.

(I don't think this one use-case being not optimal should prevent such a proposal, i agree it's quite nice for some other cases).

Matt

> On Jun 2, 2019, at 06:41, Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> Hi all,
> 
>       I want to propose a modification to rules 3, 4 and 5 of BIP 125:
> 
> To remind you of BIP 125:
> 3. The replacement transaction pays an absolute fee of at least the sum
>   paid by the original transactions.
> 
> 4. The replacement transaction must also pay for its own bandwidth at
>   or above the rate set by the node's minimum relay fee setting.
> 
> 5. The number of original transactions to be replaced and their
>   descendant transactions which will be evicted from the mempool must not
>   exceed a total of 100 transactions.
> 
> The new "emergency RBF" rule:
> 
> 6. If the original transaction was not in the first 4,000,000 weight
>   units of the fee-ordered mempool and the replacement transaction is,
>   rules 3, 4 and 5 do not apply.
> 
> This means:
> 
> 1. RBF can be used in adversarial conditions, such as lightning
>  unilateral closes where the adversary has another valid transaction
>  and can use it to block yours.  This is a problem when we allow
>  differential fees between the two current lightning transactions
>  (aka "Bring Your Own Fees").
> 
> 2. RBF can be used without knowing about miner's mempools, or that the
>  above problem is occurring.  One simply gets close to the required
>  maximum height for lightning timeout, and bids to get into the next
>  block.
> 
> 3. This proposal does not open any significant new ability to RBF spam,
>  since it can (usually) only be used once.  IIUC bitcoind won't
>  accept more that 100 descendents of an unconfirmed tx anyway.
> 
> 4. This proposal makes RBF miner-incentive compatible.  Currently the
>  protocol tells miners they shouldn't accept the highest bidding tx
>  for the good of the network.  This conflict is particularly sharp
>  in the case where the replacement tx would be immediately minable,
>  which this proposal addresses.
> 
> Unfortunately I haven't found time to code this up in bitcoin, but if
> there's positive response I can try.
> 
> Thanks for reading!
> Rusty.

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Hi Rusty,

On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The new "emergency RBF" rule:
>
>  6. If the original transaction was not in the first 4,000,000 weight
>     units of the fee-ordered mempool and the replacement transaction is,
>     rules 3, 4 and 5 do not apply.
>
> This means:
>
> 3. This proposal does not open any significant new ability to RBF spam,
>    since it can (usually) only be used once.  IIUC bitcoind won't
>    accept more that 100 descendents of an unconfirmed tx anyway.
>

Is it not possible for Alice to grief Bob's node by alternating RBFing two
transactions, each one placing itself at the bottom of Bob's top 4,000,000
weight mempool which pushes the other one below the top 4,000,000 weight,
and then repeating with the other transaction?  It might be possible to
amend this proposal to partially mitigate this.

[-- Attachment #2: Type: text/html, Size: 1317 bytes --]

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell]

"Russell O'Connor" <roconnor@blockstream.io> writes:
> Hi Rusty,
>
> On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The new "emergency RBF" rule:
>>
>>  6. If the original transaction was not in the first 4,000,000 weight
>>     units of the fee-ordered mempool and the replacement transaction is,
>>     rules 3, 4 and 5 do not apply.
>>
>> This means:
>>
>> 3. This proposal does not open any significant new ability to RBF spam,
>>    since it can (usually) only be used once.  IIUC bitcoind won't
>>    accept more that 100 descendents of an unconfirmed tx anyway.
>>
>
> Is it not possible for Alice to grief Bob's node by alternating RBFing two
> transactions, each one placing itself at the bottom of Bob's top 4,000,000
> weight mempool which pushes the other one below the top 4,000,000 weight,
> and then repeating with the other transaction?  It might be possible to
> amend this proposal to partially mitigate this.

Good point.  This will cost Alice approximately one tx every block, but
that may still be annoying.  My intuition says it's hard to play these
games across swathes of non-direct peers, since mempools are in constant
flux and propagation is a bit random.

What mitigations were you thinking?

Cheers,
Rusty.

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell]

Matt Corallo <lf-lists@mattcorallo.com> writes:
> I think this needs significantly improved motivation/description. A few areas I'd like to see calculated out:
>
> 1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-miner, I'd think no evicted transactions would be allowed to be in the next block range. This would probably require some significant additional tracking in today's mempool logic.

This is a good question, which is why I really wanted to look into the
implementation details.  There are some approximations possible wrt. pre-
and post- tx bundle feerate, but they have to be examined closely.

> 2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I think we're already not in a great place, but maybe it's worth it or maybe there is some other way to reduce this cost (intuitively it looks like this proposal could make things very, very, very bad).

I *think* you can currently create a tx at 1 sat/byte, have it
propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
times before your transaction gets mined.

If that's true, I don't think this proposal makes it worse.

>> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS attack, but it may also be the case that is (a) not worse than other fundamental issues or (b) sufficiently expensive.

I thought we still meet rule 5 in practice since bitcoind will never
even accept a tree of unconfirmed txs which is > 100 txs?  That would
still stand, it's just that we'd still consider a replacement.

> 4) As I've indicated before, I'm generaly not a fan of such vague
> protections for time-critical transactions such as payment channel
> punishment transactions.

The bitcoin network offers no propagation guarantees; it's all best
effort anyway.  This makes it no worse, and we can tunnel txs through
the lightning network if we have to.

> At a high-level, in this context your counterparty's transactions (not to mention every other transaction in everyone's mempool) are still involved in the decision about whether to accept an RBF, in contrast to previous proposals, which makes it much harder to reason about. As a specific example, if an attacker exploits mempool policy differences they may cause your concept of "top 4M weight" to be bogus for a subeset of nodes, causing propogation to be limited.

If miners have a conflicting tx in the top 4MSipa, you don't have a
problem.  So an attacker needs to limit propagation in a way which
isolates the miners from either the new tx or the conflicting one, which
is much harder.

> Obviously there is also a ton more client-side knowledge required and complexity to RBF decisions here than other previous, more narrowly-targeted proposals.

Define client-side here?

I'd say from the lightning side it's as simple as a normal RBF policy
until you get within a few blocks of a deadline, then you increase the
fees until it's well within reach of the next block.  You can even
approximate this by looking at fees on the previous block, with some
care for outliers.

> (I don't think this one use-case being not optimal should prevent such a proposal, i agree it's quite nice for some other cases).

I like that it's conceptually simple and inventive-robust, and doesn't
really rely on bitcoind's internal policy mechanics of RBF.

I think in the longer term we're going to need other mechanisms for
restricting abusive propagation anyway, but that's a bit out-of-scope.

Thanks!
Rusty.

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <rusty@rustcorp.com.au> wrote:

> "Russell O'Connor" <roconnor@blockstream.io> writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >>  6. If the original transaction was not in the first 4,000,000 weight
> >>     units of the fee-ordered mempool and the replacement transaction is,
> >>     rules 3, 4 and 5 do not apply.
> >>
> >> This means:
> >>
> >> 3. This proposal does not open any significant new ability to RBF spam,
> >>    since it can (usually) only be used once.  IIUC bitcoind won't
> >>    accept more that 100 descendents of an unconfirmed tx anyway.
> >>
> >
> > Is it not possible for Alice to grief Bob's node by alternating RBFing
> two
> > transactions, each one placing itself at the bottom of Bob's top
> 4,000,000
> > weight mempool which pushes the other one below the top 4,000,000 weight,
> > and then repeating with the other transaction?  It might be possible to
> > amend this proposal to partially mitigate this.
>
> Good point.  This will cost Alice approximately one tx every block, but
> that may still be annoying.  My intuition says it's hard to play these
> games across swathes of non-direct peers, since mempools are in constant
> flux and propagation is a bit random.
>
> What mitigations were you thinking?
>

For example,  "If the original transaction was not in the first 4,000,000
weight units of the fee-ordered mempool and the replacement transaction is
in the first 2,000,000 weight units...." might adequately address the issue.
There are probably other ways as well.

[-- Attachment #2: Type: text/html, Size: 2447 bytes --]

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[David A. Harding]

On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
> Matt Corallo <lf-lists@mattcorallo.com> writes:
> > 2) wrt rule 4, I'd like to see a calculation of worst-case free
> > relay. I think we're already not in a great place, but maybe it's
> > worth it or maybe there is some other way to reduce this cost
> > (intuitively it looks like this proposal could make things very,
> > very, very bad).
> 
> I *think* you can currently create a tx at 1 sat/byte, have it
> propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
> times before your transaction gets mined.

Yes, the current incremental relay fee in Bitcoin Core is 0.00001000
BTC/KvB.

> If that's true, I don't think this proposal makes it worse.

Here's a scenario that I think shows it being at least 20x worse.

Let's imagine that you create two transactions:

  tx0: A very small transaction (~100 vbytes) that's just 1-in, 1-out.
       At the minimum relay fee, this costs 0.00000100 BTC

  tx1: A child of that transaction that's very large (~100,000 vbytes,
       or almost 400,000 bytes using special scripts that allow witness
       stuffing).  At the minimum relay fee, this costs 0.00100000 BTC

Under the current rules, if an attacker wants to fee-bump tx0 by the
minimum incremental fee (a trivial amount, ~0.00000100 BTC), the
attacker's replacement also needs to pay for the eviction of the huge
child tx1 by that same incremental fee (~0.00100000).

Thus the replacement would cost the attacker a minimum of about
0.00100100 (~1 mBTC) for the original transactions and 0.00100100 for
the replacement (about 2 mBTC total).

The attacker could then spend another 1 mBTC re-attaching the child and
yet another 1 mBTC bumping again, incuring about a 2 mBTC cost per
replacement round.  At writing, 2 mBTC is about $14.00 USD---an amount
that's probably enough to deter most attacks at scale.

* * *

Under the new proposed rule 6, Mallory's replacement cost would be the
amount to get the small tx0 to near the top of the mempool (say
0.00100000 BTC/KvB, so 0.00010000 BTC total).  Because this would evict
the expensive child, it would actually reduce the original amount paid
by the attacker by 90% compared to the previous section's example where
using RBF increased the original costs by 100%.

The 0.1 mBTC cost of this attack is about $0.70 USD today for the
roughly the same data relay use as one round of the currently possible
attack.  In short, if I haven't misplaced a decimal point or made some
other mistake, I think the proposed rule 6 would result in approximately
a 95% reduction in the cost paid by an attacker for wasting 400,000
bytes of bandwidth per node (x60,000 nodes = 24 GB across all nodes, not
counting INV overhead).

Although the attacker might only get one replacement per block per
transaction pair out of this version of the attack, they could execute
the attack many times in parallel using different tranaction pairs.  If
this is combined with the treadmill leapfrogging Russell O'Connor
described elsewhere in this thread, the attack could possibly be
repeated multiple times per block per transaction pair at only slightly
increased cost (to pay the increasing next-block transaction fees).

> >> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty
> >> nasty DoS attack, but it may also be the case that is (a) not worse
> >> than other fundamental issues or (b) sufficiently expensive.
> 
> I thought we still meet rule 5 in practice since bitcoind will never
> even accept a tree of unconfirmed txs which is > 100 txs?  That would
> still stand, it's just that we'd still consider a replacement.

Although the BIP125 limit is 100, Bitcoin Core's current default is 25.[1]
(When RBF was implemented in Bitcoin Core, transaction ancestry was only
tracked for purposes of ensuring valid transaction ordering within
blocks; later when CPFP was implemented, ancestry was additionally used
to calculate each transaction's package fee---the value of it and all
its unconfirmed ancestors.  This requires more computation to update
the mempool metadata when the ancestry graph changes.)

Again, I'd be thinking here of something similar to O'Connor's
treadmilling attack where replacements can push each other out of the
top mempool and so create enough churn for a CPU exhaustion attack.

> >>  Obviously there is also a ton more client-side knowledge required
> >>  and complexity to RBF decisions here than other previous, more
> >>  narrowly-targeted proposals.
> I'd say from the lightning side it's as simple as a normal RBF policy
> until you get within a few blocks of a deadline, then you increase the
> fees until it's well within reach of the next block.

It's already hard for wallet software to determine whether or not its
transactions have successfully been relayed.  This proposal requires LN
wallets not only be able to guess where the next-block feerate boundary
is in other nodes' individual mempools (now and in the future for the
time it takes the transaction to propagate to ~100% of miners), but it
possibly requires that under the condition that the LN wallet can't
guess too low because it might not get another chance for relay in the
limited time available before contract expiration.

On top of that, there's O'Connor's suggestion to increase treadmilling
costs by only allowing bumps if they're in the top-half of the
next-block mempool.

Considered that way, I worry that these constraints produce a recipe for
paying extremely high feerates.  If that's an actual risk, is that
actually significantly better than dealing with the existing transaction
pinning issue where one needs to pay a high total fee in order to evict
a bunch of junk descendents?  Paying lots of fees may not be the optimal
solution to the problem of having to pay lots of fees.  :-)

-Dave

[1] Excerpt from bitcoind -help-debug :

  -limitancestorcount=<n>
       Do not accept transactions if number of in-mempool ancestors is <n> or
       more (default: 25)

  -limitdescendantcount=<n>
       Do not accept transactions if any ancestor would have <n> or more
       in-mempool descendants (default: 25)

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[rhavar]

What about this? We store a RBU ("relay bandwidth used") with each transaction in the mempool. Where RBU is defined as the size of the transaction + RBU of all transactions it has evicted.

For a replacement to be valid: The feerate must be higher than what it's evicting, and the fee must be greater than minRelayFee*RBU.




-Ryan

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 9, 2019 7:07 AM, David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>
> > Matt Corallo lf-lists@mattcorallo.com writes:
> >
> > > 2.  wrt rule 4, I'd like to see a calculation of worst-case free
> > >     relay. I think we're already not in a great place, but maybe it's
> > >     worth it or maybe there is some other way to reduce this cost
> > >     (intuitively it looks like this proposal could make things very,
> > >     very, very bad).
> > >
> >
> > I think you can currently create a tx at 1 sat/byte, have it
> > propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
> > times before your transaction gets mined.
>
> Yes, the current incremental relay fee in Bitcoin Core is 0.00001000
> BTC/KvB.
>
> > If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
>
> Let's imagine that you create two transactions:
>
> tx0: A very small transaction (~100 vbytes) that's just 1-in, 1-out.
> At the minimum relay fee, this costs 0.00000100 BTC
>
> tx1: A child of that transaction that's very large (~100,000 vbytes,
> or almost 400,000 bytes using special scripts that allow witness
> stuffing). At the minimum relay fee, this costs 0.00100000 BTC
>
> Under the current rules, if an attacker wants to fee-bump tx0 by the
> minimum incremental fee (a trivial amount, ~0.00000100 BTC), the
> attacker's replacement also needs to pay for the eviction of the huge
> child tx1 by that same incremental fee (~0.00100000).
>
> Thus the replacement would cost the attacker a minimum of about
> 0.00100100 (~1 mBTC) for the original transactions and 0.00100100 for
> the replacement (about 2 mBTC total).
>
> The attacker could then spend another 1 mBTC re-attaching the child and
> yet another 1 mBTC bumping again, incuring about a 2 mBTC cost per
> replacement round. At writing, 2 mBTC is about $14.00 USD---an amount
> that's probably enough to deter most attacks at scale.
>
> Under the new proposed rule 6, Mallory's replacement cost would be the
> amount to get the small tx0 to near the top of the mempool (say
> 0.00100000 BTC/KvB, so 0.00010000 BTC total). Because this would evict
> the expensive child, it would actually reduce the original amount paid
> by the attacker by 90% compared to the previous section's example where
> using RBF increased the original costs by 100%.
>
> The 0.1 mBTC cost of this attack is about $0.70 USD today for the
> roughly the same data relay use as one round of the currently possible
> attack. In short, if I haven't misplaced a decimal point or made some
> other mistake, I think the proposed rule 6 would result in approximately
> a 95% reduction in the cost paid by an attacker for wasting 400,000
> bytes of bandwidth per node (x60,000 nodes = 24 GB across all nodes, not
> counting INV overhead).
>
> Although the attacker might only get one replacement per block per
> transaction pair out of this version of the attack, they could execute
> the attack many times in parallel using different tranaction pairs. If
> this is combined with the treadmill leapfrogging Russell O'Connor
> described elsewhere in this thread, the attack could possibly be
> repeated multiple times per block per transaction pair at only slightly
> increased cost (to pay the increasing next-block transaction fees).
>
> > > > 3.  wrt rule 5, I'd like to see benchmarks, it's probably a pretty
> > > >     nasty DoS attack, but it may also be the case that is (a) not worse
> > > >     than other fundamental issues or (b) sufficiently expensive.
> > > >
> >
> > I thought we still meet rule 5 in practice since bitcoind will never
> > even accept a tree of unconfirmed txs which is > 100 txs? That would
> > still stand, it's just that we'd still consider a replacement.
>
> Although the BIP125 limit is 100, Bitcoin Core's current default is 25.[1]
> (When RBF was implemented in Bitcoin Core, transaction ancestry was only
> tracked for purposes of ensuring valid transaction ordering within
> blocks; later when CPFP was implemented, ancestry was additionally used
> to calculate each transaction's package fee---the value of it and all
> its unconfirmed ancestors. This requires more computation to update
> the mempool metadata when the ancestry graph changes.)
>
> Again, I'd be thinking here of something similar to O'Connor's
> treadmilling attack where replacements can push each other out of the
> top mempool and so create enough churn for a CPU exhaustion attack.
>
> > > > Obviously there is also a ton more client-side knowledge required
> > > > and complexity to RBF decisions here than other previous, more
> > > > narrowly-targeted proposals.
> > > > I'd say from the lightning side it's as simple as a normal RBF policy
> > > > until you get within a few blocks of a deadline, then you increase the
> > > > fees until it's well within reach of the next block.
>
> It's already hard for wallet software to determine whether or not its
> transactions have successfully been relayed. This proposal requires LN
> wallets not only be able to guess where the next-block feerate boundary
> is in other nodes' individual mempools (now and in the future for the
> time it takes the transaction to propagate to ~100% of miners), but it
> possibly requires that under the condition that the LN wallet can't
> guess too low because it might not get another chance for relay in the
> limited time available before contract expiration.
>
> On top of that, there's O'Connor's suggestion to increase treadmilling
> costs by only allowing bumps if they're in the top-half of the
> next-block mempool.
>
> Considered that way, I worry that these constraints produce a recipe for
> paying extremely high feerates. If that's an actual risk, is that
> actually significantly better than dealing with the existing transaction
> pinning issue where one needs to pay a high total fee in order to evict
> a bunch of junk descendents? Paying lots of fees may not be the optimal
> solution to the problem of having to pay lots of fees. :-)
>
> -Dave
>
> [1] Excerpt from bitcoind -help-debug :
>
> -limitancestorcount=<n>
>
>        Do not accept transactions if number of in-mempool ancestors is <n> or
>
>        more (default: 25)
>
>
> -limitdescendantcount=<n>
>
>        Do not accept transactions if any ancestor would have <n> or more
>
>        in-mempool descendants (default: 25)
>
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Rusty Russell]

"David A. Harding" <dave@dtrt.org> writes:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>> If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.

[ Snip ]

Indeed :(

To be fair, if I have a transaction of median size (250 bytes) and I use
the current estimatefee 2 of '0.00068325' I get to replace is 68 times;
that's $0 for an additional 1GB across all nodes.

So, I don't think the current rules are sufficient.  But I understand
the desire not to make things worse.  I'll roll in some changes and
re-propose.

> It's already hard for wallet software to determine whether or not its
> transactions have successfully been relayed.

As the deadline approaches, a lightning wallet would RBF with increasing
desparation until it gets into a block.  It doesn't really matter *why*
the tx isn't going through, there's nothing else it can do.

> This proposal requires LN
> wallets not only be able to guess where the next-block feerate boundary
> is in other nodes' individual mempools (now and in the future for the
> time it takes the transaction to propagate to ~100% of miners), but it
> possibly requires that under the condition that the LN wallet can't
> guess too low because it might not get another chance for relay in the
> limited time available before contract expiration.

I think you mean any proposal which relies on a deadline?  If so, that
bus has already left.

When you see a block you can guess the fees required for the next block.
You need some smoothing to avoid wild spikes, but in practice you can
start this "desperation mode" 10 blocks before your deadline.

Without RBF changes, it needs to assume that it needs to replace a
400kSipa tx @ feerate-for-next-block.  With some RBF change, it need
only replace @feerate-for-next-block.

> Considered that way, I worry that these constraints produce a recipe for
> paying extremely high feerates.  If that's an actual risk, is that
> actually significantly better than dealing with the existing transaction
> pinning issue where one needs to pay a high total fee in order to evict
> a bunch of junk descendents?  Paying lots of fees may not be the optimal
> solution to the problem of having to pay lots of fees.  :-)

I don't understand this at all, sorry.

Cheers,
Rusty.