summaryrefslogtreecommitdiff
path: root/c9/cad4312ee662ef92c340f0ae5f4d345b8ba7fd
blob: d23127674369d1230db6d02dd224ff27c6257274 (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
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 73E6786
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Aug 2015 00:18:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 07F2511C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Aug 2015 00:18:47 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.162])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.riseup.net (Postfix) with ESMTPS id 33561C1CA7;
	Tue, 11 Aug 2015 17:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1439338727; bh=J4qvDt/fCpZOSGNY6GT0TrOQQxvdRP58Lh4OBI6Q25Y=;
	h=Date:From:To:CC:Subject:References:In-Reply-To:From;
	b=fWVaEImSpxqS9nmkyMbGMWi6vOMnsX6Ty9A5TAGN++UQVwl9ZWkmspcpTn/C6gV7i
	TDCIjrtxmmwRvxFxydVqPRggd5lU3uGYN0bzlmsAcJ+FoN5PfgArQxHBFG8I7F5C36
	ycFMXtrp3hKDGK5ILzZDV+WrkNEIUswR2psgtcJ0=
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id 1217D1413FA
Message-ID: <55CA90E5.6070508@riseup.net>
Date: Tue, 11 Aug 2015 17:18:45 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Mark Friedenbach <mark@friedenbach.org>, 
	Thomas Zander <thomas@thomaszander.se>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>	<2547793.e4fEoOQyIR@coldstorage>	<CAOG=w-thKPQUPx_ev3qzgkHjBfF3f_6EtFWq3QJdw1fETdnzhA@mail.gmail.com>	<1623892.Xps1bl6nlD@coldstorage>
	<CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com>
In-Reply-To: <CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
	UNPARSEABLE_RELAY, 
	URIBL_DBL_ABUSE_REDIR 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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
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, 12 Aug 2015 00:18:49 -0000

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

Hello, I thought these were good points, but I have a couple questions..
.

