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.
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.
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.
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).
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.
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.
The difficulty recalculation in Bitcoin ABC was reduced significantly. I believe it is 6 blocks but could be wrong. At most it would take several days as opposed to several weeks.
It looks like 25% of the nodes in the Bitcoin network are suddenly running "Bitcoin ABC" (the implementation supporting bigger block sizes) on AWS... someone somewhere has started a bunch of (spot?) instances it seems.
Which is a "PR" move and nothing much, I want to point out. I think the metric everybody is watching for at the moment is the hashrate on the BCC fork. It'll show what portion of miners actually commit to the fork.
Spawning nodes is cheap and doesn't really mean much.
Are you able to run multiple nodes on a single machine, or does each node need a unique IPv4 address? If you can do IPv6 or multiple ports, a Potemkin village of even t2.nanos seems wasteful.
You can actually get multiple IPv4 addresses on a single EC2 instance. How many depends on the instance type, it ranges from 4 public addresses for the smallest type, to 750 on the biggest types.
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?
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.
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.
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.
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?
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.
>These guys are the researchers and engineers with the deepest understanding of decentralization, game theory, and adversarial blockchain design.
These guys don't have the deepest understanding of any of those things. The minutia of the protocol, and the source code that implements it, is extremely important, but knowledge of it does not impart one with any insights into game theory, the political implications of different decentralisation tradeoffs, and adversarial blockchain design as it pertains to political/economic attacks.
I beg to differ. These guys have spent the whole of their professional careers discussing various tradeoffs, attacks, and sources of attack surface as related to decentralized blockchains.
I guess a statement like yours and a counter like mine is difficult to back up with evidence, but if you look for some of the technical debates realted to SegWit, Bitcoin Unlimited, Bitcoin Classic, Emergent Consensus, etc, it's pretty obvious that the bitcoin core developers are well ahead of their opponents even in the realms of economics and politics.
Bitcoin has a lot of defenses to manipulative politics in place already, including the fact that it's intentionally very difficult to hardfork the newtork, and including the fact that releases follow a fixed schedule (which makes it much harder to shoehorn in features).
The characterization that the core devleopers focus primarily on code and traditional software engineering falls far short of the reality.
The amount of time they've spent discussing and analyzing these things has nothing to do with their contribution to the source code. There are plenty of people who have spent thousands of hours discussing the various trade offs, attacks and sources of attack surface and have not contributed to the Bitcoin Core client github repository.
>The characterization that the core devleopers focus primarily on code and traditional software engineering falls far short of the reality.
That wasn't my characterisation. I disputed your characterization of the Core contributors being the most knowledgeable on these game theory aspects of security based on their contribution to the source code.
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.
>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).
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.
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?
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.
I really agree with the author that Bitcoin is quickly becoming the “MySpace” of crypto-currenc, when you see options like Monero you wonder why you would use Bitcoin in the future.
If it is anything like the ether split, 8mb btc + SW BTC > old BTC
Logically SW BTC should go down (and it has) and 8MB BTC should have value cut out of it, but with ethereum and now it seems the sum of both parts is greater than the whole before the fork. BCC futures market up about $100 since this morning on more than double yesterday's volume. SW BTC down a couple hundred but added together they are at $3,168 at time of this comment.
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.
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 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.
Hashrate distribution can indeed only be inferred from the rate of block production and their difficulties. And you need quite a few samples to get a clear picture (Poisson distribution).
EDIT: It would probably be faster to determine the speed of the Cash fork by noticing the reduction in hash rate on the main Bitcoin network.
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.
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.'
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."
