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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F2D8B98C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 02:27:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com
[209.85.216.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52FB71BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 02:27:36 +0000 (UTC)
Received: by mail-qt0-f178.google.com with SMTP id i34so26172235qtc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 19:27:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=GhKpY1Ec2eC42m6/iTj1bH02JGCIueD+lkTYiilRkAQ=;
b=oVr+HQFWAZF6yXkEP3q3XjeI/DmLplkeWjg4Ew6O5iGIpMmHhoMmecO1JlMrRgirQV
1Pa2yKk7I7CkVVU7jd7T0pIU/sXpunaUdJ74pVp4uTr1h8Epc/13Vylrewnrwok51EED
w8MuTnnmLDRWnKcrexax6Q+mTtlllL+kpRntdI1IjjzcdT2sVZhZkPj97AuYK2o2sJ+1
utHo9QZ53bI2g6sdn9qPE+QMLKcaZUqvNyWlc7+qDRvw9gc1hzFlkit2ID0i6QRPJWi/
Mh9jHOT48jy5YUlXIHIZbjEDg6obEK6m2Ze85X/iF6kxiWvOjRSAb1scOLRvQL7GEqr6
l5hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
:from:date:message-id:subject:to:cc;
bh=GhKpY1Ec2eC42m6/iTj1bH02JGCIueD+lkTYiilRkAQ=;
b=uXeDMJy1Ml3aG6m60RvAkFoRJKB2h0H7giNaoLm5PYAPTjTNvNNJ4zZEHYZbTA95IU
26OzUkGAGQFTNM7pcg3cW6VE5PGBn1W5sU7spJ0/eNwryb5U7xMoEd1+LdgyRDFbuhte
92HQrYYxkaKscWG1czd5qS0ficdaWmzFl6COqsT8kUZ2L1l3n4l5Vv7pQaqmjkG56qI3
sLV+tDlKhL5nJcDpuhlt2dVHUOdsFDBWz27msIQwsn+ApQSV8zGbp/0hoHpDU8EcD8cn
JOGVArLVYBRcwIiWfFQPBB1qaedbjY2bVGoh6UBeEbqirO2ju5Bi7AjFoUxiTBNiuhzl
6TsA==
X-Gm-Message-State: AFeK/H2lj7WQxZO6/tN7bPkKzRHAb4O6lnNF4g9pmFeN4qLRbqDVHkS9xvKnGt2PbeBAuY/YI9NiP/LxBKCF+w==
X-Received: by 10.200.43.17 with SMTP id 17mr30006874qtu.199.1491445655421;
Wed, 05 Apr 2017 19:27:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:27:34 -0700 (PDT)
Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:27:34 -0700 (PDT)
Reply-To: erik@q32.com
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: Erik Aronesty <earonesty@gmail.com>
Date: Wed, 5 Apr 2017 22:27:34 -0400
Message-ID: <CAJowKgLUrMR9XN2Sb9ZuXCZx3K8Jy65pOOYGVhYeisszPoWLdA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c0342a7e4ce3054c7640d0
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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: Thu, 06 Apr 2017 02:29:17 +0000
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 02:27:37 -0000
--001a11c0342a7e4ce3054c7640d0
Content-Type: text/plain; charset=UTF-8
I personally appreciate the minimal changes, and often encourage
development to be done this way - when it needs to be released quickly.
But does this need to be released quickly?
- maybe the proposal should be renamed segwit 8mb and be discussed solely
in terms of block weights.
- a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.
- miners who currently object to segwit while pretending to like larger
blocks will find some excuse to object to this too.
- Given the challenges miners seem to have in flipping bits, I expect any
fork that requires 95pct hash power to be vaporware.
On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c0342a7e4ce3054c7640d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto">I personally appreciate the minimal cha=
nges, and often encourage development to be done this way - when it needs t=
o be released quickly.=C2=A0 But does this need to be released quickly?<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">- maybe the proposal sh=
ould be renamed segwit 8mb and be discussed solely in terms of block weight=
s.</div><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">- a=
high consensus hard fork is probably preferable to a low consensus soft fo=
rk, however there is nothing to indicate that segwit as it stands isnt alre=
ady very high consensus except for a handful of pool operators protecting f=
ee income. =C2=A0</div><div dir=3D"auto"><br><span style=3D"font-family:san=
s-serif">- miners who currently object to segwit while pretending to like l=
arger blocks will find some excuse to object to this too.</span><br></div><=
div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><d=
iv dir=3D"auto"><span style=3D"font-family:sans-serif">-=C2=A0</span><span =
style=3D"font-family:sans-serif">Given the challenges miners seem to have i=
n flipping bits, I expect any fork that requires 95pct hash power to be vap=
orware.</span></div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev&qu=
ot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner v=
ia bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation=
.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>The hard-fork is conditional to 95% of the hashing power has approv=
ed the segwit2mb soft-fork and the segwit soft-fork has been activated (whi=
ch should occur 2016 blocks after its lock-in time)</div></div></blockquote=
><div><br></div><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 i=
nterested in the research that Johnson in particular is pioneering. However=
, I have failed to understand your point about 95% miner signalling in rela=
tion to a hard fork, so I am eagerly awaiting your explanation.</div></div>=
</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>
--001a11c0342a7e4ce3054c7640d0--
|
