From: Peter Todd <pete@petertodd•org>
To: rhavar@protonmail•com
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Date: Tue, 13 Feb 2018 13:40:34 -0500 [thread overview]
Message-ID: <20180213184034.GA10642@fedora-23-dvm> (raw)
In-Reply-To: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]
On Mon, Feb 12, 2018 at 06:23:12PM -0500, rhavar@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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-02-13 18:40 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 [this message]
2018-02-14 2:07 ` rhavar
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=20180213184034.GA10642@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rhavar@protonmail$(echo .)com \
/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