I pinged Casa and Unchained Capital folks to chime in ...

On behalf of Unchained: we've been discussing internally how best to implement multisig on Taproot and have a final meeting scheduled for mid-December. I'll report back and chime in with our plans then.

Given the interactivity requirements of other tapscript constructions, I expect Casa will move forward with OP_CHECKSIGADD

Given the interactivity requirements of other tapscript constructions, I expect Casa will move forward with OP_CHECKSIGADD

@jlopp, would that be using a single OP_CHECKSIGADD-based k-of-n script or a k-of-k script for every combination of pubkeys? The advantages and disadvantages of the two are discussed in https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-5. If I am not mistaken, Casa uses 2-of-3 multisig and 3-of-5 multisig. On average the single OP_CHECKSIGADD-based k-of-n script is better in both cases in terms of the size of the resulting witnesses. But note the words "on average". If you optimize the Merkle tree for the happy path / typical use case, then the k-of-k script for every combination may be more optimal in terms of witness size for the happy path.

Single OP_CHECKSIGADD-based k-of-n script, otherwise we'd have to change the UX to force users to either preselect which keys they're signing with, or have them sign multiple leaves of the tapscript.

Chiming in again after our meeting: we're hoping to support both of the two OP_CHECKSIGADD based approaches mentioned in BIP 342, with a preference for the k-of-k script (though we anticipate making use of the k-of-n script as well).

Any update?

Hi @prusnak,

Any update on this?

Added the basic OP_CHECKSIGADD funtionality in #4159

I was tagged here but I don't see the comment.

It was deleted just now after my comment.

there was nothing in the comment, except for the tag - i considered it a spam, because it added no value to the discussion, so I deleted it