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 1EB98C09 for ; Wed, 24 Jan 2018 16:05:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 07BFE37C for ; Wed, 24 Jan 2018 16:05:11 +0000 (UTC) Date: Wed, 24 Jan 2018 11:05:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1516809904; bh=YAYiy+dyeSvB3Nm7/skRmQ8EAsU6x8XnYQm6YbrWZkA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=h1aI+VrBF7mu1MXPnR+7OfthCg55Cg0GAB/BhznAEhCIfYEb9NNMqdLUxWMQ28+8x Nl+Gh8uipJQ1eEA5UTE66Pzwl7j8kOqVkMFg3v6UM96hRBBiA6Ljc7yA+A2/Ak7COb zxJDBfEumfSe+q0sgSJLXAur1WMUDJocfCFrKqzs= To: Alan Evans From: Rhavar Reply-To: Rhavar Message-ID: In-Reply-To: References: <20180122200023.GA1055@savin.petertodd.org> <7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com> <20180124074453.GC12767@savin.petertodd.org> 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 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Thu, 25 Jan 2018 21:02:35 +0000 Cc: Bitcoin Protocol Discussion 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: Wed, 24 Jan 2018 16:05:13 -0000 >I'm confused, the mempool=C2=A0only sees 1 transaction at a time, first A,= then later B. "the original transactions", plural, should not exist in the= mempool. > >B's fee and rate needs to be larger than A's, but B will be greater than o= r equal to A anyway. So, just increasing the fee rate will cause a larger f= ee anyway. > >Am I missing something? 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) t= o it. The issue with this, is from a practical perspective is _very_ complex. Bec= ause you really need to do a lot of tracking to see which of the two transa= ctions 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-maliciou= s will likely contain the replacement). 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 ti= me in the near future. But "retroactive transaction merging" is actually pretty approachable probl= em for a service to implement. You just get N valid transactions you've mad= e, merge them into one. Strip extraneous inputs[1], and combine and alter t= he change amount. The reason this is so appealing to implement, is there is very little compl= exity. If the "retroactive transaction merge" fails, or doesn't get confirm= ed, it actually has no impact. If it does get confirmed, that's just pure c= ost-savings. However, the rules of bip125 currently make it (unnecessarily?) unappealing= , because I can never lower the absolute amount of fees I pay. Hence I thin= k it'd be pretty sweet if they could be relaxed to support this if it can b= e done in a pretty risk free way. [1] Need to be very careful with that, if you're ever merging a merged tran= saction. > > >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 bip= 125 is >> > > rather incentive incompatible right now? If we're assuming a competi= tive >> > > mempool, it really doesn't seem generally rational to accept a repla= cement >> > > transaction of a lower fee rate. >> > >> > BIP125 replacement requires that the fee rate increases.=C2=A0 The tex= t of >> > the BIP document is written in a confusing way that doesn't make this >> > clear. >> >>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 a= nd thus >> miners could overall earn more from the additional transactions they cou= ld fit >> into their block. But to do that properly requires considering whether o= r not >> that's actually true in the particular state the mempool as a whole happ= ens to >> be in, so I ditched that idea early on for the much simpler criteria of = both a >> feerate and absolute fee increase. >> >> -- >>https://petertodd.org 'peter'[:-1]@petertodd.org >> >>_______________________________________________ >> bitcoin-dev mailing list >>bitcoin-dev@lists.linuxfoundation.org >>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >