
The Bitcoin Blocksize: A Summary - alexcasalboni
http://rusty.ozlabs.org/?p=535
======
jackgavigan
What's really interesting for me about the Blocksize Debate is what it reveals
about Bitcoin's governance. Most of the people involved agree that the
blocksize limit should be increased (with the notable exception of Peter Todd)
and the main disagreement seems to be about _how_ (and how quickly) and the
increase should happen.

There also seems to be a hint of power struggle in the backlash against
Gavin's push to increase the limit to 8MB.

I personally believe that Bitcoin will need to evolve if it has any hope of
surviving and maintaining its value. The fact that the core community appears
to be having a tough time reaching consensus on this particular issue doesn't
bode particularly well for the sort of changes that may be required in the
future (e.g. changing the proof-of-work mechanism).

~~~
Bae8anoh
Read up on the history of Mike Hearn, he has wanted to fork Bitcoin into his
own governance for years, this is just an excuse.

In 2011 he was proposing to Satoshi that he should take over the project[0],
in 2013 he was trying to pitch the concept that development was stagnant and
that a fork was needing to fix it[1][2], and now in 2015 it's again come about
that he has found an excuse to attempt it (this time with some mild enthusiasm
from part of the community). In the past Mike Hearn has pitched censorship
features in Tor[3], attempting to subvert the inclusion of privacy fixes in
Tor[4], proposed "redlists" of supposedly undesirable transactions in
Bitcoin[5]. The current branch of Bitcoin XT already includes an alarmingly
ill advised hardcoded blacklist of supposedly Tor exit nodes which are de-
prioritized[6].

The measure of "consensus" has already slipped down to 75% when it become
clear that 95% of the hashrate was never going to happen. The solution from
Mike Hearn is that if miners don't want to get to 75%, he will simply hardcode
his own centralized markers into Bitcoin wallets[7] to make sure it happens
regardless. This is unbelievably toxic stuff, and spells certain death of
Bitcoin if it goes ahead.

