CIP-0146? | Multi-signatures wallet registration and discovery

[Scitz0]

A new CIP for multi-signatures wallet registration and discovery handling. CIP-1854 describes the meat of multisig (native scripts) but leaves some areas in the peripheral untouched.

Metadatum label 1854 is also added to the CIP-10 registry.

---

Rendered Proposal

[Scitz0]

Thanks @Crypto2099 for raising the potential issue at today's CIP editors meeting.

To quickly describe the issue mentioned, we (Eternl) are adding multi-sig (native script) support to our upcoming v2 release. With this, we created this specification (harmonization between wallets/dapps) for how you can pre-announce this native script using the aux data field in tx together with metadata. This was the intention of the field in CDDL as described by CIP-1854. Each participant in the multi-sig somehow needs to know about the script, either through public or offline sharing. The discovery process described in CIP draft looks for TXs containing metadata with label 1854 and native scripts that contain the user's multi-sig key cred.

The problem as mentioned by Adam is that some malicious user could look for these registration transactions and post their own, mimicking the real one but with a modified script that would allow them to drain the native script without the other participant's involvement. When the participant tries to discover multi-sig wallets that include his multi-sig key cred, they would find both the invalid (scam) wallet in addition to the real one, and might add and fund the wrong one.

Is it a problem in real life 🤷‍♂️ ... but it's sort of similar to the scam tokens we have seen sent around. There isn't much you can do about those except be vigilant and educate yourself that scammers exist and what methods they use.

The only solution I can currently think of is that a multi-sig key (cred) can only be used/registered once. All subsequent registrations would need to use the next key index. Thus a scammer could not replay a posted registration re-using an existing key cred. It complicates handling and syncing but currently the only thing I can think of to mitigate this issue. The other solution would be to acknowledge that it's a potential issue we need to educate users about.

Feel free to add other potential solutions to the problem.

[rphair]

@Scitz0 we agreed at today's CIP meeting to assign this a CIP number regardless of how the issue mentioned in #971 (comment) may progress.

Please rename the proposal directory to CIP-0146 and update the proposal link in the first comment above. 🎉

[Scitz0]

Updates pushed according to the above-proposed solution for mitigation against attack vector on public multisig wallet registration. It also contains changes to metadata format and various tweaks to improve the standard.

[QSchlegel]

Brief comment on Registration could you change to off Chain sharing instead of offline as we expect most pre- registrations to be shared online but off Chain, rather than offline.

Best Regards
QS

[QSchlegel]

Also what do you think about using CIP-0083 (encrypted message metadata) for a pre-registration tx to each potential wallet member.

Downside only works if member wallet addresses are known pre-registration.

To much chain bloat?

Or is this out of scope for CIP-0146?

[rphair]

@Scitz0 #971 (comment): Feel free to add other potential solutions to the problem.

@QSchlegel #971 (comment): what do you think about using CIP-0083 (encrypted message metadata) for a pre-registration tx to each potential wallet member.

It sounds like this could be one solution (assuming those addresses are known in advance)... @Scitz0 can you confirm or refute?

[Scitz0]

Clicked the wrong button 😆

[gitmachtl]

How about adding another scope to CIP88? Like we did in the CIP88v2 for Pool-Daily-Key Registration?

[Scitz0]

@Scitz0 #971 (comment): Feel free to add other potential solutions to the problem.

@QSchlegel #971 (comment): what do you think about using CIP-0083 (encrypted message metadata) for a pre-registration tx to each potential wallet member.

It sounds like this could be one solution (assuming those addresses are known in advance)... @Scitz0 can you confirm or refute?

Encrypted metadata wouldn't solve issue with replay of multisig wallet registration. The only solution I can see is by rotating keys as currently described in CIP.
AUX data CDDL for conway look like this:

;               metadata: shelley
;   transaction_metadata: shelley-ma
; #6.259(0 ==> metadata): alonzo onwards
; 
auxiliary_data = metadata
                  / [transaction_metadata : metadata
                    , auxiliary_scripts : [* native_script]]
                  / #6.259({? 0 : metadata
                           , ? 1 : [* native_script]
                           , ? 2 : [* plutus_v1_script]
                           , ? 3 : [* plutus_v2_script]
                           , ? 4 : [* plutus_v3_script]})

