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
|
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 554E0710
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 18:12:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F172A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 18:12:34 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so219922467wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 11:12:33 -0700 (PDT)
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:date
:message-id:subject:from:to:cc:content-type;
bh=nnLsewH8ImOO5dD4Hk6P76AQ6AvvLz+3GOJs1B0zcjA=;
b=Z6e5njCSExIComgfgwkSQyysoiJ03vxL5br/uiUjGyFZ6QGiRCkyPBxcYj1Q5pOV2J
DiZKC2ejmsAixnS8YJ0kkyP5xYAS/jgzl7+G4ooTk+Uifu4TTo19NfUuUsxDZwrGbwQ9
iNG3mjjiGFUbYedN3QLyH+W6HnHDfkSQc3v1bFcgNOSxWNgQcrb1lD9Ra1yaiFjOpSQV
QnY9eFIA451CSGBScJ7Ciz8mI06vK8J0BFBiA4E6LxrPRO75hERiYr2LDt6cine2Kojl
mp6M8shZ20NAdcRqMuUMdrsZXmlR91I4OLc503MfGP4V7FzJ3ZD6Ux+9sIl+2G+H0j2R
rTNA==
X-Gm-Message-State: ALoCoQmrLhyXhl8Q5yTgRcxWuMGzMm9QHU0FXCX3KTGVNn7iKgxQqpTQlqB6heqZByLl5D6VINwD
MIME-Version: 1.0
X-Received: by 10.180.109.6 with SMTP id ho6mr55674160wib.58.1437675153392;
Thu, 23 Jul 2015 11:12:33 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 11:12:33 -0700 (PDT)
In-Reply-To: <CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
<CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
Date: Thu, 23 Jul 2015 20:12:33 +0200
Message-ID: <CABm2gDquCeB7F5X6Drv_LcFcUYL6kL45swaMeZY31tQyXqknyA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Cory Fields <lists@coryfields.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
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] Bitcoin Core and hard forks
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: Thu, 23 Jul 2015 18:12:35 -0000
On Thu, Jul 23, 2015 at 1:42 AM, Cory Fields via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
For what is worth, here's yet another piece of code from the "doing
nothing" side:
https://github.com/bitcoin/bitcoin/pull/6382
It allows you to create a regtest-like testchain with a maximum block
size chosen at run time.
Rusty used a less generic testchain for testing 8 MB blocks:
http://rusty.ozlabs.org/?p=509
Unfortunately I don't know of anybody that has used my patch to test
any other size (maybe there's not that much interest in testing other
sizes after all?).
I'm totally in favor of preemptively adapting the code so that when a
new blocksize is to be deployed, adapting the code is not a problem.
Developers can agree on many changes in the code without users having
to agree on a concrete block size first.
I offer my help to do that. That's what I'm trying to do in #6382 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008961.html
but to my surprise that gets disregarded as "doing nothing" and as
"having a negative attitude", when not simply ignored.
|
