Hot search keywords

Hot search keywords

As a China Mining Pool Owner, Why I am a Hardcore Opponent to SegWit

Editor’s note: Zhuo’er Jiang is the Founder and CEO of the mining pool: ltc1btc. This article is a direct response to Samson Mow’s viewpoint. Discussion thread on 8btc forum has sparked over 170 replies.
In the article Why support SegWit, COO of BTCC give his answers, Samson Mow focused on SegWit without mentioning the real problem: the post-segwit roadmap from Core. I just have to clarify something Mr.Mow is unwilling to touch.

I.The True Focus: Core’s Roadmap

Mr.Mow brags about the benefits of segwit in his article, and accuses scaling side on anti-core being political. Truth is, however, scaling side is pro segwit and LN as well. Scaling side is anti core’s roadmap, which is, from soft-forked segwit implementation to permanent limit of block size on 1 MB. This will turn the main chain into a SWIFT-like settlement network. High tx fee on the main chain will chase all the daily tx away to the LN.

Why Core’s roadmap is wrong? Simple logic: more is better than less, more options are always better than fewer ones.

“I’m right so I will take your rights away”—this is a dangerous mindset. Just look at the history of Communism and the possible millions of deaths associated with it. A vicious fruit of a vicious mentality. Why in China’s Big Leap in the 60s we saw millions of deaths of peasants? Because they were restricted to their own land by the low level party bodies and the household registration system, preventing them from fleeing their land. (passport in 60’s)There’s no option but to starve to death.

How can someone be so sure that he’s right? What if he’s wrong? How can he shoulder the responsibility of millions of lives? Can core do that? Who gave the right to Core from prevent us from using the main chain? Is core capable of shouldering the responsibility of the doom of Bitcoin?

II.Fragile LN

Secondary networks like LN can only be a supplement to the main chain, not a replacement to it. LN’s big nodes have clearly capital, efficiency and operation advantages. Looking upon them to maintain many small nodes is so childish. There will be Matthew Effect. There will be big fish devouring small fish. LN, in the end, will be dominated by big players like what we see with Alipay/Wechat Pay today. Decentralization will be a banned word.

Rumors recently mentioned “Chinese monetary authorities are looking to limit the transfer of Bitcoin from domestic exchanges to their foreign counterparts. Crypto community lived on such a joke. But can you laugh when tx are all running on giants-dominated LN?

LN operators cannot confiscate your Bitcoin, but they can, with the excuses of regulation compliance, ask you to conduct compliance checks. You want to quit then? To where? Main chain? Core had it in mind already: 1MB block size is only for big-amount LN tx settlement, the tx fee will be as high as with the SWIFT. How about 100 dollars per tx? Quit?

III.Dangerous Soft-Fork SegWit

Core is implementing segwit through softfork, that is by lying to old nodes to realize compatibility. This brings significant technical risks and hefty tech debts.

twisted softfork

With bottom layer data structure altered, Core wants to lie to old nodes so as to fool them into believing “nothing-has-changed”. This is just as difficult as the twisted hand in the pic above. The risks and debts behind it are so self-explanatory. We can already expect tremendous difficulty in the future development that will be based on this twisted hand.

Why Core says “SegWit almost changed every line of Bitcoin’s codes?” (They wanted to brag about the workload).

Based on the HK consensus, the segwit should have been out in Apr. and online since Jul.,why is it so late in Nov. even under the pressure from consensus and miners? Because core wanted to build a twisted hand.

Systemic complexity rising echoes with a falling stability. We all have seen the price of ETH’s Turing-Completeness: four or five HFs and lots of nodes being attacked into destruction. Bitcoin, as a formally 10B level financial system: Can it pay such a high price? Can Core take that responsibility?

IV.Enough Block Size

If our network cannot take 1MB+ block size, Core’s limit can be justified. But the reality is that even the GFC-limited Chinese pools can accept an 8MB size, see the pic below (see report in June 2015):

Joint statement on 8mb scaling in June 2015

Compared with “who’s-your-daddy” Core, BU is not so condescending to the very least:

