[dylkil]

>The claim that BTC chose a non-scalable solution for ease of running a node isn't true.

Except that it is true. There were few reasons for not increasing the block size limit, one of those was the cost of running a node. If the costs became too much for normal people to afford, it would centralize the system in a small number of big miners.

[Blockbuster]

I never understood this argument. The cost of mining already centralizes nodes to the point where block size is not a factor. People that are able to run cost effective mining setups are also able to support blockchains of any size. Given the current state of mining, how would switching to 10mb blocks increase centralization?

[xorcist]

Miner centralization is not without risks, but is fundamentally very different from centralizing economic activity, with different security outcomes.

A dominating miner runs the risk of a 51% attack, which can cause denial of service or censorship, but game theory dictates that the missed opportunity cost is huge. A dominating economic actor makes the whole blockchain an obsolete backend to something like Paypal.

[grubles]

Block propagation speed.

[CyberDildonics]

How does that make any sense?

Block sizes are under 1MB.

Anyone can rent a VPS for under $10 USD per month that would transfer that in 1/100th of a second.

The block time is 10 minutes.

Why do people repeat stuff like this? Is it because you have seen other people say it and never stopped to look at the math?

[tubbyjr]

The only huge pushers of that were the like of core dev LukeJr... who wants to decrease the block size down to 100k or by 10x.

The article states that claim, as though it was the sole one, when it was just one small reason pushed by Raspberry Pi hobbyists... while the average person doesn't even know wtf a Pi or ARM SBC is.

[dylkil]

Why not increase the block size limit then?

[xorcist]

This is also what happened. Larger blocks was implemented with segwit. This played out during an infected debate that provided the perfect cover to launch an altcoin without it, that changed the name and some constants in the code. The free PR gave them more economic activity from the start compared to similar coins, and was likely quite lucrative.

[dylkil]

Increase the block size limit was really just a 1 line change, a single variable within bitcoin core controlled it. Instead of changing this variable from a 1 to a 2 they chose the convoluted mess that was segwit. What was so wrong with increasing the block size limit the normal way?

[xorcist]

This was thoroughly debated over many months at the bitcoin-dev mailing list so it would be presumptuous of me to summarize that now. The list is open and anyone can read the actual back and forths that took place.

There were several perspectives on this, including that no one found a way to deploy that protocol change to a live network in an acceptable way. It is much easier to build consensus around "soft" forks.

[elif]

non-mining nodes have zero bearing on chain consensus

[jude-]

That's not really true. If the vast majority of user- and exchange-operated nodes decided a miner's well-formed block is invalid, then other miners would be dissuaded from building on it, and would instead orphan it.

[dylkil]

if a non mining node decides a block is invalid it will fork onto its own chain. If no mining nodes start mining on this forked chain then the original node is left on a chain where no transactions can be processed.

Non-mining nodes have no power or influence over the networks state. It is the mining nodes who decide which chain lives and which chain dies.

[jude-]

Non-mining nodes are still responsible for storing and relaying blocks. If no one stores and relays your block, was it ever mined?

[dylkil]

Remove the non-mining nodes from the network and the node count goes down, but the network security stays the same. Non mining nodes do nothing for the security of the bitcoin network.

Having more non mining nodes to store and relay blocks is beneficial to decentralization, but they have no influence over which chain becomes the longest chain.

[jude-]

I'm sorry, but this is simply not true. Bitcoin's security is ultimately underpinned by each node being able to independently validate the chainstate. If nodes couldn't be guaranteed to receive all blocks on the best fork -- a task fulfilled not by miners, but by the continued availability of non-mining nodes that store and relay blocks -- then not only would miners be unable to build a high-quality chain (since they would have a hard time receiving each other's blocks), but also it would be much easier to eclipse nodes and/or feed them a valid but lower-quality chain that they would be unable to determine is the globally-best chain.

Also, block validity includes more than just proof-of-work. Each node ultimately decides which block it accepts or rejects. The protocol defines the minimum criteria for a block to be valid, but each node may independently apply additional criteria that must be met. If all nodes decide to reject a protocol-valid block that a miner produces, then the block will be orphaned -- it won't matter how many descendant blocks get built on it, because the rest of the network will ignore them all. In fact, this is the mechanism by which a user-activated soft fork works [1].

[1] https://en.bitcoin.it/wiki/Softfork

[CyberDildonics]

Nodes aren't "responsible" for anything, they can only help if they want. Miners broadcast their blocks to other miners to signal they found a valid block.

Miners can broadcast to anyone they want and nodes can't find or manipulate blocks, so they take the role of passive helpers.

[dylkil]

Yes id agree with you there, many dont though.