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
149
150
151
152
153
154
155
156
157
158
159
|
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 D3A6367
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Aug 2015 07:16:56 +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 0AD71E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Aug 2015 07:16:55 +0000 (UTC)
Received: from localhost ([::1]:36894 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZLnVu-001dyO-Ah; Sun, 02 Aug 2015 03:16:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 02 Aug 2015 03:16:54 -0400
From: jl2012@xbt.hk
To: Pieter Wuille <pieter.wuille@gmail.com>
In-Reply-To: <CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
<CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
Message-ID: <bbdbc08925ca3416f0f9982466b98413@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
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,LOTS_OF_MONEY,
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] 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: Sun, 02 Aug 2015 07:16:56 -0000
Pieter Wuille 於 2015-08-01 16:45 寫到:
> On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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.
>
> Given the time recent softforks have taken to deploy, I think that's
> too soon.
Since I'm using "30 days after 75% miner support", the actual deployment
period will be longer than 30 days. Anyway, if all major exchanges and
merchants agree to upgrade, people are forced to upgrade immediately or
they will follow a worthless chain.
>
>> 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.
>
> I have considered suggesting a faster ramp-up in the beginning, but I
> don't think there is indisputable evidence that we can currently deal
> with significantly larger blocks. I don't think "painful" is the right
> criterion either; I'm sure my equipment can "handle" 20 MB blocks too,
> but with a huge impact on network propagation speed, and even more
> people choosing the outsource their full nodes.
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6 MB blocks, there would be more complaints about
> low full node counts, maybe 90% instead of 60% of the hash rate would
> be have SPV mining agreements with each other, we'd somehow have
> accepted that even worse reality, but people would still be
> complaining about the measly 25 transactions per second that Bitcoin
> could handle on-chain, and be demanding a faster rampup to a more
> "reasonable" 64 MB block size as well.
Since the block reward is miners' major income source, no rational miner
would create mega blocks unless the fee could cover the extra orphaning
risk. Blocks were not constantly full until recent months, and many
miners are still keeping the 750kB soft limit. This strongly suggests
that we won't have 4MB blocks now even Satoshi set a 8MB limit.
I don't have the data now but I believe the Satoshi Dice model failed
not primarily due to the 1MB cap, but the raise in BTC/USD rate. Since
minting reward is a fixed value in BTC, the tx fee must also be valued
in BTC as it is primarily for compensating the extra orphaning risk. As
the BTC/USD rate increases, the tx fee measured in USD would also
increase, making micro-payment (measured in USD) unsustainable.
We might have less full nodes, but it was Satoshi's original plan: "At
first, most users would run network nodes, but as the network grows
beyond a certain point, it would be left more and more to specialists
with server farms of specialized hardware. A server farm would only need
to have one node on the network and the rest of the LAN connects with
that one node." Theoretically, we only require one honest full node to
prove wrongdoing on the blockchain and tell every SPV nodes to blacklist
the invalid chain.
I think SPV mining exists long before the 1MB block became full, and I
don't think we could stop this trend by artificially suppressing the
block size. Miners should just do it properly, e.g. stop mining until
the grandparent block is verified, which would make sure an invalid fork
won't grow beyond 2 blocks.
>> 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/
>
> I'd rather be conservative here. My primary purpose is trying to
> create an uncontroversial proposal that introduces an expectation of
> growth with technology.
If we could have a longer initial ramp up period, we may adopt a slower
long term parameter. I think we should at least restore the original
32MB limit in a reasonable time frame, say 6-8 years, instead of 20
years in your proposal. If you believe Bitcoin should become a global
settlement network, 32MB would be the very minimum as that is only 75%
of current SWIFT traffic.
|
