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
{{ message }}
This repository was archived by the owner on Jan 13, 2023. It is now read-only.
Copy file name to clipboardExpand all lines: docs/multisig.rst
+63-2Lines changed: 63 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ In order to use multisignature functionality, a special multisignature address m
20
20
21
21
Created digests should be shared with each multisignature participant, so each one of them could regenerate address and ensure it is OK.
22
22
23
-
Here is the examples where digest is created:
23
+
Here is the example where digest is created:
24
24
25
25
.. code-block:: python
26
26
@@ -113,13 +113,57 @@ First signer for multisignature wallet is defining address where tokens should b
113
113
Sign the inputs
114
114
---------------
115
115
116
+
When trytes are prepared, round of signing must be performed. Order of signing must be the same as in generate multisignature addresses procedure (as described above).
117
+
118
+
.. note::
119
+
120
+
In example below, all signing is done on one local machine. In real case, each participant sign bundle locally and then passes it to next participant in previously defined order
121
+
122
+
**index**, **count** and **security_lavel** parameters for each private key should be the same as used in **get_digests** function in previous steps.
After creation, bundle can be optionally validated:
145
+
146
+
.. code-block:: python
147
+
148
+
validator = BundleValidator(bundle)
149
+
ifnot validator.is_valid():
150
+
raiseValueError(
151
+
'Bundle failed validation:\n{errors}'.format(
152
+
errors='\n'.join((' - '+ e) for e in validator.errors),
153
+
),
154
+
)
155
+
156
+
119
157
120
158
Broadcast the bundle
121
159
--------------------
122
160
161
+
When bundle is created it can be broadcasted in standard way:
162
+
163
+
.. code-block:: python
164
+
165
+
api_1.send_trytes(trytes=signed_trytes, depth=3)
166
+
123
167
Remarks
124
168
-------
125
169
@@ -129,5 +173,22 @@ Full code `example`_.
129
173
130
174
How M-of-N works
131
175
176
+
One of the key differences between IOTA multi-signatures is that M-of-N (e.g. 3 of 5) works differently. What this means is that in order to successfully spend inputs, all of the co-signers have to sign the transaction. As such, in order to enable M-of-N we have to make use of a simple trick: sharing of private keys.
177
+
178
+
This concept is best explained with a concrete example:
179
+
180
+
Lets say that we have a multi-signature between 3 parties: Alice, Bob and Carol. Each has their own private key, and they generated a new multi-signature address in the aforementioned order. Currently, this is a 3 of 3 multisig. This means that all 3 participants (Alice, Bob and Carol) need to sign the inputs with their private keys in order to successfully spend them.
181
+
182
+
In order to enable a 2 of 3 multisig, the cosigners need to share their private keys with the other parties in such a way that no single party can sign inputs alone, but that still enables an M-of-N multsig. In our example, the sharing of the private keys would look as follows:
183
+
184
+
Alice -> Bob
185
+
186
+
Bob -> Carol
187
+
188
+
Carol -> Alice
189
+
190
+
Now, each participant holds two private keys that he/she can use to collude with another party to successfully sign the inputs and make a transaction. But no single party holds enough keys (3 of 3) to be able to independently make the transaction.
0 commit comments