1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E4BB3305
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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)
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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--
|
