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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 731BFFB7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:47:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 511EA162
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:47:19 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 7315E38A9164;
Wed, 30 Dec 2015 23:47:18 +0000 (UTC)
From: Luke Dashjr <luke@dashjr.org>
To: Tomas <tomas@tomasvdw.nl>
Date: Wed, 30 Dec 2015 23:47:16 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <1451493317.3215816.479282618.4F666D71@webmail.messagingengine.com>
<201512301710.27154.luke@dashjr.org>
<1451499779.3919416.479357794.2C21BFA1@webmail.messagingengine.com>
In-Reply-To: <1451499779.3919416.479357794.2C21BFA1@webmail.messagingengine.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201512302347.17609.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
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, 30 Dec 2015 23:47:20 -0000
On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote:
> > The specification itself looks like an inefficient and bloaty reinvention
> > of version bits.
>
> The actual assignment of version bits isn't clear from the
> specification. Are you saying that any implementation that wants to
> propose a change is encouraged to pick a free version bit and use it?
That should probably be clarified in the BIP, I agree. Perhaps it ought to be
assigned the same as BIP numbers themselves, by the BIP editor? (Although as a
limited resource, maybe that's not the best solution.)
> Furthermore, my proposal addresses the danger of forward-incompatible
> changes; a hard-fork can no longer occur as every implementation will
> agree on the active the set of rules even if it has not implemented
> them. This seems to be lacking in the version bits proposal.
I don't think that's possible. First of all, a hardfork can always occur,
since this is something done by the economy and not (even possibly opposed to)
miners. Furthermore, consider the change affecting how further rule changes
are made, such as a PoW algorithm change.
Luke
|
