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
|
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 BD1D0481
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 15:12:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0FF1D1F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 15:12:20 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so25222640wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 08:12:19 -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
:content-transfer-encoding;
bh=/Lzeb8/HeANtyUyBoNph4U7cnXJ2g3LjmWS5NnJ7IyY=;
b=W220nMIgNpgUzpPhCdawlx1ggAlv2QF9jLt7V/26z+OSDtocWSeE6wfX5hbu6dMB82
M81qMm91yRqovMIWhcuIWrkgAz25FqqEzshr55eojtMyRh+zTN71ZrTMw0we1TKPWzPI
plc7m01y6r0LIPDrg5L9oE2c9DG20xB2vwdiik4QyjLvkxQtg+8Ge36sDRPJll8y/Qup
HNdKUhWzxeaD7df4H1cpwmtg2uXfbPFw2UXhTpJxv0VnNbm4HzQsm4u6BJY/YTJus0Te
TH7ymJLIfMf+6TuoKT5QGUDq7ngmEfZKidx//TuFsY4wuNiyN4RSb+fEgcfm1nP3He2Z
Oz4w==
X-Gm-Message-State: ALoCoQme4aCjeSczfCZl+qfRQjYmroopqvxYSkXqKw+XEt+pGMxeNg16naTlirlLN+zNRwlmpVNP
MIME-Version: 1.0
X-Received: by 10.180.37.74 with SMTP id w10mr6938485wij.92.1438269139497;
Thu, 30 Jul 2015 08:12:19 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 08:12:19 -0700 (PDT)
In-Reply-To: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
Date: Thu, 30 Jul 2015 17:12:19 +0200
Message-ID: <CABm2gDrHjfkC+whh3Vh2LZNdSR1WSAXpNitR-jEdxtbKj7J25g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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, 30 Jul 2015 15:12:21 -0000
1) Unlike previous blocksize hardfork proposals, this uses median time
instead of block.nTime for activation. I like that more but my
preference is still using height for everything. But that discussion
is not specific to this proposal, so it's better if we discuss that
for all of them here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.htm=
l
2) I think uncontroversial hardforks should also take miner
confirmation into account, just like uncontroversial softforks do. We
cannot make sure other users have upgraded before activating the
chain, but we can know whether miners have upgraded or not. Having
that tool available, why not use it. Of course other hardforks may not
care about miners' upgrade state. For example "anti-miner hardforks,
see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-=
hardfork
But again, this is common to all uncontroversial hardforks, so it
would probably better to discussed it in
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.htm=
l
(gmaxwell assigned to bip99 to my bip draft).
3) As commented to you privately, I don't like to make any assumptions
about technological advancements (much less on economical growth). I
don't expect many people to agree with me here (I guess I've seen too
many "peak oil" [or more generally, peak energy production] plus I've
read Nietzsche's "On the utility and liability of history for life"
[1]; so considering morals, technology or economics as "monotonic
functions" in history is simply a ridiculous notion to me), but it's
undeniable that internet connections have improved overall around the
world in the last 6 years. I think we should wait for the
technological improvements to happen and then adapt the blocksize
accordingly. I know, that's not a "definitive solution", we will need
to change it from time to time and this is somewhat ugly.
But even if I'm the only one that considers a "technological
de-growth" possible, I don't think is wise to rely on pseudo-laws like
Moore's or Nielsen=E2=80=99s so-called "laws".
Stealing a quote from another thread:
"Prediction is difficult, especially about the future." - Niels Bohr
So I would prefer a more limited solution like bip102 (even though I
would prefer to have some simulations leading to a concrete value
(even if it's bigger) rather than using 2MB's arbitrary number.
Those are my 3 cents.
[1] https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pd=
f
On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> here is a proposal for long-term scalability I've been working on:
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> Some things are not included yet, such as a testnet whose size runs ahead=
of
> the main chain, and the inclusion of Gavin's more accurate sigop checking
> after the hard fork.
>
> Comments?
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