1)block size?

Pool decides. No 50%+ pools will choose too high of a size that the network cannot take. (or they suffer from high orphanage rate).

2)tx fee?

Market decides. Should the network unable to take a big block size, the limited block supply from pools will raise the tx fee to an equilibrium point on the market.

3)LN or not?

Tx fee decides. If the network cannot take big size blocks, while LN is cheap and fast, why not use it under high tx fee scenarios?

I think 2) is not going to happen. I used a 56k modem back in junior high, and I use a 200M optical fiber connection today at 17 dollars per month. That’s a 4,000 times scaling. But I’m not against 3). Core, however, considers 2) as fate, so “I’m your daddy let me decide for you.” So they castrate the main chain tx and decide for you that future tx should go through the LN.

Why such a rush? Who’s the “GOD”, Core or the market? Or the reason being that Core’s daddy BS is the standard maker of LN?

V.Who is qualified to take responsibilities when it comes to Bitcoin security?

What is the consequence of Core breaking Bitcoin the big toy? Leave. That’s it. So many Internet companies are out there and a glorified ex-Bitcoin developer will surely find a new job.

Only miners, who invested millions-worth of personal wealth, the sunk cost, cannot leave like a bitcoiner, thus can be qualified as the Bitcoin’s safe guards. Mt.Gox was bearing the Bitcoin price in hope to cover up for their loss. Only miners want the Bitcoin to thrive with more users and a bullish market.

I can conclude with great confidence: SegWit will never ever be activated. It’s not about the 95% threshold. Even in 75% or 51% scenarios it will not be alive.

Why? I am a miner, a member of the mining pools. I invested millions of real wealth into the mining business.

Got an issue? Show me your money.

Before the non-stopping wheels of history, some people are destined to be nailed up on the pillar of humiliation.

Operator of LTC1BTC.com, a highly profitable and GPU-based mining pool

COMMENTS(101)

2 years agoHitchslappy

Frustrating to see so many people confuse centralization with organisation, ie. those who think Core is the weakest point of centralization because they operate under one name. Core have been explicit in stating that all they can do is provide suggestions to improve bitcoin in the form of code. No one is obliged to adopt their work.
It feels like there’s an element of East vs West going on too, as opposed to us all being on the same team. The more decentralized mining becomes the less politically contentious changes to the protocol will be, as people will be forced to scrutinise the code on its technical and economic merits alone.

The solution is BOTH we baby step 1. Segwit with 2mb to start SF no drama then WE SEE HOW IT GOES.
The issue is fear of LN but that is where it goes pair shaped because LN is only OPTIONAL payment channels LN needs on chain termination right? There will be pro’s and cons to LN usage but I see LN and on-chain working together not opposing.
Let’s on-chain scale NOW to the limit where it would not effect decentralization (i.e. nodes too big to run easily) 2MB to 4MB max and at same time activate segwit.
What is the risk in SF seqwit +2MB now? would that not satisfy everyone and give us more data points in 2017 to see the effects?

With good reason. Raising tx exorbitantly far above the natural market rate by introducing an Economic Change Event through a very low blocksize limit is an extra subsidy to miners that was not part of the original proposition to Bitcoin investors, exactly like raising the 21M coin limit would be. A lot of people would quit (or just fork away) if the 21M limit were lifted, but many of these same people seem to have no problem with inflation by another name.

This all reminds me of the massive long blogs Hearn was writing while whinging about the exactly the same things, before he ultimately ragequit and become yet another grease-stain in Bitcoin’s undies.
Keep going Jihan … Bitcoin will chew you up and poop you out like yet another insignificant trying to play BigGuy.

Thanks for this translation. Seems like the discussion is excactly the same in china as in here..
For example one of the commenters said
2.it is highly wrong to make the main chain a settlement network
But its not like we have a choice.

Fascinating. Chinese are very smart, with one of the oldest cultures in history. We could learn a lot from them, there is clearly a lot of wisdom here. Like they said, the battlefield is China right now, they have the most computing power. They will ultimately decide it.

