Segwit BIP148 could easily take a majority of users with it, causing the market price of the 1MB chain to drop. There's no point mining a blockchain with no users, although fiat money could be used to pump the 1MB chain up of course (to wit, Ethereum has no users, and a huge market cap to match.... strange huh).
Well, there's a difference between venting your opinion, or selling your original bitcoins at dumping prices. The right thing to do is not to dump the version of the coin you don't like, but to dump the version of the coin that will lose the battle (which may be the one you don't like). You have to dump your "original bitcoins" to kill the legacy chain. You need balls to do so. Not just a big mouth or a node in your basement.
Quote
This is because the 1MB chain would be at a serious practical disadvantage: the transaction capacity that (supposedly) forms the crux of the whole blocksize debate. The BIP148 chain would have at least 2 times the on-chain capacity (so ~600,000 transactions per day) and the 1MB chain would still have only 300,000 transactions per day.
Let us not forget the rate at which blocks will be produced on both prongs will be proportional to the hash rate that goes with each of the chains, because of bitcoin's slow difficulty adjustment. As such, if the initial hash rate split is 1/3 for 148 and 2/3 for the rest (which is if all segwit-signalling pools "jump the fence" right now and the others remain mining as they used to, on the legacy chain), then the 148 chain will have one block every 30 minutes, while the legacy chain will have one block every 15 minutes.
Quote
And once BIP148 mining hashrate is higher than the 1MB chain's hashrate, it's game over for the 1MB chain. The 2 chains are compatible, as a result of Segwit being a soft fork. A minority BIP148 hashrate causes a chain split because of this, but a minority hashrate for 1MB causes the 1MB chain to get orphaned out of existance.
Of course, if the legacy chain is running on, at a certain point, one needs to protect it with a HF to protect if from a reorganizing. That HF could include also a block increase (not very hard to do with Core software: just change the block size parameter). The simplest HF would be to include a check point after the split.
It would be wise to do that if the legacy chain survives for several days and if both coins get listed on exchanges (which is the only way to make an ECONOMIC difference between both: if both bitcoins are not listed on exchanges, people cannot dump one and buy another one). So if exchanges list both coins, the fork should be made bilateral with a HF ; one could use that HF to increase the block size.
In fact, both chains would have something to offer: one would be segwit-bitcoin but which is locked into the paradigm of "never a hard fork" ; the other chain will have to HF to protect itself, and once the first hard fork is taken, this dogma of never a hard fork is gone now ; after all, the only reason to avoid hard forks was to avoid a chain (and coin) split, and the funny thing is that it are the proponents of a soft fork that forced the chain split ! So the argument of soft forks that was supposed to do away with hard forks ("avoid chain splits at all costs") has been killed exactly by the proponents of soft forks.
Quote
It's a high wire strategy that Shaolinfry is employing, for sure. But it could well work, I can't help but admire the boldness and determinism, but it really needs that majority or super majority user support. I think it's sitting somewhere around 30% or 40% of full nodes right now, but that's majority people just using the version string comment, which I don't believe would actually work to activate the BIP148 fork too smoothly. It needs 50%+ nodes to run the actual BIP148 compliant Bitcoin node software to stand a chance. I hope it works, but I''m on the fence right now.
Again, the fraction of full nodes doesn't matter at all in this. First of all, it could very well be Sybilled ; second, it doesn't include any firm engagement of nobody ; third: it is absolutely not representative of the real choices of the economic majority when it comes to dumping their original bitcoins ; and finally, its hope is self-contradictory: in order to gain economic traction, BOTH COINS need to be listed on exchanges (excluding exchanges already as economic actors, because they have to list both) ; once both coins are listed, the two chains need to be protected with a HF (also, to avoid replay attacks and all the mess coming from that) ; once the legacy chain has been forced to HF, it has no problems any more to HF again to bigger blocks.
Note that in this entire "user activated soft fork" business, the full nodes don't count for zilch. What matters is:
1) that a sufficient fraction of miners leaves the original chain to go and mine their own (probably minority) fork - so the game is initiated by miners
2) that exchanges list both coins, the legacy one and the segwit one
3) that enough bitcoin owners dump one of their coins and buy the other so as to make one prevail over the other.
However, the nasty thing is that in order for one to prevail, both coins first need to be listed, and that there is no guarantee that "prevailing" will mean "death" of the small chain.
In other words, in order for the UASF manoeuvre to succeed, bitcoin needs to be split, most probably for ever (because the legacy chain will need to HF quickly to protect itself).
The ONLY way in which this UASF could have the desired result, is that miners are so afraid of a split, that a majority joins IMMEDIATELY the new chain. In that case, the soft fork imposes its majority rule PURELY by MINER CHOICE (no users, no full nodes nothing).
Once miners learn that they can implement soft forks by simple majority, and not by any kind of consensus, and not by taking into account any users or markets, another Box of Pandora has been opened.
I think that there's more than enough potential spectacle in the UASF thing to take popcorn and be watching the 1. August
). 