Re: [bitcoin-dev] Improving RBF policy

[Bram Cohen <bram@chia.net>]

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

On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric@voskuil.org> 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.

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