Arbitrary multisig, a multisig design for CKB which supports multiple digital signature algorithms

[xxuejie]

PREVIEW LINK

[Hanssen0]

I insist that we should at least explain this clearly in the document. From the last script to now, the only thing that is available in the public documentation is a description of the reserved area, but there is no description of its function or why we chose the value that way. This has caused confusion.

For full context see cryptape/quantum-resistant-lock-script#14

[xxuejie]

Just to fill in the complete context: in cryptape/quantum-resistant-lock-script#14 (comment), @Hanssen0 actually proposed a different design: we can simply remove S, whether it is a reserved field or a version field, a lock / type script implementing current multisig design should implement this multisig design only. When a new multisig design is introduced, a new script should be used, different code_hash shall be used to distinguish one multisig design from another.

Not to say which direction is better, but just want to provide a complete background here, we can then discuss which design adapts to the future better.

[xxuejie]

Adding a counter example: in the design of cobuild, we actually encoded special union IDs:

union WitnessLayout {
  SighashAll: 4278190081,
  SighashAllOnly: 4278190082,
  Otx: 4278190083,
  OtxStart: 4278190084,
}

See here for more details.

Those special union IDs, are exactly hacks required, because WitnessArgs do not have a version byte, or a reserved field. In future expansions, we will need to tell the 2 formats apart(WitnessArgs vs cobuild data structures). Even if an old script only deals with WitnessArgs, it still brings merits since it can reject apps that wrongly use the new cobuild format.

So personally, I do see values in a reserved field in the multisig format. Even if we want to stick to the fact that one script only implements a single multisig format, it still can benefit us in the future.

[phroi]

There is an incoherence in this RFC implemented by the quantum resistant lock:

1. S needs to be explicit (version field).
2. Set of supported digital signature schemes (by a given lock implementing the RFC such a the current) is implicit and requires off-chain knowledge to interact with said lock (though only a subset of ALGO_IDs is supported).

Do we need off-chain knowledge about the lock we are interacting with?

• If no, ok, prove it: design a test suite for the RFC that doesn't need to be tailored for a given lock implementing this RFC (no hand picked exclusion of tests depending on the lock, that's cheating)
• If yes, we can drop this field, as it is not necessary.

[phroi]

Additionally, where are the examples/visualizations in this RFC?

The section named examples is just a low effort link to an incomplete implementation of this RFC in the form of the quantum resistant lock. I'd call it low effort because it's very much unclear what's the mapping between the entities described in the RFC and the ones appearing in the code.

Are we even trying to get other devs to understand the work being done here?

Please provide examples and visualizations!! 🙏