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
|
Return-Path: <venzen@mail.bihthai.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D0C71273
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 16:37:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.165])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8EB7112
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 16:37:25 +0000 (UTC)
Received: from [10.8.0.6] (unknown [10.8.0.6])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested) (Authenticated sender: venzen)
by mail.bihthai.net (Postfix) with ESMTPSA id D682B2042F;
Sun, 28 Jun 2015 18:38:03 +0200 (CEST)
Message-ID: <559022BE.2060503@mail.bihthai.net>
Date: Sun, 28 Jun 2015 23:37:18 +0700
From: Venzen Khaosan <venzen@mail.bihthai.net>
Organization: Bihthai Bai Mai
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Aaron Voisine <voisine@gmail.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com> <20150627074259.GA25420@amethyst.visucore.com> <20150627095501.C59B541A40@smtp.hushmail.com> <558E78CB.7070207@mail.bihthai.net>
<CACq0ZD5WV-J1H7QA0F2wnErXVFJ3MSxWtQidPhVwaxauoHQz_A@mail.gmail.com>
In-Reply-To: <CACq0ZD5WV-J1H7QA0F2wnErXVFJ3MSxWtQidPhVwaxauoHQz_A@mail.gmail.com>
OpenPGP: id=1CF07D66;
url=pool.sks-keyservers.net
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
autolearn=no 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] The need for larger blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: venzen@mail.bihthai.net
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, 28 Jun 2015 16:37:26 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2015 02:55 AM, Aaron Voisine wrote:
> On Sat, Jun 27, 2015 at 3:19 AM, Venzen Khaosan
> <venzen@mail.bihthai.net <mailto:venzen@mail.bihthai.net>> wrote:
>
>
> That is a false assumption. Given the increased adoption of Bitcoin
> by users and businesses during the past year, does the price chart
> reflect greater value or price? Of course not, the price chart is
> at terminal lows. Fact not fiction.
>
>
> You're not taking speculative cycles into account. For most of 2013
> the price was in the $100 range. Adoption as a store-of-value is
> what determines the price over the long term, as with any monetary
> commodity.
Aaron, I am most definitely taking speculative cycles into account - I
write Bitcoin market analysis reports on a daily basis.
Since discussion is exploring notions of "value" and assumptions about
"what increases value" I will post the following.
You're correct to point to the speculative influence, since Bitcoin
having the fundamentals it does, and being a commodity that floats
freely in the market, without centralized control - plus being
unregulated - it is a speculator's wildest dream come true. In this
case its exchange value (to fiat) is based on social mood and
perception and not on underlying (fundamental) value. I think that is
what you imply, too.
What is specifically relevant to the wider discussion, is your mention
of *Commodity Money*, because the term accurately describes a major
facet of Bitcoin's function and role.
Bitcoin's exchange rate, as a commodity money floating freely in the
market, will go up and down according to speculative cycles and we
should conceptually separate its valuation in fiat terms, from its
fundamental value which is: mathematical consensus, cryptographic
transaction security and censorship resistance, etc. These values are
critically reliant on Bitcoin's *degree of decentralization* for them
to remain true and for Bitcoin to retain its meaning, and, therefore,
its value. That is what I point out when I say "greater adoption has
not reflected in the price chart". And that may remain the case for
evermore because the value is in the protocol, the blockchain and its
utility and degree of decentralization, not in the chart or the size
of the user base (however, I'm by no means proposing that the user
base be limited - only that it be grown with primary reference to the
requirements imposed by decentralization).
I argue that we already know what the value of Bitcoin is. In its
current form Bitcoin most likely fulfills 80% or 90% of its eventual
fully evolved value. Increased adoption will not strengthen the
fundamentals, so let's proceed with scaling that will safeguard
Bitcoin's fundamental value and implement protections that ensure
quality of decentralization.
Given the start of a new speculative cycle for Bitcoin and the
possibility of a global liquidity crisis in the coming months or
years, block utilization may increase more rapidly than suggested by
current trends. Utilization may ramp up in a spike, so I agree with
suggestions made here for starting tests of a larger blocksize
(2-8MB), or for speeding up blocktime (whichever is technically
preferred).
Gavin Andresen has committed (if i recall correctly) to tests of 8MB
blocks, so a different size test can be agreed by Core developers.
Once test data and fork outcomes can be reviewed then decision making
has actual parameters to proceed from.
Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVkCK8AAoJEGwAhlQc8H1m7c0IAKBjj3QHhBh5cqDKrVDpPsfv
GEdmjC4CVC+OCZR5TjJ71fsbx9s/9Yh1sglKPfKmInBbgUFeLuermpTnAC+GAEq9
rTPJgGKIIqax2vU9E8fLYrUC/uNk8wdB7PG50tQG+kOWATZOXWimy3Qi1hxOFLNI
bWhRlwIW4tO9HTz6M1WLNyv6T1G7eaUGskW3xODgmr69/ISbG4f/uv7Yy1leEu+r
64hwrswBkvIWeLvPJ3lkuA862HZxbLRkoehEpH3ULTUQ3bDJ1kUkSzi9Z4rwOfHG
p02hs69FVrfHckTtV7wQ4owHekiUT8hjob4V/3YrN0/qMGs4JmrxfyerfZ9GQ9o=
=hc1s
-----END PGP SIGNATURE-----
|
