Hacker News Reader

>One thing we know for a fact is, if you owned bitcoins prior to the fork, you will get the same amount of SegWit and Cash varieties.

I want to point out that here "owning" means actually having the coins on one of your personal addresses whose private key you own. If your coins are hosted on an exchange or any kind of 3rd party wallet nothing is guaranteed (unless said exchange explicitly announced that they would let you trade your BCC).

Which is why I moved my small BTC holdings out of coinbase yesterday to a private wallet address :)

Bitcoin price is not "crashing"; it's fluctuating well within its normal variation.

Between ridiculous and ridiculously insane, as always.

> One thing we know for a fact is, if you owned bitcoins prior to the fork, you will get the same amount of SegWit and Cash varieties.

So am I dumb for not having bought some Bitcoins prior to the split, and getting free "money"?

If the number of BTC suddenly doubled, you'd expect the value of each one to halve given rational expectations and perfect knowledge of BTC holders.

Of course a) the two BTC variants won't have equal worth and b) participants in the BTC economy have neither perfect knowledge nor total rationality (the level of rationality in the BTC ecosystem has been much debated over recent years as we all know) so the actual outcome may differ from the 'perfect' one, but the likelihood is that values will converge over time to the outcome that the value of BTC1+BTC2 post split is equal to the value of BTC pre-split, plus or minus any gains/losses along the way (which may include a reputational loss or gain based on how well the split goes).

Yes & no, consider this like a stock split. But instead of an even split, where your 1 share of GOOG becomes 2, both with the same price, you get 1 (or fraction of) BTC and BCC, where BTC = ~$2700 and BCC = ~$230.

The overall value may go up, but you may also see the cost of BTC drop by the value of BCC (like when a dividend is paid on a stock).

BCC could also lose adoption, and lose value significantly.

Not necessarily. The real total value may be constant, and will simply be split between the branches. That, of course, would not happen instantly, so there's probably a way to time it perfectly. As in, buy right before the split, and sell right after. But don't forget there are fees involved, and also the spread between buy and sell.

If one or either of them drops below the value of BTC pre-split, then no. No one knows what will happen, and assuming they'd not drop by the difference of pre-split is definitely not guaranteed, especially if you consider the pre-split price highly inflated.

Note I follow CC a little bit more than casually, no expert and I'm not sure what the GP means exactly by this statement.

Depends on how many people did that and what their intentions are.

Also to sell 8mb bitcoins, a >1MB mined block will have to be accepted by the network which may not happen for hours or days. There is a schedule for difficulty changes but there's no telling how long it will be before they are actually tradable.

[I was definitely wrong here]

UAHF specs that the fork happens after the 1st >=1MB block is mined.

https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-techni...

But it looks like the "fork" is already happening, because Bitcoin Cash network rejected block 478559, and now has to mine one of its own.

    2017-08-01 13:23:46 ERROR: ContextualCheckBlock: BUIP055 fork block (00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148, height 478559) must exceed 1000000, but this block is 272502 bytes
    2017-08-01 13:23:46 ERROR: ProcessNewBlock: AcceptBlock FAILED
    2017-08-01 13:23:46 Invalid block due to bad-blk-too-small
    2017-08-01 13:23:53 ERROR: AcceptBlockHeader: block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148 height 478559 is marked invalid

// If UAHF is enabled for the curent block, but not for the previous block, we must check that the block is larger than 1MB. https://github.com/Bitcoin-ABC/bitcoin-abc/blob/174846aaaf56...

That's very interesting, thanks for linking to the code. Why would they require the first block to be >1MB?

It's to make sure the block will be rejected by the non BCC nodes. This way you have a "clean cut": the Bitcoin Cash nodes rejecting the non-BCC blocks while segwit nodes reject the BCC fork because it starts with an invalid >1MB block.

I think if the block is >1MB, then that's at least one indication that BTC cannot possibly include it in its blockchain, and thus is a new blockchain entirely.

The outcome will likely depend of how many miners switch to the b-cash chain. I can see both sides dumping to try and convince the market that theirs is the real bitcoin and that the other will be worth(-)less. Likely to be a lot of volatility but b-cash proponents who favor growing the blocksize are big enough in number that I think both will survive, at least until that chain hits real scaling problems.

That kind of economic warfare seems very risky to me. Miners, at least, are ultimately businesspeople, and the risk/reward for dumping either coin doesn't seem all that attractive to me. Why not just keep mining whatever they've chosen to mine, and switch to the other chain if it looks like they made the wrong choice? Or just mine whichever coin is most profitable at any given time?

> The split happened because people have very different ideas on how Bitcoin should scale (transactions per second).

I would say that the split will happen because the Bitcoin Cash have enough firepower (e.g. marketing, business) to diverse the attention to them since these forks could have been possible for long time. It is not a coincidence that these days are important for the SegWit2x and UASF projects too.

One important point to be careful about are replay attacks. If you decide to spend your coins on the Bitcoin Cash, you're essentially broadcasting a transaction signed with your private key, which could be used to move your coins on the other Bitcoin SegWith chain.

So if you spend coins on one chain, it may automatically occur also on the other chain.

Replay protection is no longer opt-in, and is now mandatory.

> How is transaction replay being handled between the new and the old blockchain?

Bitcoin Cash transactions use a new flag SIGHASH_FORKID, which is non standard to the legacy blockchain. This prevents Bitcoin Cash transactions from being replayed on the Bitcoin blockchain and vice versa.

Non-standard transactions aren't usually included by miners, but as far as I understand Bitcoin miners are still free to include those transactions if they want to. Wouldn't this mean that a malicious miner would be able to replay transactions from Bitcoin to bcash?

No, because the signatures will not match. That's the whole point of replay protection (or at least my understanding of it).

IIRC, if a miner includes an invalid sighash into a block it will be rejected by regular bitcoin nodes. Ya gotta follow the spec.

What does that mean for "normal" user? Say, one that buys some things online and cares a bit about investment?

It might impact a normal user if one chain is seen to be more effective at handling larger load. There were long delays previously in bitcoin that caused transactions to not go through for hours from my understanding.

Thank you! I hadn’t heard of this fork until now and your write up was clear and makes sense.