You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* first draft remediation of CIP-1854
* got some heading levels wrong
* reclassifying as Active due to implementation in Round Table
* syntax error in YAML header
* Update CIP-1854/README.md
* Update CIP-1854/README.md
* Update CIP-1854/README.md
---------
Co-authored-by: Matthias Benkort <[email protected]>
This document describes how to realize multi-parties transactions in Cardano. It is defined as an alternative to [CIP-1852] for Cardano HD wallets. This specification does not cover the transport and sharing of partially signed transactions which is / will be covered in another document.
16
20
17
-
## Glossary
21
+
## Motivation: why is this CIP necessary?
18
22
23
+
### Overview
19
24
20
25
Term | Definition
21
26
--- | ---
22
27
HD | Hierarchical Deterministic, refers to wallets as described in [BIP-0032].
23
28
Multisig | Shorthand for Multi-party signature scheme.
24
29
25
-
# Motivation
26
-
27
-
## Overview
28
-
29
30
Multisig wallets are Cardano wallets capable of providing and tracking keys involved in multi-parties transactions. Such transactions are used to move funds from addresses where (typically) more than one user must sign transactions for its funds to be spent. A simple analogue is a joint bank account where two account holders must approve withdrawals from the account. Cardano has native support for multi-signature schemes: funds at a multi-signature script address are owned by a monetary script, which specifies one or more combinations of cryptographic signatures which must be present to unlock funds at the address (see the [Formal Ledger Spec, Figure 4: Multi-signature via Native Scripts][ledger-spec.pdf]). In a similar fashion, Cardano multisig scripts can also be used to capture stake rights on a particular address, shared between different parties.
30
31
31
32
In the Shelley era, Cardano offers six (partially overlapping) primitives for constructing monetary scripts which are summarized as the following grammar:
In order to spend from such script, one would have to provide a witness showing ownership of the key associated with either of `key-hash#1` or `key-hash#2` (or possibly, both).
54
55
55
-
56
-
## Creation of a Multisig Script/Address
56
+
### Creation of a Multisig Script/Address
57
57
58
58
The creation of a multisig address will not be covered in this document. Such addresses are described in [Shelley design specification - section 3.2 - Addresses and Credentials][delegation_design.pdf] and are obtained by serializing and hashing a multisig script. This functionality is assumed to be available through existing tooling or piece of software in a variety of ways.
59
59
60
-
## Spending From a Multisig Address
60
+
###Spending From a Multisig Address
61
61
62
62
In order to spend from a multisig address, one must provide a special witness in the spending transaction called a "multisig witness". Such witness must be the exact script used as an input for creating the hash part of the multisig address. Then, any additional required verification key signatures specified by the script must be provided as separate verification key witnesses (i.e. signatures of the hashed transaction body for each signing key).
63
63
64
64
This means that a wallet software has access to the full script to validate and also identify verification key hashes present in transactions, but only does so when funds are being spent from a multisig address! From the Allegra era and beyond, it is also possible to include script pre-image in transaction auxiliary data. Softwares may use this to communicate scripts ahead of time.
65
65
66
+
## Specification
66
67
67
-
# Specification
68
-
69
-
## HD Derivation
68
+
### HD Derivation
70
69
71
70
We consider the following HD derivation paths similarly to [CIP-1852]:
72
71
73
72
```
74
73
m / purpose' / coin_type' / account_ix' / role / index
75
74
```
76
75
77
-
78
76
To associate multi-signature keys to a wallet, we reserve however `purpose=1854'` to distinguish multisig wallets from standard wallets. The coin type remains `coin_type=1815'` to identify Ada as registered in [SLIP-0044]. The account index (`account_ix`) may vary across the whole hardened domain. `role=0` is used to identify payment keys, whereas `role=2` identifies stake keys. `role=1` is left unused for multisig wallets. Finally, the last `index` may vary across the whole soft domain, but according to the following rules:
79
77
80
78
- Wallet must derive multisig key indexes sequentially, starting from 0 and up to 2^31-1
@@ -87,36 +85,20 @@ We can summarize the various paths and their respective domain in the following
87
85
| --- | --- | --- | --- | --- |
88
86
|`1854'`|`1815'`|`[2^31 .. 2^32-1]`|`0` or `2`|`[0 .. 2^31-1]`|
89
87
90
-
91
-
### Rationale
92
-
93
-
- Multisig keys are scoped to accounts, which allows wallet's owners to separate their activity easily.
94
-
95
-
- We use a different purpose for mainly two reasons:
96
-
97
-
- It prevents mixing up standard wallets with shared wallets, which would be undesirable and become rapidly a nightmare for software to maintain. In particular, it also makes it possible to share an intermediary account key with co-signers without disclosing any information about non-shared keys in our wallet.
98
-
99
-
- It makes it easier to extend any of the 1852' or 1854' in a similar manner. The addition of a new role can be done in both scheme very consistently.
100
-
101
-
Using a different purpose also fits well the use-case on hardware wallets who can still rely on a single root seed to manage many types of wallets.
102
-
103
-
- One or many keys can be created from a parent public key via soft-derivation. This allows participant to easily share their multisig keys to participate in a multisig script without having to fetch for their hardware device. The device is still required for signing.
104
-
105
-
### Examples
88
+
#### Examples
106
89
107
90
-`m/1854’/1815’/0’/0/0`
108
91
-`m/1854’/1815’/0’/2/14`
109
92
-`m/1854’/1815’/0’/2/42`
110
93
-`m/1854’/1815’/0’/0/1337`
111
94
112
-
113
-
## User-facing encoding
95
+
### User-facing encoding
114
96
115
97
Multi-signatures payment verification and signing keys (`role=0`) with chain code should be presented bech32-encoded using `addr_shared_xvk` and `addr_shared_xsk` prefixes respectively, as specified in [CIP-5]. When represented without chain-code, `addr_shared_vk` and `addr_shared_sk` should be used instead.
116
98
117
99
Similarly we use `stake_shared_xvk`, `stake_shared_xsk`, `stake_shared_vk` and `stake_shared_sk` for multi-signatures stake verification and signing keys (`role=2`).
118
100
119
-
### Examples
101
+
####Examples
120
102
121
103
```yaml=
122
104
- base16: |
@@ -128,9 +110,9 @@ Similarly we use `stake_shared_xvk`, `stake_shared_xsk`, `stake_shared_vk` and `
To define a multisig wallet, participants must provide:
136
118
@@ -213,15 +195,21 @@ After exchanging their corresponding public keys, both wallets should be initial
213
195
214
196
When Alice initiates a transaction from this wallet, she'll construct the transaction body, sign it with her corresponding private key, include an instance of the script as witness and broadcast the transaction to Bob via Telegram. Upon reception, Bob is able to verify that the transaction was indeed signed by Alice using her private key at index #0 (Bob has indeed Alice's parent public key in its possession and is therefore able to derive a child key at index #0 to verify the signature on the transaction). Bob proceeds with the payment by signing the transaction in return and submitting it.
215
197
216
-
# Backwards Compatibility
198
+
## Rationale: how does this CIP achieve its goals?
199
+
200
+
- Multisig keys are scoped to accounts, which allows wallet's owners to separate their activity easily.
201
+
202
+
- We use a different purpose for mainly two reasons:
203
+
204
+
- It prevents mixing up standard wallets with shared wallets, which would be undesirable and become rapidly a nightmare for software to maintain. In particular, it also makes it possible to share an intermediary account key with co-signers without disclosing any information about non-shared keys in our wallet.
217
205
218
-
N/A (no preceding implementation or design).
206
+
- It makes it easier to extend any of the 1852' or 1854' in a similar manner. The addition of a new role can be done in both scheme very consistently.
219
207
220
-
# Reference Implementation
208
+
Using a different purpose also fits well the use-case on hardware wallets who can still rely on a single root seed to manage many types of wallets.
221
209
222
-
None yet.
210
+
- One or many keys can be created from a parent public key via soft-derivation. This allows participant to easily share their multisig keys to participate in a multisig script without having to fetch for their hardware device. The device is still required for signing.
0 commit comments