summaryrefslogtreecommitdiff
path: root/b2/5ca28cf6d4b9669cf9974f2c3d6c54409fe5f6
blob: cbfc7e742751a80b37e2b1ae632933c2774ac710 (plain)
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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
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 7851CACC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 08:16:35 +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 2D8E4E7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 08:16:34 +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 47C632037B;
	Sat, 27 Jun 2015 10:17:09 +0200 (CEST)
Message-ID: <558E5BDB.90608@mail.bihthai.net>
Date: Sat, 27 Jun 2015 15:16:27 +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: Eric Lombrozo <elombrozo@gmail.com>, bitcoin-dev@lists.linuxfoundation.org
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>	<CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>	<CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com>	<CADm_WcbQog_UCV=JPHyqTRxKbaGY7jedtHE_D8jJSe_thMg05w@mail.gmail.com>	<558DB997.4030209@phauna.org>
	<2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com>
In-Reply-To: <2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com>
OpenPGP: id=1CF07D66;
	url=pool.sks-keyservers.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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
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: Sat, 27 Jun 2015 08:16:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, Eric, blockchains are a means of mathematically determining
consensus among those who use them. The application goes beyond value
token into the realm of vote and deterministic politics. Eventually,
blockchains will allows citizens to choose state projects and to
contribute taxes according to their ability, and to benefit according
to their need.

Economic Participants
The dichotomy of the mining operator as an economic class on one hand
and the user as a dependent on the other is based on the current
Keynesian model of economics that views the centralized as inevitable
and the citizen as a consumer to be enlisted into spending at every
opportunity.

Schools of Thought
Although not a definitive answer, the Austrian School of Economics
illustrates that the Keynesian model (which we all harbor to some
degree, thanks to its global hegemony) is fundamentally flawed:
https://www.youtube.com/watch?v=SLfnpwHu4Hw (Of all the resources
available, this speaker is most succinct, although I cannot vouch for
his degree of Frankfurt School compliance or potential Zionist
leanings - the account conforms to academic agreement of what the
Austrian School of Economics stands for).

Developers are, by necessity, making economic decisions
If the developers will seize this moment of having to make economic
decisions about how Bitcoin will be influenced and grow according to
market dynamics, they should make an informed decision (only the
developers can make the decision at this time), they should strive to
make a well-informed decision - not some fumbled
"hurry-the-blocksize-is-running-out" decision. Pieter Wuille argues
the point convincingly in his initial post.

Fulcrum
The fundamental question to be answered here is: Do developers want to
compete with existing payment networks, or do developers want to
define Bitcoin's network in its own right?

If Bitcoin must compete and win, then centralize it and it will soon
beat the competition on every metric.

If Bitcoin is its own beast, then users and finance capital must adapt
to its constraints, for the benefit of all involved.

Developers have a crucial role to play in implementing economic
policy. It's not self-evident: a multinational or government sponsored
entity mining this blockchain with the purpose of dominating it does
not mean you have done your job of surrendering Bitcoin to the "free
market".


The decision rests on your informed understanding of economics (and
myths about economics) and choosing the way that liberates Bitcoin and
its users, and does not co-opt them into a system that seeks to devour
competition. Talk about making Bitcoin more compliant to finance
capital business is counter-Bitcoin and speakers harboring this
opinion have come to dominate discussion here. If increased business
and user adoption truly increased value, you would see it in the price
chart. What has ignorant, fashion-prone mainstreet adoption done for
Bitcoin? Will it really do something else, as some posters claim, or
will it do more of the same?

Venzen Khaosan



