Oddbean

AFAIK: uses Schnorr signatures instead of ECDSA addresses start with bc1p, not bc1q like V0 segwit addresses has more abilities regarding multisig...before TR, when spending from multisig as P2SH or P2WSH, had to include pubkeys of all signers, whereas TR only has to reveal aggregate pubkeys & signatures. this may or may not involve cross input signature aggregation, which I'm unsure of current use/availability.

All of the benefits of TR that were touted prior to its activation have not yet been realized AFAIC...unless talking about shitcoinery on BTC. With segwit, it was activated in Aug 2017, and wallets had incorporated it before year end...first the "wrapped" segwit addresses, embedded in P2SH, then native segwit in early 2018. TR is a different story. Activated mid 2021, certain wallets here and there began rolling it out, as single sig. The TR advantages of transactional privacy (CISA) and decaying multisig (ie starts as 3 of 5, then in a year becomes 2 of 5, then 1 of 5) to me have value only when applied to multisig scenarios, and have yet to be incorporated into wallets. Single sig TR isn't much of an improvement over single sig P2WPKH...it was way more meaningful to update from legacy to segwit addresses, however TR, as it stands now, doesn't offer near the benefit to change one's setup.

yes sir, or more focusing attention on TR anyway. No devs on my payroll though, unfortunately. I have no idea how the coding of segwit wallet integrations compares with TR...for all I know, TR may be way more difficult. As a humble user, I will run the best wallet and node software that's available. Doing P2WSH multisig on Electrum, Spectre, Caravan, Nunchuk and Sparrow has been available for years, and is amazing as-is, which I'm thankful for.

The taproot soft fork included schnorr signatures as already noted. Taproot itself is the idea that an output can be unlocked (spent) *either* by providing a signature on the public key *or* by executing a Script *and* proving that the script was in a merkle tree whose root was embedded in the pubkey. One nice feature is that if you just sign on the pubkey, the outside world will never know about the (potentially thousands+) scripts that are embedded. Also note that when you use a script to spend, you won't have to expose all the others that were embedded. (See MAST for more on that part).

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.

that could be...the 2of2 multisig of lightning channels is abstracted away from me, unlike wallets where I'm setting up the scripts and signing manually. I bet if your node software that's putting together your channel opens and closes used TR, they could make channel open/close txns indistinguishable from a single sig TR spend.