Use case title | [FR0109] Signing multi-signature transaction |
---|
Status | |
Preconditions | - There is a multi-signature account in the Iroha network
- The user has access to the one or many key pairs for the multi-signature account
- The current amount of signatures to the multi-signature transaction is lower than a current quorum value
|
Use case flow | - The user obtains the current list of pending transactions (<<include>> FR0203)
- The user finds the required transaction that can be signed by his/her signatures
- The user signs required transaction using the available key pair by calling the corresponding method from CLI or client SDK
- The user sends signed transaction to the Iroha peer (<<include>> FR0100)
|
Postconditions | - Amount of signatures in the signed instruction increased by 1 signature
- Signed instruction disappears from the list of pending instructions for the current user's account
|
Alternative flow | - On step 2 the user can select more than one transactions, all of them can be sent on step 4 as a separate requests
- On step 3 the user can sign the transaction by more than one signature, and all of them can be sent as a single request per single transaction on step 42 ideology of Iroha1 when creation of same transaction which already exists will result in addition of signature to this transation in pending state. This reduces need to perform queries and search for transactions needed to be signed. For bridge functionality that is a prefered flow, because all bridge instances will already know about how to form a transaction from the bridge consensus. And only malicious bridge peers will send wrongly formed transaction what is expected.
- On step 3 the user can sign the transaction by more than one signature, and all of them can be sent as a single request per single transaction on step 4. In bridge implementation scenario is: 1. Selected bridge get all bridge instances signatures from the block and calls an Iroha2 ISI with the transfer information, attaching all bridge nodes signatures. It can be implemented as in Iroha1 by sending multple ISI calls in one transaction or batch, or it can be implemented as One ISI call with multiple signatures.
|
Exception flow | - On step 1, in case of the empty list of pending transactions, the Iroha peer will return corresponding status and the use case flow stops
- On step 3, if the user uses key pair, which was already used for signing the transaction, the CLI/SDK will return corresponding error status; use case flow stops if there are no more available key pairs. (define, will it be available to do on the client-side?)
|