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
150
151
152
153
154
155
156
157
|
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 DAECA2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 12:49:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148106.authsmtp.co.uk (outmail148106.authsmtp.co.uk
[62.13.148.106])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86610F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 May 2017 12:49:00 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v4DCmsFL075243;
Sat, 13 May 2017 13:48:54 +0100 (BST)
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.14.2/8.14.2/) with ESMTP id v4DCmqdH005571
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 13 May 2017 13:48:53 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id D7E3D4008E;
Sat, 13 May 2017 12:48:51 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id E897720486; Sat, 13 May 2017 08:48:48 -0400 (EDT)
Date: Sat, 13 May 2017 08:48:48 -0400
From: Peter Todd <pete@petertodd.org>
To: Luke Dashjr <luke@dashjr.org>
Message-ID: <20170513124848.GC8884@fedora-23-dvm>
References: <201705121922.57445.luke@dashjr.org>
<20170512222214.GA4462@fedora-23-dvm>
<201705130049.33798.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/"
Content-Disposition: inline
In-Reply-To: <201705130049.33798.luke@dashjr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 8551e5ae-37da-11e7-829f-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwEUFVQNAgsB AmEbWldeVFV7XGA7 bghPaBtcak9QXgdq
T0pMXVMcUgEcckFA UmYeUhx3cAQIeXx2 Y0AsVnVeXRF/JBNg
QUkARHAHZDJndWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYA50 elNFB1YVSkVDBT8z QRkGVTgpE0ofTCg2
Iho6YkAdFQ4NIg08 PFY6Mf9/
X-Authentic-SMTP: 61633532353630.1037: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-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 13 May 2017 12:49:02 -0000
--GZVR6ND4mMseVXL/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, May 13, 2017 at 12:49:33AM +0000, Luke Dashjr wrote:
> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> > nVersion signaling is already technically unenforceable, in the sense t=
hat
> > we don't have good ways of ensuring miners actually adopt the rules
> > they're claiming to signal. Equally, it's users who ultimately adopt
> > rules, not miners, and attempting to pay miners to signal certain bits
> > will further confuse this point.
>=20
> This BIP doesn't change that. Enforcement remains primarily by users.
I'm not arguing that it changes that; I'm arguing that it further confuses =
the
situation.
> > Quite likely the outcome of users trying to anonymously pay anonymous
> > miners to signal certain bits will be the complete breakdown of the
> > honesty of the nVersion signalling system, currently enforced only by
> > "gentlemans agreement".
>=20
> You assume users will pay for signalling of softforks prematurely. So lon=
g as=20
> it waits until deployment of the softfork is widespread, this risk is min=
imal.=20
> At worst, it creates risks similar to a UASF. So long as UASF is the=20
> alternative, this way seems strictly better.
I think you're assuming that the users paying for soft-fork signalling will
represent an economic majority; that's not necessarily the case.
For example, if miners decide there's no downside to false signalling, they=
may
take the extra fees provided by 1% of the users paying to signal a fork, wh=
ile
the other 99% don't participate, resulting in a situation where we have blo=
cks
violating the nVersion protocol, and an unknown % of that 99% rejecting tho=
se
blocks. At best that'd be no worse than a UASF, and at wost you're wrecked =
the
validity of the nVersion "gentlemans agreement"
> > Also, as an aside, this "specification" again shows the inadequacy and
> > unreadability of English language specifications. I'd strongly suggest =
you
> > delete it and instead mark the "reference implementation" as the
> > specification.
>=20
> How so?
Just read it: you have ten separate lines of dense English text describing
something that could have been specified instead by ten lines of much more
formally defined C++. In particular, note how many of those lines of English
text refer to C++ code anyway, like the sentence "minimal-length 40-bit
CScriptNum"
I don't want to have to learn another language - formally defined English t=
hat
still fails to be formally defined - just to read Bitcoin's specification.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--GZVR6ND4mMseVXL/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZFwCvAAoJECSBQD2l8JH7BvoH/3FyKbT2CB4HCYFMtJc4uaOm
IfSgU+EKGJYs37nnQyaovBCUeTory/1rB6hfy0T4e9aOzLuqdtsgP+qIPRrvJ0xy
q+/rIrSM7l2w0hCE56hz0QW7OgW6og5vFq3U5GNONXEMBD2uwFSE26BVB5h2yU41
V4WVEYqsELnoYEO1ZB32Hsk+nxiM4GZ2IXObnxnNG70eM/YBdMgIszjzMwMvoP+m
JHwSJpegCFl1rQCWOsL94L7BkaZ/9p2YWLwirtVKLRzUAFS0MHDtoRErmuGETZ0X
ghdBBnUR5kGimzLDKG1H0lsYEwI8Y9ToDmrnd6eB+jnm1AdsPocSIinhj2HI+BQ=
=/J+C
-----END PGP SIGNATURE-----
--GZVR6ND4mMseVXL/--
|
