
Coin Dance – Bitcoin Cash Hard Fork - csomar
https://cash.coin.dance/
======
nnx
Can easily monitor status of each competing/potential split at
[https://www.btcforkmonitor.info](https://www.btcforkmonitor.info)

~~~
runeks
So, Bitcoin ABC (Cash) is three blocks behind the other nodes, but no chain
split has been detected. What’s up with that?

Did the block three blocks ago cause a fork? Are we just waiting for someone
to mine a Bitcoin Cash block on top of this block and then there’ll be a fork?

 _EDIT:_ Here's the log from a Bitcoin ABC node I have running:

    
    
        2017-08-01 13:23:36 ERROR: AcceptBlock: bad-blk-too-small, size limits failed (code 16) (block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148)
        2017-08-01 13:23:36 ERROR: ProcessNewBlock: AcceptBlock FAILED
        2017-08-01 13:23:48 ERROR: AcceptBlockHeader: block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148 is marked invalid
        2017-08-01 13:23:48 ERROR: invalid header received
        2017-08-01 13:24:06 ERROR: AcceptBlockHeader: block 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148 is marked invalid
        2017-08-01 13:24:06 ERROR: invalid header received
        [ ... last two lines repeat ... ]
    

Looks like 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148
AKA block number 478559 was rejected by Bitcoin ABC.

 _EDIT2:_ Here's the code [1]. The block was rejected by Bitcoin ABC/Cash
because it was smaller than 1 MB.

[1] [https://github.com/Bitcoin-ABC/bitcoin-
abc/blob/174846aaaf56...](https://github.com/Bitcoin-ABC/bitcoin-
abc/blob/174846aaaf564e64b6bd06d679996b52ba86ad53/src/validation.cpp#L3397)

~~~
simias
That's normal. Bitcoin ABC is rejecting the non-BCC blocks once the median
time is after 12:20 UTC. So BTC blocks after 478558 are rejected.

Now the BCC miners are actually working on producing the first BCC-only block,
which will be block 478559 on the BCC chain and will be different from block
478559 on the BTC chain, hence effectively splitting the chain.

Since BCC has only a tiny fraction of BTC's hash rate (around 1% by most
estimates, although it's pretty hard to evaluate) it will take a while for
this block to be found. Probably hours, maybe even days.

Eventually the difficulty on the BCC chain will adjust, so even if the hash
rate remains low the "blockrate" should steadily increase within the next few
weeks. Also since BCC blocks can be 8 times as big they can fit more
transactions in a single block, somewhat mitigating the effect.

~~~
eterm
The adjustment is by block-count not time, if they only produce a block per
day it'll take ~144 days to lower the difficulty.

I think people would abandon long before that.

~~~
simias
There's a "cheat" to avoid this situation in the technical spec[1]:

 _In case the MTP of the tip of the chain is 12h or more after the MTP 6 block
before the tip, the proof of work target is increased by a quarter, or 25%,
which corresponds to a difficulty reduction of 20%._

So as long as the BCC keeps lagging behind massively (less than 6 blocks every
12h) the difficulty is reduced by 20% after every new block.

[1] [https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-
techni...](https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-
spec.md#req-7-difficulty-adjustement-in-case-of-hashrate-drop)

~~~
eterm
Thanks I didn't know of that 'cheat', it sounds from the spec though that the
difficulty of the block yet to be found would be reduced but it would then go
back up for the block after that to the proper-set difficultly (because there
would now be a block within the 12h window).

~~~
simias
It's computed over 6 blocks: "the MTP of the tip of the chain is 12h or more
after the MTP 6 block before the tip".

So it takes 6 consecutive blocks to be found "fast enough" (that is, within a
12h window) to return to the normal difficulty algorithm.

~~~
Santzes
Couldn't big miners play this by mining 6 blocks of Bitcoin Cash and then
letting it rot without blocks?

~~~
simias
Only possible if the colluding miners have almost all the hashing power to
themselves (to mine 6 consecutive blocks faster than everybody else). If
that's the case then those miners can do anything they want anyway, including
double-spending money[1].

Furthermore if they really only wanted to slow down BCC and nothing else it
still wouldn't be very efficient. They'd just postpone the scaling for the
next 6 blocks and then the rule would kick in again. So they'd have to keep
make sure that they're always just at the limit of 6 blocks per 12 hours...
but at this point you're actually mining block and contributing to the
ecosystem, so there's no problem.

[1] [https://bitcoin.org/en/glossary/51-percent-
attack](https://bitcoin.org/en/glossary/51-percent-attack)

~~~
Santzes
Ahh I thought this 20% drop per 6 blocks was only after the split block and
would end after the first 6 blocks mined in 12h, would have been too easy to
game that one.

Looks like though they're getting blocks now, 4 blocks in less than two hours.

------
jswny
I think I have enough understanding of the different types of Bitcoin between
SegWit and Bitcoin Cash and what they do differently. However, I'm not very
invested in the Bitcoin community. Could someone explain which of the
significant parties (developers, users, miners, exchanges, etc.) are
supporting which type of Bitcoin and why?

~~~
Taek
The people responsible for writing 90%+ of the code changes to Bitcoin since
2013 are all heavily in favor of SegWit, and heavily against Bitcoin Cash and
also against SegWit2x. These guys are the researchers and engineers with the
deepest understanding of decentralization, game theory, and adversarial
blockchain design.

The most politically active exchanges, miners, and payment processors are all
in favor of SegWit2x, and against the bitcoin-core developers. These are the
people who are most familiar with business, who are closest to the userbase,
and have to deal with the practical problems associated with running Bitcoin
businesses in ways that the core developers do not. At the same time, they
often miss significant security and stability risks in the changes that they
propose.

A small faction of highly passionate users with relatively deep pockets and
effective social media skills favor Bitcoin Cash. This group passionately
distrusts the bitcoin-core developers, has a strange vendetta with the EFF-
commended company Blockstream, and is the source of a large number of
conspiracy theories. This is the same group that passionately backed the
failed Bitcoin-XT project, the failed Bitcoin-Classic project, and the failed
Bitcoin-Unlimited project. Their following I think was largest during the
Bitcoin-Classic days, but at this point I think they've disenfranchised a lot
of their early community members with their stubborn anti-bitcoin-core
rhetoric.

~~~
runeks
What does the difference between SegWit and SegWit2x amount to? Is it just the
difference in block size limit? As I understand, they’re practically in
agreement on the limit, but not _exactly_ , thus risking a fork because of a
relatively tiny discrepancy.

~~~
Taek
SegWit2x contains a hardfork that brings the block size limit to 2mb. The
primary point of contention with SegWit2x is the fact that it introduces a
hardfork, something that most developers very strongly oppose.

A secondary concern is scalability - SegWit already increases the burden for
full nodes in terms of bandwidth and storage by doubling the practical
capacity of the blockchain, and quadrupling the max size if miners are being
abusive. SegWit2x quadruples the practical capacity of the network, which
quadruples the burden of running a full node. And attackers now have 8x the
wiggle room for attacks. I don't want to dive deep into the details, but there
are a lot of reasons to be concerned about this.

~~~
berberous
1\. Why do most of the developers strongly oppose a hardfork? Isn't that
primarily an economic issue (i.e., is it good for the price/ecosystem for
there to be warring factions), or is there some technical concern I'm missing?

2\. You seem to be well-informed and (which can be rare in this space) cool-
headed. Any recommendations for the best readings/websites/forums/users to
follow, with a high signal-to-noise ratio?

Thanks.

~~~
Taek
There are two very good reasons to oppose a hardfork, and then a bunch more
besides. I think that I would say the best reason to oppose a hardfork is to
protect yourself against political manipulation. The whole point of Bitcoin is
that it's money that nobody controls. Hardforks introduce decision points that
people can have control over, and they can use political leverage to get
things out of the hardfork that you may not like. Especially if the ecosystem
becomes accustomed to hardforks, it gets a lot easier to introduce changes
which are supported by popular opinion. As we know from Trump, popular opinion
is not always what you want to be directing your future.

There's also a fantastic non-political reason, which is compatibility. As we
know from IE6, Windows XP, outdated versions of Flash, IPv4, and lots of other
things in software history, industry wide upgrades take a loooong time. When
you hardfork Bitcoin, you are introducing a change that is only successful if
100% of people upgrade. That's a really high bar. If someone or some company
does not realize that there's been a hardfork, they are sitting on an old,
vulnerable chain and don't realize it. Everyone who doesn't upgrade is
vulnerable to accepting payments that they think are worth 1 btc, when they
are actually worth 1 btc-old, and btc-old may have a dollar value that's only
a few percent of the btc price.

When you hardfork, you force everyone in the ecosystem to upgrade. This causes
a lot of friction, breaks compatibility with existing software, and really
reduces the value of your ecosystem substantially because you lose a lot of
legacy code and hardware and systems that may no longer be compatible with the
post-hardfork chain.

As for recommendations, honestly there's not much I can do to help. All the
major places that I know of have been overrun by people who think they know a
lot more than they actually know. There's also a lot of brigading in general,
though I think the fundamental problem right now is an ecosystem-wide Dunning-
Kruger effect, and I think it'll blow over once the ICO mania matures more.

If you really want some good stuff, look for anything posted to a mailing list
or to IRC by Greg Maxwell. While his reddit comments are often petty, he's
probably the most intelligent person in blockchain today. Take everything he
says with a grain of salt, but even if you don't like him you will learn a LOT
by reading everything he's posted over the past 2-5 years. Other names worth
following (not a complete list, sorry to anyone I miss) would be Pieter
Wuille, Peter Todd, Luke Dashjr, Eric Lombroso.

------
gigatexal
Can someone explain to a distant *coin observer what this means? What it might
mean for the price of Bitcoin etc?

~~~
olegkikin
It means there will be 2 different bitcoins: 1) SegWit Bitcoin and 2) Bitcoin
Cash.

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

SegWit supporters think that most transactions should happen off the
blockchain (in something like Lightning network), which then settle on the
chain. They also talk about increasing the block to 2MB (SegWit2X), but I'm
not sure that will happen.

Bitcoin Cash instead extends the block size from 1MB to 8MB (and probably more
in the future), allowing all of the transactions to exist on the chain.

What it means for the price is not clear, and if someone tells you they know
where the price will go, they are just guessing. As we are speaking, Bitcoin
price is crashing a bit (currently at $2695). Bitcoin Cash is valued at around
$293.

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.

~~~
pavel_lishin
> _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"?

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

~~~
olegkikin
[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...](https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-
spec.md)

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

~~~
debaserx
// 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...](https://github.com/Bitcoin-ABC/bitcoin-
abc/blob/174846aaaf564e64b6bd06d679996b52ba86ad53/src/validation.cpp#L3397)

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

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

------
eof
Anyone know how to / where to get an idea of hashrate distribution? It seems
it can really only be estimated by the number of blocks that come out; which
means (if I understand correctly) it could be days before the next BCC block
if BCC has some minuscule amount of hash power.

~~~
flashdance
I've heard that it's roughly 1%. It probably isn't too high because:

1) The main chain's rate of block generation has not dropped substantially. Of
course, it's hard to tell in such a short timeframe, but at least according to
[https://bitcoinwisdom.com/bitcoin/difficulty](https://bitcoinwisdom.com/bitcoin/difficulty)
not much is happening.

2) No BCH blocks have been mined in the past 2.5 hours. This could be variance
(even with 100% of the hashrate this sort of gap is plausible), but I suspect
not.

------
xeromal
Do people get double money from the split? So if I had 100 bitcoins do I also
get 100 bit coin cashes?

~~~
taysic
Yea you get 100 BCC but you only get double the money if the value of BCC will
be equal to BTC prior to the fork. More realistically they will both drop so
that the two chains will be equivalent in value before the fork. However, no
one really knows what will happen to the value.

------
Taek
This is a misleading headline I feel. It makes it seem like Bitcoin Cash is
the new Bitcoin, and that the old Bitcoin is no longer going to be usable.

The old Bitcoin is very clearly favored in the markets, and has the most
active userbase. A better title might be 'Bitcoin Cash creates their own
version of the Bitcoin network with a shared history and bigger blocks.'

~~~
dang
Ok, we'll revert it to the title on the page.

Submitted title was "Bitcoin forking to Bitcoin Cash with a higher block
size". That breaks the HN guidelines, which ask "Please use the original
title, unless it is misleading or linkbait."

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

