If it would be possible to plan hard fork in this way, core would never need to use the segwit sf hacky way to solve the transaction malleability bug and raise the block capacity (they could simply modify the transaction format and raise the block size using a hard fork, save those several thousand lines of bloated codes and greatly reduce the code complexity and attack vector, their time can be spent on more valuable things and the community would not even split)
But if a hardfork was planned this way, then Bitcoin is no longer determined by consensus.
It would be effectively determined by force.
So this idea is "safe" only because if others don't want to play ball, we can financially blackmail them.
This will institutionalize the blackmailing into the Bitcoin protocol.
We shouldn't force the hash. That is like an election and having only one party on the ballot,
and if you choose not to vote, you get shot. This seems pretty immoral.
Following your logic, then we should never do any soft fork, because what this method does is exactly the same as what a soft fork does: Orphaning the old style transaction/blocks after major hash power has upgraded, to force miners to reach 100% consensus
Reduce the block size limit to 0.5MB is a simple soft fork since it tightens rules. The result is that original miners/nodes would still accept new blocks but upgraded miners/nodes will reject old blocks that are larger than 0.5MB. So if old miners are still generating 0.7MB blocks, all those blocks will be orphaned, but old miners won't split into their own chain since all the blocks on the longest chain is valid based on their rules (<1MB), so they alway reorg to that longest chain (containing less than 0.5MB blocks)
This is major hash power running newer rules forcing the old nodes to upgrade, otherwise they will lose their mining income
I don't think so. A softfork does not orphan any blocks, neither does a hardfork.
Orphaning is a byproduct of the mining process where two blocks are announced
at roughly same time, propagate differently, and only one gets to be the "truth",
so the other orphans. Using purposeful orphaning on one chain to prevent that chain
from living is not new (in the past people talked about DDOSing those miners), but is
not reasonably entertained because it is contrary to how Bitcoin consensus works.
This is forced consensus, instead of natural consensus. If a consensus is never reached,
well that is also a type of consensus.
If we reduced the blocksize to 0.5MB, and old miners are making 0.7MB blocks, the
blockchain will perform an unintentional fork, which will split the chain into two coins
because the old miners rules violate the new rules. Basically, the old forked themselves
away from the new. I do not think there will be a reorg unless all the new miners have a
majority hash in order to do a reorg race. In theory, to fix the unintentional fork, the hash
should go back to an old version, not the new version.
Only miners need to upgrade in this theory, not the nodes.
The nodes will be lost since they have no incentive to upgrade.
(I'm not even mentioning the nodes who oppose a blocksize increase outright.)
Now in a safe hard fork, upgraded nodes all accept 2MB blocks, but at first they would only accept <0.95 MB blocks. So their blocks are all accepted by the original miners/nodes. However, similar to a soft fork, upgraded nodes will drop transactions/blocks that are generated by the original miners/nodes (by either blocking >0.95MB blocks or filtering on old block/transaction pattern), and minority miners will just find out that most of their mined blocks become orphaned, so they will immediately upgrade to new version
I do not understand. In a softfork, nodes will not drop the new blocks since they do not know
they are new. They will accept them since they mimic the original non-updated rules. As soon
as the new version mines >1MB block, the old nodes will reject that >1MB block.
Your argument assumes Nodes are rational and participating in the Bitcoin system like miners.
They are separate individual entities, that either follow or do not. If they do not, Bitcoin becomes
weaker, thus the reason to make SegWit a softfork, because the nodes won't be lost. With a hardfork,
all nodes are lost, unless they upgrade. If we do not get enough upgraded nodes and still hardfork,
the network would be weaker for attacks. A successful attack on the network at that time could be
harmful to the future prospects of global recognition and acceptance.
After all the miners have upgraded to the new version, now the upgraded miners could start to produce >1MB blocks, and since every miner already accept the larger blocks by now, there will not be a chain split
Someone on reddit pointed out that this is essentially a two phase soft fork + hard fork, where the first soft fork phase is used to reach a unified status among miners, then the hard fork can be executed relatively safe
Nodes will not be affected at the beginning, if there is a pattern based filtering for old style transactions, they might find out that their transactions will just not confirm, so they also have the motivation to upgrade to the new version. And even if they don't upgrade, they don't lose money, since the old style transactions/blocks would never work, old nodes will just find out that their nodes stops working, and understand it is time to upgrade
Nodes do not normally upgrade. There are nodes that still exists that are running years old
versions of Bitcoin. All those nodes would be lost and not upgrade, increasing centralization
of the network and making it prone for attacks. If nodes did upgrade as you say, we wouldn't
have lost so many of them back from the previous unintentional hardfork.
One of the real concerns with hardforks is node loss, not just split chains.
If we got 100% consensus for a hardfork, we'd still lose many nodes, and become weaker.
That is a reason why SegWit is a softfork. We're attempting two birds with one stone.
