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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1YqJrE-0007ao-Lb
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:20:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.42 as permitted sender)
client-ip=74.125.82.42; envelope-from=laanwj@gmail.com;
helo=mail-wg0-f42.google.com;
Received: from mail-wg0-f42.google.com ([74.125.82.42])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqJrD-0005rp-G2
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:20:48 +0000
Received: by wgic8 with SMTP id c8so13576382wgi.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 04:20:41 -0700 (PDT)
X-Received: by 10.194.133.71 with SMTP id pa7mr6545972wjb.155.1430997641477;
Thu, 07 May 2015 04:20:41 -0700 (PDT)
Received: from amethyst.visucore.com (dhcp-089-098-016-041.chello.nl.
[89.98.16.41])
by mx.google.com with ESMTPSA id wr2sm2878374wjb.45.2015.05.07.04.20.40
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Thu, 07 May 2015 04:20:40 -0700 (PDT)
Date: Thu, 7 May 2015 13:20:43 +0200
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Message-ID: <20150507112042.GB30564@amethyst.visucore.com>
References: <554A91BE.6060105@bluematt.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554A91BE.6060105@bluematt.me>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqJrD-0005rp-G2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 11:20:48 -0000
On Wed, May 06, 2015 at 10:12:14PM +0000, Matt Corallo wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
I'm weakly against a block size increase in the near future. Some arguments follow. For sake of brevity, this ignores the inherent practical and political issues in scheduling a hardfork.
Against:
1. The everyone-verifies-everything approach inherently doesn't scale well. Yes, it is possible to increase the capacity, within limits, without completely destroying the system, but if scaling turns out to be a success, even a 20-fold increase is just a drop in the bucket (this will not make a decentralized Changetip possible). The gain will always be linear, at a total cost that scales in the number of (full node) users times the block size. The whole idea of everyone verifying the whole world's bus tickets and coffee purchases seems ludicrous to me. For true scaling, as well as decentralized microtransactions, the community needs to work on non-centralized 'level 2' protocols for transactions, for example the Lightning network.
I prefer not to rely on faith that 'Moore's law' - which isn't a physical law but a trend - will save us. And it doesn't so much apply to communication bandwidth as its techniques are more diverse. E.g. for Bitsat, 20MB blocks will push the limit.
2a. Pushing up bandwidth and CPU usage will, inevitably, push people at the lower end away from running their own full nodes. Mind you, the sheer number of full nodes is not the issue, but Bitcoin's security model is based on being able to verify the shared consensus on one's own. A lot of recent development effort went into making the node software less heavy. Yes, one could switch to SPV, but that is a serious privacy compromise. In the worst case people will feel forced to move to webwallets.
That was about sustained bandwidth - syncing a new node from scratch through the internet will become unwieldy sooner - this can be worked around with UTXO snapshots, but doing this in a way that doesn't completely pull the rug under the security model needs research (I'm aware that this could be construed the other way, that such a solution will be needed eventually and fast block chain growth just accelerates it).
2b. The bandwidth bound for just downloading blocks is ~4GB per month now, it will be ~52GB per month. Behind Tor and other anonimity networks, nodes will reveal themselves by the sheer volume of data transferred even to only download the block chain. This may already be the case, but will become worse. It may even become harmful to Tor itself.
3a. The costs are effectively externalized to users. I, hence, don't like calling the costs "trivial". I don't like making this decision for others, I'm not convinced that they are trivial for everyone. Besides, this will increase supply of block chain space, and thus push down transaction fees, but at cost to *all users*, even users that hardly do any transactions. Hence it favors those that generate lots of transactions (is that a perverse incentive? not sure, but it needs to be weighted in any decision).
3b. A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I'm afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax, until it's again time for a block chain increase, and then they'll rally Gavin again, never resulting in a smart, sustainable solution but eternal awkward discussions like this.
4. We haven't solved the problem of arbitrary data storage, and increasing the block size would compound that problem. More data storage more storage available for the same price - and up to 20x faster growth of the UTXO set, which is permanent (more externalization). More opportunity for pedonazis to insert double-plus ungood data, exposing users to possible legal ramifications.
For:
1. First, the obvious: It gives some breathing room in a year (or whenever the hard fork is planned). If necessary, it will allow more transactions to be on-chain for a while longer while other solutions are being implemented.
2. *Allowing* 20MB blocks does not mean miners will immediately start making them. Many of them aren't even filling up to the 1MB limit right now, probably due to latency/stale block issues. This makes objection 2 milder, which is about *worst case* bandwidth, as well as 4, as the end result may not be 20MB blocks filled with arbitrary "junk".
3. Investment in off-chain solutions is guided by not only fee pressure, but also other reasons such as speed of confirmation, which is unreliable on-chain. This eases objection 3b.
Whew, this grew longer than I expected. To conclude, I understand the advantages of scaling, I do not doubt a block size increase will *work* Although there may be unforseen issues, I'm confident they'll be resolved. However, it may well make Bitcoin less useful for what sets it apart from other systems in the first place: the possibility for people to run their own own "bank" without special investment in connectivity and computing hardware.
Also the politics aspect (at some point it becomes a question of who decides for who? who is excluded? all those human decisions...) of this I don't like in the least. Possibly unavoidable at some point, but that's something *I*'d like to kick down the road.
Wladimir
|
