search

w3f / schnorrkel

Schnorr VRFs and signatures on the Ristretto group
BSD 3-Clause "New" or "Revised" License
309 stars 93 forks source link

N of M multi sig #44

Closed wooparadog closed 4 years ago

wooparadog commented 5 years ago

Hi,

Don't know if it's a duplicate of #11 , but is there a way to create a n/m multi-sign address for substrate(consequently polkadot)?

The test in mul.rs requires all singers present, but for security's sake (rougue singer/lost private key), it's better to have a n of m mechanism.

Thanks in advance.

burdges commented 5 years ago

I'd place this under #11 yes. Related: https://github.com/w3f/bls/issues/6

I'd happily accept PRs adding this to musig.rs, but not doing it myself anytime soon. It's not so hard, but we've no notion of "signer set" here, so that's logically the first part. We discussed this with another group, but they might be kinda busy right now.

A priori, I'd favor accountable threshold multi-signatures via bitfields ala https://github.com/w3f/bls/blob/master/src/bit.rs over true untraceable threshold jazz. At least one example of a signer set abstraction exists there.

I've no idea if the interface should abstract both accountable and non-accountable versions. And I haven't looked into DKGs in ages, so never really considered the design choices.

Among the true threshold designs, PVSS which sounds generally useful and might play some role in the DKG. It's straightforward to implement PVSS from the batched DLEQ proofs in vrf.rs. I'll forward this thread to someone who knows more about DKGs than me.

We should ideally resolve #6 and #15 before spending much serious effort here because the three round trips design kinda sucks and the design decisions there impact this of course. We're making progress on those topics.

burdges commented 5 years ago

In the short term, there is one issue here: How should we delinearize keys?

We delinearize based on the current signer set in MuSig currently. In BLS otoh, we delinearize based on the candidate signer set, which permits storing the delinearized keys as an optimization. I did not consider this optimization relevant for an accounts oriented scheme, but maybe worth supporting, and not too hard to support.

burdges commented 5 years ago

interesting: https://medium.com/@amanladia1/zerowallet-a-zkp-based-wallet-authentication-mechanism-9871dcca0a01

burdges commented 4 years ago

I'll close this as a duplicate of #11