Bitcoin Forum

We all know that the biggest worry about a hard fork is that the minority hash power might extend and permanently split the chain

But what if a hard fork can prevent this from happening just like a soft fork? This is the latest post in chinese forum

"Terminate the hard/soft fork debate: A safe hard fork works the same as a soft fork" http://8btc.com/thread-40796-3-1.html

Put is shortly: A very smart Chinese engineer from the best science university in China analyzed the behavior of soft fork and concluded that the same behavior can be setup in a hard fork to achieve the same result, making sure that no chain split would ever happen

Let's look at an example: A new bitcoin version reduced the block size limit to 0.5M. This is a soft fork since it is a tightening of the rules. If majority of the miners are running the new version, then the old miners who produce 1M blocks will get nothing: All their mined blocks are rejected and orphaned by the miners running the new version. So their economy incentive will be quickly upgrade to the new version to avoid loss

If this new version increased the block size limit to 2M, that will be a hard fork, since it is a loosening of the rules. If majority of the miners are running the new version, then the minority miners who only accept 1M blocks would still working fine: All their mined blocks are accepted by the miners running newer version

The breakthrough is coming from here: In a safe hard fork, all the upgraded miners will reject those small blocks produced by the minority miners, and extend the chain with small blocks mined by them, thus orphaning those small blocks

As a result, non-upgraded nodes would incur huge loss and will immediately upgrade to the new version, quickly make the hash rate on the new version almost 100%

And for those full nodes running old version, they will not be affected as long as the new version still produce less than 1M blocks, so after a while when all the hash power are already on the new version, they could upgrade to enable the bigger blocks, since they don't command any hash power, their impact to the network would be minimum

Many times they came up with many proposals. But, ultimately none has been executed. The consensus problem prevails in every solution.

This makes no sense.
As soon as a block is made larger than 1MB it will split the chain.

Where is the part that explains why this is a "safe hard fork"?

the only reason ethereum split. was not about the differing rules or consensus.
because the orphan mechanism would have taken care of it.
high consensus of 95%=only 5% of blocks "may" get orphaned. low consensus=major orphaning happening and people are required to wait XX confirmations to ensure the tx's dont just disappear.

by the way orphans happen every day, its nothing new. its part of bitcoin security

for ethereum it was about ethereum added extra 'blacklist' feature to ban nodes with opposing rules "--oppose-dao-fork". thus doing a work around to prevent the orphan mechanism of consensus from sorting it out the differences to keep just 1 chain. and allowing the splits to continue by ignoring the other side.

ethereum was not a consensus hard fork. but an intentional split known as a controversial split (creating an altcoin)

non of the bitcoin proposals have proposed a controversial split, instead they all want a consensual upgrade and desire it to activate at 75-95% to reduce the orphan headaches as much as possible. (most have agreed 95% is acceptable risk)

the issue however is 'conservatives' who will protest against any changes probably will add a ban list to avoid the consensus orphaning mechanism and force their own split. to live on a minority 2nd chain based on the old rules.

but as long as there is not intentional ban list/protest.. then we wont have a problem, there wont be 2 chains surviving. and the doomsday was never a dooms day.
the funny part is that those crying doomsday are probably the protesters that will actually be the 5% against it and use a ban list mechanism to force 2 chains to survive. thus self creating the doomsday they pretend to cry they dont want

But the adoption to new version will be real problem in this one also, miners and node operator need atleast few days or weeks to consider/test/implement new version in their machines and if small blocks start getting rejected by new version than loss for them will be really high.

Size limit debate is really high and if size is increased network may get spllited, which will be even bigger problem.

I hope they could have a dry run at least for several months before it is implemented.We cant afford to crash in the middle of implementation as more people will be affected and possible millions of dollars will lose.

Well that would be possible for the Chinese miners behind the Great Firewall. They'd end up with a new and separate "Bitcoin China" coin, of course, but hey, that's a safe way to do it :D

In this solution, by the time a block is made larger than 1MB, almost 99.9% of the miners are already running the new version, the remaining 0.1% hash power would make no sense, they might mine a block every week, means no transactions can be done in a week on the old chain

If you are against this solution then you would also against any soft fork, since what it does is exactly as in a soft fork

"and if small blocks start getting rejected by new version than loss for them will be really high"????

