path: root/03/5a8f686d593752ce54017e279f4cf74b245bfb

Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 88490FE6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jan 2018 16:43:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
	[66.111.4.27])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83367306
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jan 2018 16:43:37 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id 94E7820D7E;
	Sun, 28 Jan 2018 11:43:36 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
	by compute1.internal (MEProxy); Sun, 28 Jan 2018 11:43:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
	content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; bh=BzASf+QO8/aeb3eOxJzM9zUGcCCfw
	en38dLL8kAzDpI=; b=gH2p2pMMK1z4CgupkRkHsDnvhbWtV249qNWXc5ieMh9km
	bPZ7JescnzUsK7TaEQOF2EnsRyWSMa62T6/KhXD7I8EbNxE8+oQnyIX37FP5u42s
	F/e1psNsPtW4tDBrTm6k1vK2CwSO7VDyNWIckosa2X5dzcbt9H8Tp9MFaC9D9dqY
	uxd8mhQjROqBt9BNPCLeRzqUTnZLrvNfeUVT7DUrxQms7oZa1z5Gyeeoaf8Y8eit
	K32JuCiVN6T/1ZIQ3uC/dj9usNllgWNisWw6ccLS6Wr5Gg8oAbVOglLtlJIVMBDQ
	fEgRGg5CGIcwvGMM46ar70udoEvfiHDddvc4T9brQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BzASf+
	QO8/aeb3eOxJzM9zUGcCCfwen38dLL8kAzDpI=; b=WbRx5YgFqOskOKrfutgRdW
	nLCU7Pb3+/xhaBV5CAa9M8j9OUqEIZOXBOOYsirlQZ/+a6AQLZH1YqfPBjlTLyus
	YjItyjvQ1rNmAWWAj+Ck3ApslALGhwI1v8mGinBXntRSvheBvXiYyAbsuehbEjbY
	HVCVbx3z/laDX5lfTl3NPW/8MaE7CCPonRafwAdQFfzJiXGYZUuWynZD+/euWgmo
	jU6dratKFjzD6tpASSwnmLU7IIKRPW4TTRWvKOq3e9YDd0+p3uToTNQdpqEFsbGN
	V6+Gcil1BlYEp39ssYdNTBBB24WRTxGxBKw/hyQY/gzizwdqeLjHYXvgf1/LPBJA
	==
X-ME-Sender: <xms:uP1tWkTlFbANJjfHtNT2fiQ_kXZbx_v67vZviBJ8_5z4QSnC9voIsw>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
	[84.105.61.15])
	by mail.messagingengine.com (Postfix) with ESMTPA id EBEE824691;
	Sun, 28 Jan 2018 11:43:35 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sun, 28 Jan 2018 17:43:34 +0100
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
	<20180122200023.GA1055@savin.petertodd.org>
	<7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com>
	<CACiOHGw=XUe6Fxmh8JkNPZWK1d3hWaaVPsNy1dPNoU1qULckrA@mail.gmail.com>
	<oY5fxEk2FEJwHTtN9hKit2Unfu9C6CpSKLOVr0Tu99W_ctym_TNtEPLjgSg77e_RePgWHLBF7sNZoXa11aDgm6ClDxT33Jz2M-q3HZC1n40=@protonmail.com>
	<CAAS2fgQBMSOhDBUZ6d9cG7fHg4tRr8o+E0j3ZXhdHkxv4kTwUA@mail.gmail.com>
	<20180124074453.GC12767@savin.petertodd.org>
	<CALPhJayjSopa6qPDAo=8-FVCz5+SjXneGMmoYF2Yi2p3FrCb0g@mail.gmail.com>
	<PdUSy7mO1QTH-sAU_gBRjZOhLi1FoZRPUhNZt80kPL8d0lOgsCfMeNzf52Ae7_wrcTBy7d-tROvRLqBuHMMtmduzAskGuzPlwxI2yG4yY64=@protonmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Rhavar <rhavar@protonmail.com>
In-Reply-To: <PdUSy7mO1QTH-sAU_gBRjZOhLi1FoZRPUhNZt80kPL8d0lOgsCfMeNzf52Ae7_wrcTBy7d-tROvRLqBuHMMtmduzAskGuzPlwxI2yG4yY64=@protonmail.com>
Message-Id: <36682FF4-5C68-4610-9E82-FCE6F93E050F@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.5.20)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 28 Jan 2018 17:00:58 +0000
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jan 2018 16:43:38 -0000

I can see how merging after the fact could be more practical than =
appending existing transactions.

