Given infinite time, the likelihood of this happening approaches infinity.  I.e. it will happen.  It is also very likely to happen with a real hashrate support below 95%, unless it is on an increasing trend and well above 95% already.

It less less likely to be triggered by a minority (<50%), but it is in no way failsafe against getting triggered by less than 95%, as Organofcorti points out.

Yes, it will happen if the hashrate is stable on both sides.  If the divide is 94.5% vs 5.5%, and the 5.5% share have bad luck for a day, it will trigger.  Since the test is done every ten minutes by average, the chance of the 5.5% having bad luck for long enough at some point is very high.

Do you think 75 is some kind of special number, and with 95% it is impossible for e.g. 94.9% to produce 95% of the blocks for a while?

See my previous posts.  I wrote a summary of point 4 above:

950 of the last 1000 blocks (what they actually test for) is not necessarily produced by 95% of the hashrate, and certainly not 95% of the network (most nodes don't mine).  Again, I refer to Organofcorti's blog for the explanation and details.

Not only the header; they didn't check the validity of the block at all.  They announced support for the new consensus rules, without actually supporting them by checking if blocks were valid or not.  I.e. a variant of false support announcement.

I made no argument against 95%, btw.  However 95% of the last 1000 blocks will be triggered by less than 95% (see explanation by Organofcorti).  95% of one difficulty period (2016 blocks, fixed measurement points) is much more likely to be a certain 95%.  At 95% of the last 1000 this somewhat premature activation doesn't carry a high risk of a prolonged fork, so it probably doesn't matter as long as there is a cut-off date where the soft fork will fail if not achieved.

It may be a wise decision by the pool operator.  Note the fact that the parameters chosen by at least two of the current forks, "Classic" and "XT", are specifically chosen to ensure a very small majority will eventually trigger the fork.  Even a lucky minority can do it.  I think a pool operator refusing to take the risk of making a premature decision is only doing his job.  See this explanation by organofcorti from long before "Classic" was conceived.  The evenly distributed hashrate between the forks means it may take weeks to discover which fork is the most popular.  It would be best to use this time wisely, as miners may announce false support for a fork, and stay on the standard bitcoin chain when it is time to switch.  A variant of this happened after the BIP66 soft fork, which was triggered on a 95% majority, resulting in a long chainfork which took hours to resolve.

Most miners will probably leave due to unprofitability when the price crashes on the uncertainty surrounding the fork.  How this sudden drop in hashrate will change the support for the different forks is completely unpredictable, but must be taken into account when choosing which fork to mine.  If the "Classic", "XT" or "Unlimited" fork is chosen, and the real majority ends up following the old consensus rules, all work done on the forks may be lost.

I wish the forkers were more responsible when choosing their parameters.  Either they don't know better, or their goal is drama and destruction, not change.  If they think an economic majority want larger blocks, they could launch a sidechain with 2 MB blocks, and see most bitcoins moved over there.  This sidechain would become the de-facto bitcoin chain with no harm to Bitcoin, and larger sidechains would be easy to deploy when needed or wanted.

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.

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

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.

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".

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.

Det er dei fleste, inkludert Skatteetaten og Skattedirektoratet.

Spørsmålet har vore oppe i mange trådar her på forumet.  Sjå til dømes her og her og her.
 
So lenge Skattetaten ikkje kan fortelle meg nøyaktig kva reglar som gjeld, er det ikkje praktisk mogeleg å føre eit mva-rekneskap for bitcoin-handel.  Eit døme er ved handel på børsar i utlandet der bitcoin er deponert på den utanlandske børsen.  Du anar ikkje kva land kjøparen bur i, eller om vedkommande er privat eller næringsdrivande.  Du veit heller ikkje om vedkommande tek ut bitcoin frå deponiet, eller om vedkommande sel dei vidare same stad.  Det einaste eg kan dokumentere er at eg har sendt bitcoin til utlandet, og at nokon har kjøpt dei, men i fylgje mva-lova er det kvar kjøparen bur som avgjer om salet har skjedd til utlandet eller ikkje.  På ei anna side er det sannsynlegvis børsen som er leverandør av tenesta, sidan det er dei som evt leverer ut bitcoin frå deponiet.  Skatteetaten anar ikkje korleis eg skal handtere dette.  Då kan ikkje eg føre eit komplett mva-rekneskap, og inntil Skatteetaten gjer det mogeleg har eg heller ikkje tenkt å prøve.  Dette har eg skrive i sjølvmeldingar og næringsopppgåver, utan at Skatteetaten har kommentert det med eit ord.

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.

Correct.  It depends on relayfee.  Now that mempool limiting has been implemented (in 0.12) it is safer to lower relayfee again.

I know.  You clearly shut your head off, and I think everyone else on Bitcointalk understood my explanation long ago.

If that tells you nothing, I feel genuinely sorry for you.  You are blind by choice, or someone gave you glasses with coloured glass.  Some people are investing a lot of money in splitting the community, and you won't accept the evidence.  This is a small drop in the ocean of spam.  And it proves my point that spam fills the blocks.  Most of the transactions are unconfirmed, and as soon as they are, the coins are sent on and spent on more spam.  Actually the coins are usually just sent without waiting for a confirmation, creating large trees of unconfirmed transactions.

More qualified people than me have estimated the amount of spam to at least 3/4 of all transactions, but the number is of course not certain.  There are "mixing services" as well generating a ton of transactions.  CT and payment channels will help get rid of those, I hope.  Segwit makes it all much easier.

A hard fork won't solve any real world problems.  Just create more, by splitting the community in a brutal way.  Many large and rich businesses, e.g. R3,  want to destroy Bitcoin and create a new blockchain where they are in control, and they may have found the cheapest way to do it.  Now they are in a hurry, since they know for a fact that segwit and the possibilities enabled by segwit will make a 51% attack their only option, and their investments until now will be lost.  Their best hope is control over a hard fork by incompetent people, and a community hostile to progress.

OK, I'll find a baby spoon:
Bitcoin has been designed in such a way that running a node without incoming connections work fine.

Of course you need at least one node on the network which is able to accept incoming transactions.  Preferably more than one.

I have tried ELI5.  I just don't understand why you can't understand it.  Please try to read again.

As I stated above, the bitcoin network depends on at least one node able to accept incoming connections.  That node will accept incoming connections from all other nodes.  Upgraded or not.  It doesn't matter.  The only way to split this, is if the single node is not upgraded.  In that case all upgraded nodes will be isolated until at least one of them is able to accept incoming connections.  But this isn't likely to happen, is it?  Another way to split this network in the case above, would be to switch off the only node on the entire network which accept incoming connections.  In that case nobody can connect to other nodes, and every node is isolated.

Fortunately in the real world there is more than one node on the network able to accept incoming connections, so this will not be a problem.  If at least one of the nodes which accept incoming transactions is upgraded, there won't be a split.  Both upgraded and non-upgraded nodes will have a common connection point there.  When 95% of the hashrate is on upgraded nodes already (otherwise they wouldn't be able to create upgraded blocks), we can safely assume the upgraded nodes are well connected.

