On Mon, Feb 12, 2018 at 06:23:12PM -0500, rha...@protonmail.com wrote:
> 
>  On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.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.
> 
> It's a bit of a made up term, but when Russel said "pinned" it refers to a 
> child transaction that was made  (i.e. in this case by Alice) and for us to 
> replace our transaction we need to "unpin" it.

Yeah, sorry, I just misread what scenario you guys were talking about. IIRC the
term "pinned" may have even been invented by myself, as IIRC I noticed the
issue when the RBF patch was being developed years ago. I don't think I had a
solution at the time so I just punted on it.

> However to unpin it, the current bip125 rules require you pay not only the 
> relay of the transactions you're throwing away, but the absolute fee. This is 
> general is cost prohibitive, as even a normalish transaction can be spending 
> $20 in fees. 
> 
> Also FWIW this whole idea of T_a and T_ab  is good, but it's also pretty 
> impractical at the moment due to the sheer amount complexity it introduces 
> (i.e. monitoring, seeing which confirms, trying to rebroadcast the missing 
> one in a way that is safe against reorgs, blah blah).

I'm not sure that's actually true, as you're only creating transactions sets
that are reorg safe. Though I don't have a detailed design in mind so I may be
missing something.

> > A better way to solve this class of problems may be diffed tx replacement
> > propagation: basically broadcast a diff between the original tx and the
> > proposed replacement, allowing you to do the minimum bandwidth accounting 
> > based
> > on the size of the diff instead.
> 
> This would definitely work for some specific use-case. For instance currently 
> if you do n replacements of a transaction, each time adding an additional 
> output .. you need to pay something like O(n^2) relay fee. If you used a diff 
> instead, you could probably get it to O(n)ish. 
> 
> But relay fee (and n) at the moment, mean it's not a big deal at all. The big 
> flaw (imo) in bip125 is that you need to pay the absolute fee from the 
> transactions you are evicting. And that can be from transactions you didn't 
> even generate yourself.  We can already compactly represent the diff  (the 
> new transaction invalidates it)  the debate is more "Should you have to pay 
> the absolute fee or just relay fee for the stuff you invalidate"

Yes, the diff approach doesn't help for the pinned case.

Unfortunately the only solution I have is basically the same as what you
proposed(1) months ago: limit spends of unconfirmed outputs in some way.

So here's a question: how many wallets have actually implemented CPFP fee bumps
for incoming transactions?

1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

Attachment: signature.asc
Description: Digital signature

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to