From: rhavar@protonmail•com
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Date: Tue, 13 Feb 2018 21:07:25 -0500 [thread overview]
Message-ID: <IoXsS2vxicFBvVPa_4p0ERi684PMJySPwFt82NRUTzcFJ1xzTEBsuDYkDN3GIc6GDKqLTfcWtw_bn8JvCxQKPsh9nZII65536x2XL9nzC_8=@protonmail.com> (raw)
In-Reply-To: <20180213184034.GA10642@fedora-23-dvm>
On February 13, 2018 1:40 PM, Peter Todd <pete@petertodd•org> wrote:
> 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.
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 "Super Withdrawals".
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 bumps
> 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 incoming transactions.
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)
>
>1. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html
>
> --
>https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
prev parent reply other threads:[~2018-02-14 2:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 15:52 Russell O'Connor
2018-02-12 17:30 ` rhavar
2018-02-12 22:58 ` Peter Todd
2018-02-12 23:19 ` Russell O'Connor
2018-02-12 23:42 ` Peter Todd
2018-02-12 23:46 ` Russell O'Connor
2018-02-14 14:08 ` Russell O'Connor
2018-02-14 14:16 ` Greg Sanders
2018-02-27 16:25 ` Russell O'Connor
2018-03-01 15:11 ` Peter Todd
2018-03-08 15:39 ` Russell O'Connor
2018-03-08 18:34 ` Peter Todd
2018-03-08 20:07 ` Russell O'Connor
2018-03-09 18:28 ` Peter Todd
2018-03-09 18:40 ` rhavar
2018-02-12 23:23 ` rhavar
2018-02-13 18:40 ` Peter Todd
2018-02-14 2:07 ` rhavar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='IoXsS2vxicFBvVPa_4p0ERi684PMJySPwFt82NRUTzcFJ1xzTEBsuDYkDN3GIc6GDKqLTfcWtw_bn8JvCxQKPsh9nZII65536x2XL9nzC_8=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox