Blockchain Intelligence Group discusses what was SegWit2X

On Wednesday November 8, Mike Belshe, CEO of the software wallet BitGo announced that SegWit2X was being suspended due to “...(in)sufficient consensus for a block size increase”. For many in the Bitcoin community, this stalling of the SegWit2X hard fork was inevitable, for some it was a relief, for others, it was a chance to get back to developing the Bitcoin ecosystem.

We at Blockchain Intelligence Group were watching developments and readying ourselves for the prospect of the hard fork to go live. So, the suspension is an opportunity for us to tease out the intricacies of what this hard fork was about.

Q: What was the background behind SegWit2X?

A: Over the last few years, there has been an intense debate within the Bitcoin community about how to accommodate the growing volume of transactions on the Bitcoin blockchain.

Before discussing SegWit2X, we need to backtrack and explain SegWit. Short for segregated witness, SegWit was the user-activated soft fork (UASF) solution to the scaling issue that had opposed the idea of larger blocks. It was a means of re-organizing transaction data in such a way that it discards the witness (signatures) data from the rest of the transaction data. This means that the witness data is neither broadcast to the blockchain nor does it form part of the fee calculation.

On August 1, a user-activated soft fork (UASF) invited wallets, miners and nodes to “flag” whether they will support Core’s SegWit solution.

However, Core’s SegWit proposal was not the only solution that proposed an answer to the block size issue. Jeff Garzik authored a Bitcoin Improvement Proposal, BIP 102, that proposed a hard fork to 2Mb on a “flag day”. This “flag day” might be construed as a response to the UASF’s August 1 date. (Song). Indeed, the SegWit2X proposal was also launched on that “flag day”.

All these events sound spontaneous, at first. However, the UASF and the emergence of SegWit2X were all part of the New York Agreement (NYA) which this article will focus on, below (Haywood).

For a more detailed map of the fork architecture, please find this post on Reddit.

Q: What was SegWit2X?

A: A hard fork is “a permanent divergence in the block chain, (which) commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules” (Bitcoin Glossary).

What did this mean for SegWit2X? It was a proposed change to the rules on which the Bitcoin protocol is run. It was intended to be a hard fork from Bitcoin Core’s SegWit chain which means that new rules were to become valid on the SegWit2X chain but to be backwards-incompatible with those of Core’s SegWit rules. This means that Core’s rules, no longer supported by the SegWit2X chain, would have become invalid.

The BIP102 specification that I mentioned had three components (quoted verbatim from the github source):

Maximum block size permitted to be valid is 1MB;
Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support;
Increase maximum block sigops by similar factor, preserving SIZE/50 formula (jgarzik/bips; Hertig ¹ )

So, the main features of SegWit2X are:

Organization of transaction data – based on BIP141 (SegWit)
Block size – 2Mb

Q: At which block number was SegWit2X due to activate?

A: 494784.

Q: What were the similarities between SegWit2X and other Bitcoin versions?

A: SegWit2X’s fork was no different from that of Bitcoin Cash and Bitcoin Gold in the following regards:

It was a version of bitcoin, with alternative features, that sought to modify the Bitcoin software run by network participants, such as the nodes, developers and miners. Bitcoin Cash’s version was labelled as “Bitcoin ABC (Adjustable Blocksize Cap)”, Bitcoin Gold’s was named “BTCGPU” and the SegWit2X version of Bitcoin was “btc-1”.
It was an effort to carry out one specific change to the rules of the Bitcoin protocol. Whereas SegWit2X focused on increasing the block size on the SegWit UASF chain, Bitcoin Cash had focused on changing the block size from 1Mb to a maximum of 8Mb and Bitcoin Gold had been about changing the proof-of-work algorithm from SHA-256 to Equihash.
It was a hard fork, as explained in the “What is SegWit2X” section. Bitcoin Cash and Bitcoin Gold were also hard forks in that their new version and rules were incompatible with those nodes that had not upgraded their own rules to those of Bitcoin ABC or BTCGPU. Likewise, the SegWit2X rules required nodes that still wanted their blocks to be regarded as valid on the SegWit2X fork to signal for btc-1 (Rizzo).

(For more details about the Bitcoin Gold hard fork, please see the Blockchain Intelligence Group’s discussion about it, here.)

Q: And what were the differences?

A: The differences between this fork and the others lay not so much in the contents of the SegWit2X fork itself but in the manner by which this fork had been conducted. Unlike Cash and Gold, SegWit2X was not just a proposal that sought to change bitcoin’s technology but was also a formal written agreement reached between certain parties interested in that change (Coindesk). There were several factors at play here:

