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 1D9C7E43 for ; Thu, 8 Mar 2018 15:40:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f67.google.com (mail-it0-f67.google.com [209.85.214.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02AFB5CD for ; Thu, 8 Mar 2018 15:40:07 +0000 (UTC) Received: by mail-it0-f67.google.com with SMTP id c11so8100025ith.4 for ; Thu, 08 Mar 2018 07:40:07 -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=GU7bU9UuIpQGH7fh8kX11CgT+PMjnaIGFNiAWXvboAo=; b=1JzrAD+brGdNStRB2ED2E141wR5UIopDwK0gsEA2hLD5aRoMUjfD0H6LzMKIF7jSSM ra6XMNSaMfdMoo+YS4528bvIk4y8yWTs5o14TQC0E1OLz9keqNMvUBuk2+IIJvEYqb8p KsFVYIjGPGNn+zXrkmWzo5PWuA0tJIsfh52Cc= 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=GU7bU9UuIpQGH7fh8kX11CgT+PMjnaIGFNiAWXvboAo=; b=NPf3YVjoU1lDt+qTwGcclZaxPFKUn2ezHgfyc8aqZMjNyMMZbkfXeUh4B41tJDjlth mh3oW3IiqHiotKeYRrfyTcPtqoDSydzFzdX7yrlmWWIX+dTLZG5AW0JjQV7LxvLejWyM eUuWOCGhJnBSNdtNn0GkTfKvPKRR+Mk35vhJIyER71e8GeqRuE06zl56sCAQ+V8I52aC FigH1w92u/waTnk4duk6Ie3GwkGEiE4DHNfpVLb9JHmfDmamZa80XyQixNxAuVIA52on tAa/LDMLB2W01r7znhGUGKKo5VPc+z/FCyDuriYEKLpn35T/Dw5v0cQUSZ8NjpJ7FBSK NmZA== X-Gm-Message-State: AElRT7ErHZB71vFBueO+4GWgXDmdzMuxSIdRV6HYPgUk7wvfzfsJUN87 28GMU0Nkfgj8Lup2O7YQ36S6jTzjiVoGZjexz/Pt0oGQ X-Google-Smtp-Source: AG47ELuGrShpOsOQbHYIjP9b1PN/SiFhYWA/dZACmYTD2pLCBoRBl9H11UVi7L29AgqCkqLGS+MYoyatsTfrqoGx0xM= X-Received: by 10.36.67.1 with SMTP id s1mr14432686itb.145.1520523607278; Thu, 08 Mar 2018 07:40:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.166.10 with HTTP; Thu, 8 Mar 2018 07:39:46 -0800 (PST) In-Reply-To: <20180301151129.GA9373@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> <20180301151129.GA9373@fedora-23-dvm> From: "Russell O'Connor" Date: Thu, 8 Mar 2018 10:39:46 -0500 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="001a11441cf27c61180566e87d69" 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: Thu, 08 Mar 2018 15:40:09 -0000 --001a11441cf27c61180566e87d69 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote: > On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote: > > 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? > > I mean, I think in general solving this problem is probably not possible. > Basically, the fundamental problem is someone else has consumed network > bandwidth that should be paid for with fees. What you're trying to do is > replace a transaction without paying those fees, which is identical to > what an > attacker is trying to do, and thus any such scheme will be as vulnerable to > attack as not having that protection in the first place. > > ...which does give you an out: maybe the attack isn't important enough to > matter. :) > Thanks, that makes sense. I still think it is worthwhile pursuing this proposed change in RBF policy as it would seem that the current policy is problematic in practice today where participants are just performing normal transactions and are not trying to attack each other. --001a11441cf27c61180566e87d69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete@petertodd.org>= wrote:
On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Conno= r wrote:
> 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 transactio= ns
> 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)?=C2=A0 Is your concern only ab= out the
> ability to computing and track the package fee rate for transactions w= ithin
> the mempool or is there some other issue you foresee?

I mean, I think in general solving this problem is probably not= possible.
Basically, the fundamental problem is someone else has consumed network
bandwidth that should be paid for with fees. What you're trying to do i= s
replace a transaction without paying those fees, which is identical to what= an
attacker is trying to do, and thus any such scheme will be as vulnerable to=
attack as not having that protection in the first place.

...which does give you an out: maybe the attack isn't important enough = to
matter. :)

Thanks, that makes sense.

I still think it is worthwhile pursuing this proposed change in RBF polic= y as it would seem that the current policy is problematic in practice today= where participants are just performing normal transactions and are not try= ing to attack each other.
--001a11441cf27c61180566e87d69--