My guess is no major changes to the original protocol. There are plenty of ways to settle up off-chain already.
Tx fees should be way higher, also. I’m fine with incentivizing miners more and de-incentivizing spammy, unneccessary transactions, because I can afford a higher fee in the rare case I need to settle something on-chain.

I know. The bitcoin community needs to start admitting the uncomfortable truth about Blockstream: not only do they not design Lightning, but they don’t design anything of any practical use. The company exists solely as a vehicle to enrich its executives on the backs of poorly-informed investors who don’t really understand cryptocurrency beyond a few buzzwords like ‘blockchain’.

I do wish people would stop conflating Core and Blockstream. Core actually produces things, even if the general public might not fully agree with what they’re doing. On the other hand, Blockstream is on a fast track to insolvency.

I can’t see any evidence so far that Blockstream is anything more than a front to leverage participation in bitcoin-wizards irc into a full-on VC money exit scam to enrich themselves and their nepotistic cronies.

I know I still think r/bitcoin has more balanced views but jesus we need to get to the bottom of this and neither side is 100% right so we must FLUSH OUT what to do “ASK NOT WHAT BITCOIN CAN DO FOR YOU BUT WHAT YOU CAN DO FOR YOUR BITCOIN’ LoL

Also can anybody tell me what 2mb and 4mb block size would do to my node vis a vis capacity needed. My nodes are on data center ubuntu servers .. What storage might I need etc? I do not want block size so large that small guys like me can’t run nodes. Anybody can help with with quick and dirty estimate?

First off, it’d be nice to have some proof. Next time someone sees a post they suspect might get removed from here by a mod, archive it.

Second, calm your tits dude. Have some tact and poise. You are the same guy who made a 20 minute rant video on OKCoin only to completely forgive them like 2 days later when you realized the whole mess up was because you have them a fake ID number and didn’t write it down. You’d think you would learn your lesson. Calm down and don’t jump to conclusions.

Third, what part of Segwit + hard fork to 2mb is a compromise from the big blockers? Taking on Segwit? Not making blocksize completely unlimited? Honest question.

Fourth, “They think core will leave blocksize at 1mb forever” is a terrible reason to block Segwit progress. That’s just playing politics. How you can be a bitcoin supporter and get behind the idea of blocking progress for the sake of playing politics is ridic. If you oppose Segwit for other reasons, that’s fine, but block bitcoin progress just because you don’t like who the core developers are as people is ridiculous.

Fifth, Seeking 95% consensus on a change that is not very controversial is far from “dictator” or “monopoly” or “hijacking the protocol” or whatever you want to call it. It’s the opposite. They put a lot of work into a product they stand strongly behind but STILL realize that community consensus is a must. As opposed to what the big blockers want to do which is hard fork and just make everyone pick a side. Hard forking is a form of allowing the community to vote, but it is a highly risky one. Soft forks are not perfect either but “if we get 51% fuck you guys we are forking!” Seems a lot worse to me than “hey guys we worked on this for a long time and if 95% of the community can agree, we’d like to implement this.”

First of all as posted by mod it appears it was posted before is why they removed it.. i just didnt see it before so PROOF no longer needed.

2ndly leave my personal situation out of it dick head.

3rd.. Im not even on BIG BLOCK SIDE at all and am PRO segwit However we will NEVER SEE IT.. unless we figure this out together which is why it has to be hashed out. Core needs to show ROADMAP to appease onchain scaling so it can compete SOMEWHAT with LN case closed.

Here is my take. While the block reward is 12.5 Btc. Let’s grow. Let’s the side chains do all the work and then in return the miners will have a steady stream of income coming from sidechains. It will be the waterfall effect. The more sidechains the more water that falls.
There are no downsides to Segwit. It creates 300% more in TPS. But included is the malleability fix. This allows features for sidechains and layers on top of the Blockchain. Miners get a subsidy to secure the Blockchain. It’s not the whole ecosystems responsibility to ensure they make massive amounts of profits on top of that. Let the creativity and innovation expand on top of the Blockchain. Visa can have a sidechain. PayPal can have a sidechain. Western union can have a side chain. All side chains add value to the Blockchain. Lightening and many others will allow consumers and small to midsize merchants to transact in a timely manner.