The btc-1 developers believed that SegWit2X was the true Bitcoin-in-waiting,
This hard fork was not introduced as a single BIP, but it was created from shards of previous BIPs and enshrined in the NYA document,
On the strength of support for the NYA, SegWit2X enjoyed significantly greater support from miners, entrepreneurs, exchanges and wallets than those preceding forks,
Whereas the developers of the preceding forks were prepared to recognize their respective blockchains as minority chains, btc-1’s goal was to keep Bitcoin’s existing users on a single blockchain, with SegWit2X as that single blockchain,
In expectation of this one SegWit2X-run single chain to emerge, btc-1 hoped that a chain split would be averted and, therefore, face-off the call from Core-supporting stakeholders to offer replay protection (Rizzo; Deschapell).

Q: What is the NYA, its tImetable and what are the positions of the stakeholders?

A: The NYA was a document that set the timetable for implementation of SegWit and SegWit2X. The leaders of the NYA were the Digital Currency Group (DCG) and ShapeShift. The Agreement was announced in May 2017 as the Bitcoin Scaling Agreement. It announced, among their signatories, an impressive array of 56 supporting companies located in 22 countries. The companies represent:

28% of Bitcoin hashing power
US$5.1 billion, monthly, on chain transaction volume
5 million bitcoin wallets (Medium)

The timetable was proposed as the following:

23 May – set timetable for SegWit and SegWit2X implementation

1 Aug – UASF deadline for SegWit activation using BIP 148

1 Nov – as long as there is a minimum of 80% support for the SegWit2X hard fork, the miners will activate it using BIP 9

Below is a table that shows the positions that Bitcoin stakeholders take on SegWit2X:

	Position on SegWIt2X	What is Bitcoin?	What is Bitcoin’s main priority?	View on forks in NYA timetable	Concerns about the future
Miners/exchanges/entrepreneurs	For	Payment network	Compete with VISA and fiat currenciesBecome an established medium of exchange	SegWit has failed to attract support & bring much-needed capacity increase	Other blockchain protocols will start competing with bitcoin and overtake it
Developers/nodes	Against	Store of value	Bitcoin should prioritize innovations that don’t require larger blocks	SegWit2X too risky… dev team untriedSegWit2X gives miners and exchanges too much power	Bitcoin will lose its decentralized governanceCould become undemocratic in its decision-making processes

Q: So, how representative was the NYA of the Bitcoin community as a whole?

A: Btc-1 stated the hash power of the NYA signatories (83.28%) knowing that the figure passed the 80% threshold required to activate SegWit2X. So, btc-1 interpreted the pledged support for NYA as legitimacy for it to switch the whole Bitcoin protocol over to SegWit2X.

However, btc-1 should not have assumed victory. As an instrument for the development of a new Bitcoin protocol, the NYA was far-removed from the standard practice of delivering a bitcoin proposal. Traditionally, this has been the role of the BIP. Blockchain Intelligence Group identified four reasons why the fork proposal should have been presented to the community as a BIP:

To remain in keeping with Bitcoin’s ethos of consulting all stakeholders under a governance model that is consensus-based and decentralized;
This was a hard fork that, due to its backwards-incompatible nature, would have disenfranchised those stakeholders that will have preferred to mine or validate blocks using the legacy/SegWit+UASF chain;
The nodes needed to be able to update their software so as to avoid splitting the blockchain;
This fork was presuming to replace the legacy Bitcoin chain. Everyone needed to be consulted and in full agreement for btc-1’s Bitcoin software to replace that of Core.

Running this proposal through the NYA document that not all parties will have seen, let alone agreed with, and then acting on it will have disenfranchised a large section of the Bitcoin ecosystem. So, in the unlikely event of SegWit2X replacing Core’s legacy chain (as planned), the fork would have jeopardized the fabric of the Bitcoin blockchain.

Btc-1’s own faith in the comprehensiveness of NYA was presumptuous given that the group had shown no sign of having reached out to Bitcoin stakeholders beyond those who had already signed the NYA. The NYA even went so far as to claim “a critical mass of the bitcoin ecosystem”, that 83.28%, on the strength of a list of signatures. Also, the NYA’s referencing of hash power should not have been considered as an inclusive benchmark on which to judge the community’s support for the hard fork (Deschapell). Mining pools and some exchanges may have had the computational resources and access to low-cost infrastructure to benefit from SegWit2X but not those parties i.e. nodes and developers, for whom this fork will have proved to have been a more expensive version of Bitcoin.