Please answer my question above.  I think it shows very clearly how large the spam problem is by one example, showing just a small part of this spammers transactions on the blockchain.  How would larger blocks solve this problem?

You know very well that task is impossible to prove.  Segwit increases the capacity and make secure 0-conf off-chain transactions very easy to do.  Spamming the blockchain to make normal transactions unreliable, increase centralization, promote censorship and split the community would no longer work.

RBF is optional in 0.12.  Users don't have to use RBF if they don't want to.

And all the other improvements?  Is e.g. data limiting to satisfy network data quotas controversial?  Or the speed improvements?

Tell that to the spammers.  There are plenty enough transactions coming to fill 20 MB blocks today, if you want all the junk to litter your disk and network, and get most full nodes off the network.  2 MB blocks will be just as full as 1 MB blocks.  The only limiting factor right now is the fact that most miners demand a minimum amount of fee per KB to avoid building too large blocks, or block some of the spam, because larger blocks take longer to spread.  My mempool has hundreds of megabytes of spam in it.

I can only give examples.  Here is one from the latest block from F2Pool, one of the pools including dust as long as it pays enough fees.  0.0000082 BTC sent, paying a fee of 0.0001 BTC.

And what do you think of this?  Does it look like economic activity or spam to you?  If you follow the transactions, you see they are just spending fees to send very small amounts (0.0001 BTC) in circles.

This won't decrease, no matter how much block space you throw at it.  Larger blocks will only make room for more transactions of this kind.  You could have gigabytes of block space, and there will always be another spammer spending a few bitcents on fees to "prove" it is not enough, claiming that "bitcoin is dead" and arguing for centralization, control and censorship.

I answered.  Segwit will get us further.  It makes room for more transactions than 2MB blocks will, is easier and safer to deploy, contains lots of other improvements, and scales much better in the future.