On 08/11/2015 12:08 AM, Mark Friedenbach via bitcoin-dev wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> On Monday 10. August 2015 23.03.39 <tel:2015%2023.03.39> Mark 
> Friedenbach wrote:
>> This is where things diverge. It's fine to pick a new limit or
>> growth trajectory. But defend it with data and reasoned
>> analysis.
> 
> We currently serve about 0,007% of the world population sending 
> maybe one transaction a month. This can only go up.
> 
> There are about 20 currencies in the world that are unstable and 
> showing early signs of hyperinflation. If even small percentage of
> these people cash-out and get Bitcoins for their savings you'd have
> the amount of people using Bitcoin as savings go from maybe half a
> million to 10 million in the space of a couple of months. Why so
> fast? Because all the world currencies are linked. Practically all
> currencies follow the USD, and while that one may stay robust and
> standing, the linkage has been shown in the past to cause 
> chain-effects.
> 
> It is impossible to predict how much uptake Bitcoin will take, but 
> we have seen big rises in price as Cyprus had a bailin and then
> when Greece first showed bad signs again. Lets do our due diligence
> and agree that in the current world economy there are sure signs
> that people are considering Bitcoin on a big scale.
> 
> Bigger amount of people holding Bitcoin savings won't make the 
> transaction rate go up very much, but if you have feet on the
> ground you already see that people go back to barter in countries
> like Poland, Ireland, Greece etc. And Bitcoin will be an
> alternative to good to ignore.  Then transaction rates will go up.
> Dramatically.
> 
> If you are asking for numbers, that is a bit tricky. Again; we are
> at 0,007%... Thats like a f-ing rounding error in the world
> economy. You can't reason from that. Its like using a float to do
> calculations that you should have done in a double and getting
> weird output.
> 
> Bottom line is that a maximum size of 8Mb blocks is not that odd. 
> Because a 20 times increase is very common in a "company" that is
> about 6 years old. For instance Android was about that age when it
> started to get shipped by non- Google companies. There the increase
> was substantially bigger and the company backing it was definitely
> able to change direction faster than the Bitcoin oiltanker can
> change direction.
> 
> ...
> 
> Another metric to remember; if you follow hackernews (well, the 
> incubator more than the linked articles) you'd be exposed to the
> thinking of these startups. Their only criteria is growth. and this
> is rather substantial growth. Like 150% per month.  Naturally, most
> of these build on top of html or other existing technologies.  But
> the point is that exponential growth is expected in any startup.
> They typically have a much much more agressive timeline, though.
> Every month instead of every year. Having exponential growth in the
> blockchain is really not odd and even if we have LN or sidechains
> or the next changetip, this space will be used. And we will still
> have scarcity.
> 
> 
> I'm sorry, I really don't want to sound like a jerk, but not a
> single word of that mattered. Yes we all want Bitcoin to scale such
> that every person in the world can use it without difficulty.
> However if that were all that we cared about then I would be remiss
> if I did not point out that there are plenty of better, faster, and
> cheaper solutions to finding global consensus over a payment ledger
> than Bitcoin. Architectures which are algorithmically superior in
> their scaling properties. Indeed they are already implemented and
> you can use them today:
> 
> https://www.stellar.org/ http://opentransactions.org/
> 
> So why do I work on Bitcoin, and why do I care about the outcome of
> this debate? Because Bitcoin offers one thing, and one thing only
> which alternative architectures fundamentally lack: policy
> neutrality. It can't be censored, it can't be shut down, and the
> rules cannot change from underneath you. *That* is what Bitcoin
> offers that can't be replicated at higher scale with a SQL database
> and an audit log.
> 
> It follows then, that if we make a decision now which destroys
> that property, which makes it possible to censor bitcoin, to deny
> service, or to pressure miners into changing rules contrary to user
> interests, then Bitcoin is no longer interesting. We might as well
> get rid of mining at that point and make Bitcoin look like Stellar
> or Open-Transactions because at least then we'd scale even better
> and not be pumping millions of tons of CO2 into the atmosphere from
> running all those ASICs.
> 
> On the other side, 3Tb harddrives are sold, which take 8Mb blocks 
> without problems.
> 
> 
> Straw man, storage is not an issue.
> 
> 
> You can buy broadband in every relevant country that easily
> supports the bandwidth we need. (remember we won't jump to 8Mb in a
> day, it will likely take at least 6 months).
> 
> 
> Neither one of those assertions is clear. Keep in mind the goal is
> to have Bitcoin survive active censorship. Presumably that means
> being able to run a node even in the face of a hostile ISP or
> government. Furthermore, it means being location independent and
> being able to move around. In many places the higher the bandwidth
> requirements the fewer the number of ISPs that are available to
> service you, and the more visible you are.
> 
> It may also be necessary to be able to run over Tor. And not just 
> today's Tor which is developed, serviced, and supported by the US 
> government, but a Tor or I2P that future governments have turned
> hostile towards and actively censor or repress. Or existing
> authoritative governments, for that matter. How much bandwidth
> would be available through those connections?
> 
> It may hopefully never be necessary to operate under such
> constraints, except by freedom seeking individuals within existing
> totalitarian regimes. However the credible threat of doing so may
> be what keeps Bitcoin from being repressed in the first place. Lose
> the capability to go underground, and it will be pressured into
> regulation, eventually.

Bitcoin (as well as the internet, and the world wide web) is already
regulated around the world.
There used to be a map that documented this fairly well, called
bitlegal (bitlegal.net) but the site is now parked or offline.  There
is an alternative visual picture of the subject at:
http://is.gd/vFgYrf
The upshot of that is that web wallets (which are popularized due to
convenience) cannot be considered to provide users with control over
their money - extended discussion on this here in the bitcoin.org
repository:
https://github.com/bitcoin-dot-org/bitcoin.org/issues/996

My question, therefore is this:
When you say "it will be pressured into regulation, eventually," what
do you mean? Are you implying that even the hardware wallets and
desktop wallets for bitcoin will be regulated to the point where they
cannot be used by individuals who actually care about being able to
circumvent financial censorship?  If so, explain how that is the case.

 I could see an argument where that might be the case to some degree
if you would mention it in the context of services like Chainalysis
and other companies that are in the process of setting up services for
corporation-states for "virtual currency compliance;" e.g.; if
activity can be scanned and if a state has a requirement you are
supposed to be registered with the state to use virtual currency at
some level, and if companies scan the blockchain and report this
information to states (as they now do), then as you say, the only
reasonable method of using virtual currencies would be one in which
location is masked and information about the nodes and history of
transactions can be hidden.  However, this requires more privacy and
anonymity effort in bitcoin development, but I don't think it would
actually keep people from using hardware and desktop wallets (although
I do think eventually people will, as they are beginning to now, be
gradually censored more and more from utilizing web wallets for
activities that they desire).

