summaryrefslogtreecommitdiff
path: root/6a/5c8d2c771b875f46fd079b47b0e34d316a00ae
blob: ef0136286122b420195f0ca95d5a38ea4bc926c5 (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
Return-Path: <thomas@thomaszander.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 95CBF7E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 11:19:21 +0000 (UTC)
X-Greylist: delayed 00:06:39 by SQLgrey-1.7.6
Received: from mta03.svc.cra.dublin.eircom.net
	(mta03.svc.cra.dublin.eircom.net [159.134.118.145])
	by smtp1.linuxfoundation.org (Postfix) with SMTP id C2BF41D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 11:19:20 +0000 (UTC)
Received: (qmail 6121 messnum 17190849 invoked from
	network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]);
	11 Aug 2015 11:12:40 -0000
Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14)
	by mta03.svc.cra.dublin.eircom.net (qp 6121) with SMTP;
	11 Aug 2015 11:12:40 -0000
Received: from coldstorage.localnet ([83.71.193.244])
	by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway
	id 3PCW1r00t5Gqgwr01PCfMD; Tue, 11 Aug 2015 12:12:39 +0100
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 11 Aug 2015 13:10:48 +0200
Message-ID: <1681438.F7ZY8xlbAj@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<1623892.Xps1bl6nlD@coldstorage>
	<CAOG=w-u7KwhTg1b-WvD97ZY5oBbvLBdsOGLedS=fx1fBw_hZ8g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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: Tue, 11 Aug 2015 11:19:21 -0000

On Tuesday 11. August 2015 00.08.42 Mark Friedenbach wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
> So why do I work on Bitcoin, [] It can't
> be censored, it can't be shut down, and the rules cannot change from
> underneath you.

Fully agreed, and I like that a lot as well.

> It may hopefully never be necessary to operate under such constraints,
> except by freedom seeking individuals within existing totalitarian regimes.

I think remembering the Internet architecture here is viable.
There is a saying that censorship on the internet is seen as a defect and 
route around. Bitcoin follows the same concept, and arguable is even better at 
it since transactions don't have to be delivered to the network in real time. 
It can be shipped by carrier pigeon in the extreme case ;)
Or though smileys over skype chat...


> 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.

I understand your point, its a good one.

Here is my counter argument; countries (or states) that fail to legally get 
the bandwidth to do mining, are not an indicator for the success of Bitcoin.
Tor will work fine with a full node (or gnunet, if you want), just make sure 
you take the transmission delays into account.
And naturally, there is the point that actual end users don't need a full 
node. The system as a whole will work just fine for people in totalitarian 
regimes as long as 100% of the world doesn't reach that point.
With various nodes in Sealand (near the UK) and miners in China, the system 
would still work for users in New York.

> > 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.
> 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?

Naturally, I was referring to the existing proposal that 8Gb blocks would be 
reached only in many years. Its a really long way away.

And if you read my previous replies on this thread you can see a more 
substantial argument which I'll make brief here;
I'm not suggesting we scale the blocksize to accomodate for the next 10 years 
of growth.
Instead I'm suggesting that we use solutions like Lightning and sidechains and 
anything people can invent as soon as possible.  But we need bigger blocks as 
well. Because not any single solution is the answer, we need a combination of 
multiple.

There really is no reason to suspect we can't actually increase the blocksize 
in some months as the first thing we do.

-- 
Thomas Zander