summaryrefslogtreecommitdiff
path: root/a5/e41410459e2606c7a030d22549edb619db7f63
blob: 4b7c2dbd8bd60d278a6a689914e8a41c2ee6f7f5 (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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 147D0EA6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 30 Mar 2018 20:52:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com
	[209.85.217.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68DB4622
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 30 Mar 2018 20:52:52 +0000 (UTC)
Received: by mail-ua0-f177.google.com with SMTP id q38so5971030uad.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 30 Mar 2018 13:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-transfer-encoding;
	bh=XgohFK2xUCyRozTGhYiazQBIZuzmcsgrxfeycSR/DnI=;
	b=chakjNveaY7YhCZ8v9ZoatSd7vtLqh2AYYAlBhgC801fqr8f3KBSMpoWg/UFGgaUkB
	ZeLf2XWhcFag3bTiN1+RSB661AaKrOW31z7MZFFgccAfleZSknqWFTdLT9Kmj3ZfBFHA
	GJnIcaPY2JHGPv4r2BQ0qt44DEfEm5jPz7+xVOQLDNw5CgiEAvJy+YNj3C3YXTFv1bac
	MaMOKhjtUz8e/7kKgy0omftqF9dOsMMA+eYghq/ECvo/jJXfeZAn/084fHsCEf6FxTTw
	hRgjUW+89oGJqu9tn99+UC0WNoHys4aQQCZ5ghCj9HtkY4qTxwEstG580uf2KgOPcvwG
	cC+g==
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:content-transfer-encoding;
	bh=XgohFK2xUCyRozTGhYiazQBIZuzmcsgrxfeycSR/DnI=;
	b=MIJW+fimuomVIaJCNgU+6B4iJYEncEHY2MuhtYOOJzXM1Wy+sLCkJgMxEgYsciIpjn
	yOM0K0DxsCOrHRv2Sa4CQUTiQeZMKe45g+dkt46Lhwy8vnXJ5Nc/jm2woie4Yc9/GWB0
	ta1vJzT1oxqLodHSnZlhFvhijNKqy+fnl8o/M9tRv4DLtIQmV0C4QKcBJzwTxSRKQflB
	54h+nSpAGAKZ78RzEinhHhifQQDcmY9q8t1PtI9R6rKeXus5j72p3EpUxPzA+pATRpLt
	r2LisU5N8N7dxxztboIpT6h+TbWIRkSi59SI4xBJq6sMKEzVukuIgKAc5vYO8u89UTpi
	VQOw==
X-Gm-Message-State: AElRT7HPdYoy4zuxDPKb25s7vMAgTBa/okmtrbPITO+JJKOHvWwr27MJ
	CTbuKTftiBisgFnPh/rU8fH0SXsqOu/cujXJqDT+JA==
X-Google-Smtp-Source: AIpwx49IEqCGGJMi528xqj2vIM1Fes7s4zutzZjBDjfWaXcDHgMyjCJtku/GyDSxhaTT0YcAR66IKtpy1VgrYZOzbLI=
X-Received: by 10.176.91.146 with SMTP id y18mr340850uae.46.1522443171461;
	Fri, 30 Mar 2018 13:52:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.168.211 with HTTP; Fri, 30 Mar 2018 13:52:50 -0700 (PDT)
In-Reply-To: <CAAQZUuCW+dijXgLOkDwjx8sCnhFbygqaT-0gLxAwx7EEx=VcaQ@mail.gmail.com>
References: <CAAQZUuDEJeMFTxxJcgUEmTUQbxM_ZWkBD1k+UOvafsqbqj++Jg@mail.gmail.com>
	<CABm2gDq2pa_8T7Xhniuyh86eTi=PmSA_t=2Z0nYp1LhN=zc_NA@mail.gmail.com>
	<CAAQZUuCW+dijXgLOkDwjx8sCnhFbygqaT-0gLxAwx7EEx=VcaQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 30 Mar 2018 22:52:50 +0200
Message-ID: <CABm2gDpRY81cxyMmBnKyTefk=6d89YCxPVZjt3C2qwNq1sTK_g@mail.gmail.com>
To: Samad Sajanlal <samad.sajanlal@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FROM_EXCESS_BASE64,
	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
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: Fri, 30 Mar 2018 20:52:53 -0000

Yes, in fact, you don't need to lose those bits like bitcoin by
imposing that the version is greater than that. But I guess just doing
the same is simpler.

On Thu, Mar 29, 2018 at 7:14 AM, Samad Sajanlal
<samad.sajanlal@gmail.com> wrote:
> 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 0x00000=
002
> (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> wrot=
e:
>>
>> 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 blo=
ck
>> > heights where the enforcement begins.
>> >
>> > I understand this is already active on bitcoin. I'm working on a proje=
ct
>> > 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 no=
t
>> > 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
>> > the
>> > 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 u=
p
>> > 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 t=
o
>> > 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 doi=
ng
>> > it
>> > without any signaling beforehand. I also would prefer not to have to
>> > make
>> > 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
>> > same
>> > 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
>> >
>
>