A MultiSig wallet registration contains two parts. The native scripts that define the MultiSig in auxiliary_scripts, alternatively in 1 native_script array for 259 tagged set. This is not encryptable and contains the pub keys of participants. The label 1854 metadata defined in CIP is mainly for additional data like describing the MultiSig. This could theoretically be encrypted according to CIP-83 if you want to publically share but hide this additional data describing the wallet with a name, description etc. CIP-83 is however an addendum to CIP-20 for label 674 metadata and placing this additional MultiSig metadata under this label would make it harder/less performant to search for MultiSig registration transactions. It would also force participants to share this secret off-chain/offline to be able to reconstruct the metadata.

If you feel encrypting metadata as a way of hiding 1854 metadata is worth looking into, I could add this as an optional feature. In this case, I would reference CIP-83 and not re-define it. So if enc field is present just like described in CIP-83, use that to determine if payload needs to be decrypted or not. In that case I would argue that each string value should be decrypted according to CIP-83, ie something like:

{ 
  "1854": { 
    "enc": "<encryption-method>",
    types: ScriptType[
      "base64-string 1", "base64-string 2" ...
    ],
    name: "base64-string",
    description: "base64-string",
    icon: "base64-string",
    participants: {
      [key: string]: {
        name: "base64-string",
        description: "base64-string",
        icon: "base64-string"
      }
      ...
    }
  }
}

[Scitz0]

How about adding another scope to CIP88? Like we did in the CIP88v2 for Pool-Daily-Key Registration?

Though I have read through CIP-88 (once) I'm not that familiar with how it works. Could you please in more detail go over what parts of this CIP you think CIP-88 could solve in a better way?

Note that it's important to be able to search for native scripts that include the user's 1854-derived pub key to find all MultiSig wallet registrations that it belongs to. So these must be available on-chain to search for to link to the native script. It's also not possible for participants of the MultiSig to all witness this registration as that would defeat the purpose of the registration/discovery flow and people could just off-chain share the registration. Because of this I currently don't see how CIP-88 in this case can solve it better but as I just explained, I haven't looked deep into CIP88 so I might just not see it.

[Scitz0]

Brief comment on Registration could you change to off Chain sharing instead of offline as we expect most pre- registrations to be shared online but off Chain, rather than offline.

Best Regards QS

Updated according to your comment wording for offline to off-chain 👍

[Scitz0]

I will try to join the CIP editors meeting on March 4th where we can maybe talk it through further.

[rphair]

@Scitz0 no problem; have put it on the agenda: https://hackmd.io/@cip-editors/107 (cc @Crypto2099 @jinglescode @QSchlegel @gitmachtl)

[rphair]

thanks @Scitz0 - my understanding was that securing the metadata was the last thing we were waiting for. The rest of this has always looked OK to me (though I don't have practical experience in the field) so I'm ready to approve this after a couple formatting adjustments.

[rphair]

@Ryun1 - in summarising this for my April report I noticed that all our feedback from that period has been addressed: so this should have moved into the final review stages 🤔 cc @Scitz0

[Scitz0]

@Ryun1 - in summarising this for my April report I noticed that all our feedback from that period has been addressed: so this should have moved into the final review stages 🤔 cc @Scitz0

Ok, yeah I don't think I have anything more to add to the CIP.

[rphair]

@Scitz0 the feedback from the CIP meeting today is that this is ready to merge as soon as #971 (comment) is addressed to everyone's satisfaction (assuming no further challenges are raised). Therefore this is still in Last Check for the next meeting (https://hackmd.io/@cip-editors/113) unless most editors approve if for merge earlier.

[QSchlegel]

Additional Implementors

The multisig platform from Mesh is also in the process of implementing this CIP.

https://github.com/MeshJS/multisig
https://multisig.meshjs.dev/

[rphair]

thanks @QSchlegel (cc @Scitz0) ... proposing we add this to the Acceptance Criteria as a box to be ticked as soon as CIP-0146 compliance is demonstrated:

[Scitz0]

I made a minor adjustment: if metadata is encrypted, values need to be string arrays, as the length of the content might exceed the 64-character limit.

[rphair]

Added MeshJS as Path to Active implementor in 0f9b649 as per #971 (comment).

Last Check status for next CIP meeting (https://hackmd.io/@cip-editors/114) was punted from previous meeting when we ran out of time due to a long issue discussion.

Final approval to merge (as previously suggested in #971 (comment)) should be contingent upon @perturbing @Scitz0 conversation #971 (comment) being resolved... I believe it's currently resolved by default since no actual change has been suggested since then. 👀