Oddbean

I should note the idea of the "taproot assumption" which illustrates why Schnorr really helps taproot specifically: schnorr allows a multisig which looks exactly like a single sig. This means that N parties can use the scripts part as above to have complex contracts between each other, but the taproot assumption is that it'll always be valuable to have one special contract clause: "everyone agrees", and that is handled by a multisig on the pubkey *which to the outside world looks exactly like single sig signing*, retaining maximum privacy.

Excellent summary. At a low level I think it's also important to point out that Schnorr sigs allow us to remove multisignature complexity from bitcoin consensus. ECDSA multisignature operations are performed in bitcoin script which reduces privacy and increases blockspace usage. Taproot multisig all happens off-chain, which brings huge benefits that are still being explored with novel protocols.

Nit: taproot also has script multisig (op_checksigadd , a new multisig opcode), and it's useful separately to musig or frost etc. Good point about outside consensus, and more generally schnorr is much more amenable to sophisticated cryptographic techniques than ecdsa was.

Interesting point. I think taproot is not actually an improvement in terms of data availability for the most common multisig setups. Most ECDSA multisig addresses hash the script so you need to keep it safe off-chain. If you lose your wallet descriptor (which contains the script) you get rekt because you can't spend the UTXO, even if you have the right signatures. This is why you always want to store the descriptor in physical format along with each private key. You don't know which key will get got so you need redundant copies. A cool project I don't have time for would be to encrypt your wallet descriptor using your master key and store it as an inscription recoverable using only that private key. You still have to pick some kind of standardized wallet descriptor to go from master key to that first address, but this could just be a bip or some other standardized protocol. It would be fun and educational to build but limited impact.

So is this what allows clients like Sparrow or Nunchuck to use native segwit address types when creating a multi-sig while Blockstream Green still uses segwit ("3") for it's multi-sig? I've been trying to understand this.