The exchanges and wallets that did not sign up to NYA were not obliged to run the software as they did not sign up to it. According to CoinDance, 17.3% of full nodes signalled support for btc-1 (CoinDance (nodes)). In comparison, 83.2% of mining pools signalled their intention to mine on btc-1’s network (CoinDance (blocks)). This showed the disparity of interest between full nodes and miners. However, this statistic may not have taken into account those miners that may not have intended to mine on btc-1 exclusively. Some may have shard-mined on a range of networks: not just btc-1 but Core also.

In closing, I would like to point out that I could not find a copy of the NYA document on the Web. On November 7, I searched “new york agreement bitcoin” on Google and the closest I could find was the Bitcoin Scaling Agreement. However, this Bitcoin Scaling Agreement did not make it clear whether it was the NYA or whether it related to it.

Q: Did the NYA hold its support from May to October 2017?

A: Throughout those five months, the NYA steadily lost support. (Here is a spreadsheet that lists all 56 original NYA signatories.) However, this number immediately gets outweighed by those who signed a counter-document called No2X – more on that below. There was an interesting contrast between the two lists: whereas the No2X list may not be complete, Steven Hay of 99bitcoins.com pointed out that the published list flattered the number of NYA signatories.

Even in October 2017, Hay was still able to gradually whittle down the NYA support to sixteen genuine signatories on the grounds that, of the 56, two were individuals whose influence was no greater than any other Bitcoin user, one startup was no longer involved in Bitcoin, seven of them were subsidiaries of another signatory i.e. double-counting, five had retracted their support for NYA and then thirty had received funding from the DCG. This funding may have been significant if it had come with an obligation to support the NYA.

Even after Mr Belshe’s announcement that had suspended SegWit2X, it was puzzling to see lingering support for NYA (SegWit Party). Blockchain Intelligence Group notes that much of this support may have migrated to Bitcoin Cash. And now (November 20) that SegWit2X is no more, it can be said that there is no point in registering withdrawal from NYA now that the document is a dead letter.

Q: Why did Bitcoin Core regard SegWit2X as an attack on Bitcoin?

A: On October 11, Bitcoin Core issued a statement: SegWit2X “is not supported by the majority of the Bitcoin users and developers and is therefore a contentious hard fork.” It accused the signatories of the NYA of shifting their users to an altcoin that was incompatible with Bitcoin and yet still labelled as BTC (Bitcoin Core). Some exchanges and wallets did propose a name change (see below).

Edan Yago, from Coindesk, wrote on November 8 that the 51% attack was Bitcoin’s supreme weakness. He went on to write that 51% of the network voting for a hard fork is not an attack on the legacy chain. However, should the fork have played out with over 51% supporting SegWit2X, Btc-1’s refusal to offer replay protection would have prevented Core (having become the minority chain) to continue validating blocks. Btc-1’s willingness to allow the resulting chaos to take place was, therefore, an attack on Bitcoin by a cluster of vested interests meeting in New York behind closed doors.

Btc-1 had always refused to offer replay protection. This refusal indicates strongly that, should that 83-odd% of support from miners have become manifest, the legacy chain with SegWit UASF would no longer have been able to confirm its transactions and blocks. SegWit2X would effectively have become the sole Bitcoin blockchain.

Core’s weariness of btc-1’s hurried approach to the hard fork with its lack of consensus is epitomized in this statement: “Even when there is overwhelming consensus, unless in an emergency, a hard fork should have at least a year notice period to give enough time for users to upgrade. This hard fork being adopted by the signatories of this agreement (NYA) achieves none of these things. It is a rushed and hasty upgrade which only has minority community support and has been thoroughly rejected by users and the technical community” (Bitcoin Core).

Q: Will replay protection be implemented?

A: Because btc-1 had asserted SegWit2X as the true version of Bitcoin, it chose not to support replay protection. To support replay protection would have been to admit that Core remained the true chain and that SegWit2X would be a mere fork from it.

Given that btc-1 expected a ‘winner takes all’ outcome, even a minority of surviving Core supporters will have been seen as a defeat.

The exchanges, whether or not they had supported SegWit2X, did show concern about the lack of replay protection in the hard fork.

For more on the issue of replay protection, please see the Cryptocoinsnews article here.

Q: What had the exchanges and wallets been saying about SegWit2X?

