{"id":23175,"date":"2017-09-22T18:11:02","date_gmt":"2017-09-22T18:11:02","guid":{"rendered":"http:\/\/ci027cfe6520042697"},"modified":"2017-09-22T18:11:02","modified_gmt":"2017-09-22T18:11:02","slug":"segwit2x-and-case-strong-replay-protection-and-why-its-controversial","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/culture\/segwit2x-and-case-strong-replay-protection-and-why-its-controversial","title":{"rendered":"SegWit2X and the Case for Strong Replay Protection (And Why It’s Controversial)"},"content":{"rendered":"
<\/div>
<\/figure>\n

Come November, the remaining signatories of the \u201cNew York Agreement<\/a>\u201d (NYA) plan to deploy the \u201cSegWit2X\u201d hard fork to double Bitcoin\u2019s block weight limit, allowing for up to 8 megabytes of block space. Since not<\/a> everyone<\/a> supports this hard fork, this could well \u201csplit\u201d the Bitcoin network into two incompatible blockchains and currencies, not unlike Bitcoin and Bitcoin Cash (Bcash) did two months ago.<\/p>\n

But this NYA hard fork is controversial and not only because it lacks consensus. It\u2019s also controversial because of design choices made by the development team behind BTC1<\/a>, the software client associated with the New York Agreement. Perhaps most importantly, this development team, led by Bloq<\/a> CEO Jeff Garzik, has so far refused to implement replay protection, a measure that Bcash did take. Partly for this reason, at least one NYA signatory \u2014 Wayniloans<\/a> \u2014 has backed out<\/a> of the agreement.<\/p>\n

So what is replay protection, why should BTC1 implement it \u2026 and why doesn\u2019t it?<\/p>\n

What Is Replay Protection? (And What Are Replay Attacks?)<\/h3>\n

Bitcoin could see another \u201csplit\u201d by November. (It\u2019s arguably more accurate to consider the \u201csplitting\u201d nodes and miners as an entirely new cryptocurrency with a new blockchain and token \u2014 not an actual split of Bitcoin itself.) For the purpose of this article, we\u2019ll refer to the blockchain and currency that follows the current Bitcoin protocol as \u201cLegacy Bitcoin\u201d and \u201cBTC.\u201d The blockchain and currency that follows the New York Agreement hard fork is referred to as \u201cSegWit2X\u201d and \u201cB2X.\u201d<\/p>\n

If this split happens, the two blockchains will be identical. All past transactions and (therefore) \u201cbalances\u201d are copied from the Legacy Bitcoin blockchain onto the SegWit2X blockchain. Everyone who owns BTC will own a corresponding amount of B2X.<\/p>\n

Without replay protection, new transactions will be equally valid on both chains as well. This means that these transactions can be copied or \u201creplayed,\u201d from one chain to the other \u2014 in other words, for them to happen on both. This is called a \u201creplay attack.\u201d<\/p>\n

So, let\u2019s say Alice holds BTC at the time of split, which means she also owns B2X after the split. Then, after the split, she wants to send BTC to Bob. So, she creates a transaction that spends BTC from one of her Legacy Bitcoin addresses to one of Bob\u2019s Legacy Bitcoin addresses. She then transmits this transaction over the Legacy Bitcoin network for a Legacy Bitcoin miner to pick it up and include in a Legacy Bitcoin block. The payment is confirmed; all is good.<\/p>\n

But this very same transaction is perfectly valid on the SegWit2X blockchain. Anyone \u2014 including Bob \u2014 can take Alice’s Legacy Bitcoin transaction and also transmit it over the SegWit2X network for a miner to include in a SegWit2X block. (This can even happen by accident quite easily.) If this payment is also confirmed, Alice has inadvertently sent Bob not only BTC but also an equal amount of B2X.<\/p>\n

And, of course, all of this is true in reverse as well. If Alice sends B2X to Bob, she might accidentally send him BTC as well. A lack of replay protection, therefore, is a problem for users of both chains. No one wants to accidentally send any money \u2014 not even if it was \u201cfree money.\u201d<\/p>\n

Technically, there are ways to \u201csplit\u201d coins on both chains to ensure they can only be spent on one chain. This would, for example, require newly mined coins to be mixed into a transaction. Tiime-locks can also offer solutions. But this takes effort and is not easy, especially for average users \u2014 not to mention that many average users may not even know what\u2019s going on in the first place.<\/p>\n

To avoid this kind of hassle, at least one side of the split could add a protocol rule to ensure that new transactions are valid on one chain but not the other. This is called replay protection.<\/p>\n

Why Should BTC1 Implement Replay Protection? (And Why Not Bitcoin Core?)<\/h3>\n

In case of a split, at least one side must implement replay protection. But many \u2014 Bitcoin Core developers and others \u2014 believe there\u2019s only one viable option. It\u2019s the splitting party \u2014 in this case BTC1 \u2014 that should do it.<\/p>\n

There are several arguments for this.<\/p>\n

First of all, it makes the most sense for BTC1 to implement replay protection because that requires the least effort. BTC1 is a new client that\u2019s already implementing new protocol rules anyway, and it\u2019s not very widely deployed yet. It would be relatively easy for BTC1 to include replay protection.<\/p>\n

Meanwhile, it would not be sufficient for Bitcoin Core to implement replay protection on its own. While it is dominant, and even considered by some to be the protocol-defining reference implementation, Bitcoin Core is not the only Bitcoin implementation on the network. Bitcoin Knots, Bcoin, Libbitcoin and other alternative clients would all have to implement replay protection, too. (And that\u2019s not even taking non-full node clients into account.)<\/p>\n

But even more importantly, the reality of the current situation is that all deployed Bitcoin nodes do not have replay protection implemented. And logically, they can\u2019t: Some of these nodes even predate the New York Agreement. So even if Bitcoin Core and other implementations were to implement replay protection in new releases of their software, it wouldn\u2019t suffice. All users must then also update to this new version within about two months: a very short period of time for a network-wide upgrade.<\/p>\n

If only some of the nodes on the network upgrade to these new releases, Bitcoin could actually split in three: Legacy Bitcoin, SegWit2X and \u201cReplay Protected Bitcoin.\u201d Needless to say, this three-way split would probably make the problem worse \u2014 not better.<\/p>\n

Lastly, there is a bit of a philosophical argument. Anyone who wants to adopt new protocol rules, so the argument goes, has the responsibility to split off as safely as possible. This responsibility should not fall on those who want to keep using the existing protocol: They should be free to keep using the protocol as-is.<\/p>\n

Many developers \u2014 including RSK<\/a> founder Sergio Lerner<\/a> who drafted the SegWit2Mb<\/a> proposal on which SegWit2X is based \u2014 have argued that BTC1 should implement replay protection. In fact, many developers think that any hard fork, even a hard fork that appears entirely uncontroversial, should implement replay protection.<\/p>\n

But so far, the BTC1 development team will only consider<\/a> optional replay protection.<\/p>\n

What\u2019s Wrong With Optional Replay Protection?<\/h3>\n

Implementing optional replay protection, as proposed<\/a> by former Bitcoin developer Gavin Andresen, for example, is currently on the table<\/a> for BTC1.<\/p>\n

In short, this type of optional replay protection would make certain specially crafted (\u201cOP_RETURN\u201d) Legacy Bitcoin transactions invalid on the SegWit2X chain. Anyone who\u2019d want to split their coins could spend their BTC with such a transaction. These transactions should then confirm on the Legacy Bitcoin blockchain but not on the SegWit2X chain. This effectively splits the coins into different addresses (\u201coutputs\u201d) on both chains.<\/p>\n

Such optional replay protection is probably better than nothing at all, but it\u2019s still not a definitive solution.<\/p>\n

One problem is that the Legacy Bitcoin blockchain would have to include all these OP_RETURN transactions. This would probably result in more transactions on the network and would require extra data for each transaction. All this data must be transmitted, verified and (at least temporarily) stored by all Legacy Bitcoin nodes. It presents a burden to the Legacy Bitcoin network.<\/p>\n

But more importantly, it would probably still not be very easy to utilize this option. It might suffice for professional users \u2014 exchanges, wallet providers and other service providers \u2014 as well as tech-savvy individual users. But these are generally also the types of users that would be able to split their coins even without replay protection. Average users, if they are even aware of what\u2019s going on, would probably find it much more difficult to utilize optional replay protection.<\/p>\n

Optional replay protection, therefore, offers help to those who need it least and does little for those who need it most.<\/p>\n

Does the NYA Preclude Replay Protection?<\/h3>\n

While it\u2019s unclear what was (or is) discussed behind closed doors, the New York Agreement seems to be a very minimal agreement. Published on May 23, 2017, it really only consists of two concrete points:<\/p>\n