[0]:
[http://pastebin.com/raw.php?i=3kt5Reeh](http://pastebin.com/raw.php?i=3kt5Reeh)

[1]:
[https://www.reddit.com/r/Bitcoin/comments/29qafs/circle_ceo_...](https://www.reddit.com/r/Bitcoin/comments/29qafs/circle_ceo_issues_thinly_veiled_threat_of_hard/)

[2]: [http://www.coindesk.com/bitcoin-core-development-falling-
beh...](http://www.coindesk.com/bitcoin-core-development-falling-behind-warns-
mike-hearn/)

[3]: [https://lists.torproject.org/pipermail/tor-
dev/2014-July/007...](https://lists.torproject.org/pipermail/tor-
dev/2014-July/007167.html)

[4]: [https://lists.torproject.org/pipermail/tor-
dev/2014-July/007...](https://lists.torproject.org/pipermail/tor-
dev/2014-July/007173.html)

[5]:
[https://bitcoinfoundation.org/forum/index.php?/topic/505-coi...](https://bitcoinfoundation.org/forum/index.php?/topic/505-coin-
tracking/)

[6]:
[https://github.com/bitcoinxt/bitcoinxt/blob/73c9efe74c5cc8fa...](https://github.com/bitcoinxt/bitcoinxt/blob/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23/src/torips.h)

[7]:
[http://sourceforge.net/p/bitcoin/mailman/message/34162353/](http://sourceforge.net/p/bitcoin/mailman/message/34162353/)

~~~
mike_hearn
Oh dear, you have some serious anger issues, don't you?

I have not wanted to fork Bitcoin for years. I still don't - I have many
better things to do, like working on Lighthouse or oh .... really anything
else. Screwing about with gitian and gcc all day is right at the bottom of my
list of "fun things to do on a sunny day".

But the fact that Bitcoin Core was heading for disaster was obvious for a long
time now. It has been progressively abandoning things that the user community
finds important: SPV wallets, unconfirmed transactions, now even the notion of
growing the platform at all have all become "controversial" and therefore
untouchable. Anyone who suggests that maybe these things are useful is
immediately branded an idiot. Combine with a maintainer who hides any time a
decision is needed and you have a recipe for deadlock.

You seem to think I hate Tor. I am actually the maintainer of a full blown Tor
implementation (Orchid). I've done a lot of work on integrating it into
bitcoinj and I'm basically the only guy who can actually move the needle on
Tor/Bitcoin usage, by enabling the use of it by default in consumer wallets
that have hundreds of thousands of installs. We're not there yet (it's still
too slow) but we're a lot closer than before.

This doesn't change the fact that Tor is heavily abused. It can be useful but
it's a frequent source of attacks of all kinds. So finding ways to get the
good without the bad involves some tricky coding.

Below, you say "anyone can jam the network with just two IP addresses". Yes,
that's unfortunate isn't it. I've been sounding the alarm about Bitcoin Core's
poor DoS protection for years. Nobody listened, that's why I have now written
a new anti-DoS system that can handle this sort of thing. It starts by
clustering and deprioritising Tor because we've seen actual jamming attacks
that came through Tor, and because using it is a lot safer and more convenient
for an attacker than using your own IP addresses or using a botnet. But it
absolutely should be extended to have more advanced heuristics. Instead of
whinging that (gasp) loading a file from a web server is "insane", maybe you
should be writing code instead.

~~~
jwilkins
Core has been moving away from failed experiments like unconfirmed
transactions. (How that wasn't an obviously flawed idea in the first place is
beyond me, but hey, might as well get the data..)

No one in core is saying that growth is a bad thing and must be avoided, the
key point that has been repeated is that the approach you and Gavin took with
XT was not a good one. It has been poorly thought out from the get go. The
initial proposal contended that we had to go to 20MB or we were doomed,
remember that?

Bitcoin needs a steady hand at the wheel. Wladimir and co are putting out a
solid amount of code with remarkably little disruption.

Your statement re: orchid is a little misleading. You might be a maintainer,
but
[https://github.com/subgraph/Orchid/commits/develop](https://github.com/subgraph/Orchid/commits/develop)
shows that your contributions are minor.
[https://github.com/subgraph/Orchid/graphs/contributors](https://github.com/subgraph/Orchid/graphs/contributors)

Why do you continue to cause this degree of public spectacle and unnecessary
drama?

~~~
mike_hearn
Orchid is developed in the bitcoinj tree these days, not the subgraph
repository. Upstream imported changes one time, but I continue to handle it on
a day to day basis.

Unconfirmed transactions are not at all a failure. The data is in - usage of
them has been increasing over time, not decreasing. When someone attacked
shapeshift.io (an exchange that uses them!) and double spent, their response
was "We get significant value from fast payments, we can easily patch the
exploit they used, and we're going to continue with our current path".

The initial proposal was not "20mb or we're doomed". It was "we need more
space or we're doomed, 20mb seems to work OK based on <reasons>". But lowering
it to make the Chinese pools happy is not a problem, as it's an upper limit.

I'm afraid the drama has all been created by others. The limit was always
meant to be removed, remember? We're not the ones suddenly trying to change
the plan.

------
CydeWeys
An important thing to consider is that, while there probably is an ideal block
size for the current set of conditions (risk of centralization, average
Bitcoin network latency, rate of transactions), there's no a priori reason
that it should be 1 MB. It may well be less than 1 MB, or it may well be more.
1 MB is arbitrary. My best guess is that the optimal current block size is
somewhat larger than 1 MB.

~~~
pstrateman
> My best guess is that the optimal current block size is somewhat larger than
> 1 MB.

The optimal current block size is without a doubt smaller than 1MB.

The two most important metrics for block size limit are node count and miner
validation.

Node count has been continually dropping for years despite heroic efforts to
improve performance in bitcoin core.

Miners have been found to be blindly mining blocks in an attempt to reduce
their orphan rates.

~~~
statoshi
The optimal block size is obviously 0, as these blocks will propagate through
the network the fastest, thus lowering the orphan rate to nearly 0, and will
require the least resource usage (bandwidth, hard disk space, CPU cycles) for
full node operators.

... see what I did there?

~~~
pstrateman
The blocksize limit is fundamentally a trade off between capacity and
usability.

Too far in either direction is bad.

The evidence strongly supports the argument that the current 1MB limit is too
high.

------
meshr
I have a question, why not to solve the bitcoin issues another way: by
decreasing the amount of transactions by changing the way of paying with
bitcoins. I suggest using bitcoin wallets as a cash banknotes and send bitcoin
private keys (i.e. the wallet itself) instead of paying from the wallet to
transfer money. So everyone should have a set of bitcoin wallets with
different bitcoin amounts instead of using one bitcoin wallet. This method has
some advantages: instant transactions, zero fees and anonymity. The
disadvantage that I can see is the necessity of development the mechanisms of
having “the change”, probably specialized bitcoin fork, or it can be solved by
using hybrid method: usual transaction + bitcoin wallet private keys sending.
“The change” is not necessary for some types of payments: like gifts, balance
replenish, or periodic payments which bitcoin has lack of support now. It’ll
definitely help to decrease amount of transactions here.

~~~
kang
Because no one prevents the sender to keep a copy of that wallet. Wallets are
nothing but list of your private keys. Suppose I gave my private keys to you,
what prevents me to not use them before you use those keys?

------
nothrabannosir
> A large mining pool used their power to double spend and steal thousands of
> bitcoin from a gambling service[3]. When it was noticed, they blamed a rogue
> employee. No money was returned, _nor any legal action taken._

Wasn't that the point of Bitcoin?

------
pmorici
Something I haven't seen discussed that I'm curious about is why a larger max
block size necessarily means lower transaction fees. Ultimately miners decide
which transactions to include in a block or reject so if miners feel they need
to get a certain fee per transaction that is their prerogative regardless of
the block size.

~~~
haakon
Miners typically include the highest-paying transactions first, naturally. If
there is a consistent backlog of transactions waiting to be included, low-fee
or no-fee transactions may have to wait a long time, perhaps indefinitely.
This creates fee pressure - at least in a scenario where Bitcoin clients are
intelligent about fees and are able to add fees to pending transactions so
that block space is effectively auctioned out. This is not necessarily today's
scenario, but Bitcoin is working towards it.

But if blocks are not consistently full and there's no significant backlog,
there is room for cheap transactions. This has been the case up to now. If the
block size limit were to be increased, the assumption goes, there would again
be room for cheap transactions - until they fill up again.

In practice, we don't know if miners would actually include cheap transactions
if it makes their blocks significantly bigger. Their incentives seem to be
against it, since bigger blocks have higher orphan rates.

~~~
maaku
> In practice, we don't know if miners would actually include cheap
> transactions if it makes their blocks significantly bigger. Their incentives
> seem to be against it, since bigger blocks have higher orphan rates.

This is incorrect in fact. The Google search term you'll need is selfish
mining. It's a well studied phenomenon that for sufficiently large miner they
stand to benefit from having larger blocks.

------
t0mbstone
The problem with bitcoin is the idea that it even requires a mining pool or
transaction fee.

Bitcoin will die the moment someone figures out how to build a decentralized
crypto-currency that doesn't need a stupid idea like "mining" to be functional
and secure.

~~~
maaku
> Bitcoin will die the moment someone figures out how to build a decentralized
> crypto-currency that doesn't need a stupid idea like "mining" to be
> functional and secure.

Yup. But I wouldn't hold my breath. No one has ever created a decentralized
consensus algorithm with the properties bitcoin has, before or since. And
since bitcoin achieves its unique properties as a result of the economic costs
of mining, asking for a mining-less bitcoin is kinda like wishing for a
perpetual motion machine.

~~~
DennisP
Well there are several altcoins using proof-of-stake. Whether they'll be as
secure in the long term is an open question, but I wouldn't go so far as to
call it a perpetual motion machine.

~~~
pstrateman
Proof of Stake does not work.

[https://download.wpsoftware.net/bitcoin/pos.pdf](https://download.wpsoftware.net/bitcoin/pos.pdf)

------
davidgerard
Important point about this debate:

* There is not the organic transaction growth for this to even be a problem, and there is no evidence there ever will be. Bitcoin's only real-world use case is illicit goods.

* Even 20MB blocks would be susceptible to a cheap spam attack like the DDOS "stress test" a few weeks ago.

This is the quintessential bikeshed: a fight to the death for insanely low
stakes.

~~~
maaku
> Bitcoin's only real-world use case is illicit goods.

Please get up to date with things. Bitcoin is huge in the remittance world,
and bitcoin-like technology is being tentatively explored in all realms of
financial technology.

~~~
davidgerard
I really would like you to detail these cases for which Bitcoin is huge in the
remittance world, because this would be new and useful information for me to
update myself on. If I'm wrong, I'd like to know.

------
Andrew_Quentin
For people who are not familiar with the whole blocksize debate which has been
raging in the bitcoin community for around three months now, even leading to
outright censorship by theymos, perhaps asked to do so by "someone", the
author of the post is highly biased and the article is biased too.

It refers for example to an attack by Ghash, and then dismisses their
explanation that it was an employee without providing much evidence and
without pointing that his dismissal of their explanation was simply
speculation. Moreover, it suggests that Ghash gained 50% of hashing power and
nothing happened. In fact a lot happened, so much so that Ghash currently has
around 2% of the hashing power.

It is hard to present an unbiased view when one is necessarily biased. But as
an engineer, one would expect someone like Rusty to present a more complete
view of the problems as both sides see them and the solutions as both sides
present them. His failure to do so raises questions on his integrity pertinent
to his responsibility to present to the community a software which can work
and problems are not hidden under the carpet.

Specifically, the Lightning Network which wishes to change bitcoin from a
payment system as stated by satoshi to some experimental, uncoded, and
conceptually flawed settlement system needs to be openly presented with all
its attack vectors laid out as a lot of money could be lost otherwise. I do
not see how I can trust such code however when one is extremely biased and
makes no attempt whatever to overcome it.

Good enough is not sufficient where money is concerned Rusty. And to suggest
that Gavin, or even Satoshi himself, is myopic, seeing only the "user" ui
point of view, is slightly idiotic and shows that you do not quite understand
the debate or you wish to wilfully mislead.

~~~
RustyRussell
> It refers for example to an attack by Ghash, and then dismisses their
> explanation that it was an employee without providing much evidence and
> without pointing that his dismissal of their explanation was simply
> speculation.

I did not dismiss it, how did you read that?

> Moreover, it suggests that Ghash gained 50% of hashing power and nothing
> happened. In fact a lot happened, so much so that Ghash currently has around
> 2% of the hashing power.

That doesn't seem to be related: they were close to 50% 4 months after the
theft incident, and again 10 months after. Someone else queried that, and I
did some digging to ensure that my memory of event order was correct. See:
[https://www.reddit.com/r/Bitcoin/comments/3fxvbr/blocksize_a...](https://www.reddit.com/r/Bitcoin/comments/3fxvbr/blocksize_a_debate_summary/cttdfi4?context=3)

> And to suggest that Gavin, or even Satoshi himself, is myopic, seeing only
> the "user" ui point of view

"only"? In my final paragraph I tried to draw the distinction between the
priorities of the different views.

You seem to have read things in my article which aren't intended :(

