Multisignature specs #680
Multisignature specs #680
Conversation
grarco
force-pushed
the
fraccaman+grarco/multisig-specs
branch
from
7fad791
to
1f3b0be
Compare
| The [replay protection](./replay-protection.md) mechanism of Namada will prevent third-party malicious users from replaying a transaction having a multisig account as the source. This mechanism, though, is not enough to completely protect multisigned transactions: in this case, in fact, the threat could come from the members of the account themselves. | ||
|
|
||
| With the current hash-based replay protection mechanism, once the transaction has been executed, its hash gets stored to prevent a replay. The issue, with a multisig transaction, is that the same transaction with a different set or amount of signatures would have a different hash, meaning that it can be replayed. |
There was a problem hiding this comment.
I wonder if it might be worth adding a counter to multisig for this reason
There was a problem hiding this comment.
can we hash the inner-inner transaction (what the multisig signers sign over) and replay-protect with that?
There was a problem hiding this comment.
that's a better idea! We can use the hash of an unsigned tx, which we can reconstruct from a signed tx (we already do this for sig verification)
| The k-of-n multisignature validity predicate authorizes transactions on the basis of k out of n parties approving them. This document targets the encrypted wasm transactions: at the moment there's no support for multisignature on wrapper or protocol transactions. |
There was a problem hiding this comment.
We do not need multisignatures for wrapper or protocol transactions, as far as I am aware
| ## Protocol | ||
|
|
||
| Namada transactions get signed before being delivered to the network. This signature is then checked by the VPs to determine the validity of the transaction. To support multisignature we need to extend the current `SignedTxData` struct to the following: |
There was a problem hiding this comment.
either:
- there should be one VP for all accounts, which is a multisignature (and regular accounts are just 1-of-1), or
- we should use a different struct for the two different VPs
It looks like you're proposing the latter, right? wdyt about the former? it does reduce the number of VPs by one...
There was a problem hiding this comment.
I think the idea of a single VP should work and we could use vp_user also for multisig accounts
| Steps 1 and 2 allow us to short-circuit the validation process and avoid unnecessary processing and storage access. Each signature will be validated **only** against the public key found in the list at the specified index. Step 3 will halt as soon as it retrieves enough valid signatures to match the threshold, meaning that the remaining signatures will not be verified. | ||
|
|
||
| In the transaction initiating the established address, the submitter will be able to provide a custom VP if the provided one doesn't impose the desired constraints. |
There was a problem hiding this comment.
hmm, I think we won't support non-whitelisted VPs in Namada initially though, omit this for now?
| - An initial transaction to be used as an initializer for the relevant data | ||
|
|
||
| ## Multisig account init validation |
There was a problem hiding this comment.
I think we should be able to skip all this by having a fixed code for a k-of-n multisig VP and just different data
There was a problem hiding this comment.
Yeah in the end we won't apply any kind of validation (actually not even in case the VP was a custom one)
| The [replay protection](./replay-protection.md) mechanism of Namada will prevent third-party malicious users from replaying a transaction having a multisig account as the source. This mechanism, though, is not enough to completely protect multisigned transactions: in this case, in fact, the threat could come from the members of the account themselves. | ||
|
|
||
| With the current hash-based replay protection mechanism, once the transaction has been executed, its hash gets stored to prevent a replay. The issue, with a multisig transaction, is that the same transaction with a different set or amount of signatures would have a different hash, meaning that it can be replayed. |
There was a problem hiding this comment.
can we hash the inner-inner transaction (what the multisig signers sign over) and replay-protect with that?
Specs addressing #81