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
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC1974A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 20:33:55 +0000 (UTC)
X-Greylist: delayed 00:05:04 by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6357118A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 20:33:54 +0000 (UTC)
Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx001
[212.227.17.184]) with ESMTPSA (Nemesis) id 0LqylH-1cDqW43kzj-00eblM;
Sat, 25 Mar 2017 21:28:48 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
Date: Sat, 25 Mar 2017 13:28:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.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>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:VjSSe95/B1INjwMMhfQZYHKiqyhZ5lUZCziF5ietTg2irVFYWSG
UkJzdSHyBeA2if+AN8uOj6UghWUXq38Dchzawd/3zbyMY9qJpd2Ki905aqLUo+wHGFl/KKN
LudCEFsjO2Bntc2lcSv3NkEbrPGoNWqTvSTP5TrHG9h01BdmxnRB37Wb4LLGZzQuOS0Ocwk
mUCsmWkx46jjOGK0WH4dQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Q1B3TRxz1AY=:JjXAye0BLc/hecCkgU78Ke
YflUJjMYOsqjRIe0UVp5x7Jct0HQjn8m+QGcaAc2n3J8X2r8g/GNh+ULsU26KKkBtYgt3JEyT
c0hnf6fc5nAoI5+7zrmulxcK03O97wbXva42xrj8SiXW/3WDe9X/riotBr0C6i20KXWaIfCAT
d06CjWiNcTR15z0X4+wRAZhQInoz6enX3DANxedpy/7mmyF9AsmMgvPgzbLqu7ekM7j0UWKHb
tUqMoZcZ5zSSlBX6/jbPdW7W3ThdNfdbVTbHG5+NQOQKl7rv8OuQy87f2+6pD7ABNsDDLOFwL
tZKidxy7OO7MLUW0b3MDJ2hQDqFwjxq164r/CgObLZovvOoOnp/pmf8RKzgGox9uoYD1niJFT
2iAQSEo5r8zIHLEbOD/rjvyMw1FP/RZMhAf/H7oDBkVsxLyO1IvaMko1SFpgLZJNh0CyEtqMy
Nqv278gZktaV6YnXZAguFi5d4KkL9IzkAqpas833XRvu71G9PO8eyohvP1PrmMhBWso+qfnXk
VyWndj0Gsy05C0w22HuGg4dqmMp44hkAHu8Pm2gjHjduarbnvREeGews6rLVrYT6lo0khRvJQ
Dr5YhWncn0dbdQIhnAe2Wyof89CIeqxCEjtWU+Nto1/TbcmQHI8TahVUwqAc7kEyceMOLjr7M
C5/bP9B6ax5+ISHSfMfoJpL28ikOQMM+kCRk0O0AFO6IV556UzT3ePOdtJYvWlWn9wdzVWsyO
/2dbLU4GuHEcxm/1dwcifhT6v/iQA0bFw1j8j9iEcHC/HRGcx0buD1Tb9MCoPeHISIJloEisP
p7MweUD
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
LOTS_OF_MONEY, RCVD_IN_DNSWL_LOW,
T_MONEY_PERCENT 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: Sat, 25 Mar 2017 22:54:17 +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: Sat, 25 Mar 2017 20:33:55 -0000
One of the purported benefits of a soft-forking change (a tightening of =
the consensus rule set) is the reduced risk of a blockchain split =
compared to a loosening of the consensus rule set. The way this works =
is that miners who fail to upgrade to the new tighter ruleset will have =
their non-compliant blocks orphaned by the hash power majority. This is =
a strong incentive to upgrade and has historically worked well. If a =
minority subset of the network didn=E2=80=99t want to abide by the new =
restricted rule set, a reasonable solution would be for them to change =
the proof-of-work and start a spin-off from the existing Bitcoin ledger =
(https://bitcointalk.org/index.php?topic=3D563972.0).
In the case of the coming network upgrade to larger blocks, a primary =
concern of both business such as Coinbase and Bitpay, and most miners, =
is the possibility of a blockchain split and the associated confusion, =
replay risk, etc. By applying techniques that are known to be =
successful for soft-forking changes, we can likewise benefit in a way =
that makes a split less likely as we move towards larger blocks. Two =
proposed techniques to reduce the chances of a split are:
1. That miners begin to orphan the blocks of non-upgraded miners once a =
super-majority of the network hash power has upgraded. This would serve =
as an expensive-to-ignore reminder to upgrade.
2. That, in the case where a minority branch emerges (unlikely IMO), =
majority miners would continually re-org that minority branch with empty =
blocks to prevent transactions from confirming, thereby eliminating =
replay risk.
Just like after a soft forking change, a minority that does not want to =
abide by the current ruleset enforced by the majority could change the =
proof-of-work and start a spin-off from the existing Bitcoin ledger, as =
suggested by Emin. =20
Best regards,
Peter R
> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> I don't know what "Time is running short I fear" stands for and when =
50%
>> is supposed to be reached
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> "Time is running short I fear" stands for and when 50% > is supposed
> to be reached
>=20
> According to current hashrate distribution tracking site coin.dance,
> very likely within less than four weeks according to current hashrate
> takeover rate.
>=20
> While a fork is very likely, that I dont really fear because worst
> case scenario is that bitcoin still survives and the invalid chain
> becomes an alt. My fear is the centralized mining power being used
> to attack the valid chain with intentions on killing it. [1]
>=20
> Shouldn't this 50% attack they are threatening be a concern? If it
> is a concern, what options are on the table. If it is not a concern
> please enlightent me as to why.
>=20
>=20
> [1] Source:
> =
https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_=
to_force_a_hard_fork_by/
>=20
> Text:
>=20
> The attack quoted from his article:
> =
https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-b=
lock-size-limit-insights-from-my-visit-with-2348878a16d8
>=20
> [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners will orphan =
the
> blocks of non-compliant miners prior to the first larger block
> to serve as a reminder to upgrade. Simply due to the possibility
> of having blocks orphaned, all miners would be motivated to
> begin signalling for larger blocks once support definitively
> passes 51%. If some miners hold out (e.g., they may not be
> paying attention regarding the upgrade), then they will begin
> to pay attention after losing approximately $15,000 of revenue
> due to an orphaned block.
>=20
> [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn the scenario =
where Levels
> 1 and 2 protection fails to entice all non-compliant miners to
> upgrade, a small-block minority chain may emerge. To address the
> risk of coins being spent on this chain (replay risk), majority
> miners will deploy hash power as needed to ensure the minority
> chain includes only empty blocks after the forking point. This
> can easily be accomplished if the majority miners maintain a
> secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt off their last =
empty
> block=E2=80=8A=E2=80=8Apublishing only as much of this chain as =
necessary
> to orphan any non-empty blocks produced on the minority chain.
>=20
>=20
>=20
>=20
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832=20
> Email: cannon@cannon-ciota.info
>=20
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD=20=
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.=20
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>=20
> iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> /T93MuZgmvSCry5MlccA
> =3DR71g
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