A: In the absence of a centralized governance structure that could state which is the “real” version of Bitcoin i.e. which version should be labelled ‘BTC’, we should look to what the market indicates about that “real” version of Bitcoin. So, we look to the exchanges and wallets for those indicators because the activity on those platforms consists of decisions made by informed users.

The likelihood of SegWit2X activation divided the exchanges and wallets between those who rejected SegWit2X and those in favour.

That pro-SegWit2X group then branched into two loose camps that were based around how to redefine Core’s BTC after the fork:

Those that accepted that SegWit2X would become the minority chain and so Core’s bitcoin would continue to be the “main chain” i.e. retain the ‘BTC’ label,
Those that placed the fulfilment of a condition before deciding which chain should be the main chain. Should SegWit2X fulfil the condition more successfully than Core, the ‘BTC’ label would switch to the SegWit2X chain.

Having said this, the exchanges and wallets were unified by whatever was in the best interests of their customer base. Opponents and supporters of SegWit2X, alike, had said that they will protect their customers’ balances from the risk of replay attacks.

Anti-SegWit2X

This cluster nailed its colours to the mast in several ways. Some of them did not sign the NYA and had stated support for Core no matter what, such as the Electrum wallet. Some went on to sign a counter-document called “No2X”. Meanwhile, there were some exchanges that signed neither but gave a vigorous anti-SegWit2X statement of their own.

The exchanges whose name was absent from the NYA were Poloniex, Bithumb, Kraken and Gemini. The exchanges that signed “No2X” were Poloniex, Bitfinex, OKCoin, Kraken, Gemini, Bitmex, LakeBTC and Bitstamp. Two wallets, Green Address and Holy Transaction, also signed this counter-document. No2X was a reaction to the lack of transparency and representation behind NYA. No2X’s meme reads “Agreement? I didn’t sign no stinking Agreement!”

The organizations listed above also made a statement about their anti-SegWit2X position but, curiously, some of the most notable statements had been made by exchanges that had not engaged with either the NYA or No2X. Gatecoin was fully against SegWit2X. In their statement about the hard fork, Gatecoin declared: “We will NOT process any B2X sent to our bitcoin wallet addresses, NOT distribute any B2X to our clients, NOT list any B2X coin on our exchange” (Gatecoin). Gatecoin, as well as Gemini, Bitmex and BitGo, all pointed to SegWit2X’s lack of replay protection as grounds to not support the fork.

Livecoin, one of the top-25 exchanges in the world (at the time of writing) made a broad statement about all non-Core forks. Pointing to Bitcoin Core’s October 11 statement that had warned BTC developers about the contentious nature of any fork that deviates from Core’s software, Livecoin declared: “Our official viewpoint for all BTC forks is based on original Bitcoin developers statement. Everyone who support BTC forks will be blacklisted by developers of the original BTC, that is why we are not planning to list forks” (Livecoin). This statement, though not directly against SegWit2X, had taken a long view about hard forks in general. Livecoin’s long view was that Core’s original chain would prevail post-fork.

Pro-SegWit2X

The position of those exchanges and wallets that supported the SegWit2X fork was more ambiguous than their anti-SegWit2X counterparts. Some exchanges declared their support for the fork by either signing NYA and then saying no more about it, such as BitFlyer, or simply rolling their sleeves up and making their platforms ready for SegWit2X e.g. Bitpanda, BTC.com, BTER, CoinOne and Coinnest.

Unocoin said that, though they supported SegWit2X, they still expected Core to produce the longest chain and so would treat SegWit2X as the minority chain (Unocoin). This was a position that Bitcoin Core had encouraged mobile wallets to take: “A majority of miners have pledged to support the contentious hard fork, therefore the longest chain as seen by most mobile wallets may not be the true block chain” (Bitcoin Core).

So far so good.

However, the greatest ambiguity among the pro-SegWit2X cluster was over how to articulate the main chain post-fork. Does Core’s chain continue to be regarded as the “main chain” or does that status switch to SegWit2X’s chain?

Bitfinex made an unusual statement by saying they would continue to state Core as BTC even if SegWit2X were to produce the greater hash power (Bitfinex).

But some of them questioned whether the original chain would still necessarily produce the longest chain after the fork takes place. So they specified the fulfilment of a condition by which the Core chain and SegWit2X chain would compete for the label of ‘BTC’. These criteria were based on mining factors, such as who produced the longest chain (BTCC), commanded greater hash power (HitBTC), or generated the most accumulated difficulty (GDAX, Blockchain.info, Coinbase, Xapo). Huobi Pro gave no specifics but stated the success of the hard fork as a condition for their label flip.