firstly a proposal like 2mb base is NOT saying all blocks have to be over 1mb and under 2mb. it means all blocks under 2mb are good.
meaning old blocks fit the rules too
this is why XT, BU, classic and other nodes are running right now with the rule enabled and nothing is crashing. because a 0.01kb block, <-> 0.995mb block are all in the 'under 2mb' category.

separetly no pool is going to dare to make blocks bigger than 1mb due to high orphaning risk at low consensus within the network right now. and they wont do anything without high consensus. orphans hurt miners as it removes their income. so they wont do anything to risk that.
so relax the doomsdays are propaganda


the dry run is already happening.. before even using the node to flag a desire.. the code they developed, reviewed and audited needed to be developed, reviewed and audited just to get to be able to flag their desire.
and when 95% of them raise their flag they have to keep it raised for a while so the community see its legit... then the grace period starts for the other 5% to have some extra time just to be gracious.
its not an overnight thing where grace periods are triggered anytime soon.

while this is happening miners are doing their own review to then do their own flag as a second stage.
then when the nodes are active. miners start flagging their desire and at 95% for a certain time(1000blocks some say) then a miners grace period starts for the other 5%, just to be gracious.

again its not an overnight thing where grace periods are triggered in a day. it takes time to make code, review and implement just to even start off the %% even before the grace starts.

if all the nodes implementations, including core compromised to:
2mb base (majority of brands)
2mb base 4mb weight(in cores brand case).
similar to what we thought every implementation agreed to 10 months ago at the large consensus roundable

with activations of:
stage one activation: nodecount 95%
graceperiod
stage two activation: minerblockcount 95%
graceperiod

(taking many months to get to)
EVERYONE would get EVERYTHING they ALL want, and guess what it wont be a rush job.

That still doesn't make sense. Why is that any different from a 95% softfork or 95% hardfork?
What you are saying can be applied to those as well. What makes this so "safe"?

If I understand correctly, this solution creates a hardfork that prevents a 5% hash chain split,
by blackmailing or threatening the 5%? So there is no true vote or signaling process?

It seems like coercion and not free choice. Maybe I'm missing something here.

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)

When it comes to free choice, any one can soft/hard fork any time to have the blockchain split, what you are missing here is that there is a hidden major consensus that the chain should not split, and majority of the community members believe that this consensus is the highest priority. A chain split is bad because it created very confusing scenarios that no one could easily foresee its future development. Although the ETH chain split has mostly resolved by the abandoning of the ETC chain, a major chain split of bitcoin is still considered a highly controversial event

That's what I'm trying to figure out. A soft fork could be half a Mb (so tightening the rules) but if you increase or loosen the rules it's a hardfork. Where does it explain the hardfork but at the same time increasing block sizes?  ???

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.




Basically, Miners who want a larger block size (for example 2MB) will download and use the new 2MB version.
The new version will still mine in accordance with the 1MB rules. At a certain point, they will switch to the new
2MB block, split the 1MB chain, and then build invalid 1MB blocks on top of the 1MB chain, causing the old chain
and those 1 MB miners to fall into financial default. This will force the old 1MB miners to upgrade to the new 2MB
version, which will cause the previous chain to die off. It is basically a do or die mentality.

