TL;DR: Lately there has been some news about the upcoming May upgrade and Bitcoin Cash (BCH) getting Schnorr signatures, and a bit of bragging that this is happening before Bitcoin Core (BTC). Both BCH and BTC have been planning this for a long time. BTC has many more people working on it, so why is BCH getting there first? The short answer is: it is so much easier and simpler to change things with hard forks.
Schnorr Signatures on Bitcoin Cash Before BTC Due to Hard Forks
Since December, I’ve been leading the charge on trying to get Schnorr signatures added to BCH. Much discussion was had, and implementation work on the ABC codebase was finished by their Feb 15 feature freeze date. Everything was green for activation, so it went through.
In the end, it’s a simple change: add some the mathematical code that lets you verify Schnorr signatures, which is straight-forward compared to Elliptic Curve Digital Signature Algorithm or ECDSA (Amaury Séchet had this code ready to go); then, upgrade the opcodes (like OP_CHECKSIG) to optionally accept Schnorr signatures in place of ECDSA. That’s it.
This code is very simple, though the process took some significant effort due to the need for review, refactoring existing code, and creating extensive tests to ABC’s standards. Such a simple thing cannot be done on BTC. With the restriction to soft forks, one cannot be so direct. To make things worse, you cannot just think about upgrading one feature at a time.
Segwit was designed to handle upgrades through a versioning system. So far, only Segwit v0 is active. You can send coins to a Segwit v1 address, however those coins will be ‘anyone-can-spend’ much like segwit v0 coins are on BCH. The Segwit upgrade process (another soft fork) will impose a restriction on those v1 segwit addresses, removing that anyone-can-spend property. This mechanism is highly flexible, and many, many things are possible to introduce in Segwit v1.
Schnorr signatures are almost certainly slated for the Segwit v1 soft fork, and I’m sure the BTC developers by now have a clear plan for exactly how that will look. So why hasn’t it happened yet? From what I can tell, as an external observer, the main problem is that Schnorr signatures are not the only thing that the protocol developers want to introduce in v1. They want not just basic Schnorr signatures, but also: cross-input Schnorr aggregation, Taproot or something like it, SIGHASH_NOINPUT, and various other miscellaneous improvements. And to quote Pieter Wuille (see video embed, above), “There are incentives to do everything at once,” both for anonymity reasons and technical reasons.
On BCH, our introduction of the most-basic Schnorr signatures hasn’t stopped any of these other ‘cool’ features from happening later down the road. We can have cross-input aggregation, Taproot, SIGHASH_NOINPUT, and so on, if that is really desired; they are just a hard fork away, or maybe they won’t happen. We don’t need to hold back that very basic first step, waiting until all the more complex elaborations have been perfectly engineered.
CONTINUE THE SPICE and check out our piping hot VIDEOS. Our podcast, The CoinSpice Podcast, has amazing guests. Follow CoinSpice on Twitter. Join our Telegram feed to make sure you never miss a post. Drop some BCH at the merch shop — we’ve got some spicy shirts for men and women. Don’t forget to help spread the word about CoinSpice on social media.