Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

N of M multi sig #44

Closed
wooparadog opened this issue Aug 8, 2019 · 4 comments
Closed

N of M multi sig #44

wooparadog opened this issue Aug 8, 2019 · 4 comments

Comments

@wooparadog
Copy link

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
Copy link
Collaborator

burdges commented Aug 8, 2019

I'd place this under #11 yes. Related: w3f/bls#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
Copy link
Collaborator

burdges commented Aug 9, 2019

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
Copy link
Collaborator

burdges commented Aug 9, 2019

@burdges
Copy link
Collaborator

burdges commented Jan 12, 2020

I'll close this as a duplicate of #11

@burdges burdges closed this as completed Jan 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants