There is a pretty big subset of the community that believe Bitcoin is a panacea that will replace currencies, payment networks and so on, regardless of how technically inferior the blockchain is to other more mature distributed databases and networks. They believe one day, the blockchain will be just as efficient or even more so. This subset is vocal about the urgency of increasing Bitcoin's block size limit so that we can increase transaction throughput as much as possible and as soon as possible.
On the other hand, most developers who have worked on Bitcoin proper (either protocol development or Core node development) believe that Bitcoin is more about financial sovereignty and censorship resistance, not as an in-place replacement of PayPal or VISA. This group wants to find as many ways to scale the blockchain without increasing the block size limit because increasing the size of blocks puts at risk users' ability to validate the chain. This is because larger blocks means more resources required to transmit, validate and store blocks and if you cannot validate blocks, then you are trusting transaction validators (miners) just like you trust PayPal. Risking the ability to validate the chain is risking the financial sovereignty or censorship resistance they value so much.
Regardless of how well some claim SegWit2x is doing, truth is once SegWit is activated, we still have to face the 2x hard fork which many people in the second camp will simply refuse to support.
Having said all this, Bitcoin Cash represents an earnest understanding that there are two camps in Bitcoin and because of the differing economic visions, they will have different technical visions, so why not have two chains and evolve them independently? Rather than playing tug-of-war and both parties being dissatisfied?
It will just allow more transactions through, which will allow fees to fall to levels where normal people can use it for normal transactions.
The use of bitcoin as a currency is being throttled by the artificially small blocksize.
We can have more than 3 transactions per second, while still maintaining the fundamental properties that are Bitcoin.
Hopefully SegWit2X will be the sane compromise everyone hopes for - ie. that we see the bottleneck alleviated with segwit and 1MB blocksize contributing to a near 4x improvement in transaction throughput, and lower usage fees.
Incorrect. It will make running a full node for almost all consumers in Australia impossible at any price.
> hopefully SegWit2X will be the sane compromise
Segwit is the compromise and we are finally going to get it. If you want to install the 2x hard-fork to china-coin, you are welcome to. Everyone else will just continue using bitcoin. Now with segwit.
It was a flaw in the Bitcoin specification that there was a conflict of interest between miners and users that when more blocks are filled, the more fee the miners get, thus miners have no incentive to make the blocks less congested.
Not sure how doubling the block size suddenly disallows users from validating the blocks, besides, as the entire data is already around 160GB or so, none of the mobile wallets contain the full data and are delegating much of the credibility of the chain to others' full nodes.
Bitcoin Cash is mostly built around the Chinese mining community who have been rejecting to activate segwit for a while since their asicboost that helps their mining speed by 20-30% was about to become unusable, though they claim it's not used.
And with 8MB for Bitcoin Cash it would make the chain data so large after several years, if block spaces get filled you will be able to barely host a node on a desktop with TBs of storage not to mention hosting on clouds would be pretty expensive leading to centralization.
Why not? Bitcoin Cash may be more vocal in the Chinese miner community but there are plenty of Americans who believe in it too. The storage issue both chains will have to deal with if they are used in any big capacity
(i) Miners, not average users, hold the voting power.
(ii) When the 1 MB block-size is congested (like it is now), miners make significantly more money on transaction fee's.
(iii) Increasing the block-size increases supply and reduces demand for priority processing in the block, hence, reduces transaction fee's.
Which explanation truly matches your view of reality here. People (miners) are motivated by "A shared vision" or a dollar in the bank account? Look at it closer (quote from parent comment):
>
> "larger blocks means more resources required to transmit, validate and store blocks and if you cannot validate blocks, then you are trusting transaction validators (miners)"
>
Can you see the problem with the explanation now? Its written from the view of an end user (of bitcoin), not a miner. But its miners who vote on the fork, hence, the above quoted text is mostly irrelevant to understanding the "WHY" of the fork battle.
1- You imply that only one camp wants to scale. Actually, both camps want to scale. The only difference is that the "big blocks" camp do not think a user's ability to validate the blockchain is worth keeping.
2- The size of the network is irrelevant to the government's ability to censor transactions. The only thing that stops them from having power over the network is decentralization. If you as a user have no say whatsoever in what goes into blocks, you are forfeiting your power and handing it over to the miners. Then, the miners become transaction validators that can be compelled to censor certain kinds of transactions by their government. As a user, you will have no means to stop this because you can't even validate the chain they are producing (because it costs you too much to transmit, store and validate it in computing resources).
I'm not saying the argument for the "not-big-blocks" camp is to never increase the block size, but it is to try everything they can to keep the power in the user's hands while growing the network. The minute you give up on decentralization for the purpose of scale, Bitcoin loses its value proposition as it looks less like digital cash and more like paypal with central transaction validators and a central database.
You are correct that segwit2X is a hard fork, and therefore the other side could potentially stop it from happening.
But the thing is that it is already established that it is possible to do a blocksize increase via a soft fork. Segwit itself is literally a blocksize soft fork.
So if the hard fork fails, the big blockers could instead just blocksize soft fork instead of hard fork.
The war won't be over if segwit2X fails. That is the beginning, not the end, of the real Bitcoin civil war that will happen.
No one can stop you from forking bitcoin. It's open source. Anyone can do it. What you can't do is force all of the existing users to stop using bitcoin, and instead use your china-coin fork.
I wish you woukd fork. But you won't. Because as soon as you do, you'll find that none of the existing users of bitcoin will follow your fork. So a week or so later, you'll blame core.
But they don't believe it's technically inferior to more mature distributed databases and networks..
You're transposing your own opinion onto theirs.
None of these numbers are hard to find and they are widely accepted as fact, not opinion.
> They believe one day, the blockchain will be just as efficient or even more so
^This is indeed their opinion and not a fact. Do you disagree?
Because so few of % of the total coins are tradeable, I think this results in a similarly volatile "market cap" as many ICOs.
"At that point, anyone who currently has bitcoin gains the same amount of BCC, while retaining their BTC."
This is quite important, because it means that all Bitcoin holders effectively are given BCC for free, which they can sell on an exchange. Thus, the BCC market risks an immense flood of BCC sellers who very suddenly earned a tidy profit out of nowhere, which could crash the BCC price completely, because the market is so shallow, relative to the BTC markets.
In fact, I think this is quite likely to end up being the death of BCC: a constant sell-pressure from BTC-cum-BCC holders, who just want to cash out in dollars. This can end up forcing market makers out of the BCCUSD market, because they can't risk holding too much BCC with a constant sell-pressure like that.
The BTCUSD market has grown from a small stream to a small river and, when the BCCUSD market opens in earnest, this small BTCUSD river will be connected to the tiny stream that is the freshly born BCCUSD market.
You will be able to replay original bitcoin and abc tx's on each chain, unless you opt-in to some funny new untesed hash. This will hugely disrupt the minority chain ABC, as the mempools on cash chain fill with other valid tx's from main chain. Its going to be a bloodbath. Steer very clear!
From: https://bitcoin.stackexchange.com/questions/56867/bitcoin-ca...
Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.
The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.
The second method uses an OP_RETURN output which has the exact string:
Bitcoin: A Peer-to-Peer Electronic Cash System as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
There are a multitude of ways to split your coins, so that they are separate, and you don't risk selling the other chain when you don't mean to.
What would stop someone replaying a regular tx from core chain if this network accepts either replay protected or not tx's?
* Niche website linked / breaking the news
* Non-mainstream crypto-fork
* No novel interest / features
There's nothing to suggest why this would be upvoted, even among this crypto-friendly crowd.
Look at all the other stuff on the front page of HN right now:
* Dell made a new monitor. Yay. * An article about salaries in Norway * Emacs compared to alternatives * A map of Ulysses’ journey * People in the UK must register their drones now.
Everyone has different interests but something new is happening with a large, expensive, distributed piece of software that allows anyone to hack on. That's HN's raison d'être.
I hunt for respective news on other sites because HN just provides the most important crypto news. There's a lot more out there, it's new and complex. It's good to read stuff multiple times from different sources to get familiar with this new world order.
EDIT: yeah, totally organic growth I'm sure https://screenshots.firefox.com/1Jd3clym3pT37nAH/www.reddit....
On /r/bitcoin there are shadow bans, outright bans, story deletion, selective enforcement of their cherry picked rules, different default comment reorganization when the conversation doesn't go the way they like and of course closed moderation logs.
/r/btc has none of this. So who is really doing the manipulation? Many of the posters who are lock step with the narratives /r/bitcoin pushes have post histories that are ONLY in /r/btc and /r/bitcoin and end up with -100 karma. Most the accounts that pop up like this are also only a few months old.
So who exactly is engaging in those practices? Because when real people meet up, or when votes are taken with signed bitcoin keys, or any sort of real verification is done there ends up being silence of the narratives /r/bitcoin pushes.
^ Here is some information (mostly in the form of a fragment of a video, but also to a much much lesser extent some comments) on what seems to be earlier versions of this plan, which I found useful for context (though I haven't spent the time to work this all out in my head yet...).
You've quoted this number many times now, and it is completely incorrect. The upload bandwidth required for a full node with eight peers is an absolute minimum of 0.39mbps/mb of block size.
The things you're saying are the kind of things that people who really don't have any clue of the resources required by a node would say. In fact, it's pretty clear you don't run a node, have never run a node, and will never run a node. So your opinion as to the security requirements of bitcoin should be viewed in that context.
