Bitcoin Forum

I was surprised by the latest announcement of Pieter that a SegWit implementation which changes pretty much everything in bitcoin can be implemented via a soft fork, where it does not require all the nodes to upgrade to be compatible

After a bit research, this is possible because you can always give old data new meaning in a new implementation, while the old nodes simply do not know how to parse that data

In principle, with this method, you can move all the transaction data out of the block, not only signature data, so that old nodes always see empty blocks

As a result, a new block will be accepted by the old nodes because they appear to be valid blocks, but in the new implementation, they are just a small subset of the new data structure, all the transaction data is in another related block


More importantly, after further analysis, it shows that although normal nodes can still run old client, all the mining nodes will have to upgrade, otherwise the blocks mined by them will simply be orphaned, because the new nodes do not accept old blocks, and new nodes have majority of hash power

As a result, such a soft fork is to force 100% of the mining nodes move to the new implementation so that there is no slightest chance of the old mining nodes forking into their own chain: Their fork will always be orphaned since they accept the longest chain


What this means in practical?

If one type of nodes, Classic for example, controls over 51% of hash power, they can implement whatever change they like by simply use this soft fork trick: Let all the old Core nodes accept their new format blocks while Classic nodes will reject Core blocks, so that Core blocks all get orphaned due to less hash power

The most deadly part is that Classic nodes do not need to ask for permission of Core nodes, they simply enforce it by orphaning blocks mined by those Core nodes. And Core nodes have no way to fork into another chain by rejecting Classic blocks, since they can not tell which block is Core block and which block is Classic block

As a result, a miner running core will simply lose money, he either trash his miners and quit the game, or bite the bullet and upgrade to Classic so that his hash power can still mine him some coins. I guess majority of the miners will upgrade. And they might start another round of similar soft fork to regain control when they accumulated more than 51% of hash power


This is very bad, since it totally removed the freedom of choice for those old mining nodes, you can call it a forceful take over of bitcoin network rules by 51% hash power. It totally break the major consensus rule and the spirit of bitcoin, so that with only 51% of hash power, you can implement whatever you want and force it upon rest of the miners and their hash power will be captured

Sure, Core nodes can change to another PoW fork, but since the value of the coin is always roughly the same as the mining cost due to arbitraging, that coin will not get more value than litecoin and will be forgotten quickly


Unfortunately, it is almost impossible to prevent such thing from happening by current design, so it is very important in mining community to widely spread this information so that miners are fully aware of the deadly effect of a soft fork, and reject such attempt as much as possible. At mean time, trying to find a solution to fix this security vulnerability

The same happens with hard forks as well. Deployment requires consensus.

Again, deployment requires consensus, as it does with hard forks.

Anyone can do that now. You can orphan blocks mined by other miners now, it makes no difference. Again, consensus. Same thing happens with hard forks.

They will probably upgrade. As I said before, and I will say it again, consensus.

So really what is the difference in the forking between a hard fork and a soft fork? The Core nodes can proceed as they did because their chain is orphaned. Any blocks produced by the core nodes are ignored by the Classic nodes. The core nodes, if they are able to build extend their own chain, or at least build a block on top of a core block, results in their chain completely separating from the classic chain since they have a different block history. It splits, much like a hard fork.

And how would you propose to fix this? It isn't a security vulnerability, it is an issue with forking that is not able to be resolved due to the nature of forking. It isn't really any worse than hard forks are, but with the backwards compatible nature of soft forks, not all nodes are required to upgrade, only mining nodes. Hard forks require that all nodes upgrade.

Again, the way that both hard forks and soft forks are deployed are with consensus. Neither one is deployed unless a supermajority of the blocks indicate support for the fork. The deployment is the same with both forks. I don't see how a soft fork is worse than a hard fork.

tl;dr All forks are dangerous and all forks must be deployed with consensus otherwise problems happen. Applies for both hard and soft forks.

It seems you still have not get the fundamental difference here, and it is indeed difficult, because you have to first understand the most technical intensive part, e.g. the old nodes do not know at all that there is a new chain forming

It is dangerous to do a hard fork with only 51% hash power, because it will end up with 2 chains and you can not guarantee that your chain will win eventually. So you must seek major consensus before you fork.

However, you don't need major consensus to do a soft fork, only 51% hash power. In fact the name is misleading, there will be no fork in a "soft fork". You can be rest assured that there will never be a competing chain, e.g. even the other 49% of mining hash power disagree with the new chain, they can not fork their own chain, because all their nodes regard new chain to be the longest valid chain, or to say, old nodes do not know it is already a new chain, they thought that they are still working on the old chain, the only difference they will notice is that suddenly all their mined blocks are orphaned one by one


Of course the final result will be similar, but a hard fork with major consensus will create two chains, so that those disagree with major consensus could run their fork as a small alt-coin with much less hash power and value, and they will see later that chain is not practical both economically and security wise but they can still run that chain forever for hobby, or even as a test network

With a soft fork, there is no such possibility, if you disagree, you can not fork your own chain, either you upgrade to new chain, or you node become the slave of the new chain, you don't have a choice

Technically, using a soft fork can make sure that there will never be a fork, since all those mining nodes that disagree with new implementation will be captured and just mine useless blocks that will never be accepted into the blockchain. So I can understand it is a powerful hack to keep the highest level of integrity of the network. But everything has two sides, since it is such a devastating weapon that can overtake the network without major consensus, what if your political enemy get it and fire it up on you?

to: johnyj
a slight correction

soft fork attack, does not produce a different chain. it just manipulates the information within the chain to make older clients no longer understand much of what they are passing along. basically giving them cataracts and told everything is fine just pass it on, blindly.

the older clients would still pass on the information(thus being "compatible"), but without checking it. making old nodes no longer "full" and just "compatible"
imagine it like downgrading bitcoin-qt's* network responsibility down to being multibit's network responsibility, without the user choosing to be downgraded or ultimately informed that its a downgrade, using wishy washy words that everything will be fine..
*i used QT as just an example of a full node instead of core, purely to avoid confusion of blockstreams debated future implementations of the name core

people need to realise that once segwit hits.. all other full node implementations are no longer "full nodes" but "compatible, but impaired" nodes
there is not a 51% numberic flag..
basically
if 1000 people make a transaction.. and one of them is a segwit implementation
99.9% of transactions the network will understand and 0.1% of transactions wont be understood. but that transaction would still be handed over blindly
if 1000 people make a transaction.. and 250 of them is a segwit implementation
25% of the network will understand 100% of transactions. and 75% wont understand a quarter of transactions they handle. but the transactions would still be handed over blindly

once the segwit debate is over, the next generation of softfork is weakblocks. which would again reduce the verifiable data inside the main block and push it out into secondary blocks, changing from having cateracts, to complete blindness



this is the theorized idea of what would be happening between now and 2017
https://i.imgur.com/hWAGEIg.jpg

