Hacker News Reader

Comment by futuravenir | Hacker News Reader

Increasing the block size is a fundamental change requiring a hard fork and a chain split. It is not possible to continue on the same chain with a 2mb block. However, they could continue on the same chain with segwit which gives the rough equivalent of a 1.7mb block. Unfortunately, that wasn't enough for the other side (+lots of other reasons, valid or not, I couldn't say).

View on HN

Don't be fooled into thinking a soft-fork is the "same chain". It simply tricks nodes that don't know about SegWit into validating transactions that they don't really know how to validate.

It's possible for a non-SegWit miner to accidentally mine an invalid block after the soft-fork. Here is how.

The "backwards-compatibility" of SegWit comes from the fact that it looks like an anyone-can-spend transaction. Meaning, on the old blockchain, those coins would be up for grabs.

Nodes that support SegWit know that it is not really an anyone-can-spend transaction, because they have extra data not included in the blockchain.

But a node that doesn't upgrade doesn't know about this. So here's what could happen:

1) Bob sends sends a SegWit transaction to Alice

2) The non-SegWit node sees it as an anyone-can-spend transaction where Bob is basically giving up his coins

3) Eve wants to mess with the non-SegWit node, so she sends it a (valid!) transaction which spends Bob's coins and sends them to Eve

4) The non-SegWit miner mines a block with that transaction, and the block is consequently rejected by the SegWit nodes

So SegWit needs 51% of hashing power in order to work, just like a hard fork. Without it, they wouldn't be able to reject the block with Eve's transaction, which would've been valid on the old blockchain.

The only difference is that the above edge-case exists for a soft fork, whereas for a hard fork, non-upgraded nodes would simply be split into a smaller network instead of being tricked.

Not quite, it needs 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes. That's the reason BIP9 has a 95% activation threshold.

Note this is by far not the first soft fork Bitcoin has done. P2SH, CSV, and CLTV for example were also soft forked in. The original design even included 10 blank opcodes designed for soft forking in features.

> 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes

Yes, what I was pointing out is that in a soft-fork there is a risk of an eventual re-org, whereas in a hard-fork there is not. It's a minor risk, but it exists.

I also believe that any non-SegWit miners will be pushed out of the network using the mechanism I described. It would be pretty easy to trick them into mining invalid blocks.

Let's see if I understood this correctly: once the network splits into BTC (with SegWit) and BCC (without SegWit), if someone spends an old BTC coin (where old = from before the split) using SegWit, anyone can "steal" that same coin on the BCC "mirror universe"? Sounds worse than merely replaying a transaction from one chain into the other. That's so going to be a mess.

Correct, though this isn't really anything special about SegWit. If BCC had forked right before Bitcoin added P2SH for example, the same would have resulted from P2SH transactions.

Actually, since BCC is a hardfork, they can make the Bitcoin Cash spending rules whatever they want. They could have made SegWit transactions totally unspendable if they wanted. They could have made all Bitcoin Cash corresponding to the Bitcoins sent to Blockstream spendable by anyone, etc.

Reply on news.ycombinator.com