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
|
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 3C52C83D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:20:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com
[209.85.160.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A090510D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:20:37 +0000 (UTC)
Received: by ykdt205 with SMTP id t205so232379ykd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 03:20: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
:cc:content-type;
bh=pBDlypZdVmnWeg1ul6kV4ufz9LdmZeiUO3DNSKPTAZM=;
b=qnM9V58IXXVk0gqNT8pS9eT1UJS23BoHCe7N41XtGXiKce6xOh214qlp7idIuizITg
lYQ0hHi22TGSw3nrWE6nKYGomKFQaV7E0PXsLqY36g8cgEzyJUYqgRubJiMurwWWxlYV
qVy2pGEmYGgYNoYNj+SjDR3qjxIwuW8OmQRfSESdVOqfne/B56hHXH47LzjcFLSb0JeZ
FQfILc36lrdUvQ7GQRoAUwTdLar6T8Vjhw0r7FWuOyaSQpZej13sKe/6HSbIp9ucIjaC
Wf1P37GHSP2PqnM7vvfywtmygEJt7aEJPpdlPCRrpveJEY9ObcuRSKkdT6W7dvkYoOn7
nwLA==
X-Received: by 10.170.97.9 with SMTP id o9mr12590748yka.84.1439979636901; Wed,
19 Aug 2015 03:20:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.37.73 with HTTP; Wed, 19 Aug 2015 03:20:17 -0700 (PDT)
In-Reply-To: <CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
<CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Wed, 19 Aug 2015 11:20:17 +0100
Message-ID: <CADJgMztmgUzy70sJ+_Xj-OFe-kvEi6eSAYoGTb4yg-yGQ9u1dw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113b4874bdcc34051da762a9
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to
XT/Not-BitcoinXT miners
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 19 Aug 2015 10:20:38 -0000
--001a113b4874bdcc34051da762a9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Seems like 3 is something we want to do no matter what and therefore
> is the "most future-proof" solution.
> I wonder if I can help with that (and I know there's more people that
> would be interested).
> Where's the current "non-full" nVersion bits implementation?
> Why implement a "non-full" version instead of going with the full
> implementation directly?
There is a simple answer to this, convenience: versionbits has not been
implemented yet, and I believe the BIP is still in review stage. As it
seems likely the remaining locktime pull requests will be ready by or
before the next major release, we need a deployment method if versionbits
is not ready (which is unlikely because no-one appears to be working on it
at the moment). Pieter indicated he is OK with another IsSuperMajority()
rollout in the interim. Personally, I dont think we should let perfection
be the enemy of progress here because at the end of the day, the deployment
method is less important than the actual featureset being proposed.
That said, the features in the next soft fork proposal are all related and
best deployed as one featureset softfork, but moving forward, versionbits
seems essential to be able to roll out multiple features in parallel
without waiting for activation and enforcement each time.
--001a113b4874bdcc34051da762a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Seems like 3 is something we want to do no matter what and th=
erefore<br>
is the "most future-proof" solution.<br>
I wonder if I can help with that (and I know there's more people that<b=
r>
would be interested).<br>
Where's the current "non-full" nVersion bits implementation?<=
br>
Why implement a "non-full" version instead of going with the full=
<br>
implementation directly?</blockquote><div><br></div><div>There is a simple =
answer to this, convenience: versionbits has not been implemented yet, and =
I believe the BIP is still in review stage. As it seems likely the remainin=
g locktime pull requests will be ready by or before the next major release,=
we need a deployment method if versionbits is not ready (which is unlikely=
because no-one appears to be working on it at the moment). Pieter indicate=
d he is OK with another IsSuperMajority() rollout in the interim. Personall=
y, I dont think we should let perfection be the enemy of progress here beca=
use at the end of the day, the deployment method is less important than the=
actual featureset being proposed.</div><div><br></div><div>That said, the =
features in the next soft fork proposal are all related and best deployed a=
s one featureset softfork, but moving forward, versionbits seems essential =
to be able to roll out multiple features in parallel without waiting for ac=
tivation and enforcement each time.</div><div><br></div><div><br></div><div=
><br></div><div><br></div><div><br></div></div></div></div>
--001a113b4874bdcc34051da762a9--
|