and blockstreams rhetoric is... dont worry, you wont be affected.
but when pointing out that full nodes are made blind,, they reply ..if you want to be a full node. you have to upgrade to our agenda

Upgrading your node would be the answer. What's the problem with that? Keep it concise, please

Not true, just look at the July 4th fork for an example of a fork that happens with soft forks.

Blocks that are mined by the nodes with the old rules are invalid by the new rules. But if there are enough miners mining old blocks, then they could still be extending the old chain. In fact, if they were able to extend the old chain, you would end up with two different blockchains because the histories are different. Once an old block is inserted into the blockchain and miners extended on that, it would fork since the blockchain of new blocks is invalid since it has a different history. Likewise, the chain of old blocks is invalid to the other miners because they are old blocks.

Yes, the July 4th fork is possible because more than 50% of the hash power was doing SPV mining thus they could fork an old chain with major hash power. But in my example, the new chain owns more than 51% or even higher amount of hash power, which makes this kind of fork impossible

This is also another dangerous aspect of the soft fork, since some pools who have more than 30% of hash power might first support the new implementation, and after the soft fork is triggered, they changed idea and reverse to the old version thus make the old hash power larger than 55% again, thus the new implementation will stay in a new fork with minor hash power and possibly die

The question is upgrade to which version: SW? Classic? BU? XT? They all can be implemented use this soft fork trick, and it seems Classic currently have more than 51% hash power backing

How does it make it impossible? If your 51% of the miners are also SPV mining, they can just as likely fork the blockchain. Even if they are not, just one miner with the old rules getting a few blocks onto the blockchain can result in a fork.

The same can happen with a hard fork.

Exactly, I'm against this hacky soft fork practice since this is pure scam, it is possible because bitcoin nodes are so stupid, they can not understand something that is not in their existing knowledge base, they can not sense the change in environment

I recall this trick was originally brought out by Mastercoin, by encoding information into bitcoin transactions, they could use blockchain to securely transfer other information. This parasitic behavior caused some panic among devs, Peter Todd even joined them to see what was happening there. But it seems it costs too much to transport information using blockchain, so I did not hear from them any more. But the idea is widely spread and I think the side chain concept is also spawned from this thought

Happened read this days ago

https://www.cryptocoinsnews.com/davos-elites-talk-bitcoin/

“We know that bitcoin itself is a complete failure and shows the number one law of programming and software: that anything that can be programmed can be hacked. So nothing is completely secure,” said Willem Buiter, Citi’s chief economist.

This guy is smart, he really get some fundamental philosophy here. But he forget about that without hash power hackers don't have write permission to bitcoin blockchain. It seems the hash power is the only force to prevent bitcoin from being hacked. It is very important to make sure the mining nodes are not infected by this kind of virus, otherwise one day you wake up just find out that all your blocks are orphaned and you have to upgrade to a new version with the amount of total coin supply extended to 42 million  ;D

Indeed, the new chain might also have lots of SPV miners, but I think if they are aiming for a hostile take over with 51% hash power, they will be well prepared so that all their mining nodes are not doing SPV mining

A hard fork does not have so many uncertain risky scenario that can go wrong. A hard fork is a well informed situation so that everyone knows what will happen and be prepared long before it happens

I'm sorry you disagree with the primary process by which the Bitcoin system evolves which has been used since the very beginning.

Perhaps you should take this to the altcoin subforum. No one is going to buy into the suicide pact Hearn and you seem to wish for-- and even if they did, they can't enforce it: soft forks can't be prevented.

True, but a soft fork can still result in forks even when not SPV mining, as I have explained above.

And so are soft forks. When soft forks are planned to happen, everyone knows what will happen and they are known ahead of time. Like hard forks, they still require consensus in order to fork smoothly.

I know that soft fork eliminate the risk of fork by forcing nodes to upgrade from old version, but this can also work against you when some one with a different political interest gathered enough hash power, just want to list the fact

And I am not aware of this is the primary process since the very beginning, where can you point me to for a detailed documentation?

It was almost certainly here on bitcointalk, Jonny

Hardforks are much safer. When people claim softforks are safer, they are only referring to the software developers pushing the changes.
A softfork can be shipped with little to no consensus.  Keep in mind that Bitcoin is about what people run.  
So what node you run and which SPV client you run decides what you think is Bitcoin.
The problem with soft-forks is that that the software people no longer need your vote. And so they get full power over the protocol.

So its not safe to end users or node operators, its safe for the new policy makers of Bitcoin.

You can read more about why soft fork is unwelcome here: https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.6c7yhmrg2

What matters most to the user is that their own bitcoin transactions are verified. Anyone running these nodes (http://thebitcoin.foundation/) are not compatible with many soft forks currently running.  They don't care because it's not any transactions that involve their own bitcoin.  Soft forks preserve every users' choice whether or not to opt in, whereas hard forks break this capability -- along with introducing other unknowable systemic risks, but that's for another post.

OP Are you saying "Why soft fork TO SEGWIT is a bad idea?" I agree. Good post.

Segwit just ain't Bitcoin.

He is saying that all soft forks are bad, but it is interesting that he only brings it up now when SegWit is being prepared to be deployed. We have had multiple soft forks already to deploy new features. It seems to just be an attack at SegWit while simultaneously attacking soft forks.

How so?

This is nothing but a classic 51% attack by cooperating miners, and has nothing whatsoever to do with soft forks.  If you manage to control 51% of the hashpower, you can ignore everyone else and always have the best chain.  Bitcoin 101.

I personally never liked the weak block idea, and the over complexity.

But OP also seems to brings up an attack scenario specific to segwit.
Previous soft forks have not rendered nodes blind.(?)

I think it is an attack on segwit. Sort forks are only the delivery method here.

Weak blocks are not segwit. They are two completely different ideas.

SegWit does not render nodes blind (and blind to what?).

So here is the discussion going on, not in the other thread johnyj... :)

I have read your explaination and indeed i think this is a hefty thing to plan. Consensus is something different i think. It is tricking into believing everything is right.

I'm surely not so much into the tech so i might be fully wrong. Don't take it agains me. :P

So what i ask myself, when the old nodes only see empty blocks, aren't the transactions needed to calculate if the block hash is correct? If the transactions are not seeable then how can the hash be calculated as valid? As far as i remember, changing the transactions of a block will give you another seed part that is used as base to find the block hash.

You write that segwit miner still would need nearly half of the network to do this fork but wouldn't it be sufficient when 10% segwit nodes find a block, let's say a minute before the 90% non segwit nodes, then they propagate it through matt's network(?) to all the big miners and these miners can instantly confirm the block because nothing big to be calculated. They would accept the block and that would be it.

Though even then, the old nodes would still think the bitcoins, that were moved in the segwit block, are at the old addresses and the segwit nodes with bitcoins that were transferred already, wouldn't that mean a fork of some kind has happened because a big part of the network has different details about the status of the bitcoins?

