Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

["Russell O'Connor" <roconnor@blockstream.io>]

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

On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete@petertodd.org> wrote:

>
> I don't actually see where the problem is here. First of all, suppose we
> have a
> transaction T_a that already pays Alice with a feerate sufficiently high
> that
> we expect it to get mined in the near future. If we want to pay Bob, we
> can do
> that by simply creating a double-spend of T_a that pays both Bob and Alice,
> T_{ab}. BIP125 only requires that double-spend to have an absolute fee
> higher
> than the minimum relay feerate * size of the transaction.
>

The problem is that rule 3 of BIP 125 requires you pay a fee that is higher
than the the fee of T_a *plus* the fee of the sweep-transaction that the
Alice has added as a unconfirmed child transaction to T_a because
double-spending to pay Alice and Bob invalidates Alice's
sweep-transaction.  Alice's sweep-transaction is very large, and hence pays
a large absolute fee even though her fee-rate is very low.  We do not have
any control over its value, hence Alice has "pinned" our RBF transaction.

> 3'. The replacement transaction pays a fee rate of at least the effective
> > fee rate of any chain of transactions from the set of original
> transactions
> > that begins with the root of the original transaction set.
>
> I think what you mean here should be the effective fee rate of the maximum
> feerate package that can be built from the set of transactions that begins
> with
> the candidate replacement. But actually calculating this is I believe
> non-trivial, which is why I didn't implement it this way when RBF was first
> implemented.
>

Yes, that is what I mean.  My proposal was off-the-mark.

Surely CPFP is already computing the package-fee rates of mempool
transactions.  That is the value we need to compute.

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