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 E4BB3305 for ; Tue, 30 Jun 2015 01:37:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148154.authsmtp.co.uk (outmail148154.authsmtp.co.uk [62.13.148.154]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 442CB142 for ; Tue, 30 Jun 2015 01:37:42 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5U1bfQk048019; Tue, 30 Jun 2015 02:37:41 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5U1baPG098053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Jun 2015 02:37:39 +0100 (BST) Date: Mon, 29 Jun 2015 21:37:36 -0400 From: Peter Todd To: Tom Harding Message-ID: <20150630013736.GA11508@savin.petertodd.org> References: <20150629050726.GA502@savin.petertodd.org> <5591E10F.9000008@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <5591E10F.9000008@thinlink.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 987463ed-1ec8-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdQIUEkAaAgsB AmMbW1ZeU1p7XWM7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRlk B0xPMm5yfg1GfX0+ ZERqV3QVVUx9cUB+ FxpJFDhVbXphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL FQ4vNDcwO3BTJTpg CissFQBab1sPGnYG SggGFD4iWEcUAgs+ IlQqJ0YYG1cUP0Mu eUAqWV8ULhsfYgAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 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-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 01:37:43 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote: > On 6/28/2015 10:07 PM, Peter Todd wrote: > >Worryingly large payment providers have shown > >willingness(4) to consider extreme measures such as entering into legal > >contracts directly with large miners to ensure their transactions get mi= ned. > >This is a significant centralization risk and it is not practical or even > >possible for small miners to enter into these contracts, leading to a si= tuation > >where moving your hashing power to a larger pool will result in higher p= rofits > >from hashing power contracts; if these payment providers secure a majori= ty of > >hashing power with these contracts inevitably there will be a temptation= to > >kick non-compliant miners off the network entirely with a 51% attack. > > >=20 > Your incomprehensible meddling with successful usage patterns > threatens to have unintended consequences directly in opposition to > your own stated goal of decentralization. And yet you persist. >=20 > As we deliberately break things and turn the P2P network into a > completely unpredictable hodge-podge of relay policies, we should > expect many more participants to bypass the P2P network entirely. >=20 > Many of the pieces are already in place. >=20 > If we wanted the P2P network to have more predicable behavior, it > would be possible for nodes to provide incentives to their > neighbors. For example, if you had a pair of nodes, you could test > your peers to see that they actually do relay "standard" > transactions. This would have emergent usability benefits for the > P2P network as a whole. To be clear, full-RBF is a change that broadens what the P2P network relays - transactions previously not relayed are now relayed. Under no circumstance will full-RBF result in transactions *not* being relayed that previously were relayed. This makes the P2P network more useful rather than less, as it gives a predictable and uniform method to get transactions to a wider variety of miners with a wider variety of policies. Note how even if no miners ever supported full-RBF, supporting full-RBF on relay nodes would still be useful to users as it provides an easy and cost-effective mechanism to rebroadcast transactions. In fact, supporting full-RBF by default and disabling it if getblocktemplate is called would be reasonable, if more than a bit of a hack! In any case, my pull-req lets you set -fullrbfactivationtime=3D0 as a simple and easy way to disable full-RBF functionality. Miners and relay nodes who choose not to support it can easily do so, similar to how OP_RETURN transactions can be disabled with -datacarrier=3D0 --=20 'peter'[:-1]@petertodd.org 00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVkfLcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwYmZlOTMxODFhMTBlMmYxMmE0NWRhODc3YjUwMjZhZTI2 OTg4ZTkzNmExMzIyYWUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsKRggAueLctnjYJdbWjzjq0aEJqU71 llGRLJzBZVqcalZZ6d8fM2/ZCTAh8LXdblHvHJwC/H2AWaL64pqNdk5FQx9lf167 x4dRLs6pTeE55WkYLJ6XVREidJpRCmVXvvui3iAM2468CFapZV3i3+EMHYDw7CFF 46J5XQQpXhniI1b72fp/JgNBtvu8oYaApS18wldW8MCjgwVcXV73PHCSazUi6SiK dpNHiRPgTggvdKoikydGqQP7mbT/Mg/46x9UfeI2CqK7K0gRyblOAiWVPDIzIMXu aChgV/Zod7/B4eQ1ibubliO9zy7TT6l63jA3muzAcejvp2rZ5QnMa974ifB+Xw== =r0zf -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--