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 0B854EDA for ; Mon, 12 Feb 2018 23:47:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F8B9165 for ; Mon, 12 Feb 2018 23:47:04 +0000 (UTC) Received: by mail-io0-f177.google.com with SMTP id e7so5059676ioj.1 for ; Mon, 12 Feb 2018 15:47:04 -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=YTTStvbELdDl1iQ8g3WQRskHA5AOK848ZrEBIHEOVL8=; b=mpA1RkiYTIcuXudVYMI+3GSQoBrqXbEqFw6PCn9yeGDxccA9dKY2TVUKq0oao9xTkb 0aVNpspyZHLRIiQz/f3Ip2/mnd2VVtwhql64azC+iUh9D1T+eki2THZXGISpRu/xqgRD QN7c9ry/bPX/m2sjxRxq5TwRLGLuYHG32lnck= 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=YTTStvbELdDl1iQ8g3WQRskHA5AOK848ZrEBIHEOVL8=; b=SqDuGBoLqM9q3XZj7J5YEhajce76+7JO2Hg6cddLb0tRAExjEs6ex1HJq1RB4nx2b6 9GYOMr471rjdwz9ibRrzPS8TWGfpCVQM0Gk40z3Mhz8LoaHKHefCf8S72aSZkfufjjNE 141OC5cZD/LdyCgIQU0Jx/372yYNOWgGVGMcLSZxEZDMeRWaIk/a/m76HMDM3LrIWcDm jvFUONkQu7Ftmr+0ri4ShGenO82eU5LaIcmY3xs9nw2qmYMla/mKy7C6xc4tv/naqymn WhIL2LW3WyetCMzwC348rD2dUW+4cHEyvZ2dS3Q9gUe1zcDOC/pDsT74tGotsufnHTOD xuoA== X-Gm-Message-State: APf1xPCFQ/+j5K84JTdqpvGg5tT7WdFyp0H004s+L7ISPJHCOj2OEDvj Kj+rB8AHZdwzfdFjipiwTwEpNIBB9nZ1Q5vxSufZ6ZS7zpc= X-Google-Smtp-Source: AH8x224u06BWk7ZouHuJsE/wBH1naQU8U+57FAKELD+YcCs0wmMHPfJEzrjz/ZtfBX0MQHH+1RHStRYH1PMxHP7/9QA= X-Received: by 10.107.162.85 with SMTP id l82mr14884887ioe.198.1518479223732; Mon, 12 Feb 2018 15:47:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.120.33 with HTTP; Mon, 12 Feb 2018 15:46:43 -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: Mon, 12 Feb 2018 18:46:43 -0500 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="001a11403080baced305650c7e7c" 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: Mon, 12 Feb 2018 23:47:05 -0000 --001a11403080baced305650c7e7c Content-Type: text/plain; charset="UTF-8" On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > > > > I don't actually see where the problem is here. First of all, suppose > we > > > have a > > > transaction T_a that already pays Alice with a feerate sufficiently > high > > > that > > > we expect it to get mined in the near future. If we want to pay Bob, we > > > can do > > > that by simply creating a double-spend of T_a that pays both Bob and > Alice, > > > T_{ab}. BIP125 only requires that double-spend to have an absolute fee > > > higher > > > than the minimum relay feerate * size of the transaction. > > > > > > > The problem is that rule 3 of BIP 125 requires you pay a fee that is > higher > > than the the fee of T_a *plus* the fee of the sweep-transaction that the > > Alice has added as a unconfirmed child transaction to T_a because > > double-spending to pay Alice and Bob invalidates Alice's > > sweep-transaction. Alice's sweep-transaction is very large, and hence > pays > > a large absolute fee even though her fee-rate is very low. We do not > have > > any control over its value, hence Alice has "pinned" our RBF transaction. > > 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. > Adding such a restriction was Rhavar's original suggestion in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html, but it seems the proposal wasn't well received because it kinda destroys CPFP. --001a11403080baced305650c7e7c 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:
On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'C= onnor wrote:
> On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete@petertodd.org> wrote:
>
> >
> > I don't actually see where the problem is here. First of all,= suppose we
> > have a
> > transaction T_a that already pays Alice with a feerate sufficient= ly high
> > that
> > we expect it to get mined in the near future. If we want to pay B= ob, we
> > can do
> > that by simply creating a double-spend of T_a that pays both Bob = and Alice,
> > T_{ab}. BIP125 only requires that double-spend to have an absolut= e fee
> > higher
> > than the minimum relay feerate * size of the transaction.
> >
>
> The problem is that rule 3 of BIP 125 requires you pay a fee that is h= igher
> than the the fee of T_a *plus* the fee of the sweep-transaction that t= he
> Alice has added as a unconfirmed child transaction to T_a because
> double-spending to pay Alice and Bob invalidates Alice's
> sweep-transaction.=C2=A0 Alice's sweep-transaction is very large, = and hence pays
> a large absolute fee even though her fee-rate is very low.=C2=A0 We do= not have
> any control over its value, hence Alice has "pinned" our RBF= transaction.

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.

Adding such = a restriction was Rhavar's original suggestion in https:= //lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html= , but it seems the proposal wasn't well received because it kinda destr= oys CPFP.

--001a11403080baced305650c7e7c--