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
|
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 16EBF259
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 23:48:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
[209.85.213.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7923A133
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 23:48:04 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id x186so128589597vkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 15:48:04 -0800 (PST)
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; bh=DWkpM18obvqgpd/vNXYp9Qy7wPnykugsdwstSTKTqgE=;
b=IL31K9AYMveElxXmcNH1CIJM8oxrXRfwtj+a5T27AdvQ4uv0rlbvwNIGYpEYBDpgnb
UhU5jTa7IumKTCZcm4uMFTxBnEU1uV6wcVPM3MHB90D3H0HYnJJXLAixcZ8w17sqYXKO
F/W7X2v0keEFxKjO7yZrJ2Fr/vxSMNbUuB/VzI+3OFaMzMuFC0FLcxda6mvkwKH3fDj9
qnzk6msrGY3xGpQavlPdcWGuFcSASaJnQnqEDy3qmsTmlXhhP9c3GnZMHBapdniGIw2C
ZUQOUVKkMl5+nmRX7C6Qyszq6qRJ9To6QksqsMhdwDyZaiAXU89WCpxxxwaFWkA3ySHe
idHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=DWkpM18obvqgpd/vNXYp9Qy7wPnykugsdwstSTKTqgE=;
b=Gf1SYUKfat7yEcKV0ONDhrzIdyH6t4zoCyZP1wXnSFpuUXic/r7/YmGJ8apm/0Uznn
2bc/Uf+em+LX8NgOXolK4CPcyu/ZvdQHJstm7QDCZEsCV+XjbrobzZMUVXKrgX4mcWeu
mPs3i19dnvMyYOUHAnG4DTEQ73lY73QpGfuSkYIGn7+rmh+tgsrEZvYsaoukTqQqeOj1
/hhxEVogSiFZlGYhAaIItjRKpCfTI+DZDpjBlWsONX1Iq6Scqzcxct0ykP2TtvRhzqZY
g/bEQ2QTBKqkSTE2MfHHaKMmfVF4LLF4E6i5z/vAeWy93WPDr4goZDEe+2eNM79Xj9SX
m8GA==
X-Gm-Message-State: AKaTC01PFedKAbqxw3r3BcEBLikLIDGJjksGoEELNWP4K+WzJakrMR1CP3+pAgKJ+Eq/P7B3uYj/gDG4qzdPbA==
X-Received: by 10.31.94.84 with SMTP id s81mr62721vkb.167.1479340083548; Wed,
16 Nov 2016 15:48:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.41.15 with HTTP; Wed, 16 Nov 2016 15:48:02 -0800 (PST)
In-Reply-To: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Thu, 17 Nov 2016 00:48:02 +0100
Message-ID: <CABm2gDr5iLWD5vzzi-MyHV235CgqtXb-fNThM9agx0T64m+t-Q@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
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: Wed, 16 Nov 2016 23:48:05 -0000
On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This sort of statement represents one consequence of the aforementioned bad
> precedent.
>
> Are checkpoints good now?
Checkpoints are not necessary for consensus and work is being done to
remove them completely from Bitcoin Core in particular.
> Are hard forks okay now?
I personally think uncontroversial hardforks are ok.
> What is the maximum depth of a reorg allowed by this non-machine consensus?
Good question, specially if we plan to do this with future buried
deployments. What about 1 year reorg?
> Shouldn't we just define a max depth so that all cruft deeper than that can
> just be discarded on a regular basis?
Not sure I understand this question.
> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?
If this is a hardfork, it is one that will only be visible if/when
there's a very deep reorg , one of the kind where we can practically
consider Bitcoin done (and only if some nodes keep the ISM code).
But I could accept that definition. Another way to see it (even though
other said the optimization part was not important) as such an
optimization and simplification.
The way I see it, ISM and BIP9 are just coordination mechanisms for
uncontroversial rule changes.
Once the coordination happened and is long in the past, I really don't
see the problem with replacing the mechanism with a simpler height.
> The "BIP" is neither a Proposal (it's been decided, just documenting for
> posterity), nor an Improvement (there is no actual benefit, just some
> tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard
> fork defines an alt coin, so from Aug 4 forward it has been CoreCoin).
Mhmm, I disagree on the notion that any hardfork necessarily
represents an altcoin.
It is certainly an improvement in the sense that it simplifies
implementations and optimizes validation. You may argue that you don't
consider the improvement important though.
These changes to Bitcoin Core could be rolled back (and obviously
other implementations don't need to adopt them unless they want to
benefit from the simplification/optimization or fear such a long
reaorg), but I really hope we don't.
Trying to understand you better...
Accepting your definition of this as a hardfork, do you oppose to it
simply because it is a hardfork, or because you consider this
"hardfork" a bad idea for some reason I am missing?
|