I think what Moral Agent suggested is the same as your original =
proposal, namely dropping rule 3. Only fee per weight unit increase from =
rule 4 would matter.

The minimum per WU increase could be far higher than the minimum relay =
fee. The few times I=E2=80=99ve used RBF in practice I increased the fee =
by at least 50%. Rule 4 could be made more strict. I don=E2=80=99t know =
what number, if any, would address concerns about relay spam?

This wouldn=E2=80=99t be backward compatible. Does that matter as long =
as there=E2=80=99s enough nodes that follow the new rules? Is there a =
punishment for relaying transactions that violate rule 3? Could a =
recipient using the older rules be mislead (in a way that=E2=80=99s =
worse than the fact that RBF allows the sender to replace the =
transaction with anything they want anyway)?

Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?

And wrote:
> payment service for instance where a large number of deposits are =
aggregated into a smaller number of payments

So this would involve wallets (of users who deposit coins) cooperating =
with an exchange API to consolidate in-mempool transactions?

And wrote:

> In fact I considered only requiring an increase in fee rate, based on =
the
theory that if absolute fee went down, the transaction must be smaller =
and thus
miners could overall earn more from the additional transactions they =
could fit
into their block. But to do that properly requires considering whether =
or not
that's actually true in the particular state the mempool as a whole =
happens to
be in, so I ditched that idea early on for the much simpler criteria of =
both a
feerate and absolute fee increase.

Why would you need to consider the whole mempool? Let=E2=80=99s say a =
miner is considering to replace transaction A and B with transaction C, =
where C pays a higher fee per byte than both A and B. This creates space =
for ~ one additional transaction in the block. It seems to me the miner =
only needs to check that the lowest fee per weight transaction > =
min_fee(A,B). At least in first approximation.

Sjors

> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
>=20
>> I'm confused, the mempool only sees 1 transaction at a time, first A, =
then later B. "the original transactions", plural, should not exist in =
the mempool.
>>=20
>> B's fee and rate needs to be larger than A's, but B will be greater =
than or equal to A anyway. So, just increasing the fee rate will cause a =
larger fee anyway.
>>=20
>> Am I missing something?
>=20
> Kind of. The first case is that you do the "smarter" type of merging, =
where you get an original transaction and then say add an additional =
output(s) to it.
>=20
> The issue with this, is from a practical perspective is _very_ =
complex. Because you really need to do a lot of tracking to see which of =
the two transactions actually confirm. And if you are promising fast =
payments, you can be stuck in a weird limbo state where you're waiting =
for the original one to "safely" confirm before it's safe to make a =
re-payment (even a non-malicious will likely contain the replacement).
>=20
> bip125 already supports this use-case, but I will suggest that the =
logic to deploy this is sufficiently complex that no one is going to =
attempt any time in the near future.
>=20
>=20
> But "retroactive transaction merging" is actually pretty approachable =
problem for a service to implement. You just get N valid transactions =
you've made, merge them into one. Strip extraneous inputs[1], and =
combine and alter the change amount.
>=20
> The reason this is so appealing to implement, is there is very little =
complexity. If the "retroactive transaction merge" fails, or doesn't get =
confirmed, it actually has no impact. If it does get confirmed, that's =
just pure cost-savings.
>=20
> However, the rules of bip125 currently make it (unnecessarily?) =
unappealing, because I can never lower the absolute amount of fees I =
pay. Hence I think it'd be pretty sweet if they could be relaxed to =
support this if it can be done in a pretty risk free way.
>=20
>=20
>=20
> [1] Need to be very careful with that, if you're ever merging a merged =
transaction.
>=20
>=20
>>=20
>>=20
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via =
bitcoin-dev wrote:
>>>> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>> Interesting. I didn't think about this before, but it seems like =
bip125 is
>>>>> rather incentive incompatible right now? If we're assuming a =
competitive
>>>>> mempool, it really doesn't seem generally rational to accept a =
replacement
>>>>> transaction of a lower fee rate.
>>>>=20
>>>> BIP125 replacement requires that the fee rate increases.  The text =
of
>>>> the BIP document is written in a confusing way that doesn't make =
this
>>>> clear.
>>>=20
>>> In fact I considered only requiring an increase in fee rate, based =
on the
>>> theory that if absolute fee went down, the transaction must be =
smaller and thus
>>> miners could overall earn more from the additional transactions they =
could fit
>>> into their block. But to do that properly requires considering =
whether or not
>>> that's actually true in the particular state the mempool as a whole =
happens to
>>> be in, so I ditched that idea early on for the much simpler criteria =
of both a
>>> feerate and absolute fee increase.
>>>=20
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>=20