Sip 02x non sequential multisig transactions #152
Conversation
|
@jbencin - can you comment on how this relates to stacks-network/stacks-core#3710 and its associated SIP draft? Is it possible to fold these into one shared SIP effort? Let me know if it makes more sense for them to remain seperate. |
|
@AcrossfireX That PR is now implementing this draft SIP. I know there is another draft SIP mentioning order-independent multisig (#139), but that one lacks implementation details |
|
I will close the previous SIP PR so we can move all discussions to this one instead @jbencin @AcrossfireX |
| signature_1(tx), signature_2(tx), ..., signature_n(tx) | ||
| ``` | ||
|
|
||
| This would address all of the concerns listed above, and would not increase transaction size or make it easier to forge a signature |
There was a problem hiding this comment.
providing a small real-world use-case or example demonstrating these drawbacks might make the introduction even more vivid for readers who might not be deeply familiar with the subject of multisig wallets
There was a problem hiding this comment.
I would add something like:
Imagine a DAO that has 5 management team members. They decide to make a 3 out of 5 multisig on Stacks.
With the current version, signing a transaction in the creation order is required, i.e., after the 3rd owner only the 4th and 5th can sign, after the 5th owner signed - no one can add another signature.
It makes usage of the multisig painful for a lot of scenarios, for example:
- It is impossible to start signing a transaction from the 4th and 5th owners since they won't have enough owners after them to finalize the transaction
- If the 1st owner initiated a transaction, the 4th owner signed, the 2nd and 3rd owners can't sign this transaction anymore, so only the 5th owner can finalize it, the case of 2nd or 3rd owners being online and 5th not - they need to wait until the last owner makes this signature.
- If the 3rd owner initiated and signed a transaction, he needs the 4th and 5th owners' signatures in order to finalize it. 1st and 2nd owners can't participate until they make a new signing flow for that transaction.
In short, for small multisig wallets it seems to be not a blocking problem, but for multisig wallets with 4 or more owners, it becomes really hard to initiate transactions and get signatures in place.
@jo-tm @jbencin
There was a problem hiding this comment.
@fess-v This is a good example, it shows that when you establish signer order by creating a multisig address, not all signers are equal. Those near the top of the list have much more flexibility than those near the bottom
Would you please add this to the draft SIP? While you're at it, add your name and email to the authors list, you've done a lot of work on this
There was a problem hiding this comment.
Sure! will do that soon, thank you @jbencin
…nsactions fix: examples added, authors section modified
|
This SIP should be considered Accepted from the SIP Editors and should progress to technical CAB review. (Likely already underway) |
| ## Examples | ||
|
|
||
| Imagine a DAO that has a management team comprised of five members. | ||
| They create a 3 out of 5 multisig account on Stacks. |
There was a problem hiding this comment.
Combine lines 60-61:
Imagine a DAO that has a management team comprised of five members, and tey create a 3 out of 5 multisig account on Stacks.
There was a problem hiding this comment.
In general it's considered a best practice in Markdown to write one sentence per line. It displays the same, but makes diffs and merges easier
|
|
||
| The steps for signing a non-sequential multisig transaction (hash modes `0x05` and `0x07`) shall be as follows: | ||
|
|
||
| 0. Set the spending condition address, and optionally, its signature count. |
There was a problem hiding this comment.
I think for SIPS/documents in general, we should start numbered lists with 1 rather than the technically correct 0.
Cosmetic change - I don't feel strongly if it remains starting at 0 though.
There was a problem hiding this comment.
I'd prefer to keep it at 0 only because this is a modification of SIP-05 and that uses 0 indexing for these steps
There was a problem hiding this comment.
I don't think the signature count should be optional. Either this algorithm needs to work without it, or it should be mandatory.
There was a problem hiding this comment.
Agreed, but I don't the code actually treats it as optional. This line was copied directly from SIP-005, so we may want to revise that also
|
|
||
| The steps for verifying a non-sequential multisig transaction (hash modes `0x05` and `0x07`) shall be as follows: | ||
|
|
||
| 0. Extract the public key(s) and signature(s) from the spending condition. |
There was a problem hiding this comment.
I think for SIPS/documents in general, we should start numbered lists with 1 rather than the technically correct 0.
Cosmetic change - I don't feel strongly if it remains starting at 0 though.
There was a problem hiding this comment.
How are the public keys and signatures encoded?
| 0. Set the spending condition address, and optionally, its signature count. | ||
| 1. Clear the other spending condition fields, using the appropriate algorithm below. | ||
| If this is a sponsored transaction, and the signer is the origin, then set the sponsor spending condition | ||
| to the "signing sentinel" value (see below). |
There was a problem hiding this comment.
Can this (see below) point more directly? I don't see any other reference to a "signing sentinel".
example:
..(see below in point 4)
There was a problem hiding this comment.
This should be defined in SIP-05 where I copied it from
Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com> Co-authored-by: Brice Dobry <brice@obycode.com>
|
One more small thing I want to add here... Even though the signing order is independent, the order of the public keys in the auth fields still determines how the address is generated. For backwards compatibility and to enable previously generated multisig accounts to use order-independent signing, I don't think we should mandate public key order, but I think we should recommend a public key ordering of least to greatest (which is equivalent to lexicographical sorting of hex-encoded values) to remove the guesswork when creating a transaction |
|
@jcnelson - would we be able to get this in front of the Steering Committee for final approval and merge as the activation points to it being ready for epoch 3.0? It has been approved by the SIP editors and Technical CAB and seems ready for final discussions by the Steering Comittee. Also would you prefer that the editors assign a formal SIP number to this as it has not yet been chosen. It appears that SIP-026 would be available. |
| There are a few drawbacks to doing it this way: | ||
|
|
||
| - The order in which the signers must sign is fixed as soon as funds are sent to a multisig account, which limits flexibility when creating a spending transaction from a multisig account | ||
| - The process of signing a transaction requires each signer to validate the entire signature chain before signing, in order to make sure it matches the transaction, leading to `O(n^2)` signing times |
There was a problem hiding this comment.
Slight correction -- it requires each signer to perform O(n) signature verifications. The O(n^2) total verifications is distributed across n signers.
| to the "signing sentinel" value (see below). | ||
| 2. Serialize the transaction into a byte sequence, and hash it to form an | ||
| initial `sighash`. | ||
| 3. Calculate the `presign-sighash` over the `sighash` by hashing the |
There was a problem hiding this comment.
Can you be more specific in what you mean by "hashing the sighash with ... here? Do you mean to say that you concatenate the sighash with these fields?
There was a problem hiding this comment.
Again, this was copied straight from SIP-005, so if we change one we should change the other
There was a problem hiding this comment.
The problem I'm pointing out here is that this step is not well-specified when taken out of context. How is the reader supposed to know what hash algorithm to use, for example? Can't the text just say it here?
| and the nonce (as an 8-byte big-endian value). | ||
| 4. Calculate the ECDSA signature over the `presign-sighash` by treating this | ||
| hash as the message digest. Note that the signature must be a `libsecp256k1` | ||
| recoverable signature. Store the message signature and public key encoding byte as a signature auth field. |
There was a problem hiding this comment.
Please further specify whether or not the recoverable signature is in vrs or rsv order
There was a problem hiding this comment.
This is specified in SIP-005. I was trying to keep this document minimal and not reproduce everything here. I mention on lines 75-76 that for anything not explicitly mentioned here, SIP-005 still applies
| 4. Calculate the ECDSA signature over the `presign-sighash` by treating this | ||
| hash as the message digest. Note that the signature must be a `libsecp256k1` | ||
| recoverable signature. Store the message signature and public key encoding byte as a signature auth field. | ||
| 5. Repeat step 4 until the signer threshold is reached. |
There was a problem hiding this comment.
You're missing some steps related to how to serialize the resulting public keys and signatures into the transaction.
| The steps for verifying a non-sequential multisig transaction (hash modes `0x05` and `0x07`) shall be as follows: | ||
|
|
||
| 0. Extract the public key(s) and signature(s) from the spending condition. | ||
| 1. Clear the spending condition. |
There was a problem hiding this comment.
Please explain what it means to "clear" the spending condition with respect to how it affects the binary representation. Someone implementing this SIP needs to know this in order to calculate the sighash in the next step.
There was a problem hiding this comment.
Zero it. Again, same language as SIP-005
| 6. Repeat step 4 for each signature, so that all of the public keys are | ||
| recovered. | ||
| 7. Verify that the sequence of public keys hash to the address, using | ||
| the address's indicated public key hashing algorithm. |
There was a problem hiding this comment.
So, SIP-005 includes a description of how each TransactionAuth struct is laid out in memory, as well as a description of what each of the bytes mean. This is missing from this SIP. Please add it.
There was a problem hiding this comment.
I've tried to say that everything in SIP-005 still applies. Can you think of a way to make this clearer without copying the entire text of SIP-005's "Transaction Encoding" section?
| recovered. | ||
| 7. Verify that the sequence of public keys hash to the address, using | ||
| the address's indicated public key hashing algorithm. | ||
|
|
There was a problem hiding this comment.
I think a missing requirement in this section is to mandate a particular public key representation. SIP-005 mandates a compressed representation, with an extra byte to indicate whether or not the uncompressed representation should be used when calculating the address.
Does this SIP require that all public keys be compressed, or does it allow the same flexibility as SIP-005? I think it needs to to the latter, since the design of the TransactionAuth structs is meant to support representing the same public key formats as those supported in Bitcoin. The reason for this is that it's possible to determine the Stacks address of users who hold their STX with Bitcoin keys -- because the 20-byte hash component of Stacks and Bitcoin addresses is calculated the same way, these users (and counterparties that interact with them) can determine their funds' Stacks address without knowing the public keys. I think we need to preserve that property here.
There was a problem hiding this comment.
Same as SIP-005. Either format is allowed except in P2WSH where uncompressed keys are not
|
@jcnelson I copied all the text from SIP-005's "Transaction Encoding" section and merged it with this SIP. This can now be viewed as a complete replacement for that section |
jbencin
force-pushed
the
sip-02x-non-sequential-multisig-transactions
branch
2 times, most recently
from
0345acd
to
a82bfa0
Compare
…omplete replacement for that section
jbencin
force-pushed
the
sip-02x-non-sequential-multisig-transactions
branch
from
a82bfa0
to
e099ef6
Compare
| is used to distinguish between each chain's transactions. Transactions for the | ||
| main Stacks blockchain MUST have a chain ID of `0x00000000`. | ||
|
|
||
| #### Transaction Authorization |
There was a problem hiding this comment.
Hi @jbencin, you only need to include the description of the new "Transaction Authorization" data this SIP presents. You don't need anything else. Specifically, the reader needs to be able to read this section, and know exactly how to construct byte-for-byte a valid, well-formed TransactionAuth that supports non-sequential signatures.
There was a problem hiding this comment.
@jcnelson I guess I misunderstood what you were asking for and included too much this time. I've updated it again so that it this SIP only contains the "Transaction Authorization" and "Transaction Signing and Verifying" sections. Because it was easy to do, these sections also contain details for the old multisig formats, so that it's no longer necessary for the user to read the corresponding sections of SIP-005
| It does not remove support for the current format, rather it is intended to co-exist with the old format and give users a choice of which format to use. | ||
|
|
||
| The issue with the current format is that it establishes a signer order when funds are sent to multisig account address, and requires signers to sign in the same order to spend the funds. | ||
| In practice, the current format has proven difficult to understand and implement, as evidenced by the lack of Stacks multisig implementations today. |
There was a problem hiding this comment.
| In practice, the current format has proven difficult to understand and implement, as evidenced by the lack of Stacks multisig implementations today. | |
| In practice, the current format has proven difficult to understand and implement, as evident by the lack of Stacks multisig implementations today. |
While implementing Stacks multisig in the Ledger app (Zondax/ledger-stacks#152), I found the current multisig format confusing and hard to work with. Other developers that have tried to work with multisig seem feel the same way (example: PR #139), and as far as I know there is currently no Stacks wallet with full multisig support. So wrote up this SIP which makes slight modifications to SIP-005 to add a new multisig transaction type which is a bit simpler and allows participants to sign in any order.