Date: Mon, 22 Jan 2018 15:00:23 -0500
From: Peter Todd <pete@petertodd.org>
To: Rhavar <rhavar@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180122200023.GA1055@savin.petertodd.org>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
Precedence: list


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

On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
> So my half-baked idea is very simple:
>=20
> Allow users to merge multiple unconfirmed transactions, stripping extrane=
ous inputs and change as they go.
>=20
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum pai=
d by the original transactions."
>=20
> Because the size of the merged transaction is smaller than the original t=
ransactions, unless there is a considerable feerate bump, this rule isn't p=
ossible to observe.
>=20
> I my question is: is it possible or reasonable to relax this rule? If thi=
s rule was removed in its entirety, does it introduce any DoS vectors? Or c=
an it be changed to allow my use-case?

It would definitely introduce DoS vectors by making it much cheaper to use
relay bandwidth. You'd also be able to push others' txs out of the mempool.

> ---
> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-=
Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bi=
tcoin, and have promised to pay him immediately: Instead of creating a whol=
e new transaction if I have an in-flight (unconfirmed) transaction, I can f=
ollow the rules of bip125 to create a replacement that accomplishes this go=
al.
>=20
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it wit=
hout difficulty.
>=20
> However, the real problem is tracking the mess. Consider this sequence of=
 events:
> 1) I have unconfirmed transaction A
> 2) I replace it with B, which pays John 1 BTC
> 3) Transaction A gets confirmed
>=20
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
>
> One possible solution is to only consider a transaction "replaceable" if =
it has change, so if the original transaction confirms -- payments can imme=
diately be made that source the change, and provide safety in a reorg.
>=20
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.

Most transactions don't have change?! Under what circumstance? For most
use-cases the reverse is true: almost all all transactions have change, bec=
ause
it's rare for the inputs to exactly math the requested payment.

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

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

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

iQEcBAEBCAAGBQJaZkLRAAoJECSBQD2l8JH7f84IAIHgCCqvqQabIi/h1uxTBUuV
ucazL47BXF9PfPCCyM6ukX34Kw1Qkww9qsEFfHWk6sIQ1usF6nAUujHKbuYlpjoy
R/AHwgFcbUymC+MaEPd3N9Bl8MpDmOzD0eS0BCdZauQ4X86wUat0A2+VLNkukp28
00TG+S542Q/Gup+i+awU30XQELaHsMhEY+cKCcuz70gRUX6b6pjHKQnzN7b93dnS
6k0dArgd8fn+Y2VRTY9UYjZJQneuGfcIEPJGVOkQW2C809jEK27JWkC5PZZg8BUw
5FzU3/oSjE26gVDfHQGQgOshkQXNjQzMZmBsDDjMbybQvdVsYP0kXtXP/v4tvpk=
=me3p
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--