Some exchanges set up a futures market which issued tokens that represented the incoming SegWit2X coin, along with a token for BTC, and then allowing their traders to determine which coin should be dominant (van Wirdum). Bitfinex, OKCoin, HitBTC, Huobi Pro and BTCC dealt with the SegWit2X coin in this way.

Some exchanges that had signed No2X (which means they opposed SegWit2X, right??), nevertheless, threw the labelling decision to mining factors. Gemini, for instance, pointed to the difficulty metric as a benchmark for the ‘BTC’ label. Bitfinex also relied on mining outcomes but focused their rubric on hashing power.

Q: Is there now any value to SegWit2X?

A: Despite the November 8 suspension announcement, SegWit2X managed to retain some support but in one unexpected area. SegWit2X has a futures price i.e. B2X. B2X had peaked at $1800 per coin on Friday November 3 but, on the announcement, the USD price had plummeted to $160. Between the announcement and the arrival of block 494,782 (datestamped on November 17), the price had held around the $270-$400 region. It goes to show that, even in the Bitcoin space, a futures price does not require the presence of the underlying asset. One can view its current fortunes on this link: SegWit2x [Futures] (B2X).

UPDATE NOVEMBER 20 – However, as far as value to miners and nodes are concerned, it is much reduced. In fact, on November 17, the fork’s activation was more of a splutter than it was a full-scale launch (Higgins). As of November 20, fifty nodes were still running btc-1’s code (Bitnodes) but stuck at block 494,782. A look across at Coin Dance showed that 99 nodes, also on November 20, were still running the software (CoinDance (nodes)). The issue that caused the SegWit2X activation to run aground was an error in the code that prevented the miners from finding a block that exceeded 1Mb. Had there been enough mining support still in place for btc-1, the hashing of a super-1Mb block will have conceived the new SegWit2X chain by shifting SegWit2X-supporting nodes to that new chain. This underwhelming event is somewhat ironic after all of btc-1’s talk about being the true Bitcoin.

The Blockchain Intelligence Group does not offer financial advice, nor does it speculate about the future behaviour of any given cryptocurrency.

Blockchain Intelligence Group’s conclusion

The November 20 update gives us a chance to tie a loose end on our monitoring of this whole episode in Bitcoin’s attempts to resolve its scaling issues. Btc-1 regarded its fork as a replacement chain for Bitcoin Core but without the support of a considerable portion of the Bitcoin ecosystem. Btc-1 nailed their colours to the NYA mast. But, given the lack of transparency and inclusion around the Agreement not to mention the willingness of some signatories to back away from their initial support, the fork was never going to enjoy the consensus that the initial NYA signatory list allowed btc-1 to believe. Also, the fact that many exchanges recognized Core’s legacy chain rejected btc-1’s presumption that their SegWit2X hard fork would seamlessly replace the legacy chain.

Btc-1’s attempt to replace decentralized governance with a communiqué that met the interests of only a section of Bitcoin’s ecosystem was making this fork controversial. But we should go further than that and say that it was not in step with the established governance standards of Bitcoin Core. Indeed, Core’s terse warning to those exchanges and wallets that supported SegWit2X’s hasty and rushed fork, forms our position.

The suspension of SegWit2X will enable those Bitcoin stakeholders that supported the fork to propose alternative strategies to resolve the Bitcoin scaling issue. Blockchain Intelligence Group will be watching these developments with optimism that future projects will be carried out more inclusively.

Appendix

General references

Bitcoin Core. Beware of Bitcoin’s possible incompatibility with some major services https://bitcoin.org/en/alert/2017-10-09-segwit2x-safety

Bitcoin Glossary. Hard Fork, Hard-forking Change. https://bitcoin.org/en/glossary/hard-fork

Bitnodes. https://bitnodes.earn.com/nodes/?page=2&q=Satoshi:1.14.5

CoinDance (blocks). https://coin.dance/blocks

CoinDance (nodes). https://coin.dance/nodes/share

Coindesk. Bitcoin or Bitcoin2x? News & Guides to Navigate November’s Fork. https://www.coindesk.com/bitcoin-bitcoin2x-news-guides-navigate-novembers-fork/

Deschapell, A. Segwit2x Is Doomed to Fail. https://www.coindesk.com/opinion-segwit2x-doomed-fail/

