Hot search keywords

Hot search keywords

Time to Move on: The Worst Thing You Can Do Is Nothing

The bitcoin community is in the middle of a civil war. And the crux of the war comes down to a single word: blocksize.

Right now, the bitcoin network can only support up to 7 transactions per second. Clearly, some changes will need to be made if bitcoin is to reach levels mainstream payments providers such as Visa. (designed to handle peak volumes of 10,000 transactions per second)

But the fact is that those favoring change are having the hardest time choosing one specific scaling solution, segregated witness, bitcoin unlimited, user-activated soft fork or other scaling solutions.

Segregated Witness

Segregated Witness was proposed by Core developer Wuille at the Scaling Bitcoin conference in Hong Kong in December, 2015. It is designed as a compromise solution to make the Bitcoin network approve more transactions with each block.

What’s special about Segwit is that a consensus of the entire Bitcoin network isn’t required in order to make it work. This is known as a “soft fork” – meaning Segwit will work even if some users don’t update their software to the new version, making it much easier to implement.

Bitcoin Unlimited

Bitcoin Unlimited is primarily designed to ease the process for users who want to pick their own block size limit. It has a lot of similarities between Bitcoin Core and Bitcoin Unlimited. That is only normal, as the code base used for both branches of development is nearly identical. But it offers high levels of security, privacy, and stability, seeking to provide a voice to all stakeholders in the Bitcoin ecosystem.

User-activated Soft Fork

Rather than requiring a specific amount of network hashpower – 95% in the case of Segregated Witness, or 75% in the case of Bitcoin Unlimited – a user-activated soft fork is triggered in a different manner. Individual users, companies, and service providers can activate this soft fork within their Bitcoin software client. At a predetermined time in the future, the soft fork will be activated. Any new block of data on the network not adhering to these new rules will be automatically rejected.

This may sound rather dangerous, but makes a lot of sense to less tech-savvy users.

No one knows which solution is best for the bitcoin ecosystem in the long run. But as the debate drags on, more people have realized that the worst scenario is doing nothing.

After weeks of contemplation, F2Pool finally decided to support SegWit on bitcoin. And following F2Pool’s announcement, ViaBTC clarified its stance on SegWit, noting that SegWit cannot solve the capacity problem.

“Should SegWit be activated, Bitcoin will have no choice but to proceed with Core’s current roadmap in the coming years, which will further intensify the impacts of an incompetent dev team on Bitcoin community and rule out the possibilities for Bitcoin to grow in multiple directions.”

I have been living two lives. In one life, I am a news editor of 8btc. I translate news, interview bitcoiners and miners. In the other life, I am an AI bot programmed to .......Forget it! Who is gonna buy this BS! I'm just me, Cindy, nobody else.

COMMENTS(19)

2 years agoBitcoinAllBot

Here is the link to the original comment thread. Or you can comment here to start a discussion. Author: 8btccom

What a silly post. It should be segwit (or flextrans) PLUS a blocksize increase. It isn’t either or. Obviously the current segwit implementation is a clusterfuck, but generally speaking, segwit would be a great complement to BU or another blocksize increase.

Segregating witness data for a malleability fix with a hard fork is totally palatable to everyone. That was the HK compromise.

Segwit has morphed into clusterfuck of misaligned incentives though – subsidized witness data prices, an uncessary soft fork to create more technical debt, all the associated performance costs for a very minimal throughput increase that shouldn’t have even been included in the first place, etc.

Well… I don’t think we should disregard a solution simply because political actors are taking political action to push it. It should be considered regardless of who is pushing it in what way.

Having said that, there’s obviously a reason the current segwit is being shoved down the market’s throat and it obviously is a bad solution. I just don’t want to disregard anything simple by association.

I agree completely. And as we know, the Core devs broke the HK agreement.

They also are involved in supporting structured conversation (aka suppression of specific competing ideas) used as a tool to force Segwit down the community’s throat. Honestly this last reason ALONE is enough reason to shun it and those who made it. If they are willing to play by those rules for Segwit, then they are willing to play by those rules in the future. We don’t want devs like that. They are no better than the dirtiest political manipulators in governments today.

Lastly, they have hired troll armies to spread toxicity and defame/smear anyone who supports competing ideas.

These guys are a perfect storm of toxicity, and look what we have on our hands for the past several years: An endless debate with a divided community.

I personally disagree. Corrupt political action paints a clear picture of the character and moral standards of those engaging in the nefarious actions. Only further future chaos can result from individuals such as these. It’s best to cut them loose.

Well, the way I see it, it’s sort of a moot issue. The downsides of the SWSF proposal greatly outweigh its modest benefits so that alone provides a clear reason to oppose it. Having said that, if it were a closer case, I do think it might still make sense to oppose the proposal on “political” grounds. The current Core team (and many of their supporters) have been a pretty toxic force in Bitcoin for a long time so I think the sooner the network’s stakeholders can make it clear that Core dev is no longer “the” development team “in charge” of Bitcoin and that the Core client offering no longer represents the “reference client,” the sooner we can achieve a much healthier multi-implementation Bitcoin governance environment and Bitcoin can finally start to move forward again in a positive direction.

Yes but including it in a softfork is exactly what makes it the mess it is. Wenn we say “segwit” then we obviously refer to the whole implementation core is pushing right now and not the pure act of separating witness data. So it’s good to not support “Segwit”. Separating witness in a hardfork is another story. We cannot ignore that the word “segwit” has become a brand name for a product.

Sorry, I’m referring to segwit in general, as it was first defined, purely as a malleability fix with a hard fork.

There’s also “segwit” the merchandise, which is the aforementioned design kludged into a soft fork with a bunch of other bloatware that no one wants and is a net negative for the network. I’m not talking about that.

Still doesn’t explain why they don’t support SegWit on Litecoin, since their main argument against SW on Bitcoin is that it doesn’t fix block scaling. Block scaling is currently not an issue in Litecoin.