Date: Mon, 12 Feb 2018 18:23:12 -0500
To: Peter Todd <pete@petertodd.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
In-Reply-To: <20180212225828.GB8551@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
	<20180212225828.GB8551@fedora-23-dvm>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list


 On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev <bitcoin-dev@list=
s.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 c=
an do
> that by simply creating a double-spend of T_a that pays both Bob and Alic=
e,
> T_{ab}. BIP125 only requires that double-spend to have an absolute fee hi=
gher
> 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.

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 spen=
ding $20 in fees.=20

Also FWIW this whole idea of T_a and T_ab  is good, but it's also pretty im=
practical at the moment due to the sheer amount complexity it introduces (i=
.e. monitoring, seeing which confirms, trying to rebroadcast the missing on=
e in a way that is safe against reorgs, blah blah).


>
> I just checked one of my nodes, and the absolute minimum relay fee is abo=
ut
> 1/5th that of what estimatefee returns for the longest possible estimate,=
 48
> blocks.

If you use estimatesmartfee you should be able to get estimates all the way=
 to 1008 or something btw

> [...]
> I think this is very important. For example, without this condition I cou=
ld do
> a DoS attack by repeatedly broadcasting a transaction, then spending the
> outputs of that transaction with a very large number of child transaction=
s, all
> of minimum fee.=20

I agree.

>
> 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 current=
ly if you do n replacements of a transaction, each time adding an additiona=
l 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.=20

But relay fee (and n) at the moment, mean it's not a big deal at all. The b=
ig flaw (imo) in bip125 is that you need to pay the absolute fee from the t=
ransactions 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"