Hacker News Reader

It felt a bit like doublespeak when the author claimed ETH was more vulnerable to a 51% attack because it (intentionally) aims to make ASIC mining difficult — the whole point of making ASIC mining difficult is that Bitcoin is centralized and vulnerable to 51% attacks because there are very few miners (because capital expenditure to become a miner is high). If the few miners collaborate to cheat you, they can get away with it.

That being said, it's not even true anymore that ETH is GPU-only; despite attempting ASIC-resistance, there are now ASIC miners for ETH too, although unlike with Bitcoin, Ethereum is still able to be mined with GPUs.

The complaints that ETH has little real-world utility and is mostly speculation-driven felt similarly nonsensical compared to Bitcoin. What real-world utility does Bitcoin have? The whole thing is HODL-driven speculation on an inherently-useless deflationary asset.

(Unlike the author, who claims to have no stake in the debate a breath before admitting he's long BTC and doesn't own ETH — by definition, a stake — I truly have no stake in this debate, and currently own neither BTC nor ETH.)

> That being said, it's not even true anymore that ETH is GPU-only; despite attempting ASIC-resistance, there are now ASIC miners for ETH too, although unlike with Bitcoin, Ethereum is still able to be mined with GPUs.

Last time I looked those "ASIC" miners for ETH were basically a few GPUs stacked together in one case. More of a special PC setup than truly ASICs and that's why there is still GPU mining. Those ASIC miners were not that much faster and cost effective than a regular GPU setup.

Has that changed?

I really feel the article's quality would greatly improve, focusing on just Ethereum 2.0, where fair points regarding its issues are brought up.

Showing the node count for BTC and making it seem huge, while trying to sell the fact of how terrible it is to run a ETH node instead, and not mentioning the fact that there are actually more active ETH nodes online than BTC, is highly disengenious, and unfortunately just makes this seem like a bagholder trying to discredit competition.

>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.

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?

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.

Block propagation speed.

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?

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.

Why not increase the block size limit then?

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.

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?

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.

non-mining nodes have zero bearing on chain consensus

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.

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.

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

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.

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

When bitcoin launched there were no non-mining nodes, every node was a mining node. "Node" in the whitepaper refers to what we know today as mining nodes. You are suggesting that the task of relaying blocks falls solely on non-mining nodes, when this isnt true. Mining nodes carry out the same roles as non mining nodes when it comes to relaying/propagation. Every node within the network, whether it be mining or non-mining, pass blocks they receive to their peers.

The task of relaying blocks falls to every node; you are correct there (and I never claimed otherwise). But, if a miner produces a block that the vast majority of nodes reject, then the network effectively splits into two parts -- one part where the block was never "seen" and the other part where it was. If the part that never "sees" the block represents more economic activity -- e.g. the majority of exchanges' nodes, the majority of wallets' nodes, etc. -- then it doesn't matter how much mining PoW gets sunk into that block and its descendants because they will never be processed. Downstream, that means that the miner's coins never materialize on these nodes, which makes mining non-relayed blocks unprofitable. Miners need other nodes to recognize their blocks in order for those other nodes' operators to recognize the existence of their coins.

For example, consider what would happen if a miner produced a block that tried to spend a Segwit output without consideration of the witness. Under the Bitcoin protocol, this is technically allowed -- a Segwit output looks like an anyone-can-spend output. But due to the extra Segwit rules, only pre-Segwit nodes would accept and relay this block. Considering that nearly all exchanges, wallets, custodians, etc. apply the Segwit rules, this would mean that this block would be treated as invalid and its coinbase rendered effectively unspendable. Even if 100% of the Bitcoin miners tried to build on top of this Bitcoin-valid but Segwit-invalid block, all their blocks would be similarly rejected. Only pre-Segwit Bitcoin nodes would accept these blocks, but hardly anyone runs them [1] (note that Segwit support first appeared in version 0.16; there are indeed still some people running pre-Segwit nodes).

[1] https://luke.dashjr.org/programs/bitcoin/files/charts/softwa...

For some reason you seem to think that miners can't send out their own blocks. Of course they can do anything a simple relay node can do.

Also you are linking to a person who thinks the sun revolves around the earth and that there is nothing wrong with slavery because the bible says so.

> For some reason you seem to think that miners can't send out their own blocks. Of course they can do anything a simple relay node can do.

I never said that they can't. I said that other nodes can choose to ignore them.

> Also you are linking to a person who thinks the sun revolves around the earth and that there is nothing wrong with slavery because the bible says so.