I’ve said many times, voting for segwit is voting for scaling and GROWTH. It’s not about mining anymore. If the miners in there respective countries want. They too can create a sidechain. Nothing is stopping them. But time is running out till the next halving. Stalling or halting growth will hurt them in the long run.

Sorry I just don’t remember it and it seems to be central to the issue so why not solve their concerns so we can have it all. The world news is all in our favor now. If we can scale both a small onchain and segwit the world is ours.

You don’t research what’s happening in this world if you think we have 1 year to suss out this issue. Wonder why Ether was so easily able to steal market cap? If we don’t innovate we are dead in the water.

Go back to where your lies are supported by the sub owner, your stupid propaganda is not welcome here. No need to “research” (so scientific!) here, see stickied comment. And yeah, “1 year suss out”, look at the shitload of innovations Core delivered recently. And yes, please pump your favoured alt here. And thanks for FUD in your last sentence.

Elimination of unwanted transaction malleability: Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.

Capacity increase: Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size. Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).

Weighting data based on how it affects node performance: Some parts of each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain. One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different “weight” to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.

Signature covers value: A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed. For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.

Linear scaling of sighash operations: In 2015 a block was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can’t be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature method that doesn’t suffer from this problem and doesn’t have any unwanted side-effects.

Increased security for multisig: Bitcoin addresses (both P2PKH addresses that start with a ‘1’ and P2SH addresses that start with a ‘3’) use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security—which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address. Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin’s choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)

More efficient almost-full-node security Satoshi Nakamoto’s original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto’s method can’t guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin’s current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes. Although the problems with Nakamoto’s method can’t be fixed in a soft fork, Segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.

Script versioning: Segwit makes it easy for future soft forks to allow Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.

Activation for the segwit soft fork is being managed using BIP9 versionbits. Segwit’s version bit is bit 1, and nodes will begin tracking which blocks signal support for segwit at the beginning of the first retarget period after segwit’s start date of 15 November 2016. If 95% of blocks within a 2,016-block retarget period (about two weeks) signal support for segwit, the soft fork will be locked in. After another 2,016 blocks, segwit will activate.

For more information about segwit, please see the segwit FAQ, the segwit wallet developers guide or BIPs 141, 143, 144, and 145. If you’re a miner or mining pool operator, please see the versionbits FAQ for information about signaling support for a soft fork.

Null dummy soft fork

Combined with the segwit soft fork is an additional change that turns a long-existing network relay policy into a consensus rule. The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes consume an extra stack element (“dummy element”) after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script.

Because any value can be used for this dummy element, it’s possible for a third-party to insert data into other people’s transactions, changing the transaction’s txid (called transaction malleability) and possibly causing other problems.

Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and mining transactions whose dummy element was a null value (0x00, also called OP_0). The null dummy soft fork turns this relay rule into a consensus rule both for non-segwit transactions and segwit transactions, so that this method of mutating transactions is permanently eliminated from the network.

Signaling for the null dummy soft fork is done by signaling support for segwit, and the null dummy soft fork will activate at the same time as segwit.

For more information, please see BIP147.

Low-level RPC changes

importprunedfunds only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.
Linux ARM builds

With the 0.13.0 release, pre-built Linux ARM binaries were added to the set of uploaded executables. Additional detail on the ARM architecture targeted by each is provided below.

The following extra files can be found in the download directory or torrent:

bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries targeting the 32-bit ARMv7-A architecture.
bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries targeting the 64-bit ARMv8-A architecture.
ARM builds are still experimental. If you have problems on a certain device or Linux distribution combination please report them on the bug tracker, it may be possible to resolve them. Note that the device you use must be (backward) compatible with the architecture targeted by the binary that you use. For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit execution state) device, can run the 32-bit ARMv7-A targeted binary. However, no model of Raspberry Pi 1 device can run either binary because they are all ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.