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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BCF3899
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 22:15:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4E206F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 22:15:35 +0000 (UTC)
Received: by mail-pg0-f44.google.com with SMTP id 21so21023156pgg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 15:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=RHdBrBqzgCO3D6U8mDOSGht/Y4lYgGmcm67hQu5XbXU=;
b=P40h9oC/c8RnDouVLUQQQJ3/Finm+lIf5FSNZBiMdCbZDxTSJWpwb2LRYv7xgu6hfU
VMyXINCBmhfVF4RffxRPoNfM7zGJNYEt6xohpGbbwnfj0mYZbszKUoU3rVNOz1wN5nfi
b927dx4F0zE6v0r63d02u7ozNPNxlg6jDWDvRuLvBKqVXBG5qILuB+f1tf9ideY9kZ+4
vQF0VAE93ZwZ4kd5QL4IvINkxKCslakPTc5N+dl9X0HryBk9yTd+rUAWGzAWFnNYCzML
FHnaW5vXE2MjlVxcO578G1XiIPuRjScDyCC0731w13Dx9FTqvOKmFym60qgkPuopyjXB
fDnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=RHdBrBqzgCO3D6U8mDOSGht/Y4lYgGmcm67hQu5XbXU=;
b=lSZ67Z7n4rZN8D3dEDBqLaGWZemUvMHWK5Eu6y41oD5VOt4PgF7jck8EPqh1blsjcj
p2AIdIfN6N+uW+TzuUO1KDUKzlKLXigWiOn0JhXpvtAZzWy0ATjyfLHAuT4X3Z4U5uXS
Ia+pVnO3TNY7hMaWfvstGmVIw7nVRYC4Iz7C3ITwOJmSj7hAhH5KoM7xIh70r02ogJoP
yZpFfE/oqLW4auz/X3YMcTsYHieqQnt2CFr9zLb0G5NU3NHCNPrsutzIwwCP5/C8zpkn
TMHn4aF/dAyxfuaIiNVQakrNAay/sVLjiNl+p59YPvpjDGI7/oz6WYzDh+mOhSK+Duf1
nHwA==
X-Gm-Message-State: AFeK/H0eQpZr4k2vGcBPVbqshT19EzXaHkr40+QDvZ4e5S38OdVvGs46M7YjaVYUsGLEbQ==
X-Received: by 10.98.133.133 with SMTP id m5mr21462593pfk.146.1490566534748;
Sun, 26 Mar 2017 15:15:34 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:9053:3eee:f863:4f1c?
([2601:600:9000:d69e:9053:3eee:f863:4f1c])
by smtp.gmail.com with ESMTPSA id
l28sm16695312pgc.11.2017.03.26.15.15.33
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 26 Mar 2017 15:15:33 -0700 (PDT)
To: Peter R <peter_r@gmx.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Alex Morcos <morcos@gmail.com>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
<35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com>
<f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
<9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
<CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
<9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <b7ff549b-5ee8-172d-5a23-47ef8943533e@voskuil.org>
Date: Sun, 26 Mar 2017 15:15:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 26 Mar 2017 22:18:22 +0000
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
malicious miner takeover?
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: Sun, 26 Mar 2017 22:15:36 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
Peter,
> Yes, it is different. It’s different because the future network
> upgrade to larger blocks includes a loosening of the consensus
> ruleset whereas previous upgrades have included a tightening of the
> rule set. (BTW—this is not my proposal, I am describing what I
> have recently learned through my work with Bitcoin Unlimited and
> discussions with miners and businesses).
The repeated use of the term "network upgrade" in place of the
accepted technical term (hard fork) is misleading. This and the
presupposition that the hard fork is coming, and the claims that it's
not your proposal, make me feel like I'm shopping for a used car...
It's not used it's pre-owned, everyone's getting the warranty, let me
see what my manager has to say about the price - it's not my decision.
This is a development list. Avoidance of standardized terminology and
use of the presumptive close diminishes your message.
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
"tightening of the rule set" == soft fork
This implies that the minority hash power is producing blocks that are
valid according to rules in existence prior to the soft fork. You are
referring to these as invalid, but because this has already confused
one commentator, let's be clear. The blocks you are referring to are
valid blocks being orphaned because the majority hash power is
rejecting them because of soft fork activation. This of course
produces a minority chain, so this statement is incorrect.
> With a loosening of the consensus rule set, the situation is
> different: a hash power minority that has not upgraded will produce
> a minority branch, that will also drag along non-upgraded node
> operators, leading to potential confusion.
"loosening of the consensus rule set" == hard fork
This is also incorrect. In the case of a hard fork old nodes reject
the new blocks that are invalid according to old rules and continue to
accept other old blocks. This produces a second distinct chain. It is
neither a majority nor a minority chain with respect to the original.
It is simply a new coin that happens to share history with the old
coin. This doesn't imply confusion, since both chains continue to
operate under the rules of their nodes. The only confusion arises from
people wanting to transaction across *both* chains. It is only in this
context that replay becomes an issue.
> The idea behind orphaning the blocks of non-upgraded miners was to
> serve as a wake-up call to upgrade, to reduce the chances of a
> minority chain emerging in the first place, similar to what happens
> automatically with a soft-forking change. If one's worry is a
> chain split, then this seems like a reasonable way to reduce the
> chances of that worry materializing. The Level 3 anti-split
> protection takes this idea one step further to ensure that if a
> minority branch does emerge, that transactions cannot be confirmed
> on that branch.
Stopping people from transacting on the old chain due to an ongoing
51% attack (again, using proper terminology) is one way to make it
hard for people to transact on both chains. But if you don't care that
people are able to transact on both chains, there's no reason to spend
the money on the attack.
So let me point to the elephant in the room. The proposed 51% attack
is more obviously an attempt to transfer economic activity from BTC to
BTU, not a benevolent measure to prevent confusion. It can clearly be
viewed as elimination of competition through an electronic attack on
BTC operations. Given that they are all regulated entities, I'm not
sure how the envisioned large miner collaborators (or others who might
fund it) will feel about participation in the scheme.
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one
> of “genetic diversity” with multiple implementations, so that a bug
> in one doesn’t threaten the network as a whole
You are right that this is not about Core and BU. These are
implementations, not protocols. However, please do not presume that
other implementations are enlisted in your scheme, or that this is
about making the network more bug-resistant.
> To me it seems this is largely a fight about whether node operators
> should be easily able to adjust the size of blocks their nodes
> accept. BU makes it easy for node operators to accept larger
> blocks; Core doesn’t believe users should have this power (outside
> of recompiling from source, which few users can do).
I feel like making the block size a configuration option in Libbitcoin
just to emphasize the gross error of this idea. It has never been
about the inability of users to compile the code. It's about the
purposeful difficulty in changing the rules when everyone has a say.
> Once again, this is not my proposal. I am writing about what I
> have come to learn over the past several weeks. When I first heard
> about these ideas, I was initially against them too. They seemed
> harsh and merciless. It wasn’t until I got out their and started
> talking...
The idea was so powerful you were converted (another sales tactic).
Who's proposal is this? Can they not speak for themselves?
> So I guess the “ethics” here depend on the lens through which one
> is looking...
These are not ethical questions. These are development questions,
built on economic concepts, backed by individual financial decisions.
There is no equivalence of ideas based on one's arbitrary perspective.
> But if one's intention is to split and not follow the majority
> hash power when blocks become larger,
The "split" is always by the one that hard forks. The splitter is the
one who changes what exists and therefore creates something new.
Please fix your terminology.
> then why not change the proof-of-work? This would certainly result
> in a peaceful splitting, as you said you desire.
A hard fork, including changing the PoW algorithm, requires the
purposely improbable coordination of the economy in the creation of a
new coin and the abandonment of the old. This should be apparent from
the ongoing block size hard fork attempts.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2D2SAAoJEDzYwH8LXOFO3r0H/R0PTi2x15Zj1oceOqcNpP4k
/TrTohFl/BRE4PaOqJ9n9DbJ6W8rnAjRnguOIgOB1CSIRCuy73AQ4aqRSTCBlHbe
VVrlKKFS8zh50Cjg8tlnomWeKe1YDO31R2Avises+Dr3kyqQ9+QYtOoqxvuvYrXo
B03fjPIL0eTQypA4KP/W7CxrlHN7oyN+PtehpI51JOGMxx6Xc0RDelGz1NTlQQ1f
90Axeey51tgAzJ8wsC+Vf22hZdU06VDdtG8PSHVcrELoicDnEjR4T+1XqA1hcAY2
hWBX5qpQYJqJv1ypfTH0ouh6QtLhJZGCWzKZnpH+T7d3FUG+AXn0UjTP3Nkh7NY=
=Cc8r
-----END PGP SIGNATURE-----
|