No disagreement there. The only reason I linked to his site is because it's the only Bitcoin network status page I'm aware of that has a fine-grained breakdown of Bitcoin user-agent strings. Do you have a better link?

> I never said that they can't. I said that other nodes can choose to ignore them.

Who cares? That doesn't matter at all. Other miners will pick up the found block and any node that ignores what they are doing will just unsync themselves and become useless.

> Do you have a better link?

For the thing that's irrelevant to anything we are talking about? I'll get right on that.

> Who cares? That doesn't matter at all. Other miners will pick up the found block and any node that ignores what they are doing will just unsync themselves and become useless.

What good is a block if no exchange or wallet will accept it (and its coins) as valid? Miners aren't all-powerful entities in a blockchain. In order to have any say at all in the blockchain's behavior (let alone cash out their coins), they (1) need other nodes to recognize their blocks as valid, and (2) need a reliable underlying network to propagate their blocks. If no one accepts a miner's block, or if the block cannot be propagated, then it's the _miner_ that's useless.

Like, this is distributed systems 101 stuff. If your node broadcasts a message, and no one accepts it, then your node is dead for all intents and purposes. If 100% of miners are producing blocks that the rest of the network isn't accepting, then 100% of the miners are effectively dead.

To think of this concretely, what do you think would happen if 100% of Bitcoin miners suddenly stopped honoring Segwit witness data, and started mining blocks that claimed Segwit transaction outputs as their own (which is technically allowed, since they are marked as anyone-can-spend)? Pre-Segwit nodes would accept these blocks (my aforementioned link shows that such nodes exist on the network today), but do you think Segwit-aware nodes would accept them?

> For the thing that's irrelevant to anything we are talking about? I'll get right on that.

You sound like a very pleasant person.

> What good is a block if no exchange or wallet will accept it (and its coins) as valid?

It only matters what the other miners accept. If all the miners accept a block but "exchanges and nodes don't", then they have stopped updating their chain. What are they updating to if it isn't what the miners agree on?

> (1) need other nodes to recognize their blocks as valid,

No, they need other miners to accept their blocks and build on top of them.

> (2) need a reliable underlying network to propagate their blocks.

They have that, it's called the internet. Do you think broadcasting 1 MB blocks is difficult?

> If 100% of miners are producing blocks that the rest of the network isn't accepting, then 100% of the miners are effectively dead.

The miners are the network. If they all agree the other can either relay their chain or do nothing. There is only the chain the miners agree on. What exactly do you think relay nodes will do if they don't relay what the miners create?

> You sound like a very pleasant person.

This is the cry of someone who can't explain what they claim. I don't know where you formed a solidified but completely wrong idea in your head, but someone mislead you.

To recap: There is what the miners agree on or there is nothing. Relay nodes have no say in what a valid block is. They can relay valid blocks or not.

Thank you for responding to this jude person. I'm not sure if he's confused or a troll, but he's deep into whichever it is.

Update: ah he provided the answer by inviting us to investigate his profile.

He is trying to build a layer on top of bitcoin, and perhaps /he/ relies on non-mining consensus for /his/ uses of tokens /on top of/ bitcoin.

So it would make sense for him to proliferate a fabricated notion that non-mining nodes are important /to bitcoin/ itself.

I see you still haven't answered my question about how pre-Segwit nodes will behave. If you don't know, just say so.

> This is the cry of someone who can't explain what they claim. I don't know where you formed a solidified but completely wrong idea in your head, but someone mislead you.

Before you reply, why don't you try checking my profile? I think you will find that it is you who are mistaken.

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.

Yes id agree with you there, many dont though.

I havent heard of any claims that segwit and LN would be sufficient. It is very clear mathematics that they cant scale far. However they provide safe way to scale for short-term. Long-term solutions have to be found. If they are not found there is thousands of shitcoins claiming to solve the scalability issues better.

I agree that mathematically, they are not the scaling solutions they were touted to be, as they both have a direct dependence on the base layer size, among many other issues respectively.

You did mention yourself, under however, that it can help scale in the short-term. Many of the 'tech gurus' were essentially saying that Segwit was the short-term fix, and LN wich would take 18 months(seemingly a perpetual timeframe), would be the medium-term fix. The BTC maxi thought leader morons, like Tone Vays, who are technically ignorant, were selling noobs that both were a complete fix. I didn't choose the thought leaders for BTC.

>They are each respectively at the top of their hash domains

This doesn't matter much for ETH because its mining algorithm dissuades ASIC production. So there are some (large) number of GPUs out in the world not mining ETH that can in theory be used to attack Ethereum. The same can't really be said for Bitcoin because ASICs serve no other purpose besides mining.