Comment by CydeWeys | Hacker News Reader

Comment by CydeWeys | Hacker News Reader

Parent Full thread

> if Bitcoin can scale the way its inventor envisioned (namely by simply increasing the block size limit every now and then)

It's not nearly that simple. There are two main reasons why "simply increasing the block size" is neither safe nor simple:

1. Centralization. Running a full node is already quite a commitment. The bandwidth requirements are high, the storage requirements are high, and it takes many days to sync the full blockchain. Many people already do not bother doing it because it is such a bother. Running a VM in the cloud as a full node is not that cheap. All of these problems scale linearly with increased block size. A really large block size that causes most existing full nodes to give up and stop relaying would not be worth it for the network in the end.

2. Bitcoin is vulnerable to (and has been subject to) attacks by way of computationally expensive transactions that scale polynomially with the maximum size of a block. This has not been completely solved yet. Right now the worst possible block verification time is on the order of 10-30 minutes for an average CPU acting as a relaying node. "Simply" increasing the block size a great deal without first fixing this issue (and it's a hard issue to fix) could potentially lead to entire network collapse if a single attack block gets mined and then chokes all nodes for days.

> Centralization. Running a full node is already quite a commitment.

The problem is not the resources needed to run a full node. The problem is a lack of incentives. If you want to have lots of full nodes running in the long run, you need to focus on those that do not do so for idealistic reasons, most notably the miners, payment processors, and exchanges. They all have advantages by doing so. Blockchain.info, for example, runs a full node to be able to display incoming transactions and to monitor the network. Adopting this view, the way forward is to grow Bitcoin as much as possible. The more users there are, the larger the ecosystem becomes and the more players there are that benefit from running a full node. We can't rely on the early enthusiasts. We need growth.

> Bitcoin is vulnerable to (and has been subject to) attacks by way of computationally expensive transactions

If you are referring to what I think, then there is a simple fix: do not allow larger transactions than before when increasing the block size. AFAIK, this is what Bitcoin Classic does.

There is no maximum transaction size, other than that imposed by the fact that it has to fit into a block. You would additionally need to hard-fork to add a new transaction size limit. More info here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015...

Note that that is just one potential problem that we are aware of. I think a conservative approach is reasonable. Look at what has happened with Ethereum and the DAO.

> a conservative approach is reasonable

Many people argue that Bitcoin was designed with headroom in mind, and pays out handsome block rewards in exchange for subsidized bandwidth, so the "conservative approach" would not be to run headlong into the block size limit.

The Classic fork already includes a max transaction size.

>There is no maximum transaction size, other than that imposed by the fact that it has to fit into a block.

There is a maximum transaction size:

http://bitcoin.stackexchange.com/a/35882

It is equal to the maximum block size. One simple fix is to simply decouple the maximum transaction size from the maximum block size and not raise the former when raising the latter.

Why does it need lots of full (non-mining) nodes? Unless you are mining, adding a node to the system just adds network traffic for little benefit.

More full nodes don't provide a better service for bit coin, nor do they provide better security. (If your full node spots a double-spend, so will everyone else). It is just duplicating work that is being done elsewhere. Sure, if you really want to analyse all the blockchain, go ahead and run a full node, but IMO it's ridiculous to want to add incentives for people to do this.

People talk about how running a full node improves decentralization, but they don't prevent any extra attacks on the currency. If there was/is a worrying concentration of mining power, that is a problem, but adding more non-mining nodes does nothing to alter this.

You're right, full nodes sitting on the network don't do a whole lot. It's important that many economically active users (e.g. wallets) are fully verifying though. Wallets based on a fully verifying node are less susceptible to attacks from miners.

>It is just duplicating work that is being done elsewhere.

This is the whole point of Bitcoin. If you only want the transaction to be centrally verified, you can use a federated model instead.

Context: A full node is about 80GB right now. I deleted a full node just the other day that was 94GB, but that had a lot of cruft. Storage is most definitely not an issue unless you're trying to run a full node on your laptop SSD.

You can also use pruning, that's how I run a full node on my laptop SSD. Initial setup still requires a full download though.

While I agree it's not that simple, it is that simple to fix the problem temporarily until a truly good scaling solution is found.

Resistance to doubling the block size once to wait out good, solid alternatives suggests other motivations on the part of the resistors.

I think I understand the points you are making, but wouldn't they be mitigated by a decreased number of blocks because more transactions are fitting into a single block? Or is the point that increasing block size strictly in order to increase network throughput has non-obvious flaws?

(Honestly asking. I only know the basics.)

There would not be fewer blocks, the creation of blocks is fixed to approximately one every ten minutes.

Reply on news.ycombinator.com