This is going to be a massive foundational achievement to continue building on into the future.
Some who have been here a while might find this ironic, but the first mention of Schnorr signatures that I’m aware of was actually from former Bitcoin Core developer turned enterprise blockchain builder Mike Hearn.
Adam Back was discussing naive schemes to do a multisig addresses that looked like a singlesig ones back in 2014, utilizing Schnorr signatures.
Since pretty near the very beginning of Bitcoin, most developers actively involved in Bitcoin Core have wanted Schnorr signatures, and there has always been a pretty solid consensus on their superiority to ECDSA signatures.
Merkelized Abstract Syntax Trees , the Taproot half of this upcoming Taproot upgrade, has a similar long-standing history.
His key insight was that in any contract case between multiple participants he could think of, there was an “optimal outcome” where the contract could be settled by everyone just signing the appropriate outcome instead of enforcing the outcome with more advanced scripts and transactions.
From this point on, it was just a lot of small detail refining at the implementation level, some review period, and then the long drawn out battle over activation mechanisms. That leads us to now, just shy of activation.
This is both a direct benefit to the person using Schnorr who will pay less in fees than an ECDSA user, but it’s also a direct benefit to people not using Schnorr by requiring slightly less data be stored in the blockchain to process and validate someone else’s Schnorr signatures.
One of the nice properties of Schnorr, the linearity of the math behind it, also allows for a nice property you want in Bitcoin data: batch validation.
Schnorr signatures can be all batched together and validated mathematically at once, kind of like smashing them together and doing one math operation instead of a bunch of individual ones.
Every multisig address has to explicitly reveal all of the individual public keys involved in a multisig script at spending time, and a signature has to be provided for every key involved in the spending process.
With Schnorr/MuSig, things will be compressed into a single signature for the single combined public key, meaning spending multisig UTXOs using MuSig will become much cheaper as it’s pushing less data to the blockchain.
This is possible with ECDSA, but because of the math being non-linear compared to Schnorr, it’s relatively complicated and there are a lot of security concerns to consider in implementing it.
Because of Schnorr’s linear properties though, an adapter signature is as simple as taking a single .
Tweaking works because of Schnorr’s linear properties — when you “tweak” a public key with a Merkle root , then you can simply add the Merkle root to the original private key and generate the spending key for the new tweaked public key.
That means a miner can mine a transaction bigger than 100 kilobytes, but by default, no one’s node on the network will relay a transaction bigger than that to the miner in the first place.
Instead of the total size of all the ways you can spend the UTXO being restricted to the transaction size limit, you only have to make sure that any single way you can spend a Taproot UTXO respects this limitation.
This two-fold process provides plausible deniability for other parties involved in different spending branches you construct as to their involvement in that UTXO, as well as protects them from a thief or attacker pre-emptively targeting them knowing they have some degree of control over their target’s UTXOs.
When Segregated Witness was implemented, it created the new “witness” section of a transaction where signature data was moved to.
This not only allows the scripts buried in MAST to upgrade without using new OP_CODEs on the base layer, but also without having to upgrade witness versions either! So Taproot was designed to be as efficient as possible to upgrade in the future without limiting other unrelated upgrades to the protocol.
To start, all of the non-cooperative clauses in a Lightning channel such as penalty keys, or timelocks to allow them to be used, can be buried under a MAST with Taproot.
Imagine a Taproot tree structured so that after six months of you not moving your money, your entire family can come together and spend the UTXO however they want.
Then, six months after that, everyone minus two people can spend it.
It really is a win in so many ways for the scalability and utility of the Bitcoin protocol that it is hard to convey because of how subtle and “un-sexy” some of them are.