Siglist

From Open Transactions
Revision as of 22:20, 9 September 2014 by Justusranvier (talk | contribs)
Jump to navigation Jump to search

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.
  • The second transaction has one input:
    • Input 0 has a 2 G H I 3 OP_CHECKMULTISIG redemption script.
  • The wallet controlls private keys b, d, and i.
{[
    {
        "ntxid": "0000000000000000000000000000000000000000000000000000000000000000",
        "inputs": {[
            {[ "", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "" ]},
            {[ "dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd", "", "" ]}
        ]}
    },
    {
        "ntxid": "1111111111111111111111111111111111111111111111111111111111111111",
        "inputs": {[
            {[ "", "", "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" ]}
        ]}
    },
]}