From: Peter Todd <pete@petertodd•org>
To: "Russell O'Connor" <roconnor@blockstream•io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Date: Mon, 12 Feb 2018 18:42:25 -0500 [thread overview]
Message-ID: <20180212234225.GA9131@fedora-23-dvm> (raw)
In-Reply-To: <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]
On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete@petertodd•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.
> >
>
> The problem is that rule 3 of BIP 125 requires you pay a fee that is higher
> than the the fee of T_a *plus* the fee of the sweep-transaction that the
> Alice has added as a unconfirmed child transaction to T_a because
> double-spending to pay Alice and Bob invalidates Alice's
> sweep-transaction. Alice's sweep-transaction is very large, and hence pays
> a large absolute fee even though her fee-rate is very low. We do not have
> any control over its value, hence Alice has "pinned" our RBF transaction.
Ah ok, I misunderstood and didn't realise you were talking about the case where
Alice re-spends her unconfirmed payment. Unfortunately I don't think that case
is possible to solve without putting some kind of restriction on spending
unconfirmed outputs; with a restriction it's fairly simple to solve.
> > I think what you mean here should be the effective fee rate of the maximum
> > feerate package that can be built from the set of transactions that begins
> > with
> > the candidate replacement. But actually calculating this is I believe
> > non-trivial, which is why I didn't implement it this way when RBF was first
> > implemented.
> >
>
> Yes, that is what I mean. My proposal was off-the-mark.
>
> Surely CPFP is already computing the package-fee rates of mempool
> transactions. That is the value we need to compute.
True, maybe we can just reuse the CPFP calculation now. That said, AFAIK that's
only done in the miner code, not the mempool, so that may not be trivial to
actually do.
--
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-12 23:42 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 [this message]
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
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=20180212234225.GA9131@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/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