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

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.

What you are describing is what I 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.

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.

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

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.

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

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?

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.

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? 

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

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

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

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

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

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.

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.

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

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