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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BBF03499
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 08:39:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D063310A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 08:39:44 +0000 (UTC)
Received: from localhost ([::1]:46394 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85) (envelope-from <jl2012@xbt.hk>) id 1ZL5qx-003E2q-Bl
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 31 Jul 2015 04:39:43 -0400
Received: from 119.246.245.241 ([119.246.245.241]) by
server47.web-hosting.com (Horde Framework) with HTTP; Fri, 31 Jul 2015
08:39:43 +0000
Date: Fri, 31 Jul 2015 08:39:43 +0000
Message-ID: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
From: jl2012@xbt.hk
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
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
Subject: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal
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: Fri, 31 Jul 2015 08:39:45 -0000
There is a summary of the proposals in my previous mail at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
I think there could be a compromise between Gavin's BIP101 and
Pieter's proposal (called "BIP103" here). Below I'm trying to play
with the parameters, which reasons:
1. Initiation: BIP34 style voting, with support of 750 out of the last
1000 blocks. The "hardfork bit" mechanism might be used:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
Rationale: This follows BIP101, to make sure the new chain is secure.
Also, no miner would like to be the first one to mine a large block if
they don't know how many others would accept it.
2. Starting date: 30 days after 75% miner support, but not before
2016-01-12 00:00 UTC
Rationale: A 30-day grace period is given to make sure everyone has
enough time to follow. This is a compromise between 14 day in BIP101
and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is
given, people will just do it on the 364th day if they opt to
procrastinate.
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in
China. Most pool operators and devs should be back from new year
holiday and not sleeping. (If the initiation is delayed, we may
require that it must be UTC Tuesday midnight)
3. The block size at 2016-01-12 will be 1,414,213 bytes, and
multiplied by 1.414213 by every 2^23 seconds (97 days) until exactly
8MB is reached on 2017-05-11.
Rationale: Instead of jumping to 8MB, I suggest to increase it
gradually to 8MB in 16 months. 8MB should not be particularly painful
to run even with current equipment (you may see my earlier post on
bitctointalk: https://bitcointalk.org/index.php?topic=1054482.0). 8MB
is also agreed by Chinese miners, who control >60% of the network.
4. After 8MB is reached, the block size will be increased by 6.714%
every 97 days, which is equivalent to exactly octuple (8x) every 8.5
years, or double every 2.9 years, or +27.67% per year. Stop growth at
4096MB on 2042-11-17.
Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
p.a. of BIP101. This will take us almost 8 years from now just to go
back to the original 32MB size (4 years for BIP101 and 22 years for
BIP103)
SSD price is expected to drop by >50%/year in the coming years. In
2020, we will only need to pay 2% of current price for SSD. 98% price
reduction is enough for 40 years of 27.67% growth.
Source: http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
should be safe at least for the coming 10 years.
Source:
https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
The final cap is a compromise between 8192MB@2036 of BIP101 and
2048MB@2063 of BIP103
-----------------------------------
Generally speaking, I think we need to have a faster growth in the
beginning, just to normalize the block size to a more reasonable one.
After all, the 1MB cap was introduced when Bitcoin was practically
worthless and with inefficient design. We need to decide a new
"optimal" size based on current adoption and technology.
About "fee market": I do agree we need a fee market, but the fee
pressure must not be too high at this moment when block reward is
still miner's main income source. We already have a fee market: miners
will avoid building big blocks with low fee because that will increase
the orphan risk for nothing.
About "secondary layer": I respect everyone building secondary layer
over the blockchain. However, while the SWIFT settlement network is
processing 300tps, Bitcoin's current 7tps is just nothing more than an
experiment. If the underlying settlement system does not have enough
capacity, any secondary layer built on it will also fall apart. For
example, people may DoS attack a Lightening network by provoking a
huge amount of settlement request which some may not be confirmed on
time. Ultimately, this will increase the risk of running a LN service
and increase the tx fee inside LN. After all, the value of secondary
layer primarily comes from instant confirmation, not scarcity of the
block space.
|
