On February 13, 2018 1:40 PM, Peter Todd <p...@petertodd.org> wrote:
> Yeah, sorry, I just misread what scenario you guys were talking about. IIRC
> 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.
Yeah. I posted that before it was clarified, it's just my message got held up
in the moderation queue so it came out of order at an inconvenient time ><
> 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.
It is. T_a and T_ab are "reorg" safe, but if T_a confirms you will still need
to pay Bob in way. But you need to pay him such that in a reorg occurs and
suddenly T_ab is mined, you haven't doubled paid him.
I've been working on it's implementation, but it's honestly really complex and
hard to test. I outlined the procedure here:
https://gist.github.com/RHavar/cff76a026ece8446c898470db4f35682 which I call
My point though isn't that it's impossible, it's that it's sufficiently complex
that it's unreasonable to expect anyone to be doing it any time soon. By
relaxing any unnecessary restrictions on bip125, just makes it _drastically_
easier to do certain things.
> So here's a question: how many wallets have actually implemented CPFP fee
> for incoming transactions?
Never tried it, but I recall seeing it in the electrum gui. I originally tried
supporting this myself, but it's kind of annoying. It's generally a bit
cost-prohibitive to create a transaction specifically for the purpose of a CPFP
fee bump, but since I made transactions pretty frequently (averaged say every 8
minutes) it doesn't add an additional input for the purpose of bumping selected
The work flow is reasonably smooth: Alice has sent me 1 BTC with low fees, I
owe Bob some money. I source Alice's output in the payment to Bob, giving her
transaction a fee bump. Both transactions confirm, everyone is happy.
However during the whole time I need to watch Alice's transaction because if it
ever is replaced/conflicted, I need to immediately pay Bob (in a reorg safe
way, so I don't double-pay). It's not terribly hard to do, by making sure when
I pay Bob I use an additional input that I also use for any "repayment" but
it's enough complexity and hard enough to test that I gave up.
The really nice thing of most current send systems (and now especially so with
segwit) is everything is pretty much fire and forget. (although I just
schedule in 0.5, 1, 2, 4, .... 32 hours fee bump attempts. But that's just
background that can fail/succeed blindly)
bitcoin-dev mailing list