summaryrefslogtreecommitdiff
path: root/ca/54605b7a04c4269f5fc1e96f9f47a89c3220b9
blob: 9d3e72945e7660febc175128cd4725c99964a5f6 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1Yn3GI-00051K-KS
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Apr 2015 11:01:10 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.169 as permitted sender)
	client-ip=209.85.217.169; envelope-from=pieter.wuille@gmail.com;
	helo=mail-lb0-f169.google.com; 
Received: from mail-lb0-f169.google.com ([209.85.217.169])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yn3GE-0008Bl-QO
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Apr 2015 11:01:10 +0000
Received: by lbbqq2 with SMTP id qq2so104023742lbb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 28 Apr 2015 04:01:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.203.162 with SMTP id kr2mr14078941lac.68.1430218860436; 
	Tue, 28 Apr 2015 04:01:00 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Tue, 28 Apr 2015 04:01:00 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Tue, 28 Apr 2015 04:01:00 -0700 (PDT)
In-Reply-To: <4E63339A-69B1-4885-9D7F-6D14E75CE174@petertodd.org>
References: <20150428074414.GA19918@amethyst.visucore.com>
	<4E63339A-69B1-4885-9D7F-6D14E75CE174@petertodd.org>
Date: Tue, 28 Apr 2015 04:01:00 -0700
Message-ID: <CAPg+sBjc4iguJ8KCnUf9LrLbPkWEMc5fvr7XZsA48XQKaecN5g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1134632620e3f20514c6c7f1
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yn3GE-0008Bl-QO
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 11:01:10 -0000

--001a1134632620e3f20514c6c7f1
Content-Type: text/plain; charset=ISO-8859-1

As softforks almost certainly require backports to older releases and other
software anyway, I don't think they should necessarily be bound to Bitcoin
Core major releases. If they don't require large code changes, we can
easily do them in minor releases too.
On Apr 28, 2015 12:51 PM, "Peter Todd" <pete@petertodd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY
> implemented on Bitcoin will be something like summer 2016, a year and a
> half after it got adopted on Viacoin. (and a few other alts whose names I
> forget)
>
> Right now the shortest path to adoption would be to release a v0.12 with
> just a CLTV soft-fork as soon as the BIP66 softfork triggers. While there's
> been proposal to change the way the upgrade mechanism triggers to a
> multiple parallel fork scheme, that is quite complex, stateful, and will
> need lots of review, probably a few months worth; faster would be to
> continue with the existing mechanism.
>
> IMO the main reason to accelerate CLTV is scalability. The only viable
> scalability improvements possible in the short/medium term that don't
> entirely rely on trusting third parties are payment channel based. While we
> have a working payment channel scheme - Jeremy Spilman's refund tx based
> system - it is fairly complex, needs good and immediate backups, and is
> susceptible to tx malleability. CLTV fixes those issues robustly. Of
> course, payment channel schemes can start off with Spilman's scheme first
> and go to CLTV later, but that is a lot of extra code to be written and
> later depreciated - I'm sure many authors are dubious about going down that
> path.
>
> Thoughts?
>
>
> On 28 April 2015 03:44:16 GMT-04:00, "Wladimir J. van der Laan" <
> laanwj@gmail.com> wrote:
> >Hello all,
> >
> >The release window for 0.11 is nearing, I'd propose the following
> >schedule:
> >
> >2015-05-01  Soft translation string freeze
> >            Open Transifex translations for 0.11
> >            Finalize and close translation for 0.9
> >
> >2015-05-15  Feature freeze, string freeze
> >
> >2015-06-01  Split off 0.11 branch
> >            Tag and release 0.11.0rc1
> >            Start merging for 0.12 on master branch
> >
> >2015-07-01  Release 0.11.0 final (aim)
> >
> >In contrast to former releases, which were protracted for months, let's
> >try to be more strict about the dates. Of course it is always possible
> >for last-minute critical issues to interfere with the planning. The
> >release will not be held up for features, though, and anything that
> >will not make it to 0.11 will be postponed to next release scheduled
> >for end of the year.
> >
> >Wladimir
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVP2Wy
> AAoJEMCF8hzn9LncqOcH/3rDFbgWprqTfk8dKWAItRcY6ZyiQ+dNrqNgymaNP5Ig
> MNKaTmWYyZRH6PW13JOv72ArXia+D82Mp5reTaLIb3TV5uef2biruOCaH9eI8Uv5
> i2PCBLw3uqZIZZ5Qr/7nlp2CaBQIGDK3fg3jx10UyWpg4BxkKP2mLJibMG8l3JcK
> Moi/kh6lvwySpT8NYtZfXax+5AQ2oLXiSzbFF8P0ioI9fJYaoVCAyS5VEE4KsZnV
> thOaoPAWoK+spEYKFrjvyXnQXFe6m+KPfRPU3WKYSFhI7m8MW6bKxEnD0Lffo6qU
> YS6jsE3A0LoKs4kD73ivHcMeXDhO6LXyPAu8zQtgGr8=
> =Z/GT
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1134632620e3f20514c6c7f1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">As softforks almost certainly require backports to older rel=
eases and other software anyway, I don&#39;t think they should necessarily =
be bound to Bitcoin Core major releases. If they don&#39;t require large co=
de changes, we can easily do them in minor releases too.</p>
<div class=3D"gmail_quote">On Apr 28, 2015 12:51 PM, &quot;Peter Todd&quot;=
 &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIG=
