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 EDC0A11A9 for ; Thu, 1 Mar 2018 15:11:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net [62.13.148.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16F06473 for ; Thu, 1 Mar 2018 15:11:38 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w21FBaRF040046; Thu, 1 Mar 2018 15:11:36 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w21FBYnS014260 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Mar 2018 15:11:35 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 17E22400DE; Thu, 1 Mar 2018 15:11:34 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 0DB7F20639; Thu, 1 Mar 2018 10:11:29 -0500 (EST) Date: Thu, 1 Mar 2018 10:11:29 -0500 From: Peter Todd To: "Russell O'Connor" Message-ID: <20180301151129.GA9373@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: d556f859-1d62-11e8-9f3c-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgMUFVQGAgsB Am4bWlFeUVx7WmY7 bghPaBtcak9QXgdq T0pMXVMcUwdpd25o WH0eUx1wcQUIfnd4 Ywg2W3VdCkx/fFt8 FkhWCGwHMG99YTYc A11RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXEilL QxoMMVMUTg4hPwZ0 HkpfVQ8FMwUdQCEy JA1gQh+1 X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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, 01 Mar 2018 15:11:40 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: >=20 > > > > Ah ok, I misunderstood and didn't realise you were talking about the ca= se > > 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 spendi= ng > > unconfirmed outputs; with a restriction it's fairly simple to solve. >=20 >=20 > When you say that you don't think it is possible to solve, do you mean th= at > 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 with= in > 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. =2E..which does give you an out: maybe the attack isn't important enough to matter. :) --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqYGB0ACgkQJIFAPaXw kfv9hgf8DU1i+wq9/fT0bklFwNkolvZRrvl7z4A+G4J3toVNeaUHg0OP92G06tpf FrZqUPQModdVqdjCEUui66ZFgIMvXfsPd8UQ4txlcnUhrqOfYBLY+dJnpHpaxLnR Qvl2WSRJxNaSPtjNPw07OHEu++G/Ng/spqgyeO772gUPyENx7FNooWcssMHq175p 97NmMDPc9dLFRlPfIOIDCvRm280HfNTfRTAjFnwqqGEUKaEWLy8nCADtqpWe4yFu zP479GY2dpPJontmmRCLI0yvUOMfOjOhPDugsrVHQ8N7lA+KbcEc/ELQxwJ+dOkz WNeO5tJIN+yo8kWzx5PpP/FOpMe23A== =dLAk -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--