Good morning Mark,

> The idea is simple: instead of requiring that the final parameter on the 
> stack be zero, require instead that it be a minimally-encoded bitmap 
> specifying which keys are used, or alternatively, which are not used and must 
> therefore be skipped. Before attempting validation, ensure for a k-of-n 
> threshold only k bits are set in the bitfield indicating the used pubkeys (or 
> n-k bits set indicating the keys to skip). The updated CHECKMULTISIG 
> algorithm is as follows: when attempting to validate a signature with a 
> pubkey, first check the associated bit in the bitfield to see if the pubkey 
> is used. If the bitfield indicates that the pubkey is NOT used, then skip it 
> without even attempting validation. The only signature validations which are 
> attempted are those which the bitfield indicates ought to pass. This is a 
> soft-fork as any validator operating under the original rules (which ignore 
> the “dummy” bitfield) would still arrive at the correct pubkey-signature 
> mapping through trial and error.

That certainly seems like a lost optimization opportunity.

Though if the NULLDATA requirement is already a consensus rule then this is no 
longer a softfork, existing validators would explicitly check it is zero?

> One could also argue that there is no need for explicit k-of-n thresholds now 
> that we have Schnorr signatures, as MuSig-like key aggregation schemes can be 
> used instead. In many cases this is true, and doing key aggregation can 
> result in smaller scripts with more private spend pathways. However there 
> remain many use cases where for whatever reason interactive signing is not 
> possible, due to signatures being pre-calculated and shared with third 
> parties, for example, and therefore explicit thresholds must be used instead. 
> For such applications a batch-validation friendly CHECKMULTISIG would be 
> useful.

As I understand it, MuSig aggregation works on n-of-n only.

There is an alternative named FROST recently, that supports k-of-n, however, 
MuSig aggregation works on pre-existing keypairs, and if you know the public 
keys, you can aggregate the public keys without requiring participation with 
the privkey owners.

For FROST, there is a Verifiable Secret Sharing process which requires 
participation of the n signer set.
My understanding is that it cannot use *just* pre-existing keys, the privkey 
owners will, after the setup ritual, need to store additional data (tweaks to 
apply on their key depending on who the k are, if my vague understanding is 
accurate).
The requirement of having a setup ritual (which does not require trust but does 
require saving extra data) to implement k-of-n for k < n is another reason some 
protocol or other might want to use explicit `OP_CHECKMULTISIG`.

(I do have to warn that my knowledge of FROST is hazy at best and the above 
might be wildly inaccurate.)

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to