I think this doesn't address the node consensus aspect, only the miners.
(Also doesn't address what about lost nodes.)

This is my understanding.

Let us pretend that everyone, that means the miners, people maintaining Bitcoin nodes and the community supported Bitcoin Unlimited. What will happen to the core developers. Will they lose their position and their influence over the development of the network? Who will take over, the developers who started Bitcoin Unlimited?

Are the Bitcoin Unlimited coders competent enough to take over Bitcoin's development?

I don't go that far away into conspiracy road, but I think core devs should be more flexible and open to different ideas. This solution is so simple but missed by all the core devs, which raises a large question about core devs' competence

Yes, the Core developers would be supplanted by the Unlimited developers.
Core mostly believes in certain fundamental issues that Unlimited doesn't think should take precedence.
Because of that, majority in Core will not join Unlimited if it takes over.

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

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

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

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



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.



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.

What you are describing is what I (https://www.reddit.com/r/Bitcoin/comments/4uq9h7/are_bitcoin_users_at_coinbase_exposed_in_an/d5rvya6) and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right-- though it appears to have mostly been an accidental side effect due to the fact that their hardfork was rewriting their mutable state directly.. It has a benefit of being cleaner, but it is laughable to call it a "safe hardfork", because it eliminates only one fairly boring source of risk.

The comparisons so soft-forks do not hold-- normally a softfork does not split the chain at all. And it is safe precisely because any fraying it causes if it causes any is not lasting, and will automatically heal without human intervention or significant disruption.


It's unfortunate to see this kind of ignorance continue. You're adopting a faulty analysis that comes from 'assuming the existence of a privileged position', why is it that you assume the non-upgraded are incurring a huge loss? By each system's own rules its own chain is valid and the others is invalid in that sense they have equal standing, but one has the moral authority of being first and consistent with the philosophy of robustness against external influence. Because of this it would be more valid to say the interlopers are incurring a huge loss if anyone is.

Consider, the _only_ thing that distinguishes the litecoin blockchain from the bitcoin blockchain is a trivial bilateral hardfork.  When litecoin came into being and you were running Bitcoin instead of it-- were you incurring a huge loss? No.

From the perspective of the non-upgraded nodes, the parties with the mutilated protocol simply do not exist. Due to being bilateral, the same is true in the other direction. But none of this creates automatic winners or losers.  And in all hardfork scenarios there is plenty of opportunity for everyone to be a loser.

ofcourse people are going to reject the stupid idea to split the network..
ofcourse people are going to reject the stupid idea to avoid using bitcoins main feature... the consensus/orphaning mechanism.
but as we all know you want anyone who is not blockstream loving, to F**k off..
however blockstream is not the bitcoin owner, nor the network owner... though you want it to be.
blockstream should remain just part of the network, working with others on the network collective, to agree on rules using consensus, done via compromising and agreements by majority (consensus)


though bitcoin right now has consensus of many implementations and diverse nodes. you actually want a 'existence of a privileged position' (dictatorship) and people see that you want it. and so are describing scenarios to explain why splitting bitcoin is bad, and why we should use consensus. to avoid a 'existence of a privileged position' (dictatorship) that you desire

alot of waffle just to replace the word minority with "interloper".. a subtle but failed attempt try making people assume that bitcoin already is a dictatorship by suggesting anyone not a sheep to blockstream, as an invader (interloper)
YOU joined 2011,
core brand and blockstream brand appeared in 2013
stop pretending blockstram/core have owned bitcoin since 2009

Gmaxwell. its far easier to ask you to go and play with your monero and go program your leaders desire of a banking network over at hyper ledger. that to allow bitcoin to be sucked into the closed dictatorial realm of blockstream

bitcoin should remain in the open realm where anyone can be part of it but no one owns the protocol in full.
the only reason i see blockstream upping their game of dominance is that they fear not getting their next investment tranche from the banking sector if they cannot become a dictatorship of the network.

And Franky claims people are trolling him?

Maybe you have not read the whole proposal carefully. Or you don't really know the details about how a soft fork works? Please tell me under which condition a soft fork will create a chain split, so that I can be sure that we are talking about the same thing

It is not a bilateral hard fork, it is a soft fork followed by a hard fork. The purpose of this solution is to avoid chain split, while a bilateral hard fork is to split the chain

It is difficult to argue against this solution because what it does in the first phase is exactly what a soft fork does:  "It is safe precisely because any fraying it causes if it causes any is not lasting, and will automatically heal without human intervention or significant disruption." This automatically healing process is when those old style blocks becomes orphaned and old miners automatically switch to work on the longest chain created by upgraded miners. If your criticize against this method is reasonable, then it will automatically apply to any soft fork


Non-upgraded miners are incurring a huge loss in a soft fork because all their mined blocks are orphaned by the longest chain, and they must follow the longest chain if they use default client behavior (In a soft fork, upgraded nodes with 0.5MB block size limit will reject 1MB non-upgraded blocks, but non-upgraded nodes will not reject 0.5MB blocks generated by upgraded nodes, so all the blocks that is > 0.5MB will be orphaned if the upgraded side have major hash power. The non-upgraded nodes can not split the blockchain because they always regard the upgraded blocks are valid and always reorg to that chain)



Yes, non-upgraded nodes will not see a new chain that does not comply to their rules, however in this solution, they will notice that their own chain stopped growing, they won't have a block for months, it just becomes obsolete

Of course the second phase is still a hard fork, however, after the soft fork, all the miners are already on board the newer version, this is a big step forward if you compare it with a standard hard fork where many different versions are running by miners and nodes. So after all miners have been upgraded to new version, the only inconsistency left are those non-mining nodes. Since all the hash power have switched to the new version, there will never be any old version blocks mined, so for those old nodes, although they can ignore what happens on the new chain, what happens on their own chain becomes strange: It totally stopped growing. They have to upgrade if they want to spend their coins, but since all the transactions on the old chain is disabled, there will not be a loss for anyone running old nodes if they insist to do so

Of course you could always modify your code and create a chain split and adjust the difficulty and extend that chain forever, but if you just upgrade or not upgrade by default, the chain will automatically heal without human intervention

Just got a new name for this kind of fork: A synthetic fork  ;D

or better:
softfork = good code:patch.. bad code:trojan
hard fork = good: consensual fork=upgrade with no split.. bad: controversial fork= intentional split

none of the proposals have demanded a controversial fork(--oppose-rule, ban opposing nodes). they have all been consensual forks(consensus mechanism)
its only blockstreamers that want controversial forks if they cant get their softfork

It is not a conspiracy theory because it is possible that the core developers will be supplanted as the top developers of Bitcoin. Also in asking the question if the Bitcoin Unlimited developers are as competent as the core developers, you know what I mean. Are they as good in coding and finding solutions to Bitcoin's shortcomings? If you think they are, then who are the Bitcoin Unlimited developers and what have they accomplished?

Answers to these simple questions should be known to the community so we could form our own opinions and express them. I honestly do not know who the developers of Bitcoin Unlimited are except that it is led by Roger Ver which I think has his own agenda.

or to flip it on its head.
if devs get involved and help each other out no matter the brandname. and start working as a community rather then a fight for dictatorship
then consensus would move forward faster.

I agree, it would have been better if the developers from both sides could work together. But too bad each camp has its own agenda and self interests and now the community is caught in the middle. I believe the Chinese mining cartel is also for the smalls blocks unless I am mistaken.

the mining pools want more capacity but they are not even going to enter the civil war until the nodes sort themselves out.
after all a mining pool is foolish to make changes if the nodes are not going to accept them.

some lemon fruitloop tried to do a rekt campaign on mining pools by suggesting (falsely) that pools were planning a controversial split to scare the community into a mining civil war. but the mining pools quickly shouted the campaign as utter fud and that they would not do anything that risked the network or the security or even risk their own rewards.

mining pools want the extra capacity and some do 'have faith' that core will eventually do it. but this is not unconditional faith.

the solution many have come up with is
nodes: code, review implement THEN flag desire (taking XXweeks/months) to get to 95%
mining pools: code, review, implement at this same time.
when nodes get to 95%. there is then a grace period
THEN
mining pools: continue code, review implement THEN flag desire (taking XXweeks/months) to get to 95%
when pools get to 95%. there is then a grace period

by this point over 95% of nodes and over 95% of pools are all onboard. and pools then test out the water making a block of 1.001kb and see its orphan risk.
if deemed safe they slowly increase, until comfortable.

anyone doomsday shouting that "it will be 1.999mb blocks in 2 days" is just someone that is trying to prolong a civil war.

its worth noting that some pools already have ceded reviewed and tested and implemented their new rules. but are not stupid enough to make block beyond the current limit for obvious rational reasons. they are just waiting it out until the nodes get consensus, before even flagging a pool consensus

That's why this synthetic fork proposal is a large step towards reaching consensus: It combined the benefit from both soft fork and hard fork, thus will become easier to be accepted by both sides

It seems the most hard core core supporter in Chinese forum has expressed some interest in this proposal

Well then there is no need to argue anymore on who's right and who's wrong and let the actions speak for itself and may consensus be achieved naturally for the good of the whole network. If we get bigger blocks then we get bigger blocks if not then let us see how LN helps Bitcoin scale.

I do like to see LN launched and used because there is also great potential in it. One of it is we could make users less dependent on centralized exchanges and trading from one coin to another could be done on the Lightning Network as sort of bridge between blockchains.

21inc's LN has been launched for 6 months, no one cares. If there is slightest market demand for this kind of service, why is there no one interested in it?

Lack of marketing perhaps? I have not heard of their Lightning Network before you mentioned it. Is it working well and are there enough users in the system? The problem I see sometimes is some developers create something that should be cool but have their own shortcomings. Like Open Bazaar and bitsquare.io. They are usable but they are somewhat lacking some features or maybe they need a little more polishing.

That's not the Lightning Network. It is just their implementation of payment channels. Stop spreading false information.

you realise and know that "payment channels" is the technology/concept and LN is the brand name of one of those utilising the technology/concept.

trying to protect a brand name, even when someone is just using the brand name simply as just a laymens descriptor of the concept is very revealing.

its like saying people like to facetime each other on skype and you argue not to use the term facetime unless talking about apple.. very revealing indeed

protecting business interests more then cryptocurrency features is where the civil war began

Lightning Network is not a registered trade mark, it is only a concept of payment channels. 21inc's LN is the simplest form of payment channel thus also one type of LN

Everyone knows that all those alternative development teams aim to, is to take control of bitcoin, make their software the "official bitcoin", then live off the hope of bitcoin core devs keep doing the hard work (copy pasting their code and changing a couple of things then appealing to open source to justify this copy pasting)

Core team is the most competent team as demonstrated through the years, there's no doubt about this.

only blockstream are telling people to f**k off (you choose if ** = 'uc' or 'or')
other teams want to use consensus
other teams have compromised to find a solution the community in the majority are happy with. so that consensus moves things forward ON ONE MUTUAL CHAIN of diverse, distributed nodes to remove risks and keep decentralized security

even blockstream were happy with it in december.. but then back tracked later and started the civil war when they decided they want 100% control.

sticking to consensus means NO ONE has control and rules only change when that are MUTUAL agreements across different diverse nodes.

The reason core devs knows more about bitcoin protocol is mainly time, if you look at all those guys who started early like Jeff, Gavin, they all familiar with the different aspects of bitcoin. Purely from engineering perspective, core devs demonstrated their lacking of software engineering discipline by pushing out the segwit sf hacky codes. If you talk to anyone that have designed larger software systems, this design is not optimum, it seems the only reason it designed like this is to avoid a chain split

But now we have this two step synthetic forking method that can permanently avoid a chain split, invented by Chinese engineer. Why core has not thought about this simple method before? This is definitely not rocket science, this raised a big doubt about their competence

Of course the idea is forming during several months of debate and many different people jointly contributed to the solution, but you should never underestimate the R&D ability of Chinese, their large IT companies like Huawei have mostly defeated all the western competitors both technically and market wise

the consensus mechanism is not new.
its been there since day one.

its just that people dont talk about it because they want to avoid it and instead take control of bitcoin by shying away from the main security measure that prevents corruption. that prevents manipulation.

the linked "chinese guy" is not inventing anything. but instead highlighting consensus.
which is something we all should be thinking about and utilizing. and should always do

I have been following the discussions on chinese forums during this year and I can confirm the idea is new

The first proposal was to setting up an mining pool and attack/destroy the minority chain after a hard fork. That was at the end of June, so called "the terminator plan"
http://8btc.com/thread-35645-1-1.html

The second proposal was on 10th Oct, the author was inspirated from Ethereums "hash rate bomb", suggest to raise the difficulty dramatically if the chain has largely reduced hash power, but I don't know how that can be implemented for non-upgraded nodes
http://8btc.com/thread-40576-1-1.html

Then 5 days later, the latest "Terminate the hard/soft fork debate: Safe hard fork is soft fork" proposal by Jiang ZhuoEr
http://8btc.com/thread-40796-1-1.html

This last piece of article fully analyzed the different means to kill the minority chain, he suggested two approach for upgraded majority miners: Merged mine and mine empty blocks for the old chain forever to disable it forever, or mimic segwit, move all the transactions to extended block to disable the original chain's ability to do any transaction

The breakthrough is that this approach changed from social attack to code attack, e.g. attacking the minority chain by codes, not mining pools, so that every upgraded miner will participate in the attack automatically

Then naturally following his thoughts, the most simple real world example of using code to attack minority miners is a soft fork, almost everyone knows. So I suggested to simply use soft fork to attack, instead of other complicated mechanism, it achieves the same result but much easier to implement