SegWit2x – A New Statement

The Overwhelming power of SegWit2x

In order to safeguard the community from an undesired chain split, the upgrade should be overwhelming, but it’s not enough. It should also ‘appear’ as overwhelming. People, businesses and services needs to be certain about what is going to happen and the risks if they won’t follow. My impression is that still too many speaking english people in the western world think the upgrade will be abandoned before or immediately after block 494784 is mined, thus they are going to simply ignore it. That could lead to unprepared patch up and confusion, while naïve users risk to harm themselves.

For this reason and for the sake of the Bitcoin community as a whole, we need to show again, clearly and publicly the extent of the support to SegWit2x. We also need to commit ourselves in a widespread communication campaign. I know this is not a strict technical matter, but it could help a lot avoiding technical issues in the future.

What we have to do

First, we need a new statement from the original NYA signers and all the business, firms and individuals who joined the cause later. That statement should be slightly different from the original NYA though, and I am explaining why.

We all know that what Bitcoin is will be ultimately determined by market forces, comprehensive of all the stakeholders involved: businesses, miners, users, developers, traders, investors, holders etc. Each category has its own weight in the process, and everybody has incentives in following the market. If the market goes clearly towards a certain direction, in the long run no company will remain stuck to a position for barely ideological beliefs.

For this reason, it’s clear why some businesses communicate that they are going to support the chain which will better meet the market demand, independently from what they think is the best protocol solution or upgrade for Bitcoin.

For example, two signers of the NYA, SurBTC and Bitwala, recently stated that they completely subscribe to the technical changes proposed in the agreement for SegWit2x

