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 10517F32 for ; Mon, 12 Feb 2018 23:23:29 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9AE6D0 for ; Mon, 12 Feb 2018 23:23:27 +0000 (UTC) Date: Mon, 12 Feb 2018 18:23:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1518477804; bh=9AfZQVDj8C3eoQNCQzRGffwQHUAabROSeRFywCpJDd8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=QKPM0m193L02ORtjkdelOlaP+yRBsLT+ODUr6qCHE9+udjmQ19tFxEMKYZ2xXivUJ 8waLtJ4XOYv3MVM16+ukQzYKtlu2uZtcNsdscMCVirmSwk9UXodqM99C7OQri3d3h5 A6ggqDJC0htsLj//dzZPDVwnOgkxh34V3jVFrR+0= To: Peter Todd From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com> In-Reply-To: <20180212225828.GB8551@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> 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: Tue, 13 Feb 2018 00:57:20 +0000 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:23:29 -0000 On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev 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 c= an do > that by simply creating a double-spend of T_a that pays both Bob and Alic= e, > T_{ab}. BIP125 only requires that double-spend to have an absolute fee hi= gher > than the minimum relay feerate * size of the transaction. It's a bit of a made up term, but when Russel said "pinned" it refers to a = child transaction that was made (i.e. in this case by Alice) and for us to= replace our transaction we need to "unpin" it. However to unpin it, the current bip125 rules require you pay not only the = relay of the transactions you're throwing away, but the absolute fee. This = is general is cost prohibitive, as even a normalish transaction can be spen= ding $20 in fees.=20 Also FWIW this whole idea of T_a and T_ab is good, but it's also pretty im= practical at the moment due to the sheer amount complexity it introduces (i= .e. monitoring, seeing which confirms, trying to rebroadcast the missing on= e in a way that is safe against reorgs, blah blah). > > I just checked one of my nodes, and the absolute minimum relay fee is abo= ut > 1/5th that of what estimatefee returns for the longest possible estimate,= 48 > blocks. If you use estimatesmartfee you should be able to get estimates all the way= to 1008 or something btw > [...] > I think this is very important. For example, without this condition I cou= ld do > a DoS attack by repeatedly broadcasting a transaction, then spending the > outputs of that transaction with a very large number of child transaction= s, all > of minimum fee.=20 I agree. > > A better way to solve this class of problems may be diffed tx replacement > propagation: basically broadcast a diff between the original tx and the > proposed replacement, allowing you to do the minimum bandwidth accounting= based > on the size of the diff instead. This would definitely work for some specific use-case. For instance current= ly if you do n replacements of a transaction, each time adding an additiona= l output .. you need to pay something like O(n^2) relay fee. If you used a = diff instead, you could probably get it to O(n)ish.=20 But relay fee (and n) at the moment, mean it's not a big deal at all. The b= ig flaw (imo) in bip125 is that you need to pay the absolute fee from the t= ransactions you are evicting. And that can be from transactions you didn't = even generate yourself. We can already compactly represent the diff (the = new transaction invalidates it) the debate is more "Should you have to pay= the absolute fee or just relay fee for the stuff you invalidate"