MIME-Version: 1.0
In-Reply-To: <20180212225828.GB8551@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
	<20180212225828.GB8551@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 12 Feb 2018 18:19:40 -0500
Message-ID: <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11403080fbc79005650c1da4"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list

--001a11403080fbc79005650c1da4
Content-Type: text/plain; charset="UTF-8"

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.

> 3'. The replacement transaction pays a fee rate of at least the effective
> > fee rate of any chain of transactions from the set of original
> transactions
> > that begins with the root of the original transaction set.
>
> 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.

--001a11403080fbc79005650c1da4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
</span>I don&#39;t actually see where the problem is here. First of all, su=
ppose we have a<br>
transaction T_a that already pays Alice with a feerate sufficiently high th=
at<br>
we expect it to get mined in the near future. If we want to pay Bob, we can=
 do<br>
that by simply creating a double-spend of T_a that pays both Bob and Alice,=
<br>
T_{ab}. BIP125 only requires that double-spend to have an absolute fee high=
er<br>
than the minimum relay feerate * size of the transaction.<br></blockquote><=
div><br></div><div>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-tra=
nsaction that the Alice has added as a unconfirmed child transaction to T_a=
 because double-spending to pay Alice and Bob invalidates Alice&#39;s sweep=
-transaction.=C2=A0 Alice&#39;s sweep-transaction is very large, and hence =
pays a large absolute fee even though her fee-rate is very low.=C2=A0 We do=
 not have any control over its value, hence Alice has &quot;pinned&quot; ou=
r RBF transaction.<br></div><span class=3D""></span><span class=3D""></span=
><br><span class=3D""></span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">
&gt; 3&#39;. The replacement transaction pays a fee rate of at least the ef=
fective<br>
&gt; fee rate of any chain of transactions from the set of original transac=
tions<br>
&gt; that begins with the root of the original transaction set.<br>
<br>
</span>I think what you mean here should be the effective fee rate of the m=
aximum<br>
feerate package that can be built from the set of transactions that begins =
with<br>
the candidate replacement. But actually calculating this is I believe<br>
non-trivial, which is why I didn&#39;t implement it this way when RBF was f=
irst<br>
implemented.<span class=3D""><br></span></blockquote><div><br></div><div>Ye=
s, that is what I mean.=C2=A0 My proposal was off-the-mark.<br></div><div><=
br>Surely CPFP is already computing the package-fee rates of mempool transa=
ctions.=C2=A0 That is the value we need to compute.<br></div></div></div></=
div>

--001a11403080fbc79005650c1da4--