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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F15E6A81
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 20:14:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com
[209.85.161.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C41A122
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 20:14:37 +0000 (UTC)
Received: by mail-yw0-f178.google.com with SMTP id w3so103546411ywg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Oct 2016 13:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=nsHsmqFHyRx66zzWYRmrAk5cKstvuZJMphdsfBT/saI=;
b=SkjA89+1yPcs1wz6Xs7F38SLKfatztcIClKlQKMCRsJhiS6Axi/qoT0djmH1aczMHn
XPaB0yJtYjbo+RHYZAXUpkCgnQ/5MS1u+q39bXKDKXQhMuSDcnprLqh6Re/pakxdTEB6
xewncKm8MT9WEFMWW0eW86jWyJwzY1Ja/N+flEcrv6ItmuKmgQfld+0Nx9lCxbXAO/1H
5L0fZPHFUmazMsSEtYDo2p6nSJxMCMBKqh0L++nvdub7xb6A+6X+5BALSkS82W05kZFA
2BEQ8dvo5d3aXlaicRITBNZ3TRfvED1uOrxOi9vEtJGx6FqcZuSZG+zdPMNSPXZ4IR0w
+HIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=nsHsmqFHyRx66zzWYRmrAk5cKstvuZJMphdsfBT/saI=;
b=XLvR/tWN5s7fvTLDQhRAi6ck7qHRiJeWvqupMyg8Ogz26SysL0yYw/euRJbW8XYTbT
lTzMt+4DdP9XCURln0DFRr+qgme0m2SZ2KcMEafeAYkvZvijOdRE1PQgh0j+U8pv1HWn
78bQPWOe/lcNjZBcBU5HBlCaV/RDzfR23fOUv2Yuf5pVra4y2xH8dIA0grxE3ZsFSCwn
BAbe1LL84r4BEWa1o6kHAUwKK8uw/HTlEkiOVPV4GfSplsbrDU5KmPfsZIh6NevcK7CA
CoS6CIpry4JlC+1/x36qfNyEeNT+g6cyW9wV+8I1Y9zS+OaajSCU/cP9dl23FwUSaFHu
clnQ==
X-Gm-Message-State: AA6/9Rkt7TucZ3BYnEzkXkmCP8GHv8O4RmRKQaIofDZr1K5+ZsuX4mOU3ziBQu2kFiJADdql1F7KImDRzH6vjA==
X-Received: by 10.129.41.133 with SMTP id p127mr21261977ywp.154.1476648876315;
Sun, 16 Oct 2016 13:14:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.167.74 with HTTP; Sun, 16 Oct 2016 13:14:15 -0700 (PDT)
In-Reply-To: <2034434.4WpKWoeOrB@strawberry>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
<CABsx9T2sWKFKpRYsjcgcdef+nL7X9-4+3H10hAy1FsXaax38Og@mail.gmail.com>
<2d5abad7-cd9d-4396-4dd2-c687a1a808dc@vt.edu>
<2034434.4WpKWoeOrB@strawberry>
From: Btc Drak <btcdrak@gmail.com>
Date: Sun, 16 Oct 2016 21:14:15 +0100
Message-ID: <CADJgMzuYmJgN12FeCy3rT-U=VAr9ubqTWZy434Qcs_u0DhBb=Q@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11407e72bb2567053f011b8d
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 16 Oct 2016 20:15:19 +0000
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
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: Sun, 16 Oct 2016 20:14:38 -0000
--001a11407e72bb2567053f011b8d
Content-Type: text/plain; charset=UTF-8
I can see how it looks but actually most of the underlying libraries have
already been adapted or are almost finished being adapted for segwit. Since
segwit is not live on mainnet, most are not released (either still in PR
form or merged to a development branch). As a software developer, I think
you can appreciate that libraries cant actually release a segwit supported
versions until segwit is released as final in 0.13.1. Obviously consumers
of the libraries cant update for segwit until the libraries are released -
you get the idea. I wouldn't be too concerned about the adoption chart,
it's just very difficult to reflect the actual state of affairs. For
example Trezor is marked as wip, but they have had an updated, but
unreleased firmware version for many months[1]. We are in the process of
planning a migration guide and updating the existing development notes[2].
Additionally, many companies are already planning to update their services
for segwit.
Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and
activation. The starttime delay is simply designed to avoid miners
signalling before the soft fork has been made available for general
release; so the starttime prevents unreleased software from setting the
version bit prematurely. The whole BIP9 state machine allows predictable
activation. Non mining full nodes are under no constraints to upgrade on a
specific schedule, which is by design of soft forks. Signalling will not
begin until the first diff retarget period after the starttime of 15th Nov.
Practically it means there will be a minimum of 4-6 weeks at the very least
before activation can happen.
[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu
ecomment-217329474
[2] https://bitcoincore.org/en/segwit_wallet_dev/
On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
> > Would I want anyone to lose money due to faulty wallets? Of course not.
> > By the same token, devs have had almost a year to tinker with SegWit and
> > make sure the wallet isn't so poorly written that it'll flame out when
> > SegWit comes along. It's not like this is some untested, mostly unknown
> > feature that's being slipped out at the last minute
>
> There have been objections to the way that SegWit has been implemented for
> a
> long time, some wallets are taking a "wait and see" approach. If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready. Would be interesting to get a more up-to-date
> view.
> Wallets probably won't want to invest resources adding support for a
> feature
> that will never be activated. The fact that we have a much safer
> alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11407e72bb2567053f011b8d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I can see how it looks but actually most of the underlying=
libraries have already been adapted or are almost finished being adapted f=
or segwit. Since segwit is not live on mainnet, most are not released (eith=
er still in PR form or merged to a development branch). As a software devel=
oper, I think you can appreciate that libraries cant actually release a seg=
wit supported versions until segwit is released as final in 0.13.1. Obvious=
ly consumers of the libraries cant update for segwit until the libraries ar=
e released - you get the idea. I wouldn't be too concerned about the ad=
option chart, it's just very difficult to reflect the actual state of a=
ffairs. For example Trezor is marked as wip, but they have had an updated, =
but unreleased firmware version for many months[1]. We are in the process o=
f planning a migration guide and updating the existing development notes[2]=
. Additionally, many companies are already planning to update their service=
s for segwit.<div><br></div><div>Regarding BIP9, it's purpose is to co-=
ordinate *miner upgrade* and activation. The starttime delay is simply desi=
gned to avoid miners signalling before the soft fork has been made availabl=
e for general release; so the starttime prevents unreleased software from s=
etting the version bit prematurely. The whole BIP9 state machine allows pre=
dictable activation. Non mining full nodes are under no constraints to upgr=
ade on a specific schedule, which is by design of soft forks. Signalling wi=
ll not begin until the first diff retarget period after the starttime of 15=
th Nov. Practically it means there will be a minimum of 4-6 weeks at the ve=
ry least before activation can happen.</div><div><br></div><div><div>[1] <a=
href=3D"https://github.com/bitcoin-core/bitcoincore.org/pull/30#issuecomme=
nt-217329474" target=3D"_blank">https://github.com/bitcoin-cor<wbr>e/bitcoi=
ncore.org/pull/30#issu<wbr>ecomment-217329474</a><br></div><div>[2]=C2=A0<a=
href=3D"https://bitcoincore.org/en/segwit_wallet_dev/" target=3D"_blank">h=
ttps://bitcoincore.org/en<wbr>/segwit_wallet_dev/</a></div></div></div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Oct 16, 2016 =
at 7:20 PM, Tom Zander via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev=
<br>
wrote:<br>
<span class=3D"">> Would I want anyone to lose money due to faulty walle=
ts? Of course not.<br>
> By the same token, devs have had almost a year to tinker with SegWit a=
nd<br>
> make sure the wallet isn't so poorly written that it'll flame =
out when<br>
> SegWit comes along. It's not like this is some untested, mostly un=
known<br>
> feature that's being slipped out at the last minute<br>
<br>
</span>There have been objections to the way that SegWit has been implement=
ed for a<br>
long time, some wallets are taking a "wait and see" approach.=C2=
=A0 If you look<br>
at the page you linked[1], that is a very very sad state of affairs. The<br=
>
vast majority is not ready.=C2=A0 Would be interesting to get a more up-to-=
date<br>
view.<br>
Wallets probably won't want to invest resources adding support for a fe=
ature<br>
that will never be activated. The fact that we have a much safer alternativ=
e<br>
in the form of Flexible Transactions may mean it will not get activated. We=
<br>
won't know until its actually locked in.<br>
Wallets may not act until its actually locked in either. And I think we<br>
should respect that.<br>
<br>
Even if all wallets support it (and thats a big if), they need to be rolled=
<br>
out and people need to actually download those updates.<br>
This takes time, 2 months after the lock-in of SegWit would be the minimum<=
br>
safe time for people to actually upgrade.<br>
<br>
1) <a href=3D"https://bitcoincore.org/en/segwit_adoption/" rel=3D"noreferre=
r" target=3D"_blank">https://bitcoincore.org/en/<wbr>segwit_adoption/</a><b=
r>
<span class=3D"im HOEnZb">--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________=
__<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>
</div></div></blockquote></div><br></div>
--001a11407e72bb2567053f011b8d--
|
