Siglist

From Open Transactions
Revision as of 18:59, 9 September 2014 by Justusranvier (talk | contribs) (Initial page creation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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": "Normalized transaction id associated with the withdrawal"
                    }
                    "inputs" {
                        "type": "array",
                        "items": {
                            "type": "array",
                            "items": {
                                "type": "string",
                            }
                        }
                    }
                }
            }
        }
    }
}

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.