QIP4: Multi-Signature Wallet

[cyyber]

No description provided.

[jplomas]

Comments and discussion here.

I support this QIP.

[surg0r]

Can a signatory of a multisig address be a multisig address?

[cyyber]

Can a signatory of a multisig address be a multisig address?

Yes a signatory of a multisig address can be a multisig address.

[cyyber]

Can a signatory of a multisig address be a multisig address?

Yes a signatory of a multisig address can be a multisig address.

As per the discussion, we will not be supporting feature where a multi sig address can be one of the signatory of another multi sig address, as this simply could be achieved by using the signatory of the parent multi sig address with proportional weightage.

[surg0r]

I think this is sensible as it avoids any complications with nesting.

[surg0r]

Shared Key - Shared key refers to the multi sig spend transaction hash. In case a shared key is provided, this transaction, will not require other details such as multi sig address, address to and amount as these details will be derived from the shared key.

Does the shared key need to be a txhash? Surely any unique 32 bit number (or convertible seed phrase) would be preferable?

In this way the first multisig_spend transaction would sign the multisig address, shared key, amount and to fields. Subsequent multisig_spend transactions from other signatories would just need to sign the multisig address and shared key (plus amount and to optionally).

Whilst using the txhash is the simplest method it relies upon the other signatories knowing the precise details of the proposed transaction and choosing that transaction correctly. Furthermore, it forces the signatories to sign in a specific order. i.e. all signing transactions must reference the first for the process to work. With a unique random shared key that limitation is absent.

[cyyber]

Shared Key - Shared key refers to the multi sig spend transaction hash. In case a shared key is provided, this transaction, will not require other details such as multi sig address, address to and amount as these details will be derived from the shared key.

Does the shared key need to be a txhash? Surely any unique 32 bit number (or convertible seed phrase) would be preferable?

1. Shared key could be anything that is unique, it could be txn hash or any other unique number. Any hex number(including txn hash) could be itself be used to represent the seed phrase.

In this way the first multisig_spend transaction would sign the multisig address, shared key, amount and to fields. Subsequent multisig_spend transactions from other signatories would just need to sign the multisig address and shared key (plus amount and to optionally).

2. No, in this case, a signatory either signs multisig address + amount + to OR it signs only shared key.

Whilst using the txhash is the simplest method it relies upon the other signatories knowing the precise details of the proposed transaction and choosing that transaction correctly. Furthermore, it forces the signatories to sign in a specific order. i.e. all signing transactions must reference the first for the process to work. With a unique random shared key that limitation is absent.

3. Once the multi sig spend transaction has been initiated, other signatory to support the transaction, only need to sign the shared key.

[surg0r]

So my understanding of this is that a new multisig_spend tx does not provide a shared key in which case the txhash will be used. If one is supplied then the state machine will use it instead of the txhash, correct?

[cyyber]

So my understanding of this is that a new multisig_spend tx does not provide a shared key in which case the txhash will be used. If one is supplied then the state machine will use it instead of the txhash, correct?

In case shared key is not provided in multi_sig_spend txn, then signatory needs to provide other details which is multi_sig_address, address to , amount.

In case shared key is provided, then node will check if the shared key is a txn hash of a multi_sig_spend txn, in which multi_sig_address, address to and amount are mentioned. Further, it will check if the signer is the valid signatory of that multi sig address.

[surg0r]

What about the case where a multisig_spend tx occurs signing an existing shared key for a multisig address but providing different to and amount?

This should not be a valid multisig transaction and should be ignored?

What if several further signatories also send the same tx such that the threshold is reached.

Thoughts on this case? :-)

[cyyber]

What about the case where a multisig_spend tx occurs signing an existing shared key for a multisig address but providing different to and amount?

This should not be a valid multisig transaction and should be ignored?

The above case is not possible, because in the txn you either allowed to enter full details like to, amount, multi sig address, or you are allowed to enter only shared key.
You are not allowed to enter shared key as well as to and amount. Thus reducing the chances of human error.

What if several further signatories also send the same tx such that the threshold is reached.

Thoughts on this case? :-)

When any signatory makes multi_sig_spend transaction without shared key, it will be considered, that each signatory is creating a new poll for which voting is needed by signing the shared key. Thsu if multiple signatories also send the same txn with full details, then they are creating multiple poll which needs to be supported by multi_sig_spend transaction that signs its corresponding shared key.

[surg0r]

Finally then, the case where user one shares a planned shared key to other signatories (two and three).

Lets say due to network latency issues multisig_spend tx for two and three which simply sign the shared key alone are confirmed first. Finally the multisig_spend tx which contains the shared key and the to and amount confirms later.

I.e. the transactions are not ordered as you might expect.

Thoughts?

[cyyber]

Finally then, the case where user one shares a planned shared key to other signatories (two and three).

Lets say due to network latency issues multisig_spend tx for two and three which simply sign the shared key alone are confirmed first. Finally the multisig_spend tx which contains the shared key and the to and amount confirms later.

I.e. the transactions are not ordered as you might expect.

Thoughts?

Thats not possible as I already mentioned above, but let me give you more reasons for that.

1. When a multi_sig_spend txn provided with only shared key is transmitted, for validation, that signatory is valid, state will try to fetch full details assuming the shared key is a txn hash, and this will fail, thus this transaction will be dropped.

2. multi_sig_spend txn with only shared key is acting as a vote, one cannot vote, until the candidate has finished the formality and ready for the poll. Thus without a confirmed poll, any voting done is invalid.

3. A signatory should never sign the shared key in multi_sig_spend txn, until the shared key has been confirmed in the blockchain. So that signatory may verify the address to, amounts, before it vote for that shared key.

[surg0r]

If we are using a poll - response model then we can possibly extend the multisig specification to allow further functionality..

[AleGiovanardi]

I support this QIP.