5

I've read through the docs here and here and would like to know a little bit more about how multisigs can work in practice.

I would like to build a multisig with a set of unchanging parties, and ideally I would like to be able to derive a set of "child accounts" for this multisig, such that transactions can be sent from any of these child accounts by the same set of parties.

An example usecase is a DEX, wherein a set of signer nodes control a multisig wallet, but the identification of deposits is performed by reserving an ingress address for the transaction (e.g. DOT).

Master Pubkey K
 |- Derived Addr 1
 |- Derived Addr 2
 |- ...
 |- Derived Addr N

Is it possible to control all of the above derived addresses with the same set of multisignature signers?

4
  • Do I understand correctly that you want the multisig to be composed of derived addresses from the same private key? So anyone with this private key could easily sign the whole multisig by just signing a bunch of different messages from the different derived accounts?
    – Shawn Tabrizi
    Feb 25, 2022 at 18:54
  • Not quite. I am not sure the clearest way to explain it, bear with me. I would like to be able to derive a set of "child addresses" from a master multisig pubkey, which would require the same set of (different) private keys involved in the multisig in order to sign a message. e.g. in the above diagram, imagine 5 signers for "Master Pubkey K", with a threshold of 3 - I would like the same properties for "Derived Addr N" (the same signers, the same threshold), with the resulting public address a derivative of the Pubkey K, without the derivation requiring knowledge of K's private key.
    – Tom Nash
    Feb 28, 2022 at 8:16
  • The only way that I can think of doing this given the documentation available is to have the signers of K also generate a bunch of other account keys which are used to then derive a set of addresses. The problem with this is that doing it in a "trustless" way is not easy at all, because a single malicious multisig member at the address generation stage is capable of ensuring all addresses are useless, so you have to perform an expensive pre-commit. This is suboptimal for the large signer sets (50+) that I would like to use.
    – Tom Nash
    Feb 28, 2022 at 8:24
  • Something like an "Extended Public Key" in Bitcoin.
    – Tom Nash
    Feb 28, 2022 at 8:31

2 Answers 2

3

There a few different primitives for this interaction provided by the Multisig, Proxy, and Utility Pallet.

If I understand your needs correctly, I would do the following:

  • Generate a multisig with N people using the Multisig Pallet.
  • Generate an anonymous proxy using the Proxy Pallet, which is controlled by the Multisig.
  • Generate and submit transactions from M derivative accounts of the anonymous proxy using the Utility Pallet.

When making a call, you would then do:

  • MultisigApprove ( Proxy -> UtilityDerive -> Call (CallData) )

This setup would allow the same N multisig people to control up to u16::MAX different derived accounts from the anonymous proxy.

Furthermore, because you used an anonymous proxy, you can update the multisig backing the anonymous proxy, otherwise you can use the multisig account directly to derive new accounts.

3
  • Thank you! It looks like I can derive N accounts for the anonymous proxy without submitting extrinsics to "reserve" them first, is that right? I'll try to make a proof of concept somewhere.
    – Tom Nash
    Mar 1, 2022 at 9:03
  • Ok I had a quick look - I think I should have been clearer in my original question: I would like to utilise the benefits of native Schnorr signature support. It doesn't look like the Multisig Pallet allows us to do this (and is more expensive with more signatories). Is it possible to remove the Multisig Pallet's involvement in the above flow, and skip ahead to step 2 (use the Proxy Pallet to make an anonymous proxy controlled by the Schnorr-key)?
    – Tom Nash
    Mar 1, 2022 at 15:36
  • I dont believe we have tools which take advantage of the schnorr-key yet. Sorry.
    – Shawn Tabrizi
    Mar 4, 2022 at 4:13
2

Ok - I found that the Utility Pallet's as_derivative does exactly what I want!

The docs of the Utility Pallet say:

Each account has 2 * 2**16 possible "pseudonyms" (alternative account IDs) and these can be stacked. This can be useful as a key management tool, where you need multiple distinct accounts (e.g. as controllers for many staking accounts), but where it's perfectly fine to have each of them controlled by the same underlying keypair.

Given that I want to harness the native Schnorr compatibility of Polkadot's cryptographic scheme, this should be all that I need.

Now I just have to figure out how to replicate the pseudonym derivation (maybe with some variant of this), but that's another job.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.