Hay, S. Support for Segwit2x, the New York Agreement, and the Upcoming Bitcoin Fork Explained. https://99bitcoins.com/who-supports-segwit2x-the-new-york-agreement-and-the-upcoming-bitcoin-fork-explained/

Haywood, M. All roads lead to Segwit — Segwit2x, BIP 91 Segsignal and UASF. https://medium.com/@wintercooled/segwit2x-segsignal-and-the-uasf-all-roads-lead-to-segwit-d66fedf7fba

Hertig¹, A. Explainer: What Is SegWit2x and What Does It Mean for Bitcoin? https://www.coindesk.com/explainer-what-is-segwit2x-and-what-does-it-mean-for-bitcoin/

Hertig², A. 2x Called Off: Bitcoin Hard Fork Suspended for Lack of Consensus. https://www.coindesk.com/2x-called-off-bitcoin-hard-fork-suspended-lack-consensus/

Higgins, S. No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code. https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/

jgarzik/bips. Github. https://github.com/jgarzik/bips/blob/2015_2mb_blocksize/bip-0102.mediawiki

Medium. Bitcoin Scaling Agreement at Consensus 2017. https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

No2X http://nob2x.org/

Rizzo, P. Understanding Segwit2x: Why Bitcoin’s Next Fork Might Not Mean Free Money. https://www.coindesk.com/understanding-segwit2x-bitcoins-next-fork-might-different/

SegWit2Mb proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html

SegWit2X Final Steps https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

SegWit2x [Futures] (B2X). https://coinmarketcap.com/currencies/segwit2x/

Song, J. Segwit2x: What you need to know about the 2x Hard Fork. https://medium.com/@jimmysong/segwit2x-what-you-need-to-know-about-the-2mb-hard-fork-27749e1544ce

Van Wirdum, A. To B2X or Not to B2X: How Exchanges Will List the SegWit2x Coin. https://bitcoinmagazine.com/articles/b2x-or-not-b2x-how-exchanges-will-list-segwit2x-coin/

Wilmoth, J. Segwit2x Dev. Jeff Garzik Expelled from Bitcoin Core Repository. https://www.cryptocoinsnews.com/segwit2x-dev-jeff-garzik-expelled-from-bitcoin-core-repository/

wintercooled. An Attempt at Explaining SegWit2X and BIP 148 https://www.reddit.com/r/Bitcoin/comments/6hmof7/an_attempt_at_explaining_segwit2x_and_bip_148/

BIPs glossary

BIP – Bitcoin Improvement Proposal

BIP9 – allows multiple forks to be carried out simultaneously. https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

BIP91 – the UASF deadline of August 1 for SegWit activation. https://bitcoinmagazine.com/articles/bip-91-has-activated-heres-what-means-and-what-it-does-not/

BIP102 – proposal for SegWit with 2Mb block sizes i.e. SegWit2X. https://medium.com/@jimmysong/segwit2x-what-you-need-to-know-about-the-2mb-hard-fork-27749e1544ce

https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki

BIP141 – the definition of SegWit.

BIP148 – “a UASF that is designed to cause the existing SegWit MASF deployment to cause activation in all existing SegWit capable node software” https://github.com/OPUASF/UASF

Exchanges’ and wallets’ positions on the fork

Bitfinex – https://www.bitfinex.com/posts/223

BitGo – https://github.com/btc1/bitcoin/commit/a3c41256984bf11d95a560ae89c0fcbadfbe73dc#commitcomment-24780004

Bitmex – https://blog.bitmex.com/policy-on-bitcoin-hard-forks-update/

Blockchain.info – https://blog.blockchain.com/2017/10/12/bitcoin-hardfork-blockchain-wallet/

BTC.com – https://blog.btc.com/btc-com-wallet-and-the-segwit2x-hard-fork-10572d8f43e5

BTCC – https://www.btcc.com/fork/?utm_source=sms&utm_campaign=fork

BTER – http://queenwiki.com/blog/2017/10/where-you-should-store-bitcoins-before-bitcoingold-btg-segwit2x-b2x-btc1-hard-fork/

Coinbase – https://support.coinbase.com/customer/portal/articles/2892985-segwit-2x-faq

Coinnest – https://www.coinnest.co.kr/gonggao/94.html

CoinOne – https://coinone.co.kr/notice/posts/279/?page=1

Coinsquare – https://www.facebook.com/pg/coinsquare.io/posts/?ref=page_internal