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 17660F74 for ; Tue, 27 Feb 2018 16:26:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BDD95C9 for ; Tue, 27 Feb 2018 16:26:20 +0000 (UTC) Received: by mail-it0-f47.google.com with SMTP id v186so15950184itc.5 for ; Tue, 27 Feb 2018 08:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mQNpPNuFx+ZQJcflsyF3IN+fUZ2MpzR9nZjNaJroGI0=; b=G2HIu4eXleDwCV+e/Sxs1hY8ZDhFF4/kD0VGuSG9tx2pkolqjK/1NaD4uXGEkXs+ox BdWLtvAUfQqmx5JqH52wvGrwOPR/Hbk1pQMfDZfK+9wQ1bvrQvyRuR3A2RdlmODIt1u0 cMbo8qV41GXqQUwtKHWmReb7Weeimt87Lu/mU= 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=mQNpPNuFx+ZQJcflsyF3IN+fUZ2MpzR9nZjNaJroGI0=; b=nr3Au2NtI6TwOWpIcBZOE0vOCSe7/i4L5X4WOaXD8n+FTuJaII7h+wAdJmISCGNAwY T7XhqNWtBoUFHGCDk8ytOxwnbI46mV8EAAUzVFBHCFrK2u4E7PmOfrTiRpJ8d03wjKd+ C8CocFIslRDo7j2kMkCFQqpX1kp7diZWh2aH0bYRYOCKWOrZ/FR0i2bmKb7cN8jQkTkI 4N27Fnbw0jrE/h0yZRk/9MOfnb9mzAN3jNfdL8ghkkL7Koa7op+/QFY2CCx1mznpwVDX yvuD3NLk6kX21mYD93BIpBua0nevo2p+d8U3EGLwcdv/SUJWxdMCWfDyjw1HAxEYJPzg qWiw== X-Gm-Message-State: APf1xPBfEBjrcoGO5ZFsVjFhbMrOV/XA1gNzw4FHa5/lY8b6s/AKqAt7 zbvCFP2YkwbB/dgE8GuRecQmFN+1YZ6RDmBBTX1JDpSs X-Google-Smtp-Source: AG47ELs+YCUGT2uRk3+QFiNbA/lLF0tkADFPkfRa2p4E187OtLVo+7Q8xKVVl1lRwVqZRWoA9+iA6/yBVfJWxMUKRuw= X-Received: by 10.36.17.77 with SMTP id 74mr6166535itf.74.1519748779706; Tue, 27 Feb 2018 08:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.166.10 with HTTP; Tue, 27 Feb 2018 08:25:59 -0800 (PST) In-Reply-To: <20180212234225.GA9131@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> From: "Russell O'Connor" Date: Tue, 27 Feb 2018 11:25:59 -0500 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="001a11441194299e150566341668" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy. 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: Tue, 27 Feb 2018 16:26:21 -0000 --001a11441194299e150566341668 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > > Ah ok, I misunderstood and didn't realise you were talking about the case > where > Alice re-spends her unconfirmed payment. Unfortunately I don't think that > case > is possible to solve without putting some kind of restriction on spending > unconfirmed outputs; with a restriction it's fairly simple to solve. When you say that you don't think it is possible to solve, do you mean that there is a specific problem with this proposal of replacing transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction (and ensuring that the fee increase covers the size of the transactions being ejected)? Is your concern only about the ability to computing and track the package fee rate for transactions within the mempool or is there some other issue you foresee? --001a11441194299e150566341668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd.org&g= t; wrote:

Ah ok, I misunderstood and didn't realise you were talking about= the case where
Alice re-spends her unconfirmed payment. Unfortunately I don't think th= at case
is possible to solve without putting some kind of restriction on spending unconfirmed outputs; with a restriction it's fairly simple to solve.

When you say that you don't think it is p= ossible to solve, do you mean that there is a specific problem with this pr= oposal of replacing transactions when offered a new transaction whose fee r= ate exceeds the package fee rate of the original transaction (and ensuring = that the fee increase covers the size of the transactions being ejected)?= =C2=A0 Is your concern only about the ability to computing and track the pa= ckage fee rate for transactions within the mempool or is there some other i= ssue you foresee?
=C2=A0
--001a11441194299e150566341668--