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

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

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

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

> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > 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.
>
> Ah ok, I misunderstood and didn't realise you were talking about the case
> where
> Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> case
> is possible to solve without putting some kind of restriction on spending
> unconfirmed outputs; with a restriction it's fairly simple to solve.
>

Adding such a restriction was Rhavar's original suggestion in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html,
but it seems the proposal wasn't well received because it kinda destroys
CPFP.

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