Further on, when the network only has 10% segwit nodes, which is likely in the beginning, then wouldn't there an attack vector by misusing the blindness of the nonsegwit miner nodes?

I mean depending on how the nodes confirm the segwit blocks at all, what if someone creates a block that contains fake segwit transactions? Completely rubbish or scammy transactions. The segwit nodes would discard this block but the nonsegwit nodes could not check if the block is invalid. They would accept it and hardfork. Though when i think about it, nothing would change for the nonsegwit nodes anyway because they don't know the segwit transactions. And the segwit nodes would still work on what they know.

Which brings me back to my previous question, when the nonsegwit nodes don't see segwit transactions then they will build blocks on data segwit nodes don't use. So it would still be a fight about trusting who will win since when i would receive bitcoins with a segwit transaction but the majority of the net is not accepting that transaction then i would not accept that transaction as valid too since i could not be sure that these bitcoins will be there in the future. So i would have to consider them worthless.

So what's the status of miners claiming to accept segwit? >50% hashpower?

Sorry for my lack of knowledge on the topic. :P

What I am getting from reading all this:

Soft fork = 51% attack = no new fork for those that don't agree, no new 2nd coin

Hard fork = Consensus = yes new fork for those who disagree, or rather a new fork for those who want the change, making 2 coins


In my mind 51% is not = to consensus. To me consensus mean 95%+ or with the hard fork you choose to use the old coin and not the new coin if you don't like the change and if it doesn't work out the good old bitcoin is still there VS the soft fork that changes bitcoin wether 49% of others like it or not..

Am I understanding this correctly?

No. Soft forks are still forks and as I have explained earlier, can still create two blockchains.

All forks, hard and soft, deploy with consensus (or should). Every soft fork that has previously happened deployed with consensus. It is still a fork, and forks deploy with consensus, not just 51%.

I'm not specifically aiming segwit, but this soft fork idea is not the traditional soft fork. In a traditional soft fork, the new version only tighten the rules and make the new version more strict in accepting blocks, so that some old blocks become invalid, like july 04 soft fork. But this soft fork is trying to cheat old nodes to implement other rules, which are not a tightening of existing rules, but a total change to another set of rules

It came out from the HongKong conference, where Pieter said he originally thought it is impossible to seperate the blockchain data without a hard fork, so he dismissed that idea, but later Luke_jr told him that he can do this trick as a soft fork

But what I don't understand is, if you use this soft fork trick, you can expand the blocksize to 2MB the same way, avoiding a hard fork too. So if the main purpose of Segwit is to avoid hard fork, then a 2MB soft fork will be a better solution than Segwit, since it does not need to separate data, which causes some extra coding and testing


Segwit to bitcoin is a RAID to a hard drive, they can achieve the same purpose of storing data, but technically they are not the same thing

In my previous knowledge, there are things 51% attack can do, like double spending and reverse transactions, but there are things a 51% can not do, like spend the coins in other people's cold wallet etc. But now I understand, these are only true if the attacker run the same software as the rest of the network

Under this new soft fork trick, a 51% attack is not only a disturbance of the transactions, it become a political weapon to suppress the people with different idea and force them to give up due to their economy incentive

In old nodes' view, it is just an empty block with a coinbase transaction, nothing special,  like those blocks generated by SPV mining. So the hash function will return OK signal.


You are right. If Segwit nodes only have 10% of hash power, then when they publish their block, the block will be accepted by core nodes, and core nodes see nothing in it. But in Segwit nodes' view, that block contains a transaction that spent Alice's coins. Core nodes does not see this transaction, thus they believe Alice's coins are still there, but in Segwit nodes' view, it is already spent

As a result, later when core nodes trying to spend those Alice's coins, that block will be accepted by Core nodes but not Segwit nodes, so a fork will happen. The fork happens because Segwit nodes does not have enough hash power to prevent core nodes to publish Alice's transaction. If Segwit nodes commands more than 60% of hash power, then core mining nodes will never be able to spend Alice's coins, because all their blocks are orphaned. And there will never be a fork



True, this has been pointed out by someone and it seems to be a big issue. If a rogue segwit miner publish an invalid segwit block, it will be accepted by the core nodes while rejected by segwit nodes, so a fork will happen from there. In fact this makes the segwit implementation phase so vulnerable that just one invalid block will cause it to fork into its own chain

