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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1671BA5E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 20:43:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com
[209.85.220.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96DF8151
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 20:43:00 +0000 (UTC)
Received: by mail-qk0-f170.google.com with SMTP id f133so30747199qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Apr 2017 13:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=HzeA7Z2QK7nFK5/ixhaY9nRzrN24UmJr74jl8278KQE=;
b=qxpJG70nb3KnAJFa9y1xVp+oLkqKN8KPxB0chVWeA6EGlDhC3CGUe/VKL9/sQbaylH
kdq2mHIgzjGNy8u6Kuo4CCuiIE/yCH5NrYQo20wWhbb00T2Y5tOByCaVBtLCNfYv/QiW
exwPVatyLCzDhFHpntOD/o0yGnxZAYVItmejMr6+fHj81+tApxaNxM0NympXSbETdpPj
/Cd3mOaGya4im/l6cway0k7xqdblzMHvhfiLO2J1VvZiWcSGTyiJsjWHD3VuTiE+57PH
7I9JTKcemvnO0fO28pQszOpGR3m/ceA2QW8LtmSHuqVX1FospriS27gh7AlwcHLkvw8n
vK2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=HzeA7Z2QK7nFK5/ixhaY9nRzrN24UmJr74jl8278KQE=;
b=KJsFyTjUilgml5KLYMU+9nA6SBoSPq5FCk3HmIynu83bf/LcmqEvgivMyDtY/Kl7Ms
LwwsMvABpzErSh7tsJccIG+Hw48ysEcAGwS14Isbji2Eo7oQFzJlQVXO4EQo+tk6Yl0T
VqY8zgP4E2jfl26aQC3zIVs0VOVdFSFY60Nh7UNnHMcFbFMmmLn3o/YQ/SG2NsxHYJ6i
1FYZQ5wJghRedZtI/XUwfKF9WtvkgNiMk3CVFL5BNhc68LtwDYQr4E7aIdQ8E60PMRLN
pJyvJ4tHxF7qJLxp19AJOXJrRd5zVG5m3oInxMJ6nKbrbqQy6TwTcE/wru8ZQr9Bx9Mm
ip9g==
X-Gm-Message-State: AFeK/H2MYoNP8anTJ3dyCdoY12XOtxi9u8K8NVSd3EzxVUPn1T7l7d5KCclvn/bipgQMD1bXxGbo3R+CAP5Udw==
X-Received: by 10.55.22.95 with SMTP id g92mr26832241qkh.87.1491511379732;
Thu, 06 Apr 2017 13:42:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.170.220 with HTTP; Thu, 6 Apr 2017 13:42:19 -0700 (PDT)
In-Reply-To: <CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
<CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 6 Apr 2017 17:42:19 -0300
Message-ID: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=001a1147b01ef7b169054c858df5
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 20:43:01 -0000
--001a1147b01ef7b169054c858df5
Content-Type: text/plain; charset=UTF-8
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> wrote:
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> 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.
>
--001a1147b01ef7b169054c858df5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The 95% miner signaling is important to prevent two B=
itcoin forks, such as what happened with Ethereum HF and Ethereum Classic.<=
/div><div><br></div>Bitcoin has a very slow difficulty re-targeting algorit=
hm. 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 trans=
action capacity of the new Bitcoin protocol is reduced only 5%.=C2=A0<div>H=
owever the chain with 5% if the hashing power not only has a 20x capacity r=
eduction, but confirms transactions in 20x more time. So the mempool will g=
row 400 times. It must be noted that fees increased 10x from the moment blo=
cks 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 f=
ees 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 origi=
nal chain will be in this almost useless slow state for an average of 2016 =
blocks, or 280 days.=C2=A0<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=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <span dir=3D"ltr">&=
lt;<a href=3D"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fr=
i, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The hard-fork is=
conditional to 95% of the hashing power has approved the segwit2mb soft-fo=
rk and the segwit soft-fork has been activated (which should occur 2016 blo=
cks 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 indica=
tes they are running this proposal, but the nodes don't upgrade, what w=
ill 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 t=
o understand your point about 95% miner signalling in relation to a hard fo=
rk, so I am eagerly awaiting your explanation.</div></div></div></div>
</blockquote></div><br></div>
--001a1147b01ef7b169054c858df5--
|
