summaryrefslogtreecommitdiff
path: root/7b/6bae0726ddd356625fc4f9cacb697ffc93f18a
blob: 28ef673567717b999bcc78062003bd08ee2bf51e (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
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
Return-Path: <samad.sajanlal@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DA96E978
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 29 Mar 2018 05:14:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
	[209.85.223.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85FC0163
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 29 Mar 2018 05:14:43 +0000 (UTC)
Received: by mail-io0-f176.google.com with SMTP id o4so6204947iod.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 28 Mar 2018 22:14:43 -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=Cc4GTKlvSJWf2U/IMc5v0ItK0bOMc7ZGpXVXwt88iPw=;
	b=AvRO9hmexg9HeIHAIKPFlSkcJu+IFkqQe6GvG1XKmfkWEpPT5VqLL6WEVlfuzDw0Oo
	Gsg/0izW32gdz59geK+hqExbQqpXRraPD/cRSWNdjZpb4xBwk+ekEDTEidVsH7UfgHmU
	RWjMksAwv25WuILbkXcDR3fQGBzFD3PrMw9QHxakZg2rR0o8XELH1Nd8oLdbqdfq6AKa
	O+/OTsfEqwm3XSjd1Q+vhCB2lnMsOOP3gzMgHsnTT58cI0P8U5Zu0qPrxJW5e7HawKGX
	UihJvSKhwN5tBOLKogAulLA85sQUBEm2GBT8UuH3pfi4I7bPSVKQK59kmUggxKyU6tvt
	xPQA==
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=Cc4GTKlvSJWf2U/IMc5v0ItK0bOMc7ZGpXVXwt88iPw=;
	b=KRBhLGGofGld9IqZmHB+I0OKPxJLufbRxpEyfwFnNU4p6FZGncC/CgJQeaKx8lxxEk
	Vvc7oYCEseJIfgzvXferddvcXVs+gsX8qBXzGMGApPpXQtDKhclX6uxGEAhb/eIMSpwi
	P3XEjhcMbYIOsBl4UOOsWXaKrrOEwMVDfIXWx9nyA/EUv0im2H2KqaIv9y7TAu5hdnSq
	7OBjFL0q15x++z8Owq58OPLq+URVyRXZzZdyYnZGWtuSsXIQsmzjJUxC+UdW11lXPWTT
	6EzXkSh8lvQJOHhGkzYd6if9zSuUCVWw049NFReBPQQWnI10A1pdjabIc8ZcaS6yvAxY
	gVJA==
X-Gm-Message-State: AElRT7GclOJyI5fUS8Nx+PUz9bUgDeh0n3/PEQBoq951hDgporibkH9E
	K4TI3a1O/+j43E3vJWbl4Ykhcp2k8JUNmFX4whwkFQ==
X-Google-Smtp-Source: AG47ELvENMVC3raNW+t7FUpB5xgtAS9lnN+HFMP1HFaFLnhstB2F2hcewR7wNKWpUQXIGAuV3FWFQNY1epJRsrP8vsU=
X-Received: by 10.107.16.65 with SMTP id y62mr50189773ioi.213.1522300482816;
	Wed, 28 Mar 2018 22:14:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.140.147 with HTTP; Wed, 28 Mar 2018 22:14:42 -0700 (PDT)
In-Reply-To: <CABm2gDq2pa_8T7Xhniuyh86eTi=PmSA_t=2Z0nYp1LhN=zc_NA@mail.gmail.com>
References: <CAAQZUuDEJeMFTxxJcgUEmTUQbxM_ZWkBD1k+UOvafsqbqj++Jg@mail.gmail.com>
	<CABm2gDq2pa_8T7Xhniuyh86eTi=PmSA_t=2Z0nYp1LhN=zc_NA@mail.gmail.com>
From: Samad Sajanlal <samad.sajanlal@gmail.com>
Date: Thu, 29 Mar 2018 00:14:42 -0500
Message-ID: <CAAQZUuCW+dijXgLOkDwjx8sCnhFbygqaT-0gLxAwx7EEx=VcaQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary="001a113f2256850efb056886333a"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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, 29 Mar 2018 18:16:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?
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, 29 Mar 2018 05:14:45 -0000

--001a113f2256850efb056886333a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Excellent - Thanks for your response Jorge. This helps us plan out the
future upgrades properly.
Since I see 0.15 and 0.16 use block versions as 0x20000000, whereas the
current deployed codebase (based on bitcoin 0.9.4) makes versions
0x00000002 (as seen by a 0.15 client), it appears safe to activate soft
forks which require a minimum of version 3 and 4 blocks (0x00000003
and 0x00000004,
respectively). Would you agree?

On Wed, Mar 28, 2018 at 7:55 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

> Yes, you can activate softforks at a given height.
> I don't see any reason why you couldn't rebase to 0.16 directly.
> The block version bumping was a mistake in bip34, you don't really
> need to bump the version number. In any case, I would recommend
> reading bip34 and what it activates in the code. IIRC the last thing
> was bip65.
>
> On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Is it possible to activate soft forks such as BIP65 and BIP66 without
> prior
> > signaling from miners? I noticed in chainparams.cpp that there are bloc=
k
> > heights where the enforcement begins.
> >
> > I understand this is already active on bitcoin. I'm working on a projec=
t
> > that is a clone of a clone of bitcoin, and we currently do not have
> BIP65 or
> > BIP66 enforced - no signaling of these soft forks either (most of the
> > network is on a source code fork of bitcoin 0.9). This project does not
> and
> > never intends to attempt to replace bitcoin - we know that without
> bitcoin
> > our project could never exist, so we owe a great deal of gratitude to t=
he
> > bitcoin developers.
> >
> > If the entire network upgrades to the correct version of the software
> (based
> > on bitcoin 0.15), which includes the block height that has enforcement,
> can
> > we simply skip over the signaling and go straight into
> > activation/enforcement?
> >
> > At this time we are lucky that our network is very small, so it is
> > reasonable to assume that the whole network will upgrade their clients
> > within a short window (~2 weeks). We would schedule the activation ~2
> months
> > out from when the client is released, just to ensure everyone has time =
to
> > upgrade.
> >
> > We have been stuck on the 0.9 code branch and my goal is to bring it up
> to
> > 0.15 at least, so that we can implement Segwit and other key features
> that
> > bitcoin has introduced. The 0.15 client currently works with regards to
> > sending and receiving transactions but the soft forks are not active. I
> > understand that activating them will segregate the 0.15 clients onto
> their
> > own fork, which is why I'd like to understand the repercussions of doin=
g
> it
> > without any signaling beforehand. I also would prefer not to have to ma=
ke
> > intermediate releases such as 0.10, 0.11.. etc to get the soft forks
> > activated.
> >
> > Another related question - does the block version get bumped up
> > automatically at the time that a soft fork activates, or is there
> additional
> > stuff that I need to do within the code to ensure it bumps up at the sa=
me
> > time? From what I saw in the code it appears that it will bump up
> > automatically, but I would like some confirmation on that.
> >
> > Regards,
> > Samad
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

--001a113f2256850efb056886333a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Excellent - Thanks for your response Jorge. This help=
s us plan out the future upgrades properly.<br></div>Since I see 0.15 and 0=
.16 use block versions as <span class=3D"gmail-username-wrapper"></span><sp=
an class=3D"gmail-message-content">0x20000000, whereas the current deployed=
 codebase (based on bitcoin 0.9.4) makes versions<span class=3D"gmail-messa=
ge-content"> 0x00000002=20
(as seen by a 0.15 client), it appears safe to activate soft forks which re=
quire a minimum of version 3 and 4 blocks (<span class=3D"gmail-message-con=
tent">0x00000003</span> and <span class=3D"gmail-message-content">0x0000000=
4, respectively). Would you agree? </span></span></span><br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Mar 28, 2018 at 7:=
55 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtim=
on.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Yes, you can activate softforks at a given height.<b=
r>
I don&#39;t see any reason why you couldn&#39;t rebase to 0.16 directly.<br=
>
The block version bumping was a mistake in bip34, you don&#39;t really<br>
need to bump the version number. In any case, I would recommend<br>
reading bip34 and what it activates in the code. IIRC the last thing<br>
was bip65.<br>
<div><div class=3D"h5"><br>
On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Is it possible to activate soft forks such as BIP65 and BIP66 without =
prior<br>
&gt; signaling from miners? I noticed in chainparams.cpp that there are blo=
ck<br>
&gt; heights where the enforcement begins.<br>
&gt;<br>
&gt; I understand this is already active on bitcoin. I&#39;m working on a p=
roject<br>
&gt; that is a clone of a clone of bitcoin, and we currently do not have BI=
P65 or<br>
&gt; BIP66 enforced - no signaling of these soft forks either (most of the<=
br>
&gt; network is on a source code fork of bitcoin 0.9). This project does no=
t and<br>
&gt; never intends to attempt to replace bitcoin - we know that without bit=
coin<br>
&gt; our project could never exist, so we owe a great deal of gratitude to =
the<br>
&gt; bitcoin developers.<br>
&gt;<br>
&gt; If the entire network upgrades to the correct version of the software =
(based<br>
&gt; on bitcoin 0.15), which includes the block height that has enforcement=
, can<br>
&gt; we simply skip over the signaling and go straight into<br>
&gt; activation/enforcement?<br>
&gt;<br>
&gt; At this time we are lucky that our network is very small, so it is<br>
&gt; reasonable to assume that the whole network will upgrade their clients=
<br>
&gt; within a short window (~2 weeks). We would schedule the activation ~2 =
months<br>
&gt; out from when the client is released, just to ensure everyone has time=
 to<br>
&gt; upgrade.<br>
&gt;<br>
&gt; We have been stuck on the 0.9 code branch and my goal is to bring it u=
p to<br>
&gt; 0.15 at least, so that we can implement Segwit and other key features =
that<br>
&gt; bitcoin has introduced. The 0.15 client currently works with regards t=
o<br>
&gt; sending and receiving transactions but the soft forks are not active. =
I<br>
&gt; understand that activating them will segregate the 0.15 clients onto t=
heir<br>
&gt; own fork, which is why I&#39;d like to understand the repercussions of=
 doing it<br>
&gt; without any signaling beforehand. I also would prefer not to have to m=
ake<br>
&gt; intermediate releases such as 0.10, 0.11.. etc to get the soft forks<b=
r>
&gt; activated.<br>
&gt;<br>
&gt; Another related question - does the block version get bumped up<br>
&gt; automatically at the time that a soft fork activates, or is there addi=
tional<br>
&gt; stuff that I need to do within the code to ensure it bumps up at the s=
ame<br>
&gt; time? From what I saw in the code it appears that it will bump up<br>
&gt; automatically, but I would like some confirmation on that.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Samad<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--001a113f2256850efb056886333a--