Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D4DA3113A for ; Wed, 24 Jan 2018 13:43:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26FB1360 for ; Wed, 24 Jan 2018 13:43:31 +0000 (UTC) Received: by mail-ot0-f169.google.com with SMTP id v5so3601405oth.5 for ; Wed, 24 Jan 2018 05:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mhtw6S6AGMRim0Fs7ODBL/CMrkDFWgxW2Lzq/KBqjGM=; b=WAkSF1tzpwOh5NK+AsVzrtDDvG15BPdL2x2Z0hAE5lillJWXvmjLYvN57mdrJKwraN 9WHp4KR0IDWfrFVM8NajCETrTakU33gMUlqrys97VbWo9rfbc58S3h+f+1GjDDsKhFbC bw97Ty3AxgR/r9C7U7vGitac6NhUHmXwSW4rRG/NZ76+myOIhJVU/lquDw46G5Gykm3T gPvzWEWceMgFkBbRAfa9biSNRTtR3Qm8fy2+Yt2JYAIWpnzogTjdw66uxLHYFwOahaHc 12hEZDwyGbGtuRxoRvouAldmml0kQ5e7L73MxZip6KgGzshSpcMdtSuZxbPBjPGXaAgf Io7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mhtw6S6AGMRim0Fs7ODBL/CMrkDFWgxW2Lzq/KBqjGM=; b=XS8QguhW6WAtkuq1V98NCBu4d/7+WscOOzkWn5vhG79BMV6lDX9tHdsf/x2HdBmA9V Ec2cTHsksT85qGEE4rUbIYBnTsa40svGmK1VWLV9EaptBB5Wvj6NrIdEEu7o03oMu5QP feBgNjNvhi4j2LXp2D/3w62PLJwUHpiTqTgoTM9xCDQKjGod8RCnOuoWlmJcN1CXZj6m +oorT/XvmadsjVtC4oK464r/PBxvCMjKCJNTs8jj0PCIJRndT/w6ek/O/SR4+IJsdYxo B4HOO+l37KTTleqW7+qsHjh4sicKP1T/+S/IylN+ZFlNv9pXUyGp7trabusOrpnBG1mq cQfA== X-Gm-Message-State: AKwxytdEseHJpFYj8v8BrJjpwDEa00vSnbMtcjg2s1U1hD0mWVWzAPO9 WYO2Sl8B02Qu2UJkyyHWe065SVx3y8lCW88hgzPoHA== X-Google-Smtp-Source: AH8x225Cqgz86PRqDiAyJ5KOT6vChDHjR0UMthUIJm49kVnPEfwYd0LEw3nDHWfQYnWnb9VoPYk+7PaRU3ra0OkKyXI= X-Received: by 10.157.39.229 with SMTP id c92mr8955768otb.212.1516801410440; Wed, 24 Jan 2018 05:43:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.140.104 with HTTP; Wed, 24 Jan 2018 05:43:29 -0800 (PST) In-Reply-To: <20180124074453.GC12767@savin.petertodd.org> References: <20180122200023.GA1055@savin.petertodd.org> <7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com> <20180124074453.GC12767@savin.petertodd.org> From: Alan Evans Date: Wed, 24 Jan 2018 09:43:29 -0400 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c04707843a4b4056385d972" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Wed, 24 Jan 2018 14:34:59 +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: Wed, 24 Jan 2018 13:43:31 -0000 --94eb2c04707843a4b4056385d972 Content-Type: text/plain; charset="UTF-8" So, OP, in your scenario, you have 1 transaction in the mempool, A, then you want to spend the change before confirmation, so you broadcast a new transaction, B, which replaces A. > Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe. 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. 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. Am I missing something? 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 > > 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. > > > > 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. > > 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. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c04707843a4b4056385d972 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, OP, in your scenario, you have 1 transaction in the me= mpool, A, then you want to spend the change before confirmation, so you bro= adcast a new transaction, B, which replaces A.

> Because the size of the merged transaction is = smaller than the original transactions, unless there is a considerable feer= ate bump, this rule isn't possible to observe.

I'm confused, the mempool=C2=A0only sees 1 transaction at a time,= first A, then later B. "=C2= =A0the original transactions",= plural, should not exist in the mempool.

B&#= 39;s fee and rate needs to be larger than A's, but B will be greater th= an or equal to A anyway. So, just increasing the fee rate will cause a larg= er fee anyway.

Am I missing something?


On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; 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-d= ev@lists.linuxfoundation.org> wrote:
> > Interesting. I didn't think about this before, but it seems l= ike 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.
>
> 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 t= his
> clear.

In fact I considered only requiring an increase in fee rate, based o= n 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 n= ot
that's actually true in the particular state the mempool as a whole hap= pens to
be in, so I ditched that idea early on for the much simpler criteria of bot= h 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


--94eb2c04707843a4b4056385d972--