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
|
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 92D4CD9F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 18:36:02 +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 1DBB7116
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 18:36:02 +0000 (UTC)
Received: from localhost ([::1]:34914 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1a9Gvg-000mEQ-Nz; Wed, 16 Dec 2015 13:36:00 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Dec 2015 13:36:00 -0500
From: jl2012 <jl2012@xbt.hk>
To: Jeff Garzik <jgarzik@gmail.com>
In-Reply-To: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
Message-ID: <9a02d94fbc78afaa3e9668e0294eef64@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=-0.7 required=5.0 tests=BAYES_20,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
X-Mailman-Approved-At: Wed, 16 Dec 2015 18:41:06 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
moral hazard
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: Wed, 16 Dec 2015 18:36:02 -0000
I would also like to summarize my observation and thoughts after the
Hong Kong workshop.
1. I'm so glad that I had this opportunity to meet so many smart
developers who are dedicated to make Bitcoin better. Regular conference
like this is very important for a young project, and it is particularly
important for Bitcoin, with consensus as the core value. I hope such a
conference could be conducted at least once in 2 years in Hong Kong,
which is visa-friendly for most people in both East and West.
2. I think some consensus has emerged at/after the conference. There is
no doubt that segregated witness will be implemented. For block size, I
believe 2MB as the first step is accepted by the super majority of
miners, and is generally acceptable / tolerable for devs.
3. Chinese miners are requesting consensus among devs nicely, instead of
using their majority hashing power to threaten the community. However,
if I were allowed to speak for them, I think 2MB is what they really
want, and they believe it is for the best interest of themselves and the
whole community
4. In the miners round table on the second day, one of the devs
mentioned that he didn't want to be seen as the decision maker of
Bitcoin. On the other hand, Chinese miners repeatedly mentioned that
they want several concrete proposals from devs which they could choose.
I see no contradiction between these 2 viewpoints.
Below are some of my personal views:
5. Are we going to have a "Fee Event" / "Economic Change Event" in 2-6
months as Jeff mentioned? Frankly speaking I don't know. As the fee
starts to increase, spammers will first get squeezed --- which could be
a good thing. However, I have no idea how many txs on the blockchain are
spam. We also need to consider the effect of halving in July, which may
lead to speculation bubble and huge legitimate tx volume.
6. I believe we should avoid a radical "Economic Change Event" at least
in the next halving cycle, as Bitcoin was designed to bootstrap the
adoption by high mining reward in the beginning. For this reason, I
support an early and conservative increase, such as BIP102 or 2-4-8. 2MB
is accepted by most people and it's better than nothing for BIP101
proponents. By "early" I mean to be effective by May, at least 2 months
before the halving.
7. Segregated witness must be done. However, it can't replace a
short-term block size hardfork for the following reasons:
(a) SW softfork does not allow higher volume if users are not upgrading.
In order to bootstrap the new tx type, we may need the help of
altruistic miners to provide a fee discount for SW tx.
(b) In terms of block space saving, SW softfork is most efficient for
multisig tx, which is still very uncommon
(c) My most optimistic guess is SW will be ready in 6 months, which will
be very close to halving and potential tx volume burst. And it may not
be done in 2016, as it does not only involve consensus code, but also
change in the p2p protocol and wallet design
8. Duplex payment channel / Lightning Network may be viable solutions.
However, they won't be fully functional until SW is done so they are
irrelevant in this discussion
9. No matter what is going to be done / not done, I believe we should
now have a clear road map and schedule for the community: a short-term
hardfork or not? The timeline of SW? It is bad to leave everything
uncertain and people can't well prepared for any potential radical
changes
10. Finally, I hope this discussion remains educated and evidence-based,
and no circling
|