SurBTC: “From a technical standpoint, we’ve always loved SegWit and we see a small increment (2mb) in the size of the block as a good idea as it would relieve pressure, lower fees and give some time to other more definitive scaling alternatives such as the Lightning Network to develop (

Bitwala: “We urge all developers to take into account the demands of users and all parties of the NYA and address them adequately, if not implement them” (

Despite this, they said they cannot guarantee they will use the ticker BTC for SegWit2x coin. Bitwala states that they “would like to honor the agreement”, but they also depend on third party exchange and service payments (Xapo) and “must build our products on what they support”, so they won’t have an active role in the fork: “Everything else is up to the market”. Reading that statement no one can say Bitwala is not in favor to SegWit2x as a technical upgrade. Despite that, I also see people who misinterpreted the message and listed Bitwala among the NO2X companies. There are many companies deprecating a contentious upgrade, for this reason they move against SegWit2x hard fork, but that doesn’t always mean they oppose the upgrade in itself.

Many, including some Core developers, oppose the fork just because ‘they think’ it is contentious. But what if they are wrong? We can reasonably think companies are not eager to struggle against a big part of the industry, or put the network unity at risk, if S2X had no broad support. It’s fair. But first, you have to express your opinion, second, you see if it is shared by the rest of the community. Then, you can decide to pursue the upgrade or not. There is no point in opposing a proposal prima facie because the mere fact that it’s contentious, it’s simply illogical.

I would ask all business the following question:

“Would you favor a Bitcoin upgrade increasing the blocksize to 2mb by means of a hard fork from block number 494784, if this upgrade proposal proved to have broad support among the Bitcoin community?”

This way, we are able to identify exactly how many are in favor of the bare technical upgrade in itself, without political considerations. After we have a clear feedback, it’s left to individual companies and miners to read the response data in a political framework and decide if it’s an acceptable level of consensus. Thus each one will independently decide if it’s worthwhile pursuing the upgrade or not.

From my search, I would say that at least the following companies are in favor of the upgrade (see the list below). I included the original NYA signers, plus the companies “blacklisted” by[1] (and other companies who lately asked to be included in the blacklist[2]), plus a few others retrieved from these lists[3] which weren’t mentioned yet. Please check the list and make amendments if something is wrong, which is likely since I could have missed the most recent statements of some companies.

I included also Wanyloans, Vaultoro, CryptoFacilities[4] and SurBTC[5], original signers of NYA that lately pulled their unconditioned support. Reading their statements, it seems they are not against the technical proposal in itself: they denounce the lack of replay protection, but it’s reasonable to complain about it only if the upgrade is likely to cause a split, which is a political matter. I excluded F2pool, since I think that supporting NYA “until july” implies that they simply never supported it.

Coinfucius ATM operator
Digital Mint
Digital Currency Group
Genesis Global Trading
Genesis Mining
Grayscale Investments
Guy Corem

Our purpose is to extend this list as much as we can. I am discussing below the reasons why everybody should subscribe. We all should commit in spreading the word, post articles and engage press, digital newspaper etc. as much as we can.

Why to support SegWit2x

Let’s counterargue the major criticisms moved to SegWit2x, which are either technical and political.

TECHNICAL arguments against SegWit2x:

the 2mb blocksize is too large and leads to network centralization. The number of fullnodes will decrease due to the blocksize increase.

I think it’s important that everybody really willing to individually run a fullnode should be able to do it, without facing a significant economic effort. The reason is clear and simple: a proper number of fullnodes adds a layer of decentralization to the network. It constitutes a “proof of stake” balancing out the miners “proof of work”. Without fullnodes we lose an important stakeholder in the Bitcoin ecosystem. If miners went rogue, a proper number of fullnodes would allow to resist until miners are brought into line by market mechanisms and economic incentives. Actually, if miners “really” went rogue, which means the hashrate keeps going contrary to market demand in the medium and long term, it implies that Satoshi Nakamoto was wrong, the game theory behind Bitcoin is erroneous and Bitcoin is a failure. In that case a POW change won’t save us, it would just postpone the inevitable. If that ever happens, we would be better stop thinking of Bitcoin and instead start studying how to improve other technologies: maybe a crypto like IOTA, without the two distinct classes of miners and users.

So, fullnodes are important. But of course, we cannot guarantee the entire population be in the economic conditions to run a fullnode. What we can try is to guarantee at least that the increase in blocksize won’t reasonably lead to a drop in the percentage of fullnodes on the total number of nodes. We can see the security of the network like a function of the number of independent validators. It’s not a function of the number of participants nor the function of the ratio between validators and participants. As the number of participant increases, the number of validators need not to proportionally increase in order to maintain the same level of security. It means that if we are able to maintain the same ratio between validators and participants, and both increase, we are constantly achieving a higher level of security.

In this perspective, there is no reason at all to avoid the blocksize increase to 2mb:

  • The 1gb/s bandwidth is starting to spread in the big cities all around the world, while average bandwith requirements for a 4mb node is 592kbs.
  • A 3tb hard disk costs 100$, the blockchain storage with a 4mb blockweight full blocks chain is 205gb per year (and that is only the case with capped blocks in SegWit2x chain and full SegWit adoption among wallets).
  • An average Intel i7 2.2ghz can validate about 4000 tx per second, while a full 4mb block contains 8400tx every ten minutes average.
  • The requirements for RAM are about 512mb for current blocksize, while top generation smartphone have 6gb RAM. Surprisingly, I heard some users pointing at the RAM requirements as the bottleneck. They probably ignore the RAM requisites for Lightning Network!

There is, literally, no hardware bottleneck. Rusty Russell himself, major contributor to the RFC specifications of Lightning Network, proposed a blocksize increase to 3mb in 2016, just to increase it again of the 17% the next year. In july 2017 he recalls his estimates, stating they were too pessimistic: hardware technology grows faster than what foreseen.

The fact that a tiny block increase isn’t in itself “contentious” at the present days can be seen also in the way and timing SegWit was proposed. If SegWit BIP got the immediate support of miners, it would have been already in production a year ago. Then, I suppose its supporters could expect to reach full adoption among wallets within a year (the present days). When fully adopted, SegWit1x allows ~2mb blocks (max 4mb), implying that we would have had already 2mb blockweight right now. This is just another clue showing how the anti-SegWit2x movement is not against 2x because possible centralization issues caused by the doubling of blockchain size. Actually, very few Core members/supporters have this claim, maybe only Luke Dashjr?

In a few words, we can double the space for transactions, without any collateral effect on centralization.

Average 2017 daily mempool size is 13mb. Precisely, it is 13,288,265 bytes (1 january – 15 october). Average 2017 daily transaction fee is about 2$, with peaks at 8$ and 0.3 as bottom. One person sending from 50 to 100 bitcoin transactions in a year is likely to spend more in fees than the cost of a personal computer upgrade.

Assuming a growing user base as we have seen in the last year, that peak at 8$ could become the average. Actually, I think it’s unlikely that average fee will be so high: simply new users won’t approach Bitcoin, or old users move away to other altcoins. And this is not because technology, but politics.

The development of SegWit2x reference client is too rushed

Another argument against S2X is that the development of btc1 as reference client was too rushed. I respect whatever opinion, I just demand the same treatment for me when I state that, in my opinion, six months to deploy a build with the increase of a constant do not require a “rush” at all. You may disagree with me, but that doesn’t give you the right to denounce me as an attacker or a malicious player. The 2mb increase was proposed originally in the Hong Kong agreement of February 2016 and since then we have seen a lot of builds and proposals about how to increase such a “constant”. We already have in production builds like XT, Classic, Unlimited or Bcoin accepting bigger blocks. Actually, with the exception of Core, all the other Bitcoin fullnodes accepts blocks larger than 1mb blocksize (if I’m wrong, correct me, there are implementations I don’t know about). So only that part of the community running Core clients needs to update. I know it’s the majority of fullnodes, but in 6 months everybody is notified and have time to upgrade. If 6 months are not enough to plan and organize a hard fork, I think no upgrade could ever be done by a hard fork. But keeping backwards compatibility forever is simply crazy. And it is far more safe to test a hard fork in production with a very tiny protocol change (from 1 to 2mb blocksize) rather than for huge and more impacting changes like Schnorr signatures. Many people, like me, are still running a Bitcoin Core fullnode. But of course I am more than ready to move to btc1.

Actually, SegWit2x is not the first hard fork in the history of Bitcoin upgrades. The 11 march 2013 the upgrade from Bitcoin Core 0.7 to 0.8 caused an undesired chain split: Core developers didn’t realize that the implementation of the faster LevelDB database (compared to the old BerkeleyDB) could accidentally introduce a protocol change. For 6 hours (about 20 blocks) two chains were competing and some people could even double spend its bitcoin

In 6 hours, all miners were contacted and notified about the bug, the entire community decided immediately to roll back on build 0.7. For a part of the community (those running Bitcoin Core 0.8) that roll-back was, technically speaking, an intentional “hard fork upgrade”, which was made very efficiently in just 6 hours. This is another more reason why we should have more builds, dev teams and in general a decentralized process of BIP review and protocol change, involving as many stakeholders as possible: more builds means also that bugs and incidents happen more frequently, but they will be localized and far less dangerous, while a single bug in the only one reference client could trigger a disaster likely to leave a indelible mark in the history of Bitcoin. It’s not anymore march 2013, daily volumes are 2 billion not 2 million. Think what could happen now, in case of a repeated 11 march hard fork. When about 4 years later Bitcoin Unlimited crashed (march 2017) the network as a whole didn’t get damaged, actually a very few peopl noticed the event, if not for the jeers from the other “faction”. This is because Unlimited is just a build among many different others.

A far more “rushed” hard fork is the split of Bitcoin Cash from the network. I am not a BCH supporter and certainly that fork wasn’t perfect (the fast difficulty adjustment is a big problem), but at least it shows it’s possible to plan such a (safe) chain split in a hurry, if people is really willing to do it. The code was presented by Amauri Séchet on “The future of Bitcoin” conference the first july, mentioned on the 14 july by Bitmain blog as a backup strategy for the 1st august, in case UASF happened (and S2X failure). It was then prompted by Hosftat on July 22 on all major channels like bitcointalk and reddit or by other well known players in the international scene like ViaBTC.

In conclusion, I cannot concede that it’s the timing to make SegWit2x controversial. So I have to investigate other reasons.

POLITICAL arguments against SegWit2x:

it’s a corporate takeover of Bitcoin, an attack to the network, a contentious Hard Fork, while no upgrade should be contentious

Why the Hard Fork SegWit2x is contentious? Indeed, the community is too large and unanimity is impossible to reach, so every upgrade is in some way contentious. But why this one in particular?
It got the support of the majority of miners, and the support of a lot of the biggest Bitcoin companies.

Ask this question: if the Core team supported SegWit2x immediately after the NYA, would it be still considered contentious? Everybody should ask himself and answer honestly to this question. I might be wrong, but I firmly think the answer here is “no”.

Ask a Core dev “why don’t you support SegWit2x?”. He might answer “because it is contentious”. Then question why. The answer “because it is contentious” is tautological and we cannot accept it. Some may reply that SegWit2x is contentious because it lacks of strong replay protection, for this reason they don’t support it. This is another logical fallacy. Follow the reason:

  • No upgrade in the history of Bitcoin ever had replay protection. That is a requirement for the creation of altcoins, not a Bitcoin upgrade.
  • So a proposed upgrade (whatever it is) can’t be contentious because of the lack of replay protection.
  • But you may say that a certain upgrade requires replay protection since it is likely to end up in a chain split, with the creation of an altcoin. In that case the logical causation is reversed: SegWit2x is not contentious because it lacks replay protection, instead it lacks replay protection because we know in advance that it is contentious and might generate a split.
  • But if Core devs accept the upgrade and for this reason it’s considered no more contentious, then it doesn’t require replay protection.
  • This holds unless the real motivation of its contentiousness lies in something else and not in Core disagreement. But then what’s the real motivation?

BT1 vs BT2 futures and polls

Some may say that the market is in favor of the legacy chain because of the price of futures on Bitfinex. Actually, this doesn’t explain the Core team attitude, since they opposed S2X long before the market quotation of S2X futures. However, at the moment (23 oct) the legacy chain futures are priced about 0.85btc, while SegWit2x 0.15btc.

We know the BT2 tokens have been dumped on Bitfinex market also for ideological reason. The existence of services like confirms this, and lately we all probably read about Core supporters going around boasting about what a big deal they made. But if you dump now bt2 for political reasons, that’s a bad strategic move. If you already sold your S2X coins, it means you can’t sell them when it really matters, that is at the moment of the fork. The price is the match of supply and demand in a particular moment and what happened just a moment before doesn’t matter. For this reason, I expect the big players won’t join the game much early. At the moment, about 2,500 BT1 have been traded and 22,000 BT2 (sum of trades on BTC and USD pairs), volumes are minimal. It is about the 0,3% of the total amount of BTC traded on Bitfinex in the same period. Imagine how negligible it is compared to the total amount of BTC trades in the entire world. Looking at today trades, about 20 BT1 have been exchanged and less than 200 BT2, for a total of 260,000$, which means a lot of people who is reading me right now have the firepower to completely reverse the price of the two coins in just a couple of clicks, employing a tiny part of his funds. In conclusion, It’s too early to say what’s the preference of the market.

And what about individual users? There are no reliable surveys about individual user preferences, but I recently saw a simple poll on Coindesk website (sidebar on the right). When I gave my answer, I’ve seen the results. Even if they are easily falsifiable, I report them:

Do you think the SegWit2x agreement is good for Bitcoin?
Yes – I believe increasing the block size is needed after the introduction of SegWit (1078 votes, 37%)
Undecided – I do not feel strongly or negative about the proposal: (966 votes, 33%)
No – I believe SegWit is sufficient for short-term scaling (858 votes, 30%)

I took the screenshot at time 10/18/2017 15.40 GMT+1. For an update we should ask Coindesk I suppose.

In conclusion, technical arguments against SegWit2x have been already examined, and are not convincing. The “I don’t support because it is contentious” motivation is tautological. But there is another possible explanation: to increase the blocksize now, by means of a hard fork, is not in Core agenda and Core rejects whatever agenda doesn’t follow their indictments. In the very long run, they want to increase the blocksize, but after full deployment of Lightning Network, Schnnor, Mast. But this kind of agenda is not dictated by strictly technical reasons and the decision to stick on it or not doesn’t require coding or programming skills at all (unless there were some incompatibilities between S2X and the future upgrades Core is planning, but it’s not the case). So we shall encourage all the community major players to feel confident in freely choosing the agenda they want to pursue, according to socio-economic arguments and their own reason.

Lightning Network and Schnorr

I want to underline how long it will take before the solutions to scalability supported by Core will be ready. Look at the Status of Lightning Network, as summarized by Rusty Russel (see here

“There are protocol scaling issues and implementation scaling issues.

  1. All channel updates are broadcast to everyone. How badly that will suck depends on how fast updates happen, but it’s likely to get painful somewhere between 10,000 and 1,000,000 channels.
  2. On first connect, nodes either dump the entire topology or send nothing. That’s going to suck even faster; “catchup” sync planned for 1.1 spec.”

I am a big fan of Lightning Network (see also the dedicated section on my website), but the solution for the Bitcoin scalability currently doesn’t scale, ironically. We have to wait for developers solving these issues, then we have to wait for good user interface wallets and SPV clients, then we have to wait these wallets and clients spread up and start being used, then we have to wait for the creation of channels and a mesh network. In the most optimistic forecasts, how much time do we need, a couple of years? Look at SegWit deployment: after three months not even Electrum deployed SegWit (even if it seems to be close), and the protocol technology has been released two years ago. It’s not the case to further analyze here other issues LN may have in a Bitcoin network with a very small blocksize, like the centralization of intermediaries due to high costs in settling channels.

Schnorr doesn’t seem to be in better conditions. For the moment the Financial Cryptography and Data Security 2017 rejected the Bitcoin Core paper, asserting that the security proof for the signature aggregation scheme provided was too flimsy (see I am confident both these technologies will make the future of Bitcoin, but we also need to consider the whole picture.

The debate about SegWit2x upgrade has been marked by unfair and dishonest behavior

The “black list” of firms, miners, services and exchanges resembles the Holy Inquisition’s battle against the witches (see here and here Honest businesses and firms are publicly and officially “denounced” and their users (their clients) have been warned against them, which is a shame and might also imply economic injury. In many other posts or comments by Core supporters, the listed firms are also reported like scam or malicious player attacking the Bitcoin network. That’s a serious unethical move against a significant part of the Bitcoin community. is denouncing these companies just because they are not going to follow Core ideology. To demand that every company, under any circumstances, agree to never list S2X as BTC, even if at a certain time a supermajority of the ecosystem were to call it as such, is simply unreasonable. And it is a shame to denounce a company, which owes its existence to the market, just because it might follow the market demand. It’s a totalitarian act against the freedom of choice and the natural development of the market in a free society. And it’s not an isolated case: a Core developer (I don’t want to name names here) appealed to the United States Securities and Exchange Commission (SEC) demanding intervention to ensure “Bitcoin” name and “BTC” ticker to be legally bound to the legacy blockchain, the one supported by Core. This behavior is in evident antithesis with the libertarian philosophy. But these are just the tip of the iceberg. One example above all: the Blockstream CEO calling S2X a corporate takeover and S2X supporters as “enemies of Bitcoin” ( That statement implies someone currently owns Bitcoin, otherwise there couldn’t be a “takeover”. But no one will ever own Bitcoin, for sure Core developers don’t. What Bitcoin is shall be determined by a struggle of interests, and if in this game miners and companies can put in play more power, it’s just because they invested more, working, developing, assuming risks and satisfying clients and users. If they have a certain weight in the decision, it’s because they deserve it.

SegWit2x has no devs and no open development process

We often hear that S2X has no dev, or only one single dev. This is false, indeed. The objective truth comes easily to the surface: you just need to open the S2X github to discover it. The NO2X campaign is political, and like every political campaign its made of propaganda, which often reports a biased and even deceptive version of the reality. There are many developers and contributors to btc1, even some current Core team devs gave advise. The discussion is public, open and free, everybody can participate, just like in the mailing list. The self-evidence of its openness is the number of NOS2X posting:

But let’s assume it was true that just a few devs were working on btc1, would that make such a difference? The New York Agreement requires to increase the blocksize within 6 months by means of a hard fork. Does it really represent such an effort, for which hundreds of developers and more than 6 months of coding and testing are not enough?

For what regards the quality of development, there are former Core developers working on it. In the past, the “current” Core team sought to alienate some other prominent Core devs like Gavin Andresen, Mike Hearn or Jeff Garzik. All of them are on board since the very first days of Bitcoin development, all of them also exchanged private and public messages with Satoshi Nakamoto. Now they are all giving support to S2X, contributing to the discussion and code. Today no Core dev supports S2X, but that doesn’t mean no technical people support S2X at all. Those who thought different from the “current” Core team have been “fired” long ago. Ironically, now some Core devs accuse part of the community of attempting to fire them, but the present situation is very different: no one is trying to censor or fire the Core devs. The community is just proposing an upgrade. Core refused to discuss it, not even participating at the meeting when invited.

Nevertheless, even if the reference client will change, it doesn’t mean the Core team is “fired” and won’t actually participate to the development of the Bitcoin chain SegWit2x. It will always be possible to take the best technologies developed by Core, even if initially thought for a different chain. I agree that departing from some great devs would be a loss. Among the more prominent Core developers there are persons who were always professional, humble and dedicated to the code, never to political barroom brawls. But what recently stated Gavin Andresen is absolutely reasonable: “Early bitcoin devs luckily picked the right project at the right time. None are irreplaceable, bitcoin will succeed with or without us”. It’s irrational to worship a group of cantankerous people like divinities, believing they are the sacred chosen ones. How is that possible that in the entire world there are no honest people willing to learn about a revolutionary protocol, having at the same time high skills in programming and being smart enough to understand basic principles of game theory and economics?

However, if it really happens that two chains will survive after november, the good news is that they will share every part of the protocol, except for the blockweight. If the Core chain maintains a significant value, it could be used as a production environment to test new protocol upgrades, like Schnorr and Mast. To test an upgrade in a real economy is much better than testnet. Something similar happened also with SegWit deployed on Litecoin, with users proving their anyone-can-spend money couldn’t actually be spent by anyone.

Game of forks

Assume that, at the time of the fork, 15% of hashrate is in favor of the legacy chain, while 85% for SegWit2x.

Which means a block is produced on the legacy in 66 minutes average. The difficulty change happens after 2016 blocks, which means 133,000 minutes. It’s 92 days. During these days:

  • A single big miner like Antpool could dedicate a 8% hashpower attacking the legacy chain and orphaning blocks. It would mean 23% hashrate for legacy and 77% for S2X. More blocks for the legacy, but all empty. The legacy is not viable and to survive it’s needed a POW change.
  • If it’s not the case and both chain survive, suppose just 1/3 of users of current Bitcoin network keeps using the legacy to make transactions: if 2017 average mempool size is 13,288,265 bytes, 1/3 is about 4mb. But in the first 92 days, blocks take 6 times longer to be mined. Which means a mempool size of 24mb average, approximately doubling. And it’s an average, not the peak. Imagine how long it would take to confirm a transaction, and how much it costs.

Now, suppose the first days after the fork the trades on most of the exchanges will be suspended, so in the very short run there is no miner switching towards the opposite chain because of profitability reasons. The only thing users can see is the hashrate. When exchanges open again to the first trades, are really users willing to bet on a dead chain, in the hope that many other traders do the same, with the expectation that at a certain moment some miners will switch back to the legacy? If the fork really happens with 85% hashrate in favor of SegWit2x then.. best wishes.

[1] and here


[3] and From the first list, BitOasis is uncorrectly listed among the NYA withdrawn, you can read their statement here and nothing can make you think they are pulling support:

The same holds for Bitwala:

[4] It’s not a public communication:


Share this page: