Comment by DennisP | Hacker News Reader

Comment by DennisP | Hacker News Reader

Parent Full thread

The Bitcoin devs are working right now on something that could increase the block size more than that.

The main thing that limits the size is latency in propagating large blocks. But most miners already have most of the transactions in each block. All you really need to send is a small data structure that lets the miner reconstruct the full block, from the transactions he already has. An invertible bloom lookup table makes that pretty easy: http://www.i-programmer.info/programming/theory/4641-the-inv...

Using this, a home bandwidth connection could handle about 45,000 tx/sec, which is more than Visa at peak: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

The other problem is blockchain storage. They're planning to prune old empty addresses, which should help a lot. A more radical solution is to store the full blocks only for the last couple months, and only a linked set of hashes back to the beginning. That might be a bigger change than Bitcoin can handle, but another currency could do it.

Transactions not having to propagate across the network a second time in blocks is certainly nice, but that doesn't solve all the problems of large blocks. As you said, that proposal is focused on maintaining an incentive for miners to create large blocks without having to worry about orphan races.

All full nodes still need to process everyone else's transactions, so bandwidth requirements are still hefty, just not squared. Even if someone's home connection can theoretically maintain 45k tx/s, how many of those generous full node maintainers out there will be excited about the prospect of their Bitcoin node using their entire internet connection? Storage requirements will also still be fairly intensive, even if nodes prune everything but the UTXO set (that needs to be stored in RAM--although that can change--it's a half gig).

Not to mention that proposal can create problems where miners withhold transactions from other miners so they can build secret chains that other miners can't build on until they have see the withheld transactions.

All that aside, your comment still ignores the reality of the situation. The Bitcoin network has been bleeding nodes for ages, and has settled around 6500-7000, probably a little more[1]. What that says to me is that even if Gavin's 20MB block proposal works for him on paper and on his VPS, the reality is that we can barely maintain a healthy node landscape with the current stresses of the network. Upping it to 20MB will likely cause a "shedding" and we will come to the new normal, so on and so forth, until we increase the block size so much that we end up with only a handful of nodes.

This is all assuming the network continues grows to those needs, which I found doubtful.

[1]http://getaddr.bitnodes.io/

VISA is typically around 2000 tx/sec, so it'd only saturate at peak. And anyone with gigabit fiber won't be bothered even at peak. If we reach that traffic level, gigabit will probably be fairly widespread by then.

I don't see how those nefarious miners could succeed, unless they were powerful enough to carry out a 51% attack anyway. Otherwise their secret chain will soon fall behind the public chain.

Are there plans/other networks which distribute blockchain storage and mining somehow?

The Ethereum project has some ideas for making it so each node only has to see a subset of transactions, instead of all of them. It's not an easy problem.

They and a few other projects also hope to pull off a "proof-of-stake" system that mostly does away with mining. Done naively that can be attacked, but there appear to be ways to mitigate the problem. Initially, Ethereum is settling for a proof-of-work algorithm that's more resistant to specialized hardware, so big central miners can't get such an advantage.

The fewer miners there are, the easier it is to carry out a 51% attack. And the top miners have much more processing power than the average miner. Just a few of the top ones collaborating could carry it off.

That's definitely a problem, and it's the reason other projects are working on ASIC-resistant proof-of-work. I just don't see how the method I described would make things any worse.

I'm just pointing out that limiting active miners to people with fast internet connections means there will be fewer of them.

This used to be an issue with pools but I don't believe this to be a risk so much anymore.

Why not? Pools are still huge, and at least the "ethical" members of a pool could move their processing power to a different pool. If individuals are bigger than pools now, that means even fewer people have to collude to get 51%.

Yes you're right when talking about the steady dicrease in terms of full nodes. I think that introducing economic incentives for stimulate full node operators are badly needed.

I've recently read a proposal for such a scheme written by Justus Ranvier, you can find it here:

https://bitcoinism.liberty.me/2015/02/09/economic-fallacies-...

tl;dr Bitcoin peer-to-peer (P2P) network needs price discovery built directly into it through micropayment channels (https://bitcoinj.github.io/working-with-micropayments)

It doesn't follow that if there are 6500-7000 nodes now, there will be fewer with larger blocks. If larger blocks allow for a larger economy, there will also be more candidates for running full nodes. Things are different when the percentage of world population using Bitcoin increases from 0.01% to 20%. Spent tx pruning, which has not yet been implemented, can also help increase full node count. From what I've seen, projections on how the block size will affect full node count don't take this into account.

tl;dr: optimizations like pruning, combined with a much larger economy, could result in a far higher full node count under a large-block-size scenario than there is now.

Huh, interesting. I'm not familiar with the problem with large blocks, so I don't know why this proposed solution is good, but I'm glad it exists. If anyone wants to explain the problem, I would be indebted.

The time to propagate blocks is proportional to the block size, and if it takes too long compared to the block frequency, you end up with forks. That's the main reason we only have a block every 10 minutes, and limit to 7 tx/sec. But the transactions are sent separately, so the miners can make blocks out of them. There's no need to duplicate them all in the blocks themselves.

I see, thank you. Pretty clear.

Reply on news.ycombinator.com