(Correction: Before the fork condition is reached, e.g. 75% hash power supporting segwit, segwit nodes will not generate and accept new transaction format, so the system is still safe. And after the fork, the attacker need more than 25% of hash power from segwit nodes to push in such an invalid block, since the other 25% of old nodes' hash power will assist to write the block into the chain)

The attacker can run whatever software he wants, as long as he, or they, generate valid blocks.  If the blocks are invalid, e.g. by creating or spending coins in invalid ways, the blocks will be ignored by all validating nodes.  (SPV wallets may be vulnerable if the attacker has enough nodes on the network.)

You aren't describing a soft fork, what you describe is a 51% attack.  You describe a situation where 51% of the hashrate cooperate by ignoring blocks produced by others.  This is perfectly doable today, and the main reason why miner centralization is a problem.  If you mine at the large pools, switch to one with less than 10% of the global hashrate.

Soft forks aren't activated until 95% of the last 2016 blocks conform to the new rules, btw.

In case of an intentional attack towards bitcoin, there is no difference. An attacker (a bank or government for example)who want to destroy bitcoin would just publish empty blocks and stall the network with more than 51% of hash power, and they don't need to change the software, just use the same software as the rest of the network

However, in case of an internal political conflict, this becomes dangerous, because the attacker might not want to kill bitcoin, but just to capture and morph the hash power from his opposite side to his side. In that case, commanding 60% hash power can almost guarantee it will happen

This. I hope it never comes so far

Just wait until they start running multiple soft forks in parallel:
SegWit & Soft Forks & Sidechains, Oh, My! - Andreas Antonopoulos on Bitcoin (https://www.youtube.com/watch?v=kSq-58ElBzk&t=12m40s)

And that will trigger lots of hard fork without people even understand what is happening

No, a soft fork can not trigger a hard fork.  A soft fork can trigger chainforks which are longer than normal if a malicious miner claim they have support for the fork, but don't (which is a very bad idea from an economic perspective).  The chainfork is not hard, and the risk is pretty low.

So the actual transactions are not needed to calculate the block hash? And the transactions normally are only checked to see if they are valid but if they are valid then no checksum or something like that is created to calculate that the actual hash is correct?


I wonder how i should react on this. I mean let's assume segwit nodes start with 10% of the hashrate. As an escrow i receive coins. But either these coins only moved on the core mining nodes or only moved on the segwit nodes. The end is i can't be sure if i actually received something of value or which chain will win at the end. When i trust segwit wins then actually core nodes might win and vice versa.

The only way to handle this might be to check that i received the coins on both chains, right?

Well this really is stupid when this is enforced this way. A soft fork with 95%, like it was done before it seems, would be way safer because you know the new thing won so far and it is very unlikely that it will lose then.


Oh that actually sounds like the soft fork is implemented similarly like previous softforks? I thought segwit nodes will start to generate segwit blocks right away. So even when segwit nodes would be sure that the miner rewards for their blocks will be safe even on the other chain, they won't create segwit blocks at all until they reached majority?

They are. The merkle root is a field in the header that is the hash of all of the transactions. To check the validity of the merkle root  and thus the entire block header, all of the transactions are hashed together to see if the resulting hash matches the merkle root.

Soft fork deployment of 95% will happen. No fork deployed by developers will ever deploy without some sort of block majority.

SegWit will deploy just as previous soft forks have. There is no point to immediately start creating segwit blocks as that is also dangerous.

Can anyone explain the major difference between a soft fork and a hard fork? And why is everyone afraid of soft fork?

Soft forks are backwards compatible meaning that people running old nodes do not need to upgrade. Hard forks are not so everyone will need to upgrade their software in order to remain compatible.

People are not afraid of soft forks, they are actually the preferred method of the devs to deploy new features. It is just that people don't like SegWit which will be deployed as a soft fork.

Then the transactions get only checked against the merkle tree, which can contain all segwit transactions too, as long as the basetransaction is in there too.

But the transactions or the merkle tree plays no role in the calculation of the block hash?


Ok, the OP sounded differently and i'm no expert.


Good to hear that. If segwith really reaches that leven then it is pretty sure that it will stay since it won't lose support then anymore.

Wrong.  All transactions are recorded in the block.  Only the signatures are moved.

Wrong.  An old and a new node will have the coins at exactly the same places.  The UTXO set will be identitcal.

Segwit will not be activated until 95% of all hashpower support it, like with all soft forks.

Please educate yourself about segwit and bitcoin in general.  Have you been on Reddit or something?

There have been many soft forks so far, and it is nothing to be afraid of.  There was an issue with one of them due to a malicious miner who ended up loosing 175 BTC.  A merchant running an ancient version of bitcoin accepted the bad chain and lost on a double spend, but that's the only issue I can remember. 

Hard forks is a completely different matter.  Hard forks don't resolve themselves until 100% of all nodes have upgraded.  Until then Bitcoin will be unsafe to use, and people will lose money.  Even worse is the forking planned by some by releasing various altcoins and try to overtake a majority of the bitcoin hashpower.  In that case even upgrading to the latest version won't resolve the problems.

Do you speak about the time that will be used by segwit to reach 95%?


Then were comes the less datausage from? The signatures are not needed to verify the tx?
[/quote]

Always, even after segwit has been deployed.  Only the witness is segregated, as the name implies. 

The only thing an old node cannot do after activation, is verify if a transaction to a segwit address is valid or not, as it will always seem valid to an old node.  Fortunately this is of no consequence, since old nodes will never generate that kind of addresses or receive segwit transactions, and the risk of an old node generating a block with an invalid transaction is very small since more than 95% of the hashrate follow the new rules.  A longer chainfork is very unlikely, but as with all soft forks merchants should of course upgrade.  Old nodes can send to segwit addresses, but not spend coins sent to segwit addresses.  Read the BIP (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).

Why do you think segwit has less datausage?  It doesn't.  When it has been deployed, segwit transactions (i.e. only transactions to the new address types associated with segwit) will have their witnesses recorded in a parallel block of witness data.  The total capacity of the two blocks is 4 MB.  This can be extended by various mechanisms in a later soft fork, or more likely by using sidechains and payment channels.  The latter mechanisms are IMHO better, since they scale better and don't increase the cost of running a full node.

The merkle root is part of the block header and the block header is what determines the block hash.

Thank you for the explainations. I'm not so much into the details of the tech so i appreciate to learn how it works.

So when the witness is segregated into a parallel block then the amount of data to be transferred and to stored would not be less than if you would put the same amount of data into a normal traditional block? I thought this was one of the main reasons that were brought up against raising the blocksize limit. And the segwit nodes would have to verify the transactions, which then would mean the CPU would still have to work on, let's say, 2MB worth of transactions.

So the internet use, harddisc space and CPU-Usage would not be lower for the same amount of transactions than with traditional blocks?

sturle, you say that it is very unlikely for an old node to create an invalid block. Though segwit surely won't start with the majority of miners. So when segwit hashpower is at 10% of the net then no segwit blocks will be created, segwit blocks start at 95% of hashpower only. So 5% of the blocks would have potentially a chance of being invalid blocks because the old nodes can't see that some addresses already have their bitcoins taken away and they might try to spend them again. Though it doesn't sound like a big problem since when segwit reached that threshold then it is sure that it won't lose that power anymore. It would be safe to switch.

But it is not sure that segwit will reach that, right? Though it would be the same like with the old nodes. It would be safe to assume that segwit wins and that this transaction will never get invalidated.

So it is sure that segwit blocks only start to be created once segwit nodes hashpower reach 95%? I have read it differently, like it would be done from the start to enforce the adoption. So implemented in a different way than previous soft forks. So it is definitely the case that the old threshold is used?

To be honest... at the moment i don't even see anymore why segwit is an advantage when the arguments against 2mb blocks, internet, cpu and harddiscspace usage, are not changed. So it is only easier to raise?

I guess i misinterpreted since that sounds strange.

With the capacity, it has the same effect as increasing to 2 Mb. However, another benefit (the original purpose actually) is that it makes transaction malleability entirely impossible. SegWit would still have been created and used because it fixes transaction malleability. It just became something for capacity which is just a side effect of moving the witness data out of the block.

Pretty much.

SegWit blocks will be produced when at least 750 out of the last 1000 blocks indicate SegWit support by having a version number of 5. Due to the backwards compatible nature of segwit blocks, this is fine and non segwit blocks can actually be built on top of SegWit blocks. However, after 950 of the last 1000 blocks, all blocks less than version 5 are considered invalid and that is actually when the forking happens.

Thanks for explaining.

I find it a bit strange then why so many say that we should not raise the blocksize limit because segwit can do the same. Though it has only the advantage that it protects against an attack vector. Though good to know.

So at 75% a kind of fork starts? Old nodes would not create invalid blocks when trying to send bitcoins from addresses that were already cleard though a segwit transaciton because old nodes would still see these transactions right? So no big problem for the old nodes at this point?

I'm not quite sure what you are asking, but I will try to answer what I think you are asking.

Old nodes/miners would still see segwit transactions and accept them as valid. However, if someone wanted to spend from a SegWit transaction, they could try and old nodes would accept any spend from a segwit transaction even if the spending transaction wasn't signed with the proper private key since old nodes would treat segwit transactions as anyonecanspend transactions. However the inclusion of any such transaction in a block would result in that block being orphaned as well as that transaction being rejected by many nodes. However, that does appear to be an attack vector and I don't know why 75% was chosen. I'll look around and ask it on the mailing list as well if I don't find an answer.

CPU usage will be lower.  Large transactions with many signature validations may take very long without segwit.  A few months ago there was a 1 MB transaction, taking an entire block, which took 25 seconds to validate on a modern CPU.  It is possible to create a 2 MB transaction which take 10 minutes to validate, because signature checking is O(n²).  Segwit eliminates one hash operation, making this scale linearly.  A 2 MB transaction with a segregated witness will take less than a second to validate.

Thank you guys for your answers.

So regarding cpu usage segwit has some advantage when transactions included are big. Discspace won't be affect since the data needed for segwit is probably a little bit more than it would have been for the same amount of bitcoins in old blocks. The same should be true for the bandwith usage.

Might be that segwit miners have an advantage in mining too since they can confirm a block faster. Though i think the best way to mine would be to start mining as if the block was real then start to verify the previous block and start to include transactions into the new block, changing part of the seeds. That would probably be the fastest way to mine since miners cold mine instantly on the probable newest block.

By the way, i have read that there is already a fix against this 10 minute validation of a transaction. It only is not implemented in core yet. Might be that it is, or get, included in classic. Surely should to not give open space for attack.

Sturle, when segwit eliminates one hash operation then this has no effect at all on the safety on bitcoin, right?

I think it sounds pretty scary that old nodes will accept transactions they can't verify. Luckily only coming when segwit practically won. Otherwise this could have become a mess.

For segwit alone, yes.  Of course segwit makes other optimizations very easy.  You can pass long chains to to the blockchain, A to B to C to ... to Z, where a node can validate and commit A to Z in one operation, leaving all the intermediates out of the blockchain.  And the best of all is the fact that all transactions in between, e.g. Q to R, can have the same instant security as the number of confirmations of A.  I am sure this will be the preferred way to transfer bitcoins in the future, due to the instant secure transfers and better privacy.

This has lead to chain forks and large losses for miners.  But the real danger is for SPV clients.  An SPV client will not be able to validate the chain at all.  If a chain is built on an invalid block, SPV clients will see false confirmations.  One proposal in segwit can eliminate this to a varying degree.  Eiher in a mild form, by including a proof of knowledge of the contents of the previous block, a stronger form that you must have validated the previuos block, and an even stronger form where you have to include transactions in the block you mine for it to be valid.  All this is possible, and of course the strongest forms are controversial.

Core doesn't need it.  Worst case for core is about 25 seconds, and this risk is eliminated when segwit has been deployed.  XT had a bad hack where they introduced a hard limit on 100 kB for transactions.  It would take a new hard fork to raise this limit.  I have no idea what the so-called "Classic" implemented, but last time I checked thje suggestion for doing the same in "Classic" had very few followers.  "Classic" is supposed to be a hard fork to increase the blocksize to 2 MB, and nothing more.  Then again, I think "Classic" mostly ignore this consisder.it thing, and just do what they want.

Correct.

All nodes will do that now, in fact.  Your node will accept transactions out of order, i.e. a transaction spending from a transaction you haven't seen yet.  Your node will not know if the transaction is valid until it has seen the parent.  It won't be confirmed until the parent is, of course.

Thanks sturle... so far segwit sounds pretty positive to me now if watched at isolated. It has to show that it reaches the effects claimed first, i think. There are very different estimates as to how far segwit will be able to stop a blocksize limit increase from happening. I hope an increase will be done anyway when problems arise and that bitcoin does not lose one of its rare advantages, the cheap transaction. The visions some people have are, thought to an end, frightening. I really don't want to see a bitcoin whose fees are so high that practically only companies and "BANKS" will be able to pay it by merging many transactions into one bitcoin transaction. It would mean the opposite of what satoshi wanted i think.

I only hope it does not come to this point. Anyway, segwit alone seems to a nice project and i don't see real reasons to not implement it.

---

SPV Mining led to the losses because the did not verify the block at all, i believe. Now they changed their ways and they verify, but they already start mining on that block. The verification should not take ages so it will be seen fast that the block is valid or not. But they safe the first time where it is unknown so that in case they find a legit block they can propagate it without losing the profit. It seems mostly this behaviour worked even with unproven blocks so it will be a good decision business wise.

Of course the network can block this simply, which is a legit way in my eyes.

---

So is the solution for this 10 minute quadratic solving time only a hardlimit for the transaction size? I have read somewhere that it was a proper solution BIP something or so. Though it might have been such a hack only.

I wonder if core really would not need it. There are calculations showing that worldwide adoption will make it inevitable to raise blocksize limit anyway. I wonder how far segwit can go there. I mean how many times more transactions can be handled when all safe optimizations are used.

I hope segwit does not implement new attack vectors no one thought about yet. At the end segwit works on basic principles that were not hackable. And practically every new hack goes ways nobody thought about before. Not that i think that bitcoin will be hackable, but maybe harm can be done.

When speaking about forks, CIYAM claimed that exchanges would need to close down when a fork happens that divides the network. Since exchanges can't risk to lose the value when the coins in their wallet are coins from the losing chain.

But i think that exchanges can still run normally, the only thing they would need to do is holding the wallet they chose to use AND holding a wallet that runs on the other chain. Then they import the privkeys of the first wallet into the second wallet and when someone deposits then they only will accept the withdraw when the coins show up in the bitcoin address on BOTH chains. Then they can be sure to not lose anything. If it does not show up then they reverse the transaction on the one chain that worked.

Am i right with thinking so?

A long fork is extremely risky business.  During the next few weeks, the standard Bitcoin side of the fork can easily overtake the other side again.  Actually the most profitable strategy in this game to a miner would be to announce the intent of switching, then not do it when the switch is supposed to happen.  Many other miners will then waste their resources on the wrong side of a fork, while you keep mining on the side you know will win.  One or two large miners or pools who do this will be enough to tip the scale.  Since other miners will watch each other closely just after the fork is supposed to happen, you can mine a few fork blocks before switching back again, covertly mining standard Bitcoin blocks.  If one or two miners switch side after mining on the fork for a few hours to days, and then silently switch to standard Bitcoin again, the standard Bitcoin blockchain will overtake the fork.  So a closure of exchanges is pretty much 100% certain, at least if the fork has support from anything less than 90% of the mining power.  The weakness of the forks is the fact that if the standard bitcoin chain overtake the fork, all mining effort and transactions on the fork will be wasted and lost forever.  The standard Bitcoin chain can not be overtaken by a fork however, since the blocks from the forks will be invalid.

Anyhow, I don't believe there will be a hard fork.  Now "Classic" have released binaries, which has lead to a sharp increase in "Classic" nodes.  At the same time the number of "BitcoinXT" nodes is falling as if it went over a cliff.  Bitcoin Core has the same share of nodes on the network as it had before "Classic" binaries were released.  About 88%.  The last 12% are divided between "XT", "Classic" and "Unlimited".

I think too that it's risky. And it should be avoided. Unfortunately it seems the network has not included real decision making besides forks. And i think it's relatively sure that, when one client starts at 0% of the network and reaches 75% that this client has an advantage that is recognized. It would be unlikely that those supporting it would suddenly turn back supporting the other chain then. At least not as long as serious problems show up with the fork once activated.

It looks to me like everyone staying in the old chain would simply be stupid, regardless of which fork it is. The chance to lose everything mined after that is very high. Or does he might be able to create a valueable altcoin out of the losing chain then?

Anyway, mining in the losing fork means blocks being found every 25 minutes?, which lowers potential reward even more. And this mining can take weeks. Deadly for a mining business. On the winning chain instead the blocks will be found every 13 minutes or so. (Obviously i'm no mathematician. :))

It would be economical disastrous i think.

But i don't know a way to handle things differently. Especially when in such situation. Regardless which thing someone prefers now, the situation is so that some developers control the setup of the client. If someone disagrees and there are a big support like 50% of users and miners then there is simply no other way determined to handle things. Ok, the threshold for switching could be set higher, like 95%. This would do less harm of course. But in a situation where the community is divided that hard it's practically ensured that such a threshold can't be reached.

It's really a mess in my eyes. And i think a real crisis to bitcoin. Nothing like that happened before i think.


This is a possibility, especially with the collection of hashpower in single identities hands. Though it would be a pretty sneaky behaviour since those mining at those pools probably would support their attempt to mine on the fork too. They would be gone for good and mine in the new forks pools. Which would hurt the other pool alot.

Might be that miners can do it that own the miners. Ok, i don't know if there are such miners that would have a huge impact at all or only 10% or so.

It would stilly be risky. The most safe outcome for miners would be to trust that the other miners don't lie and follow them. The masse will win the game.


Man, i really hope nothing like that would happen. It would be like a war in the community and it would bring a deep deep canyon between user groups.

But i think exchanges have ways to protect themselves. They don't have to set on one chain alone. I mean they can own the same bitcoin addresses on both chains. They can run both chains. The only risk they would have would be to chose one chain only, then receive bitcoins that were not sent to them on the other chain. When the chain that they chose is dying then they are screwed and left with no bitcoins. But this risk can be completely eliminated by only accepting bitcoin deposits whose coins show up on the same deposit address on BOTH chains. Then they are completely safe. They would not even have to care which chain wins. They would always hold the right bitcoins.

Right?


Though that would be correct for the standard bitcoin chain too. If a fork reaches 75% and miners would still mine on the standard chain and the fork becomes the new real bitcoin then all mining on the standard chain after the fork will be gone to waste since the standard bitcoin chain blocks found after the fork happened would be invalidated. Additionally blocks would be found way way less often. Mining there would be economical suicide because the difficulty only would change each 2 weeks.


I think the Number of nodes can be completely forgotten. It can be faked easily and it most probably is faked since there are obviously fanatics who would do such things. There are not only cool headed discutants on each side. :D

Anyway, what matters is how the hashpower decides. And it really would be interesting to see what happens. In my opinion there is a majority for segway and for a raise of blocksize for 2mb at least for now. Stopping the delays in peak transaction amount times. I think the lightning network is not really loved by most. I mean it is a different system to use again. And all systems beside bitcoin had a lot of trouble finding it's acceptance.

Well thinking about that is obviously purely speculative.

But what i think is that exchanges would not have to fear any danger. I had to think about what i can do to protect me as an escrow too. And that was the solution i see for me. Only accepting coins that came in on both chains. When i receive coins only visible on the bitcoin address on one chain then i won't accept them. Too risky.

Not a chance any serious exchange would close. On the contrary, it could be like an early xmass gift for them as they could support both forks after the split, just name them ie 'BTC A' and 'BTC B' and let users engage in buying/selling war. Likely the exchanges themselves could sell their minority fork holdings. Obviously they would announce in advance that they intend to migrate to majority fork.

Not how it works.  You cannot create an altcoin based on bitcoin, and convince everyone to switch to the altcoin by telling them they are stupid.  Especially when the altcoin is a retardation compared to the real coin, and has alsmost no developers behind it.  I don't think the users will care much about what the majority of the miners are doing at that point.  They will just keep using their superior coin.

Obviously..  For a given hashrate, the chance of finding a new block, and therefore the reward, will be the exactly same in both forks.  After difficulty readjustment the success rate will increase.  So miners don't have any economic reasons to switch.

Any hard fork would be disastrous, yes, if it has followers.  Fortunately none of the suggested hard forks have gained a significant number of followers so far.

I think you may base this assumption on your flawed theory about profitability above.  As long as most merchants still use the real bitcoin, and indeed almost 90% of all nodes run real Bitcoin now, Bitcoin is the safest choice.  The success of a hard fork, and therefore the value of it's coins, does not depend on the miners.  It depends on the users.

This will work for one block maximum.  The first sport of a fork is doubling your coins by getting one transaction confirmed in one chain, and a different version in the other chain.  Coins spent as normal bitcoins won't exist in the "classic" chain and vice versa.  People will split their coins to make sure they can spend every coin they have in both chains separately, with no risk of getting the transaction confirmed in the other chain.  Eventually this will happen by itself when coins are mixed by coinbase coins which doesn't exist in the other chain.

Again, this is based on your mining profit fallacy above.  The profit in terms of coins per day for a given hashrate, will be exactly the same after a fork as before, until a difficulty adjustment.  After the adjustment the chain with the lowest hashrate will pay the most.

You mean by running Bitcoin Core and pretend to be "Classic" or vice versa?  Sure, but why would anyone do that?  It has so far only been done for mining.  Some blocks are mined as "BitcoinXT" blocks, but those have been shown to be created with Bitcoin Core with a small change to the coinbase transaction.  Since "Classic" has based their fork on an old version of Bitcoin Core, without many of the improvements for block generation, I think miners will do the same in the future as well, unless "Classic" get developers who are capable of rebasing their patches against 0.12.

I don't see any majority for raising the blocksize via a hard fork.  Quite the opposite.  It seems the majority is very clear on maintaining backwards compability, and increase the capacity by moving the signatures outside the 1 MB blocks.  Especially among the developers of Bitcoin and various bitcoin wallets.  Most of them have implemented segregated witness already.  It is very simple, and will be faster to deploy.

Of course exchanges will close until the fork has settled.  Otherwise they will be in a legal sh*thole when they lost their users deposits due to completely irrational behavior.

To safely support both Bitcoin and the altcoin, they need to get hold of coins generated in a coinbase after the split, and spend their deposits with it as an input.  This is the only way to make certain the coins can't be spent in the Bitcoin chain, and it will also die with the altchain in case the fork ends.  A coinbase take 100 blocks to mature.  Exchanges will have to be closed for at least that amount of time.

No exchange will "migrate" to any fork.  Some will take the opportunity to support both bitcoin and the new altcoin, until people have lost interest in the altcoin.  Altcoins die all the time.  In the beginning, as soon as the exchange has made sure all deposits exist at different places in both chains, all users at the exchange will have dual balances.  People predicted Bitcoin's death as soon as altcoins started to show up.  It didn't die.  Even if some misguided miners start mining on a fork people don't want (look at the node statistics, and the low merchant, user and developer support for any of the forks), and even spend more hashrate on the fork than on Bitcoin, Bitcoin will live on and grow stronger because it proved to be resistant to an attempt by miners to change the hard rules of the blockchain.

Well that is a very biased opinion. The original bitcoin went through a couple of forks already and following what you said then we would have lost the real bitcoin long ago already. Still, what decides what the real chain is is the believe of the people because they give the coins the value. If the fork wins then the new chain is the chain with advanced settings and the losing chain the one with the outdated tech that was upgraded. Pretty normal.


The chance is the same, sure, but the hashrate not anymore. The hashrate can't double like the chains double. 75% of the hashrate is in the winning chain then.


I think so too. At the end it depends on what those believe who give the coin its value.


I only say that as long as an exchange receives the bitcoins in both chains there is no risk for them anymore.


Though only theoretically since the 10 minutes are not hard set but dynamically created by the diff adjustment, judging from the amount of hashpower. And the hashpower will be way less in a losing chain.


I meant that some people create nodes just to show that their side has the most support. Setting up a node an a vpn or so and voila they have an argument of being backed. Though it is not a real hard argument in fact.


Yeah, segwit has broad support. I think it's a good thing. Though it is stil limited and can not solve adoption hindrance in the long run as far as i understand. The solutionat after that is the interesting thing.

What legal shithole? All they'd need to do is to announce beforehand which fork do they intend to follow (what they believe is a majority) and properly inform customers. Pre-split deposits would be withdrawable on either chain anyway. Which address/wallet you're withdrawing to (and which fork do you believe is the real Bitcoin) is entirely your problem.

In the worst case scenario, to be on the safe side, they could lock new deposits until it's clear which fork gets more support/hashing power. There are few ways they could carry on with trading or even take advantage of the situation without completely halting (since trading is done off-chain).

It's more likely they could face legal actions for closing their operations and cutting-off the customers from their funds.

Side note - hard fork will happen anyway, if not Classic now, then Core later on and there'll always be a group that'll oppose the fork, so it's not something you can shy away from forever.

I dealt with alot of cases where i had to inform users taking part in a project or shareholders in an investment. It is practically impossible to reach everyone. Often after months you still have many open cases.

So in theory, an exchange who only does this, might be in real trouble since the user could claim he trusted that they hold his bitcoins and they didn't. Or something like that. At least when they switch to another chain. Though then the bitcoins on the other chain should still lay in their wallet. No one could take them except the exchange. So in fact it would only apply to new deposits i guess. And that is something people have to check before.

From the legal point of view, it doesn't really matter whether you reach everyone or not. What matters is that you tried and took all the steps you reasonably could have taken to communicate with your customers. In terms of online exchange it's pretty straight forward: send emails to all, put disclaimer on log-in page, pop-up warnings while depositing/withdrawing + announcements on your official social media channels. Do all that in reasonable time-frame and you're safe.

The thing is, you cannot really escape the risk no matter what you do. You risk when moving to the new fork, you risk by staying on old one and you risk when temporarily closing (especially when BTC price crashes after the fork and people can't sell due to their funds being locked).

Hm, i wonder how far this information given policy can reach. I mean it would not work to announce a move to another server and if not all users claimed their coins till then then they are waived and taken by the exchange. The exchange has a liability to the user. So chosing to let go of the coins that, at the end, proofed being the right coins, might be problematic.

Oh and regarding that exchanges cannot escape the risk... i'm an escrow and i will face similar risks as exchanges will do. My solution so far is that i will receive coins on the escrow address. My wallet will run on the chain that i chose to be the winning one. BUT i will have a wallet running on the other chain too. And i will import all privkeys from one chain into the other chain. That way i can know what happened in the other chain. As long as the bitcoins were lying on the output address on both chans i will receive the bitcoins on both chains too. Then the escrow trade can start. If not, if i receive them only on one chain, then i will either return them or i will ask to fund the escrow address on the other chain too. Since everything else would mean a risk that i could not take. I would rather stop being escrow then otherwise.

But i think with this setup i can completely eliminate the risk. I have the coins on both chains. No risk anymore.

The previous forks has happened due to fixing simple and obvious bugs.  Nobody wants software with bugs.  If you want to run a version where you can generate 18446744073709551566 BTC in your coinbase due to an integer overflow, you are welcome, but most people would consider that an unintended bug and want to upgrade.

For a given hashrate.  The hashrate of my hardware will stay exactly the same after a fork, and my production will therefore stay exactly the same after the fork.  The global hashrate won't affect my chance of finding a block until after a difficulty adjustment.

And therefore mining the losing chain will pay more if the price is the same.  Since most exchanges haven't signaled any support for a blocksize increase, and merchants seem to be with the majority of users and developers who want to scale by other means, standard Bitcoins are going to have higher value than the altcoin, and what happens then?  The Bitcoin blockchain will overtake the altcoin again after the first difficulty adjustment.

Yes, of course.  The number of "BitcoinXT" nodes has gone down for a while with no similar increase in other nodes until now.  I suspect many of them are just cheap VPS nodes the owner has stopped paying for.  The number of Bitcoin Core nodes has been very stable for a long time.

I think segwit is a very good thing, because it solves a lot of problems without a hard fork.  I think adoption will be quicker than many people think.  Most libraries which are used by wallets have it implemented already.  A hard fork won't be usable at all until everyone have switched.

Of course not. But it's completely different case, as it would be an internal decision made by the exchange, so they'd have to take full responsibility for that (pretty sure some jurisdictions have specified timeframes on when funds can be waived if not claimed, ie unclaimed bank balances of deceased people). And HF would be an external condition, to which exchange have to react, so not quite the same.

Not the best example, but it's a bit like bank deciding on their own to convert your balance to Euro Vs. bank converting your balace to Euro because the whole country is switching to Euro.

Now i see what you mean. Less miners will find blocks faster. But the problem is until that comes through you will have to go through a hard time since this only will take effect once the difficulty updated. Only then blocks can be found faster. Until then every miner would find the same amount of blocks which means less blocks are found in the same timeframe in that chain. Until diff update.

Or do you think the chains bitcoin will suddenly rise to a 4 times value? I really doubt. The more likely outcome, when classic really could fork because they reached 75%, would be that bitcoiners either switch to the winning chain, giving this bitcoin it's real value. But more likely is that both bitcoins lose value until they are halved or are similar to the hashrate. Since it would be not possible that somehow alot of value was created that would give bitcoin a bigger market cap. Though this is up for debate since it is a thing that never happened.


I think so too. I think segwit is a good step for now. I did not find real disadvantages yet. If classic forks before that then they likely will lose. If they fork after segwit came to the end of it's wisdom but before lightning network becomes needed because segwit blocks are too small still or again then they probably will succeed.

To stay with your example... when the whole country switches ok, but if an exchange would make the error to switch to the losing chain then i'm really not sure about the liability. I mean if i imagine an escrow switches to the chain he thinks will win and it loses at the end, i'm pretty sure people would go after him because they gave him a certain value and he had not been give the right to exchange it to something less valuable. Similar to a bank exchanging to pesetas because they think they will go up. they go down and people will sue. They only gave the bank the order to hold their fiat in the way they gave it to them.

I used that example only to show there's a big difference between taking actions because "I feel like it" and reacting to external conditions (when you have to decide either way).

Off course people would lynch you if you were to move their funds to fork that dies out afterwards, but the same would happen if you chose to stay on current chain (if it loses after the split). So the best and only thing you can do is to keep all the parties informed on what you intend to do. Same goes for exchanges.

No, I don't think you get it...

Before difficulty adjustment, it will take longer time between blocks.  Since there are fewer miners to divide the profit between, the profit per miner, or more correctly per hashrate, will stay exactly the same as before the fork.  No matter how many miners there are on each side of the fork, or how this fluctuates.

It is the same when many miners join or leave between difficulty adjustments.  During one period of 2016 blocks, the income per hashrate will stay the same.  Only a difficulty adjustment will change that.  And variance ("luck"), of course, but variance goes both ways with the same probability.

I think I now know what error in thinking I had. I watched the whole hashrate on the losing chain. Though that doesn't matter to the individual miner since his time to find a block is the same as it was before. The whole chain will find less blocks only.

So in theory as long as there are enough users supporting that chains bitcoin then the reward should stay the same. Though I think uncertainty will lead to a big drop in price on both chains. People will cash out and watch what is happening out there. Though that risk applies to both chains then. Maybe a bit less to the winning chain because... it looks like being the winner.

But i think i see now what you meant. :P

Although the individual miner's reward does not change, but the total amount of miners on the minority chain will dramatically decrease, so all the miners on minority chain will only be able to find a block every 40 minutes,  to get a transaction well confirmed on that chain would take 240 minutes, this basically drives out all the transactions on that chain. And when no one is using that chain, the exchange rate will crash, and miners become underwater and moved to majority chain

It will be about 30 minutes between blocks, due to the intentional trick which makes the hard fork trigger long before it has 75% hashrate.  (And it will likely be even lower, since basic game theory says you should cheat this one by announcing support for it, and then not mine on the fork.  So there is no way to know if the fork has a mining majority at all before the fork is supposed to happen.)  30 minutes is common today.  Even an hour is quite common.  I don't think 30 minutes between blocks will stop anyone from using bitcoin.  It didn't in 2010 when someone pushed up the difficulty, and then suddenly stopped mining to show Bitcoin's weakness, and why should it this time?

This is only technically, and you have financial measure: First make sure non of the major exchanges support the exchange of the minority coin, and then using millions of pre-fork coin to crash the value of minority coin if there is any exchange for that coin, so when the value of that coin goes to single digits, it will be less valuable than even litecoin, no hash power will stay, and that chain will die in a few days maximum

Yeah, and then we can make it rain gold, and travel in time, and profit!

Most exchanges and merchants are with standard Bitcoin.  I think the exchange with the most users is Localbitcoins, and Localbitcoins are not going with any of the forkers.  This is more than enough to make sure Bitcoin will still be liquid.  I will never switch to a fork myself.  If I try to sell an altcoin as Bitcoin, I am going to get sued and ruined on the first attempt.

AFAIK only Coinbase has stated support for one of the hard forks ("Classic").  BitPay has it's own fork, but not publicly stated they will try to force anyone into using it instead of Bitcoin.  A couple of others have stated support for larger blocks, but not specified any specific solution to the problem.

Ultimately, it is those who have the most coins decide. It does not matter if localbitcoins would support the minority coin, the price there will be single digits due to the millions of coins' sell pressure

Of course if the exchanges can not reach a consensus (basically they follow the major hash power), then it means the consensus is not yet enough strong, it must come from enough users , exchanges and miners together, so 75% hash rate is enough strong, given enough support from exchanges and users

Imagine an extreme situation: A person with 1% of hash power but holds 90% of coins and billions of dollars, he can destroy any fork he does not like and force all the hash power move to his fork by pumping the exchange rate of his fork

I think it is wrong to think that you are still running standard bitcoin, it is not bitcoin anymore, it is already forked so many times and now it is very different than original bitcoin, and after the implementation of segwit, the architecture had major change, I think that version should change name to Pietercoin

In that case the numbers are currently 99.36% on Bitcoin's side (http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground), with only 0.64% on the fork's side.

Consensus is important among nodes, not miners.  Miners who don't follow the consensus rules are simply mining invalid coins, and ignored by the nodes.  No matter how much hashrate they have.  Miners aren't important in that regard.

Well, you have pumps and dumps of altcoins all the time.  It is pretty much what defines an altcoin.  In the past it was common for Bitcoin as well, but the economy is too large now.  I don't think anyone will be willing to risk that much money on pumping some fork.

There have been some bugfixes and improvements which achieved consensus.  Segwit is a small change, and a large improvement.  Coinbase doesn't like it, since it improves privacy and make their chainanalysis much more difficult, but fortunately Coinbase only make up a very small part of the global Bitcoin network, and many Bitcoin users dislike Coinbase's practices. 

I am only aware of one hardfork after Satoshi, and that one was a small bugfix to overcome limitations of a database library.  The hardfork is theoretical.  The other side of the fork has never mined a block that I am aware of, but if you run Bitcoin 0.6 on a node today, with no changes to the configuration, it will eventually stop syncing because it fails to validate a block due to too many DB changes.  (I don't remember the exact height.)  If wou want to, you can start mining from there using 0.6, and you will make an actual hard fork.  Other pre-fork nodes (if any) will pick it up.

I think that the biggest pools are often enough serving other miners or have customers. Claiming to do one thing and doing another would actually result in a huge customer loss. So I doubt that will actually come into play.


Even when the majority of nodes would promote different blocks, which assumes that the fork already happened and that miners would accept these different blocks as valid, the miners simply would need to make sure that they connect to nodes that give them the blocks they want and all the other nodes would not matter much anymore.