On 06/27/2015 09:18 AM, Eric Lombrozo wrote:
> I’ve been pondering this whole scale issue considerably…and am left
> with the conclusion that blockchains are ultimately dispute
> resolution mechanisms. The vast majority of crypto negotiation will
> be taking place at levels lesser than global consensus in the
> future - global consensus is just far too expensive to require for
> every single cappuccino. There really is little need to take most
> cases globally…unless the participants disagree. I’ve commented in
> other places that blockchains are essentially a “fix” to the
> prisoner’s dilemma - they make cooperation the equilibrium
> strategy.
> 
> Regardless of whatever linear factor we scale the blockchain by, it
> is simple math to see that any exponential growth (even if for a
> short time) in usage will overwhelm the current network. If we ever
> intend to take bitcoin mainstream, we will most likely experience
> at least a short time of exponential growth…at least until we
> either reach an inherent limitation or until we saturate. As Pieter
> said earlier, FAPP right now the demand for payments might as well
> be infinite. We’re nowhere near the ability to service it all.
> 
> The block size issue is really a usability issue at this point.
> There are two fundamental things we need to solve:
> 
> 1) There’s no model for how we’ll introduce a fee market, even
> though the design of Bitcoin fundamentally depends on fees for its
> survival (at least in the current form of the design.)
> 
> 2) There’s no mechanism for how to perform fee bidding and
> estimation. Most wallets simply have no way to do this without
> serious usability problems.
> 
> 
> 
> If we’re going to talk about block fees, let’s keep it in the
> context of these relevant issues and not confound it with the
> scalability issue…these are two very different issues.
> 
> 
> - Eric Lombrozo
> 
> 
>> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org>
>> wrote:
>> 
>> On 06/26/2015 02:23 PM, Jeff Garzik wrote:
>>> Failure to plan now for a hard fork increase 6(?) months in the
>>> future produces that lumpy, unpredictable market behavior.
>>> 
>>> The market has baked in the years-long behavior of low fees.
>>> From the market PoV, inaction does lead to precisely that, a
>>> sudden change over the span of a few months.
>> 
>> Which market participants are you referring to?
>> 
>> I entered the bitcoin market with open eyes, aware that it faces
>> hard scalability challenges by design. I was also aware that
>> because of these challenges, eventually transaction fees would
>> have to rise.
>> 
>> Nevertheless, I made the decision to invest because of the
>> utility I gain from the anti-censorship, privacy, control, store
>> of value, and security aspects of bitcoin -- many of which stem
>> from decentralization, which others have demonstrated to be
>> linked to the block size.
>> 
>> On the other hand, there are undoubtedly other market
>> participants who heard hype about "zero fee transactions to
>> anywhere in the world", believed it would scale, and made
>> (mal)investments as a result.
>> 
>> As for how many market participants of each flavor, and how deep
>> their respective pockets, who knows? My experience in markets has
>> lead me to realize that it's never wise to assume I know what
>> "the market" does and doesn't know. If Jeff Garzik is right about
>> what the market has priced in, then yes, filled blocks will be
>> rocking the boat. But who's to say that the smartest, biggest
>> investors and traders don't already see this scaling problem, and
>> have already priced it in? In this case, a sudden large increase
>> in the block size is actually rocking the boat. The point is, you
>> can't know either way, so trying to pre-empt the market in this
>> way is erroneous.
>> 
>> Regarding entrepreneurial investment specifically, why should we
>> favor the entrepreneurs who require a more centralized bitcoin
>> over those who were more considerate of the possibility of rising
>> transaction fees when making their business models?
>> 
>> In my mind, we should favor neither, which is why I'm basically
>> in agreement with Pieter that this sense of "emergency" shouldn't
>> really be a part of the debate.
>> 
>> Not that I'm taking a stand on the specific block size issue
>> either way. I just think this particular line of reasoning
>> (presupposing what information the market has and has not already
>> baked in) is unsound. 
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVjlvYAAoJEGwAhlQc8H1malgH/jKkN27KpNecMQPcSZ+RX/s8
UDIvrqIsNesWUtwnWk1/2WcaoDA8V9ho42VPXmDgGh0GTmYKzKnBUuKPeIBfe1z+
XCtG7OeWRAlo+1Zk+dT8Crv/PEHocpy7q2OFW2iOapWfTEYO/1FTA58RYMYSmKXQ
0snm3QhVIdJA3/3BE12616y0+Oo2aV3H9El6buqQVge/26Z8X8TLIsY5h8dQbTBF
+J9Kq1YdJc8ogANZBpZfZBnURmNRsolyvQ+Sb5SxnpPQz73X3QPGaTyjnNsE0oVX
Occxx6BREN/byoelIS5HMRsEYExmALIisXTiM1kysKzbcYp+ysB6Uzvyp1GzbFg=
=PE+q
-----END PGP SIGNATURE-----