Hi all, lately there has been some news about the upcoming May upgrade and BCH getting Schnorr signatures, and a bit of bragging that this is happening before 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.
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 ECDSA (Amaury 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.
Some technical background: 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 by now 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, "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.
[link] [comments]
source https://www.reddit.com/r/btc/comments/b341q5/why_bch_is_getting_schnorr_signatures_before_btc/
No comments:
Post a Comment