From: "Wladimir J. van der Laan" <laanwj@gmail•com>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Thu, 7 May 2015 13:20:43 +0200 [thread overview]
Message-ID: <20150507112042.GB30564@amethyst.visucore.com> (raw)
In-Reply-To: <554A91BE.6060105@bluematt.me>
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
next prev parent reply other threads:[~2015-05-07 11:20 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 22:12 Matt Corallo
2015-05-06 22:30 ` slush
2015-05-06 23:06 ` Eric Lombrozo
2015-05-06 22:44 ` Tier Nolan
2015-05-06 23:12 ` Matt Corallo
2015-05-06 23:33 ` Tier Nolan
2015-05-06 23:41 ` Matt Corallo
2015-05-07 2:16 ` Peter Todd
2015-05-06 23:11 ` Matt Whitlock
2015-05-06 23:13 ` Matt Corallo
2015-05-07 0:00 ` Tom Harding
2015-05-07 0:07 ` Bryan Bishop
2015-05-07 0:37 ` Gregory Maxwell
2015-05-07 1:49 ` Peter Todd
2015-05-07 3:03 ` Justus Ranvier
2015-05-08 11:02 ` Thomas Zander
2015-05-08 20:17 ` Aaron Voisine
2015-05-07 3:47 ` Pieter Wuille
2015-05-07 9:25 ` Mike Hearn
2015-05-07 10:12 ` Peter Todd
2015-05-07 10:42 ` Btc Drak
2015-05-07 10:52 ` Jorge Timón
2015-05-07 11:15 ` Andrew
2015-05-07 11:29 ` Mike Hearn
2015-05-07 12:26 ` Jorge Timón
2015-05-07 14:05 ` Mike Hearn
2015-05-07 14:18 ` Bryan Bishop
2015-05-07 14:22 ` Peter Todd
2015-05-07 14:40 ` Peter Todd
2015-05-07 14:52 ` Gavin Andresen
2015-05-07 14:56 ` Peter Todd
2015-05-07 15:04 ` Alex Morcos
2015-05-07 15:09 ` Jeff Garzik
2015-05-07 15:12 ` Mike Hearn
2015-05-07 15:17 ` Jeff Garzik
2015-05-07 15:29 ` Mike Hearn
2015-05-07 15:35 ` Jeff Garzik
2015-05-07 16:18 ` Justus Ranvier
2015-05-07 16:21 ` Jorge Timón
2015-05-07 17:29 ` Peter Todd
2015-05-07 19:37 ` Mike Hearn
2015-05-07 19:44 ` Jérémie Dubois-Lacoste
2015-05-07 20:20 ` Jérémie Dubois-Lacoste
2015-05-07 15:58 ` Matthew Mitchell
2015-05-07 16:47 ` Matthew Mitchell
2015-05-07 17:26 ` Matt Corallo
[not found] ` <CABsx9T2vAQyZODRE9apu0R1n=LybssQcuTYD7P3mAQH_Fv6QCQ@mail.gmail.com>
2015-05-07 17:40 ` [Bitcoin-development] Fwd: " Gavin Andresen
2015-05-07 17:43 ` [Bitcoin-development] " Mike Hearn
2015-05-07 18:03 ` Btc Drak
2015-05-07 18:06 ` Mike Hearn
2015-05-07 18:21 ` Ross Nicoll
2015-05-07 18:40 ` Gavin Costin
2015-05-07 18:46 ` Btc Drak
2015-05-07 19:31 ` Bernard Rihn
2015-05-07 19:31 ` Alan Reiner
2015-05-07 19:54 ` Jeff Garzik
2015-05-07 19:59 ` Justus Ranvier
2015-05-08 1:40 ` Tom Harding
2015-05-08 2:09 ` Jeff Garzik
2015-05-08 5:13 ` Tom Harding
2015-05-08 9:43 ` Mike Hearn
2015-05-08 15:23 ` Alan Reiner
2015-05-08 14:59 ` Alan Reiner
2015-05-08 15:49 ` Jeff Garzik
2015-05-13 10:37 ` Oliver Egginger
2015-05-13 11:25 ` Angel Leon
2015-05-08 17:17 ` Andrew
2015-05-08 17:51 ` Alan Reiner
[not found] ` <CADZB0_bK+YsK8sN-di2pynvjsq5VjSvnEu0-cCGhPqFunyVm7Q@mail.gmail.com>
2015-05-09 12:02 ` Andrew
2015-05-09 12:53 ` Justus Ranvier
2015-05-09 18:33 ` Andrew
2015-05-08 1:51 ` Joel Joonatan Kaartinen
2015-05-08 3:41 ` Peter Todd
2015-05-07 18:38 ` Chris Wardell
2015-05-07 18:55 ` Alex Mizrahi
2015-05-07 18:59 ` Ross Nicoll
2015-05-07 19:03 ` Matt Corallo
2015-05-07 19:13 ` Jeff Garzik
2015-05-07 19:34 ` Mike Hearn
2015-05-07 21:29 ` Matt Corallo
2015-05-07 23:05 ` 21E14
2015-05-07 15:33 ` Jorge Timón
2015-05-07 16:11 ` Mike Hearn
2015-05-07 16:47 ` Jorge Timón
2015-05-07 16:59 ` Gavin Andresen
2015-05-07 17:42 ` Peter Todd
2015-05-07 18:05 ` Jorge Timón
2015-05-07 19:57 ` Btc Drak
2015-05-07 15:39 ` Btc Drak
2015-05-07 13:02 ` Peter Todd
2015-05-07 19:14 ` Matt Corallo
2015-05-07 11:55 ` Dave Hudson
2015-05-07 13:40 ` Jorge Timón
2015-05-08 4:46 ` Tom Harding
2015-05-07 14:04 ` Jeff Garzik
2015-05-07 14:32 ` Peter Todd
2015-05-07 14:38 ` Justus Ranvier
2015-05-07 14:49 ` Peter Todd
2015-05-07 15:13 ` Justus Ranvier
2015-05-07 15:25 ` Peter Todd
2015-05-07 15:04 ` Jeff Garzik
2015-05-07 15:16 ` Justus Ranvier
2015-05-07 15:27 ` Jeff Garzik
2015-05-07 15:33 ` Justus Ranvier
2015-05-07 15:47 ` Jeff Garzik
2015-05-07 15:50 ` Justus Ranvier
2015-05-07 11:20 ` Wladimir J. van der Laan [this message]
2015-05-07 11:30 ` Eric Lombrozo
2015-05-07 15:56 ` Jeff Garzik
2015-05-07 16:13 ` Mike Hearn
2015-05-07 16:54 John Bodeen
2015-05-08 20:38 Raystonn .
2015-05-08 20:40 ` Mark Friedenbach
2015-05-08 20:51 Raystonn
2015-05-08 20:55 ` Mark Friedenbach
2015-05-08 21:01 Raystonn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150507112042.GB30564@amethyst.visucore.com \
--to=laanwj@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-list@bluematt$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox