From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 88490FE6 for ; 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 ; 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: 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 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: <20180122200023.GA1055@savin.petertodd.org> <7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com> <20180124074453.GC12767@savin.petertodd.org> To: Bitcoin Protocol Discussion , Rhavar In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 = 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 >>>> 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