Support P2SH Style MultiSign Script

[CipherWang]

Background

In Bitcoin, a multisign script is written like this:

M <Public Key 1> <Public Key 2> ... <Public Key N> N CHECKMULTISIG

One can embed this script in a TX's output, and provide enough legal signatures to unlock. However, the most popular multisign method in Bitcoin is P2SH. P2SH allows users embed the Hash160 of multisign script in an UTXO, and provide original script and signatures to unlock it later.

P2SH reduces the script size to a 20bytes hash, and thus it is easy to be encoded to a multisign address.

Multisign Script Support on CKB

Current multisign script on CKB is plain mode, which means the lock script has to embed and exposure all of the PKs. It costs more capacity, lack of security and privacy, and hard to be encoded to a short address.

So i suggest we follow Bitcoin's P2SH multisign method. Lock script only includes the script hash, and we use witness to provide full script.

Demo Implement

int main(argc, args[]) {
    if (argc == 2) {
          //  do single signature verification.
    } else if (argc == 3) {
           multisign_PK_hash = args[1]
           multisign_script = args[2]
           signers = []
           PK_hash = hash()
           for (signature in witness) {
                   PK = signature.recover()
                   PK_hash.append(PK)
                   signers.add(PK)
           }
           if (PK_hash != multisign_PK_hash) return -1;
           
           return check_multisign_script(signers, multisign_script)
    } 
}

Keep multisign_script simple, like "2/3"，and "3/5!1!4". Where "n/m" means at least n of m signature should be provided, and "!i" means one of signature must match the i-th PK.

[jjyr]

Suggest change the multisign_script to a more general option, let it works for both multisig and single signature.

We can easily extend it to support check tx since field (or other features), I am thinking this for a long time we should support since in system lock script.

For example multi=2/3,since=1d, represents the multisig is a 2 of 3, and the tx to spent this cell should be confirmed at least 1 day later than this cell created. We can also use position to indicates the option but then it will be relatively hard to upgrade or extend.

We can support a few basic since option:

• 1d, 1y, 1w, 1h we can spend this cell after X day/year/week/hours.
• 1b, 1e we can spend cell after 1 block, or 1 epoch.
• Add ! before the value to indicate value represent absolute time. for example: !1000b, !1568186924s.

[CipherWang]

I think since field should be a initiator-determined parameter, which means it is the transaction initator who should set it, not the receiver. And the address is a receiver-determined parameter. It is inappropriate to include since in address.

System scripts is used for most of users. If they use addresses with since, different since will generate different addresses even with the same PK. It is hard to explain why they cannot find all transactions on CKB Explorer for the same PK.

[jjyr]

I think since field should be a initiator-determined parameter, which means it is the transaction initator who should set it

the lock script can also constraint when a cell can be spent by verify tx since, it works similarly as Bitcoin script.

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#escrow-with-timeout

different since will generate different addresses even with the same PK.

Most time, users will ignore the since field, I am also curios how a multisig user can find txs?