Date: Mon, 29 Jun 2015 21:37:36 -0400
From: Peter Todd <pete@petertodd.org>
To: Tom Harding <tomh@thinlink.com>
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)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
Precedence: list


--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--