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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 65A9A360
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 22:29:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com
[209.85.128.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46944FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 22:29:50 +0000 (UTC)
Received: by mail-wr0-f174.google.com with SMTP id o21so54801782wrb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Apr 2017 15:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=232JLPXKOBXUMhdDHiet/76nd6mz1dyTMu20cfSK4iU=;
b=PDF9cYGTiz/TxhTWWnyzrUWuS7hqlEnkIlWZF59wFnRAh4qaBLzFFGcQgSeYXiE/JS
XBsnm2LNwLm2oW7BzJqv5VPo3ugilqfvhXETC2lIlXfOz+siuCjD7g0orfMHm2bzcWFB
uUlomn/Dlen5vUhCYQsNuPaMXCjrlshLZKS9Se0Nxv4JXWJnpir/Yysl6Zq8+FGJ2KSe
DuPKKtKyLINC5IQn8fHqLJ9pHIhvrQVBg6/Y+EvMro7J7V5ymliOBpKjfzvOWir92RA7
QQP5CKP1OLB5e+o2pjD2VbEwQzgsn9t6IB23UgsKHeia1hQSoJ51ZhZW6ysN77ZtfYuj
mS2g==
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;
bh=232JLPXKOBXUMhdDHiet/76nd6mz1dyTMu20cfSK4iU=;
b=MFAAzcqCcqtHqjmO+ePrrPPJmn9ZeyDp8s3A0+R60JjZxmsNYKiYwi4o5O64PQsVYs
vRT+jjnEYo/twMBgf+R3v+LM/xXNxx13Bw6P3g3226Sg5NJxLTDnotLWX6nEeIV5za/7
71cNVCRLf+JwWd75C6FUK0REV775SDvtMA3x3SCzyeApHFYBsyerAJmrWVg+ojx3lp4U
jYk4ikPmF7MhKbFcsp0fhFnnZV9p1c9kXVUOqY0e2WhF2K+6jcDIvNUoXrt/ymh5FBPp
z0RaaEZtiXFwaCR0PDPKI1AXzmTAKV/Lafr/3ghIjLZQ6sHih8cPiZsur670eTSvcDBS
f/Hg==
X-Gm-Message-State: AFeK/H1DXWM9qO8JAHz7A+Sdyqy1d1xanGDmgL8v9wjlgJbj5sCGjJ3gBfTxBWsn5BWQfw==
X-Received: by 10.223.139.146 with SMTP id o18mr32499417wra.61.1491517788683;
Thu, 06 Apr 2017 15:29:48 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-67-220.w83-201.abo.wanadoo.fr.
[83.201.94.220]) by smtp.googlemail.com with ESMTPSA id
m90sm3954460wmi.34.2017.04.06.15.29.47
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 06 Apr 2017 15:29:48 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
<CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com>
<CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <ccf46d59-e6a1-a8a8-7e6a-dc6e8880992a@gmail.com>
Date: Fri, 7 Apr 2017 00:29:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------20FA4C7190FCBB1FA9B5F193"
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
Comments
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: Thu, 06 Apr 2017 22:29:51 -0000
This is a multi-part message in MIME format.
--------------20FA4C7190FCBB1FA9B5F193
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Not sure to get how you are answering the question
> If the original blockchain hard-forks to re-adjust the difficulty,
then it will just represent an alt-coin having 5% of Bitcoin community,
and it can't affect Bitcoin (the segwit2mb fork).
destroys the whole thing
Because if the nodes don't upgrade and just implement the patch to
adjust the difficulty, what happens? You get a 95% mining power chain
with "no" nodes and a 5% one with "all" the nodes
I really don't get in all those discussions why the nodes are always
disconsidered compared to the miners, ie why they seem to be of zero
importance and are supposed to obey whatever you ask them
And apparently the trend is not going to revert if we look at the
priority features sent in the asicboost thread where motivating and
scaling full nodes is still something you need very powerful glasses to
see coming
Le 06/04/2017 à 22:42, Sergio Demian Lerner via bitcoin-dev a écrit :
> The 95% miner signaling is important to prevent two Bitcoin forks,
> such as what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that
> has just 95% miner support will initially (for 2016 blocks) be 5%
> slower (an average block every 10 minutes and 30 seconds). The
> transaction capacity of the new Bitcoin protocol is reduced only 5%.
> However the chain with 5% if the hashing power not only has a 20x
> capacity reduction, but confirms transactions in 20x more time. So the
> mempool will grow 400 times. It must be noted that fees increased 10x
> from the moment blocks were half full, to the moment blocks became
> saturated. I'm sure no Bitcoin (pre-fork) user will be willing to pay
> 100x times the transaction fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and
> the original chain will be in this almost useless slow state for an
> average of 2016 blocks, or 280 days.
> If the original blockchain hard-forks to re-adjust the difficulty,
> then it will just represent an alt-coin having 5% of Bitcoin
> community, and it can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak@gmail.com
> <mailto:btcdrak@gmail.com>> wrote:
>
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> The hard-fork is conditional to 95% of the hashing power has
> approved the segwit2mb soft-fork and the segwit soft-fork has
> been activated (which should occur 2016 blocks after its
> lock-in time)
>
>
> Miners signalling they have upgraded by flipping a bit in the
> nVersion field has little relevance in a hard fork. If 100% of the
> hash power indicates they are running this proposal, but the nodes
> don't upgrade, what will happen?
>
> For the record, I actually talk a lot about hard forks with
> various developers and am very interested in the research that
> Johnson in particular is pioneering. However, I have failed to
> understand your point about 95% miner signalling in relation to a
> hard fork, so I am eagerly awaiting your explanation.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--------------20FA4C7190FCBB1FA9B5F193
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Not sure to get how you are answering the question</p>
<p>> If the original blockchain hard-forks to re-adjust the
difficulty, then it will just represent an alt-coin having 5% of
Bitcoin community, and it can't affect Bitcoin (the segwit2mb
fork).</p>
<p>destroys the whole thing<br>
</p>
<p>Because if the nodes don't upgrade and just implement the patch
to adjust the difficulty, what happens? You get a 95% mining power
chain with "no" nodes and a 5% one with "all" the nodes</p>
<p>I really don't get in all those discussions why the nodes are
always disconsidered compared to the miners, ie why they seem to
be of zero importance and are supposed to obey whatever you ask
them</p>
<p>And apparently the trend is not going to revert if we look at the
priority features sent in the asicboost thread where motivating
and scaling full nodes is still something you need very powerful
glasses to see coming<br>
</p>
<br>
<div class="moz-cite-prefix">Le 06/04/2017 à 22:42, Sergio Demian
Lerner via bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>The 95% miner signaling is important to prevent two Bitcoin
forks, such as what happened with Ethereum HF and Ethereum
Classic.</div>
<div><br>
</div>
Bitcoin has a very slow difficulty re-targeting algorithm. A
fork that has just 95% miner support will initially (for 2016
blocks) be 5% slower (an average block every 10 minutes and 30
seconds). The transaction capacity of the new Bitcoin protocol
is reduced only 5%.
<div>However the chain with 5% if the hashing power not only has
a 20x capacity reduction, but confirms transactions in 20x
more time. So the mempool will grow 400 times. It must be
noted that fees increased 10x from the moment blocks were half
full, to the moment blocks became saturated. I'm sure no
Bitcoin (pre-fork) user will be willing to pay 100x times the
transaction fees to use such a slow and insecure network.</div>
<div><br>
</div>
<div>So a 6-block confirmation will take 20 hours in the
original chain and the original chain will be in this almost
useless slow state for an average of 2016 blocks, or 280
days.
<div>If the original blockchain hard-forks to re-adjust the
difficulty, then it will just represent an alt-coin having
5% of Bitcoin community, and it can't affect Bitcoin (the
segwit2mb fork).</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, Btc
Drak <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:btcdrak@gmail.com" target="_blank">btcdrak@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Fri, Mar 31,
2017 at 10:09 PM, Sergio Demian Lerner via
bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>The hard-fork is conditional to 95% of the
hashing power has approved the segwit2mb
soft-fork and the segwit soft-fork has been
activated (which should occur 2016 blocks
after its lock-in time)</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Miners signalling they have upgraded by flipping
a bit in the nVersion field has little relevance in
a hard fork. If 100% of the hash power indicates
they are running this proposal, but the nodes don't
upgrade, what will happen?<br>
</div>
<div><br>
</div>
<div>For the record, I actually talk a lot about hard
forks with various developers and am very interested
in the research that Johnson in particular is
pioneering. However, I have failed to understand
your point about 95% miner signalling in relation to
a hard fork, so I am eagerly awaiting your
explanation.</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>
--------------20FA4C7190FCBB1FA9B5F193--
|
