Date: Tue, 13 Feb 2018 13:40:34 -0500
From: Peter Todd <pete@petertodd.org>
To: rhavar@protonmail.com
Message-ID: <20180213184034.GA10642@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
	<20180212225828.GB8551@fedora-23-dvm>
	<0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5"
Content-Disposition: inline
In-Reply-To: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list


--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 12, 2018 at 06:23:12PM -0500, rhavar@protonmail.com wrote:
>=20
>  On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> > I don't actually see where the problem is here. First of all, suppose w=
e have a
> > transaction T_a that already pays Alice with a feerate sufficiently hig=
h 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 Al=
ice,
> > T_{ab}. BIP125 only requires that double-spend to have an absolute fee =
higher
> > than the minimum relay feerate * size of the transaction.
>=20
> 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.

Yeah, sorry, I just misread what scenario you guys were talking about. IIRC=
 the
term "pinned" may have even been invented by myself, as IIRC I noticed the
issue when the RBF patch was being developed years ago. I don't think I had=
 a
solution at the time so I just punted on it.

> However to unpin it, the current bip125 rules require you pay not only th=
e relay of the transactions you're throwing away, but the absolute fee. Thi=
s is general is cost prohibitive, as even a normalish transaction can be sp=
ending $20 in fees.=20
>=20
> Also FWIW this whole idea of T_a and T_ab  is good, but it's also pretty =
impractical at the moment due to the sheer amount complexity it introduces =
(i.e. monitoring, seeing which confirms, trying to rebroadcast the missing =
one in a way that is safe against reorgs, blah blah).

I'm not sure that's actually true, as you're only creating transactions sets
that are reorg safe. Though I don't have a detailed design in mind so I may=
 be
missing something.

> > A better way to solve this class of problems may be diffed tx replaceme=
nt
> > propagation: basically broadcast a diff between the original tx and the
> > proposed replacement, allowing you to do the minimum bandwidth accounti=
ng based
> > on the size of the diff instead.
>=20
> This would definitely work for some specific use-case. For instance curre=
ntly if you do n replacements of a transaction, each time adding an additio=
nal 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
>=20
> But relay fee (and n) at the moment, mean it's not a big deal at all. The=
 big flaw (imo) in bip125 is that you need to pay the absolute fee from the=
 transactions you are evicting. And that can be from transactions you didn'=
t even generate yourself.  We can already compactly represent the diff  (th=
e new transaction invalidates it)  the debate is more "Should you have to p=
ay the absolute fee or just relay fee for the stuff you invalidate"

Yes, the diff approach doesn't help for the pinned case.

Unfortunately the only solution I have is basically the same as what you
proposed(1) months ago: limit spends of unconfirmed outputs in some way.

So here's a question: how many wallets have actually implemented CPFP fee b=
umps
for incoming transactions?

1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688=
=2Ehtml

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqDMR4ACgkQJIFAPaXw
kfvIMAf/bClOIr72vWZX5CUGhzVxB/jvKKHe0FYR2M4M5v3uq+AOBpCXYqEddOMj
CXon9oC5vPVlLPdmjKhKetYeyJAMexY1cOtDsXfykdGzMX8N9PjrnMPwTjsJozBG
1AufzYmoNRfwRVwP1FH4l/dNwqtBJ3bQDCOAePxNcvHGtPkNgZYsIjaj/uYMsLbo
+1KbLICfRU3VNaB6va5YhLXOSRe+x9tJPod8O+lTkacLBGRob5RzKLxvyA1aXcuG
1bPlFLYN84J+9IbByYdxGFgMHNllSJI5jXOzrgrO6ycFpxcdawttDhtniMV65ge0
PROY/3yYqE30chbAsgqqRxBH/CAkxw==
=OOUR
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--