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

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

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd.org> wrote:

>
> 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.


When you say that you don't think it is possible to solve, do you mean that
there is a specific problem with this proposal of replacing transactions
when offered a new transaction whose fee rate exceeds the package fee rate
of the original transaction (and ensuring that the fee increase covers the
size of the transactions being ejected)?  Is your concern only about the
ability to computing and track the package fee rate for transactions within
the mempool or is there some other issue you foresee?

--001a11441194299e150566341668
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 6:42 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>Ah ok, I misunderstood and didn&#39;t realise you were talking about=
 the case where<br>
Alice re-spends her unconfirmed payment. Unfortunately I don&#39;t think th=
at case<br>
is possible to solve without putting some kind of restriction on spending<b=
r>
unconfirmed outputs; with a restriction it&#39;s fairly simple to solve.</b=
lockquote><div><br></div><div>When you say that you don&#39;t think it is p=
ossible to solve, do you mean that there is a specific problem with this pr=
oposal of replacing transactions when offered a new transaction whose fee r=
ate exceeds the package fee rate of the original transaction (and ensuring =
that the fee increase covers the size of the transactions being ejected)?=
=C2=A0 Is your concern only about the ability to computing and track the pa=
ckage fee rate for transactions within the mempool or is there some other i=
ssue you foresee?<br></div><div>=C2=A0</div></div></div></div>

--001a11441194299e150566341668--