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
|
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 0CF14720
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 21:03:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com
[209.85.220.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7AA5A20F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 21:03:53 +0000 (UTC)
Received: by mail-qk0-f173.google.com with SMTP id h67so48537854qke.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Apr 2017 14:03:53 -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=Zt+5gSPkEP6X1ACrOQ+ISuO9Nzrd454oaua+1xZp9RU=;
b=Uxg71KpAX3xqpmCJm4rPWlm2NLNuRItxWzW83pbpD0GbdtZtiM0kBKz1A8xItWkPAO
OiKDMz9cdfqn25tTgpJfIgJwHSDODWKpkoJjQMU8rTofxUFS4IB/JBADJdzeMzGYXeLP
wIdTU45kKHwnEgMeFTkSldqKtpFXbBhyAqkbJAxQ1h2q61Sce0DwRNFTCiYmA6vpQN56
gPEUyHZ+fLYr939gvCaaL5VvL6IxBAPbv34792xLt11vluLiPXi9o3qn1HPc4AcYkD0s
cszOGJQo61D3xQPSiYoxr9cXFMbr4J2FET6FT5lxjwb1HajSRrjNkAiDx5Gy1lYHzNWo
/CjA==
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=Zt+5gSPkEP6X1ACrOQ+ISuO9Nzrd454oaua+1xZp9RU=;
b=j/vvBMSpeM7hPzwh5Mol0d51PHht+z19inKHQ3VERxZ1Z7LgRMuBFlkZ33XhSmmq3o
NKP4eukaX2o5dIbry4wxSJ8vKw8V9LXrZTuszwpt9jMkAdff4hKyOTXd2yJeyadGgusL
wrrYn45tUKHFpzX6zUEJ6c7hf0FbR+adCtYc9RHft3MfBPw/oUf0IPp9cfMXW3h2NNDx
4Rr+yiOMl58XhsTI9pZrCw5nBn4MW9MR0ll6g99YD2wpmU8euMyRMnN307NfhanvMkH1
1M8Am9S+P878jbhpfWglljYxMYZT2CxwaqoMH7f/2QOwJp0fiT479Cb+hL3q2dPp0doT
YTWQ==
X-Gm-Message-State: AFeK/H0wFjt6Vx+VZm0ga1kz3SOVyRbNXBSeFbnE0i5NJkWRexRsButzAByZSlOAXexOxAb06Ypwt0P/5pEOXA==
X-Received: by 10.55.8.5 with SMTP id 5mr25831338qki.265.1491512632758; Thu,
06 Apr 2017 14:03:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.170.220 with HTTP; Thu, 6 Apr 2017 14:03:12 -0700 (PDT)
In-Reply-To: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>
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: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 6 Apr 2017 18:03:12 -0300
Message-ID: <CAKzdR-qmhXH0ZaKTYP+6NE6vdzm0u5nfhgKXp9iLc=9ZdLWLZA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=001a11487798a77245054c85d8fa
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 21:03:54 -0000
--001a11487798a77245054c85d8fa
Content-Type: text/plain; charset=UTF-8
Ups. My mistake: the mempool will not grow 400 times, the is no square
there.
I will initially grow 20 times. Multiplied by the number of times a
transaction may need to be replaced with one with higher fees. Maybe 50
times, but not 400.
On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:
> 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.
>>
>
>
--001a11487798a77245054c85d8fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ups. My mistake: =C2=A0the mempool will not grow 400 times=
, the is no square there.<br>I will initially grow 20 times. Multiplied by =
the number of times a transaction may need to be replaced with one with hig=
her fees. Maybe 50 times, but not 400.<div><br><div><br></div></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Apr 6, 201=
7 at 5:42 PM, Sergio Demian Lerner <span dir=3D"ltr"><<a href=3D"mailto:=
sergio.d.lerner@gmail.com" target=3D"_blank">sergio.d.lerner@gmail.com</a>&=
gt;</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>T=
he 95% miner signaling is important to prevent two Bitcoin forks, such as w=
hat happened with Ethereum HF and Ethereum Classic.</div><div><br></div>Bit=
coin has a very slow difficulty re-targeting algorithm. A fork that has jus=
t 95% miner support will initially (for 2016 blocks) be 5% slower (an avera=
ge block every 10 minutes and 30 seconds). The transaction capacity of the =
new Bitcoin protocol is reduced only 5%.=C2=A0<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 wi=
ll take 20 hours in the original chain and the original chain will be in th=
is 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></di=
v></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <s=
pan dir=3D"ltr"><<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=
>On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <sp=
an dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The hard-f=
ork is conditional to 95% of the hashing power has approved the segwit2mb s=
oft-fork and the segwit soft-fork has been activated (which should occur 20=
16 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 nVe=
rsion 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 t=
alk a lot about hard forks with various developers and am very interested i=
n the research that Johnson in particular is pioneering. However, I have fa=
iled to understand your point about 95% miner signalling in relation to a h=
ard fork, so I am eagerly awaiting your explanation.</div></div></div></div=
>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--001a11487798a77245054c85d8fa--
|
