Not all heroes wear capes

You’re overestimating the blockspace savings from CISA. A P2TR keypath input weighs 57.5 vB. 41 vB of that is from data that every input still needs: outpoint (36 vB), nSequence (4 vB), scriptSig length indicator (1 vB). The witness stack only contributes 66 WU.
So, assuming the CISA-compatible output had the same structure (which is reasonable) and we could just drop the whole witness stack for all but one input, the average vsize per input would asymptotically converge from 57.5 vB (one input tx) towards 41 vB as inputs grow in count on the transaction. The maximum savings would therefore be up to 28.7% of the input weight of the transaction, outputs and header remain unaffected. It’s not clear to me how that would get anyone 70–90% fee reductions.

Hard-forking in a manner as described would invalidate any pre-signed transactions created for future broadcast. For example that would destroy funds held in time-locked vaults based on pre-signed transactions for which the keys have been destroyed.

Great work of @supertestnet https://stacker.news/items/222527

Worth commenting that I'm not sure if Taproot threshold signatures will have a lower onchain footprint, like Taproot aggregate signatures do (I can't read the FROST paper, to be honest).

They do have a lower footprint. Frost signatures are the same size as musig2 signatures, which are themselves the same size as "regular" schnorr signatures. That is, they are all 64 bytes.

One of the difficulties with using frost is that it doesn't support "bringing your own key." If 3 people want to generate a 2 of 3 "frost multisig" together, they cannot each independently generate a keypair and then "combine" their pubkeys together. They have to come together to generate a keypair together in a kind of "key generation ceremony." The ceremony involves doing some math that allows every keyholder to ensure everyone followed the protocol properly so that they all know for sure they'll be able to sign later.

Not only is frost not standardized yet, there is also not yet any standardized way to do the key generation ceremony. And if companies like Unchained and Hodlhodl want to support this new form of multisig, some of them will probably have to change how they do business. Any of them that ask their users to provide 2 keys and let the company provide the third can't really do that anymore. They'll have to participate in a key generation ceremony that involves interacting with both users to generate a key and do the aforementioned math to ensure it's safe.

It's all quite involved and I don't expect much fruit to come out of it anytime soon. "Regular" multisig works well so I don't see much motivation to code up the fancier version that taproot enabled. Consequently the number of people working on it is small, and progress is slow.

Yes, this is just demand for blockspace driving up the price. Some of this demand stems from inscription transactions, in particular BRC20 transactions. The BRC20 activity increased recently again. Other than that, one issue that exacerbates the situation that blockspace production is essentially fixed, so whenever blockspace demand exceeds production, the users that are aiming for prompt confirmation tend to get into bidding wars which can quickly drive up the feerate.

I’ve written a bit more about the general subject on Bitcoin Stack Exchange: Can you explain some of the dynamics that drive the variations in mempool depth?

Day 268 of snailposting everyday 'til BTC hits $100k.

...and 68 push-ups. (30 - 30 - 8)

__@_'-'