It seems to me that the existence of various tools and conditions
(external to the whole issue of legal constraints) are also very
important.  For example, various companies have recently made public
announcements that they will leave (or not operate in) New York due to
Bitlicense - Kraken, Shapeshift.io, poloniex, and others.  It's
understandable given the extreme nature of NY's approach (I personally
oppose any regulation of virtual currencies).  But technically, they
didn't have to cease operating, did they?  This was a failure in their
business model.  They made a big statement about how evil NY was and
fled the scene, perhaps never to return to serve NY.  (Note, I don't
live in NY, so I'm not personally being left out in the cold when
Kraken etc. leave, for the record.) As said, this was a failure in
Kraken, poloniex's, shapeshift's, etc., business model.  Why?  Because
here we are talking about web-based services.  A distributed,
decentralized, peer-to-peer model in which the user has a piece of
software on their computer (think openbazaar or bitsquare) is far and
away better than services which are web based.  Why?  Because systems
which are set up such as (openbazaar, bitsquare) don't have to worry
about the constraints of state boundaries or shifting legal things,
nor do the people who made the software end up holding keys on behalf
of the users.  If Kraken, poloniex, etc., had bothered to develop
contingency software (similar to what is being worked on with
https://bitsquare.io/ for example) for users who might be affected in
jurisdictions where corporation-states Just Don't Get It (read... NY,
and possibly CA, as examples) then maybe they wouldn't have to worry
about it at all.  It just would be a matter of users installing a
piece of software from their website, discontinuing the web-based
exchange for that state, and directing users for highly regulated
states to a download page for the decentralized exchange software.
Not that hard really - but something we haven't seen done yet by the
big exchanges.

I have another question for you below...

> 
> To the second point, it has been previously pointed out that large 
> miners stand to gain from larger blocks, for the same basic
> underlying reasons as selfish mining. The incentive is to increase
> blocks, and miners are able to do so at will and without cost. I
> would not be so certain that we wouldn't see large blocks sooner
> than that.
> 
> 
> We should get the inverted bloom filters stuff (or competing 
> products) working at least on a one-to-one basis so we can solve
> the propagation time problem. There frankly is a huge amount of
> optimization that can be done in that area, we don't even use
> locality (pingtime) to optimize distribution.
>> From my experience you can expect a 2-magnitude speedup in that
> same 6 month period by focusing some research there.
> 
> 
> This is basically already deployed thanks to Matt's relay network. 
> Further improvements are not going to have dramatic effects.
> 
> 
> Remember 8Gb/block still doesn't support VISA/Mastercard.
> 
> 
> No, it doesn't. And 8GB/block is ludicrously large -- it would 
> absolutely, without any doubt destroy the very nature of Bitcoin, 
> turning it into a fundamentally uninteresting reincarnation of the 
> existing financial system.

Why do you say 8GB / block would destroy the very nature of Bitcoin?
I don't see that it would destroy bitcoin... but also, what would
cause 8GB to happen very soon?  As I understood it, any process would
phase increases.  Explain how that would destroy the very nature of
Bitcoin?

Blocksize is extremely likely to get bigger (I'm supposing here that
some version of Garzik's BIP 100 or something very close to it is what
will likely be adopted and that the blocksize would be voted on
something like this:
https://bitcoin.stackexchange.com/questions/37943/bip-100-what-votes-are
- -possible

Am I wrong?  Please let me know if I'm dumb.

I am aware consensus isn't precisely there yet, but I'm just curious.


> And still be unable to compete with VISA/Mastercard.
> 
> So why then the pressure to go down a route that WILL lead to
> failure by your own metrics?
> 
> I humbly suggest that maybe we should play the strengths of
> Bitcoin instead -- it's trustlessness via policy neutrality.
> 
> Either that, or go work on Stellar. Because that's where it's
> headed otherwise.
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVypDkAAoJEGxwq/inSG8CSAEH/00rWd1wzGU3vhXqzVCzPcHx
GnMpR3iiSYpjm1Wt1tHc1SsJnhcVL93iNuOpQMTU7jXhj9qEYu58uoVz+XnfeiFY
i4B4awt3fuR33+D5Y+IKAm3KLd1HYpcSq7N2LSSJli2r8zvum+rcm5CXppR8qxJM
nmjlS/Tp6FwKhBzqOeBGK6vWnigs1KJgllO4AzNKPSXwFPhQKZGMbH1cFx5qKxp9
5UmU4bxZNKmOtjvfFyptR1lY+JYqaoQeOkdnlOYWAaClSiH1y8DnzJtpVSImw3X5
ZYI5GUp1HgE4RrxK8cykPn5j90elHSWe+GaREjMcidnyJYvtlPapnEpEnda5iBk=
=pxSx
-----END PGP SIGNATURE-----