Topic: Todays TOP post in Chinese forum: Terminate the hard/soft fork debate (Read 2158 times)

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

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

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

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.

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.

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

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

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

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.

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?

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.

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

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

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.

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.

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

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

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

And Franky claims people are trolling him?