"I suspect that SegWit2x will end up taking over the network"
What? They had first release like yesterday, the project has released one tarball, no packaging, no very good marketing etc. The biggest marketers seem to be the tinfoil hat opponents who fear the fork so much that they speak about it everywhere.
I don't think it is at all likely that segwit2x client will gain support. Or if it will gain support, it will take years at this point for it to gain any considerable support.
The whole thins is totally exaggerated. People have nothing to talk about, so they will invent tinfoil hat scenarios and discuss those. Bitcoin protocol has staid fundamentally the same for many years and it is pretty likely that it will stay that way.
The only support it needs is hash power support. That's it. If enough of the hash power can be pulled into it, then it's game over for a minority chain. Running nodes costs almost nothing which means the network can be flooded with segwit2x supporting nodes, and companies will be motivated to switch over.
Miners can mine segwit2x blocks all they wish, but since services/exchanges are running core client, they are just mining invalid blocks from their viewpoint, and those blocks are ignored. That means miners can't sell their mined segwit2x bitcoins on exchanges. Mining blocks that services don't accept would be very, very stupid, essentially throwing good money to trash.
So if a huge number of nodes are Segwit2x capable, and the miners are mining Segwit2x blocks with the majority of the hash power, companies are going to stay on a less secure chain that can be attacked by the majority so that they can have a smaller block size and keep the core dev team because they love them? This isn't how that works. Proof-of-work will force those companies onto the dominant chain. Exchanges will probably keep trading the smaller coins also.
Bitcoin protocol is defined by bitcoin core client, and I would guess more than 99% percent of the services that process bitcoin transactions use that client. The services don't follow actively the hash rate and they won't change the client based on that - the network automatically adjusts to the hash rate available so that blocks come each 10 minutes. If there would exist some other cryptocurrency with more hash rate doesn't mean that services would start calling that one bitcoin.
That's not what it means. You are right that those clients would begin rejecting blocks, but you can be sure that when customers are calling them asking why their transactions aren't being validated that they will switch. It's not economically feasible to run a business on a minority hash power chain with low transaction throughput.
As long as one miner is still mining the core chain, the transaction will be validated. It may take a little while at first, but difficulty will adapt.
It's going to be 2 legitimate currencies that are going to differ in value in exchanges. And each current BTC holder will be able to spend 2 coins (provided they take precautions against replayability; like making at first a double-spend to different wallets on the two chains separately)
Now the question is: what will the most BTC-rich people do?
It would take years for the difficulty to adapt to a 10 minute block time if the hash power dropped that much, there is a limit per two week adjustment period. More than likely the code would have to be modified to accommodate a rapidly dropping difficulty. See my other post, but that essentially destroys the security of the minority chain.
BTC rich people are on both sides of the debate, expect to see some dumping all around as they make their positions known.
Not years. The difficulty is recalculated every 2016 blocks (14 days)[1].
If one chain has 10% hashing power, for less or equal to 14 days the transactions could take 10 times more to validate. But that's assuming markets aren't correcting miners in the "right" direction in the meantime. Who wants to waste electricity on undervalued coins?
----
Considering most of BTCs have been mined at the time bitcoin core had no competition; I'd say BTC rich people would tend to side with them. Because of emotional attachment, economic ties, and most importantly the dumb but very real reason of software maintenance.
If you're hard-forking, you can increase the recalculation rate for a few first new blocks. You can even recalculate every block for, say, 1000 or 5000 blocks .
But that wouldn't work for the 'victim chain' of the fork. In this case the idea is that 90% of the miners fork, while 10% remain on the original version.
I don't know if non-miners also check the difficulty or difficulty calculations, but if they do, even the minority chain can't fork without affecting existing users.
In that case everyone would need to fork in which case you're back to square one: what to do with the users that can't or don't want to fork. And if you need to fork anyway, it makes little sense to go with the minority chain.
Realistically, what will happen if mining power moves to an alternative chain but Bitcoins are still what is traded at exchanges, is that miners will move back very quickly. The first one to move will gain the most economically, so game theory dictates the move back will be swift.
In the end, miners mine what people buy. It's that simple.
Any speculation as to what happens if all miners move as one, motivated by ideology instead of economics, is just that.
Mining is centralised enough that large voting blocks already exist, so there is no telling right now which side will win. If the ETH/ETC split is anything to go by, both chaons will survive but only one is going to suceed
You can't steal with a double spend. At worst you can send a transaction and then later undo it. But that would require the dishonest party to work together with or be the hostile miner.
I'm pretty sure the backlash against both the hostile miner and all of Bitcoin combined would not be worth it, except in a Joker 'Let's burn all this cash' kind of way.
The worst a majority can do, is to create a new longest chain without any transactions. But in that case the transactions would still exist and can be mined again later (and supplanted again later).
But that would require a miner to want to spend resources to hurt the minority fork.
If the minority fork is big enough to be a threat, that would require a lot of 'majority' miners to work together to pull off this attack, which would lead to a tragedy of the commons situation. Any majority miner who doesn't participate in the attack would gain.
If the minority fork is small enough to be a toy for a single miner, it still doesn't make sense to put in the still substantial effort.
Just look at the Ethereum fork. Afaik there have been no shenanigans pulled of by a majority miner on the minority fork, even though it's only about 10% of the size.
"when customers are calling them asking why their transactions aren't being validated that they will switch."
If majority of hashpower would start mining invalid blocks, there would still be some amount of hashpower mining the real chain. Transactions would confirm, albeit more slowly. For the miners mining the real chain the situation would be very good, because less competition from other miners -> more found blocks, more money. Probably the hash rate would grow pretty quickly, and if it wouldn't, the difficulty target would adjust after the 2 week difficulty adjustment period, and confirmation speeds would be back to normal.
The taking a little while to adapt is because their is less hash power, which means it takes longer to find blocks which means the remaining hash power will have less blocks for many many weeks. This means their expected return is lower, not higher, they aren't getting a larger percentage of found blocks, and those blocks occur farther apart.
Then when the difficulty has fallen enough to make mining profitable and have a consistent 10 minute block time the larger hash power chain will be able to mine at a significantly faster rate on the lower hash power chain and that will make it susceptible to a %51 attack.
The only way to avoid that scenario will be for them to switch the proof-of-work or manage to get a lot more hash power back on their chain. Being on the minority chain in that situation is frankly dangerous, the value should be discounted appropriately.
"This means their expected return is lower, not higher, they aren't getting a larger percentage of found blocks, and those blocks occur farther apart."
The blocks would happen farther apart, but it would also mean that the remaining miners would have much higher change of actually finding a block, since there would be less competition. Also as there would be the same amount of transactions and less blocks, the blocks would have more collected transaction fees -> bigger reward. Also probably people/exchanges would increase the fees since competition would be bigger to get the transaction to a block.
Also, it would make sense for exchanges etc to buy some mining power. That would make blocks appear faster, and also they would get the mining reweards, so it might be net positive. Or just simply bribe some miners to mine the valid chain. Very easy way to do that would be just to increase the transaction fees that they put to transactions.
> The blocks would happen farther apart, but it would also mean that the remaining miners would have much higher change of actually finding a block, since there would be less competition.
That's not true. The chance of finding a block is the same for every hash given a certain difficulty, regardless of competition. So a miner with a certain amount of hashing power will always have the same chance of finding a block until the difficulty changes.
The remaining miners make the same amount per day, until difficulty is adjusted, and then much more.
Consider this: one pool with 20% hash power. They only get every 5th block, i.e. 1 coinbase reward every 50 minutes.
Now all the other miners fall away. Now this pool will still take about 50 minutes to find a block, but it will get 100% of them, thus still being rewarded a block every 50 minutes.
However, 2 to 10 weeks later (depending when the last difficulty adjustment was) (or longer, if difficulty adjustment is capped), a block is found every 10 minutes again, and the pool gets 100% of them, thus 5 rewards in 50 minutes.
On the other hand, gp also said:
> Also as there would be the same amount of transactions and less blocks, the blocks would have more collected transaction fees -> bigger reward.
If I understand correctly, that the hypothetical 20% mining pool would immediately get 100% rather than 20% of all transaction fees when the other miners fall away.
However, AFAIK the coinbase (mining reward) dwarfs the transaction fees (for now), so that should not be that relevant.
Depends what you mean by secure. If users cannot validate the blocks, then no matter how much hashpower is available, it is vulnerable to miner attack.
If miners would do a hard fork with different protocol rules, that would be called something other than bitcoin, maybe "segwit2x-bitcoin" or something.
If the exchanges trade 'segwit2x-coin' as Bitcoin, it will become 'Bitcoin', and the legacy coin, if it is possible to use at all, will have to be renamed.
It's not that simple. Exchanges and custodial wallets hold other people's funds, so they are not allowed to decide arbitrarily which chain is "Bitcoin". That would be regulatory suicide.
If your thesis holds, it invalidates the central tenet of a decentralised network. If a central party can set the rules, why not use the much better centralised transaction systems and forgo things like POW?
Exchanges don't care about any particular coin. They only care about their users. If their customers demand trading of segwit2x then that's what what will happen. There could be a lot of opportunity for trading segwit2x because the volatility which is what traders like. Same goes for all other bitcoin forks, it's going to be a trading bonanza for the exchanges!
From what I understood, a valid SegWit block will appear valid to an old client.
Certain invalid SegWit blocks will also appear valid to old clients, but those blocks will be rejected by SegWit-enabled miners, so they have little chance to be included should the miners change.
You're correct. However, I'm fairly sure OP was talking about Segwit (with 2x).
If most users/exchanges/services don't get on board by the time the scheduled segwit2x hardfork happens, then those blocks would be considered invalid.
That makes sense. However from what I've read, the timeline is "SegWit -> multi-month transition period -> 2x HF".
So by the time the 2x fork comes up, the segwit-enabled chain will already be in use for several months.
Another point I'm wondering (sorry if that's a noob question) : Assume that some of the forks actually lead to a chain split with hashpower distributed 90%/10%.
At some point, the difficulty of the chains will adjust to bring both of them back to the "one block every 10 minutes" rate. However, this will not happen immediately but only when the current difficulty period would complete. Before that happens, the minority chain will still have the difficulty from before the split - the one that assumes 10x as much hash power as now is actually available. That sounds as if the minority chain could become effectively unminable for the rest of the difficulty period. Worse, as the period durations are measured in mined blocks, if blocks are mined slower, the difficulty period will also go on for a longer time.
> So by the time the 2x fork comes up, the segwit-enabled chain will already be in use for several months.
Correct. But there's an asterisk here: most people (78%) are running bitcoin core, some run Core/UASF (5%), and some run bitcore (2%). Together, that's 85% of nodes. Core 0.14, Core/UASF, and bitcore are all compatible with segwit, but not with the blocksize increase. Even if you wait multiple months, if people stick with Core (a possible outcome) then they will see 2x blocks as invalid.
> That sounds as if the minority chain could become effectively unminable for the rest of the difficulty period.
The chain wouldn't be unmineable, it would just get mined slower (mining profitability wouldn't be impacted for miners staying on the chain provided the price stays the same). But you're right, blocks will come slower, throughput will be lower, and the adjustment will take longer.
Note however that several services/exchanges are part of the NYA (segwit2x supporters) too. That's one thing that makes this hard fork much different than previous attempts.
I apologize for asking what is probably a bitcoin-noob question, but can you explain (or elaborate on) why hash power has that effect? What does a "minority chain" mean? If you have two groups using different hashing algorithms, why would that have any effect on either group?
The issue is that both groups derive from a single block chain at some point, so everyone who held BTC before that split can spend them on both forks, whereas those who receive them or mine them after the split only hold the currency on one fork.
Additionally, if the split of hash power is highly asymmetric, then the difficulty of the majority fork will become much higher than that of the minority fork, over time. This opens the minority fork up to 51% attacks. Say the split is 90/10, then just 15% of the miners from the majority could team up and switch back to the minority fork to wreak havoc.
They are using the same hashing algorithm with different consensus rules. That's exactly the issue. They are fighting over the same pie because proof-of-work is what defines Bitcoin.
but if the hash power users leave to another blockchain, and holders of imaginary tokens remain and trust the old blockchain, then the remaining lower hash power users became the dominant hash power.
How is it going to have value if the client people download at bitcoin.org don't support the chain with massive hashing power you speak of? Not to mention PoW change.
So, no, hashing power is not "all you need" to take over Bitcoin. For many people, Bitcoin is whatever their wallet supports.
90% of the hashing power has signaled their intention to adopt segwit2x as of late June. I assume it will become the dominant chain once it locks in right before August 1st.
That's assuming hashing power will determine the outcome.
In the exchanges runs will take place. The actual economic users will vote this issue out.
In the end spreadsheets will be updated, and miners won't want to spend their electricity on a chain that went unprofitable.
Miners may have the software coming from segwit2x, and be the ones who actually provide the technical consensus. But the economic consensus will trump everything else; and late software along with questionable roadmap does not inspire confidence.
Hashing power is what mines the blocks. There will be no "voting the issue out" if the dominant chain is using Segwit. Just because you buy a few BTC on GDAX or something doesn't somehow give you more say than the miners over what software gets run on their own machines. Vast amounts of hashing power is concentrated in the mining pools that are signaling support for this and 99% of the people speculating on these currencies don't care about the underlying protocol, they just want to make money.
That's misunderstanding even the basic issue here. Segwit signaling needs to begin August 1st, it won't lock in for about 2 weeks and that has nothing to do with the 2x part which won't even happen until November.
Incorrect. NYA begins locking in Segwit as early as July 21st. The point is to get Segwit locked in before August 1st so the UASF has no chance of creating a second chain that has any chance at life. You are correct that the 2x portion will require a hardfork that will presumably come down the road.
No major bitcoin company has stated that they will run segwit2x client. If you have conflicting information, please link announcement/blog post about that.
As for the hashpower, it doesn't matter what clients miners run. You can't force the nodes to run specific client with hashpower.
I'm not sure if you consider Coinbase a major bitcoin company yourself, but I think they qualify.
If I was to make a prediction, everyone will be running segwit2x or another client faking segwit2x support, to get segwit passed by Aug 1st. Then once October comes along we'll have another fight over the actual blocksize hardfork.
That doesn't look like a very good proof. If coinbase plans to adopt segwit2x, why haven't they released an announcement? I wouldn't trust that wiki list very much.
You can click through to see the sources on each one on the table there.
And don't trust the wiki, no need to. Trust the hash power. The NYA signal was just a promise, so don't trust that one. But the BIP91 signals are coming in already. Just need to get that over 80% for just over 2 days. Then we'll see the original segwit signals jump to the 95%+ it needs.
But the truth is, you don't have to worry about finding any support proof or anything. We'll know what happens over the next week or two for sure. I don't care whatever direction it goes in, I just want it to go smoothly.
You basically can do exactly that. Unless the companies involved want to run on a minority chain with much less hash power, which means they are exposing themselves to a 51% attack as soon as their difficulty drops significantly behind the majority. Hash power is a very big stick.
All those claiming that coinbase is planning to run segwit2x, please link to a statement provided by a representative of that company. I think you are just talking bullshit.
That agreement seems very general, doesn't indicate that the participants will run specific code. Segwit2x client didn't even exist at that time, first release was yesterday.
Not making it up, talking to real people in the space.
You can also check out the SegWit2x mailing list archive [0] for companies actively testing SegWit2x. From there I've seen BitGo, Blockchain, Bloq, OB1 (Open Bazaar), Purse.. these are significant companies in the Bitcoin economy.
Testing is very different from actually running it in production. Companies test out a lot of different things. I think with consensus code companies will be very careful and if they plan to do something regarding that, they will announce it clearly, not in some half-assed wiki site or medium post.
That's... you're woefully out of touch with how people communicate in this space.
Show me where on these companies' sites it says "We run 0.14.2 of the reference client, with this patch set, and don't plan to ever change"?
Anyway, we'll see what happens in the next two weeks I guess. I'm expecting we lock-in SegWit via the SegWit2x client and then have another debate in a few months about the hard fork. Hoping not too many sw2x supporters get cold feet in the meantime.
What? They had first release like yesterday, the project has released one tarball, no packaging, no very good marketing etc. The biggest marketers seem to be the tinfoil hat opponents who fear the fork so much that they speak about it everywhere.
I don't think it is at all likely that segwit2x client will gain support. Or if it will gain support, it will take years at this point for it to gain any considerable support.
The whole thins is totally exaggerated. People have nothing to talk about, so they will invent tinfoil hat scenarios and discuss those. Bitcoin protocol has staid fundamentally the same for many years and it is pretty likely that it will stay that way.