Difference between revisions of "Siglist"
Jump to navigation
Jump to search
(→Schema) |
m (→Schema) |
||
Line 33: | Line 33: | ||
"items": { | "items": { | ||
"type": "string" | "type": "string" | ||
− | "description": " | + | "description": "Hex-encoded ECDSA signature" |
} | } | ||
} | } |
Revision as of 20:23, 9 September 2014
The startwithdrawal API call returns a list of signatures which can be shared with other members of the voting pool to create an valid withdrawal transaction.
The list is formated as a JSON object.
Schema
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Withdrawal signature list",
"description": "Signatures for a list of unfinished transactions which are shared among voting pool members to finalize a transaction",
"type": "object",
"properties": {
"roundID" {
"type": number,
"description": "A positive integer representing the consensus round for which the withdrawal is associated",
"minimum": 0,
"exclusiveMinimum": false
}
"transactions" {
"type": "array",
"items": {
"type": "object",
"properties": {
"ntxid" {
"type": "string",
"description": "Hex-encoded normalized transaction id associated with the withdrawal"
}
"inputs" {
"type": "array",
"items": {
"type": "array",
"items": {
"type": "string"
"description": "Hex-encoded ECDSA signature"
}
}
}
}
}
}
}
}
Determinism
In order for members of the voting pool to coordinate transaction signing, all transactions MUST be binary-identical, which means they MUST be generated in a deterministic fashion.
Likewise, the siglist
MUST create an unambiguous mapping between transaction inputs and signatures. In order to ensure this, the following rules are enforced:
- Every transaction created by the transaction construction algorithm must appear in the siglist, in the exact same order in which it was created by that algorithm.
- Every input in a transaction must be represented in the inputs array for the transactions object, in the index order which it was created by the transaction construction algorithm.
- The signature array for each input array must contain exactly n entries, where "n" is the number of pubkeys referenced by the OP_CHECKMULTISIG opcode for that input script.
- Signatures which the blockchain wallet is incapable of generating because it lacks the associated private key are represented as empty strings.
- The order of the signatures in the array is the same order in which the corresponding pubkeys appear in the input's OP_CHECKMULTISIG script.
Example
- (a,A), (b,B), (c,C), (d,D), (e,E), (f,F), (g,G), (h,H), (i,I) are ECDSA private and public keys, respectively.
- The first transaction has two inputs:
- Input 0 has a
2 A B C 3 OP_CHECKMULTISIG
redemption script. - Input 1 has a
2 D E F 3 OP_CHECKMULTISIG
redemption script.
- Input 0 has a
- The second transaction has one input:
- Input 0 has a
2 G H I 3 OP_CHECKMULTISIG
redemption script.
- Input 0 has a
- The wallet controlls private keys b, d, and i.
{[
{
"ntxid": "0000000000000000000000000000000000000000000000000000000000000000",
"inputs": {[
{[ "", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "" ]},
{[ "dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd", "", "" ]}
]}
},
{
"ntxid": "1111111111111111111111111111111111111111111111111111111111111111",
"inputs": {[
{[ "", "", "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" ]}
]}
},
]
}