NED MESSAGE-----<br>
Hash: SHA256<br>
<br>
I&#39;ll point out that at this rate the soonest we&#39;ll see CHECKLOCKTIM=
EVERIFY implemented on Bitcoin will be something like summer 2016, a year a=
nd a half after it got adopted on Viacoin. (and a few other alts whose name=
s I forget)<br>
<br>
Right now the shortest path to adoption would be to release a v0.12 with ju=
st a CLTV soft-fork as soon as the BIP66 softfork triggers. While there&#39=
;s been proposal to change the way the upgrade mechanism triggers to a mult=
iple parallel fork scheme, that is quite complex, stateful, and will need l=
ots of review, probably a few months worth; faster would be to continue wit=
h the existing mechanism.<br>
<br>
IMO the main reason to accelerate CLTV is scalability. The only viable scal=
ability improvements possible in the short/medium term that don&#39;t entir=
ely rely on trusting third parties are payment channel based. While we have=
 a working payment channel scheme - Jeremy Spilman&#39;s refund tx based sy=
stem - it is fairly complex, needs good and immediate backups, and is susce=
ptible to tx malleability. CLTV fixes those issues robustly. Of course, pay=
ment channel schemes can start off with Spilman&#39;s scheme first and go t=
o CLTV later, but that is a lot of extra code to be written and later depre=
ciated - I&#39;m sure many authors are dubious about going down that path.<=
br>
<br>
Thoughts?<br>
<br>
<br>
On 28 April 2015 03:44:16 GMT-04:00, &quot;Wladimir J. van der Laan&quot; &=
lt;<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>&gt; wrote:<br>
&gt;Hello all,<br>
&gt;<br>
&gt;The release window for 0.11 is nearing, I&#39;d propose the following<b=
r>
&gt;schedule:<br>
&gt;<br>
&gt;2015-05-01=A0 Soft translation string freeze<br>
&gt;=A0 =A0 =A0 =A0 =A0 =A0 Open Transifex translations for 0.11<br>
&gt;=A0 =A0 =A0 =A0 =A0 =A0 Finalize and close translation for 0.9<br>
&gt;<br>
&gt;2015-05-15=A0 Feature freeze, string freeze<br>
&gt;<br>
&gt;2015-06-01=A0 Split off 0.11 branch<br>
&gt;=A0 =A0 =A0 =A0 =A0 =A0 Tag and release 0.11.0rc1<br>
&gt;=A0 =A0 =A0 =A0 =A0 =A0 Start merging for 0.12 on master branch<br>
&gt;<br>
&gt;2015-07-01=A0 Release 0.11.0 final (aim)<br>
&gt;<br>
&gt;In contrast to former releases, which were protracted for months, let&#=
39;s<br>
&gt;try to be more strict about the dates. Of course it is always possible<=
br>
&gt;for last-minute critical issues to interfere with the planning. The<br>
&gt;release will not be held up for features, though, and anything that<br>
&gt;will not make it to 0.11 will be postponed to next release scheduled<br=
>
&gt;for end of the year.<br>
&gt;<br>
&gt;Wladimir<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVP2Wy<br>
AAoJEMCF8hzn9LncqOcH/3rDFbgWprqTfk8dKWAItRcY6ZyiQ+dNrqNgymaNP5Ig<br>
MNKaTmWYyZRH6PW13JOv72ArXia+D82Mp5reTaLIb3TV5uef2biruOCaH9eI8Uv5<br>
i2PCBLw3uqZIZZ5Qr/7nlp2CaBQIGDK3fg3jx10UyWpg4BxkKP2mLJibMG8l3JcK<br>
Moi/kh6lvwySpT8NYtZfXax+5AQ2oLXiSzbFF8P0ioI9fJYaoVCAyS5VEE4KsZnV<br>
thOaoPAWoK+spEYKFrjvyXnQXFe6m+KPfRPU3WKYSFhI7m8MW6bKxEnD0Lffo6qU<br>
YS6jsE3A0LoKs4kD73ivHcMeXDhO6LXyPAu8zQtgGr8=3D<br>
=3DZ/GT<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--001a1134632620e3f20514c6c7f1--