MIME-Version: 1.0
In-Reply-To: <20180301151129.GA9373@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>
	<CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
	<20180301151129.GA9373@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 8 Mar 2018 10:39:46 -0500
Message-ID: <CAMZUoKkG8tbdb+6tGmpvgXb-=3Tu4JsTWXz77o3EC+4Bcbd17A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11441cf27c61180566e87d69"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list

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

On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> > 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?
>
> I mean, I think in general solving this problem is probably not possible.
> Basically, the fundamental problem is someone else has consumed network
> bandwidth that should be paid for with fees. What you're trying to do is
> replace a transaction without paying those fees, which is identical to
> what an
> attacker is trying to do, and thus any such scheme will be as vulnerable to
> attack as not having that protection in the first place.
>
> ...which does give you an out: maybe the attack isn't important enough to
> matter. :)
>

Thanks, that makes sense.

I still think it is worthwhile pursuing this proposed change in RBF policy
as it would seem that the current policy is problematic in practice today
where participants are just performing normal transactions and are not
trying to attack each other.

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

<div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
>On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=
=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div=
 class=3D"h5">On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O&#39;Conno=
r wrote:<br>
&gt; When you say that you don&#39;t think it is possible to solve, do you =
mean that<br>
&gt; there is a specific problem with this proposal of replacing transactio=
ns<br>
&gt; when offered a new transaction whose fee rate exceeds the package fee =
rate<br>
&gt; of the original transaction (and ensuring that the fee increase covers=
 the<br>
&gt; size of the transactions being ejected)?=C2=A0 Is your concern only ab=
out the<br>
&gt; ability to computing and track the package fee rate for transactions w=
ithin<br>
&gt; the mempool or is there some other issue you foresee?<br>
<br>
</div></div>I mean, I think in general solving this problem is probably not=
 possible.<br>
Basically, the fundamental problem is someone else has consumed network<br>
bandwidth that should be paid for with fees. What you&#39;re trying to do i=
s<br>
replace a transaction without paying those fees, which is identical to what=
 an<br>
attacker is trying to do, and thus any such scheme will be as vulnerable to=
<br>
attack as not having that protection in the first place.<br>
<br>
...which does give you an out: maybe the attack isn&#39;t important enough =
to<br>
matter. :)<br>
</blockquote><div><br></div><div>Thanks, that makes sense.<br><br></div><di=
v>I still think it is worthwhile pursuing this proposed change in RBF polic=
y as it would seem that the current policy is problematic in practice today=
 where participants are just performing normal transactions and are not try=
ing to attack each other.<br></div></div></div></div></div>

--001a11441cf27c61180566e87d69--