On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <p...@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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
