As of today, over 80 percent of miners (by hash power) are including the letters “NYA” in the blocks they mine. This follows the publication of letters (translation) in which a group of Chinese Bitcoin companies — notably including most mining pool operators — announced that they would signal support for “the New York Agreement.”
The New York Agreement
The New York Agreement, sometimes referred to as “the Silbert Accord” or “SegWit2x,” is a scaling agreement forged within a significant group of international Bitcoin companies and published just before the Consensus 2017 conference in New York last May. Based on this agreement, a fork of the Bitcoin Core software client is being developed under the name “BTC1.” BTC1 developer Jeff Garzik announced the alpha release of this software last week.
While technical specifics for BTC1 are still being worked out, it seems more or less certain that rollout of the New York Agreement essentially consists of two stages.
The first stage regards deployment of Segregated Witness (SegWit), the backwards compatible protocol upgrade originally proposed by the Bitcoin Core development team. With 80 percent has power support, BTC1 should actually trigger activation of the SegWit implementation embedded in Bitcoin Core clients and should also be compatible with BIP148 clients as long as activation happens before August 1st. With BTC1’s “official” release date set for July 21st, this should be possible.
The second stage concerns the deployment of the hard fork itself, which is not backwards compatible with older Bitcoin clients. This hard fork would double Bitcoin’s “base block size limit” to two megabytes, which combined with the block size limit increase brought by Segregated Witness should make for a total maximum of eight megabytes of block space. This is scheduled for exactly three months after activation of the first stage. So if the “BIP148 deadline” of August 1st is met, the second stage should go into effect before November 1, 2017.
Through letters published shortly after the announcement of the BTC1 alpha software, Chinese mining pool operators confirmed their intent to honor the New York Agreement. Additionally, they announced to include the letters “NYA” in their “coinbase strings.” That’s what we’ve been seeing today.
So what does this “NYA” string actually mean?
Signaling and Signaling
For each block miners mine, they get to send themselves one transaction that includes brand new bitcoins. This is called the “coinbase transaction.” (Not to be confused with the company “Coinbase.”) Like all transactions, this transaction can include a little bit of extra data that actually has nothing to do with the transaction itself. This is what miners sometimes use to “signal” information to the rest of the world.
Broadly speaking, there are really two types of “signaling.”
The first type is signaling support. This requires that actual Bitcoin software has been written to monitor the signals and, once these signals reach some kind of threshold, something actually activates in all of these Bitcoin clients. For example, code for the Segregated Witness soft fork as included in Bitcoin Core clients, will enforce the Segregated Witness rules once 95 percent of newly mined blocks include a specific piece of data in the coinbase strings. If that happens, all these nodes will actually reject transactions and blocks that break the SegWit rules.
The second type is signaling intent. As opposed to signaling support, signaling intent doesn’t actually do anything on a technical level. Rather, it’s literally miners sending a message to the world, which has in the past, for example, been used to state a preference for a potential scaling solution. (While miners can also do this through letters or blog posts, coinbase signaling cannot possibly be faked, so it’s a bit more reliable.)
The recent “NYA” signaling is of the second type. It doesn’t actually trigger any code, but it instead lets the world know that the miners intend to support the New York Agreement. Specifically, they indicate that they will be signaling support for the New York Agreement once the BTC1 client is officially released: presumably by July 21st, or at least in time for August 1st. (Though earlier is possible, too.)
But notably, most miners are not signaling support yet — even though it’d be possible to activate SegWit through existing activation methods implemented in Bitcoin Core or BIP148 clients straight away.
The technical specifics for BTC1 are still being worked out, and that’s especially true for the hard fork part of it.
Right now, it seems that signaling support for SegWit2x should also trigger the hard fork code to be implemented in all BTC1 clients — but only three months down the road. So if SegWit activates before August, BTC1 users should start accepting, and potentially mining, “base blocks” larger than one megabyte by November. In fact, the first base block on the BTC1-chain, the “cut-off block,” will likely even have to be bigger than one megabyte.
But it’s far from certain that most non-BTC1 clients will follow this chain. Most notably, the odds of Bitcoin Core — currently the dominant client on the network — adopting the SegWit2x hard fork seem slim. None of the regular Bitcoin Core contributors were part of the New York Agreement, none of them support it, and contentious hard forks have so far not been implemented by the Bitcoin Core development team, more or less as a matter of policy. And even if the Bitcoin Core development team does merge the hard fork code, it would require all users to upgrade to this new version, which is probably even less likely.
As such, if BTC1 users — such as the New York Agreement signatories — follow through and actually run the software three months after the soft fork, there will likely be a split in the Bitcoin network. Some nodes will follow a chain with bigger blocks, some will stick to smaller blocks, and there would effectively be two different coins with a shared history.
But it is too soon to say how such a scenario will play out exactly — or if it will happen in the first place. Three months is a long time in Bitcoin terms and, in the end, neither written agreements, nor signaling intent are binding on a Bitcoin protocol level.