Conversation
|
|
||
| This data is transferred between multi-signature wallets until one wallet has at least `N` commitments (including its own). | ||
|
|
||
| This wallet creates a partially signed transaction with this encoding: |
There was a problem hiding this comment.
Why does the last wallet create a "partially signed transaction" and not a fully signed transaction if it already has N commitments? Or does this sentence apply until N-1 commitments are collected?
There was a problem hiding this comment.
see https://github.com/ergoplatform/eips/blob/9906f403f61d8592ab955494cc4310563f4067c6/eip-0011.md#signing-procedure.
It's a two-round protocol in which the parties generate commitments in the first round. The last party is able to partially sign (he has only one of the keys so he cannot fully sign) and then, each of them signs the transaction partially and sends the generated signature to another party. This process continues until the signature is completed.
| partialTx: "<partially signed transaction encoded as base64>", | ||
| commitments: <ancoded commitments> | ||
| signed: [<base64 encoded of signed public keys>], | ||
| simulated: [<base64 encoded of simulated public keys>], |
There was a problem hiding this comment.
What means simulated? This is only the list of missing keys, which can be determined by the wallet address. Why do we need it?
There was a problem hiding this comment.
see https://storage.googleapis.com/ergo-cms-media/docs/ErgoScript.pdf, Appendix A2. Proving.
Those signers that do not participate in signing will be simulated. See above for details.
| This reduced format can be transformed into the standard format: | ||
|
|
||
| ``` | ||
| { |
There was a problem hiding this comment.
This format differs from the actual format in EIP-11 (index/position, pubkey/pk, a/commitment). Is EIP-11 outdated?
|
|
||
| The general commitment format is as follows. However, this general-purpose commitment can be used for any contract. | ||
| ``` | ||
| { |
There was a problem hiding this comment.
Differs from EIP-11, see below
There was a problem hiding this comment.
Agree, if EIP-11 is not suitable "as-is", then please explain why and if motivated, then EIP-11 should be updated. Then this EIP should follow EIP-11.
There was a problem hiding this comment.
this format is used in the node, sigma-rust and other libs, see /wallet/generateCommitments.
I'm not sure why EIP-11 is not following this format.
|
|
||
| The general commitment format is as follows. However, this general-purpose commitment can be used for any contract. | ||
| ``` | ||
| { |
There was a problem hiding this comment.
Agree, if EIP-11 is not suitable "as-is", then please explain why and if motivated, then EIP-11 should be updated. Then this EIP should follow EIP-11.
eip-0042.md
Outdated
| - Two bytes, with values `73` and `00`, respectively. | ||
| The value `00` indicates the VLQ-encoded index of value `N` in the list of constants. | ||
| - A constant byte with value `83`, the VLQ-encoded value of `M`, and a constant byte with value `08` | ||
| - For each public key (`M` times), a byte with value `73`,followed by the VLQ-encoded value of the index of the public key in the list of constants |
There was a problem hiding this comment.
I suggest to use ErgoTree spec and specify here the ErgoTree using operation names from the specification.
And and most magic bytes in the text above are actually opcodes, so it is better to mention them (like "atLeast")
eip-0042.md
Outdated
| Sort the list of signers' public keys before being used in the contract. | ||
| Create the required ergoTree array as follows: | ||
|
|
||
| - The first byte in the array is `10`. |
There was a problem hiding this comment.
The first byte is the header, which contains ErgoTree version bits.
While it is ok to always use one specific version, in the EIP it is better to have version as parameter.
And, if the version > 0, then size bit 3 should be set, and the size of tree bytes should be stored in as necessary (see section 5.5 in the spec)
There was a problem hiding this comment.
There is a mistake.
The "Collection Element Data Type (SigmaProp)" is not saved.
Please check ConcreteCollectionSerializer and ValueSerializer.
There was a problem hiding this comment.
I'm not sure if I got it, please elaborate.
There was a problem hiding this comment.
On your picture, the "Collection Element Data Type (SigmaProp)" shown under "Repeated for each public key". This is not correct. That 08 value is stored only once. And you already showing it as "Collection Data Type (SigmaProp)"
There was a problem hiding this comment.
according to the doc, it seems you're right since Expression Serializations requires opCode and body; however, in the tests I'm getting parsing error if I eliminate those types and surprisingly it's working when type is added.
4 participants
No description provided.