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
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
