Difference between revisions of "Siglist"

From Open Transactions
Jump to navigation Jump to search
(Initial page creation)
 
(hotlink json to GitHub)
 
(6 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
==Schema==
 
==Schema==
  
<code><pre>
+
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/schema/siglist-01.json" />
{
 
    "$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",
 
                            }
 
                        }
 
                    }
 
                }
 
            }
 
        }
 
    }
 
}
 
</pre></code>
 
  
 
==Determinism==
 
==Determinism==
Line 54: Line 18:
 
* Signatures which the blockchain wallet is incapable of generating because it lacks the associated private key are represented as empty strings.
 
* 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.
 
* 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 <code>2 A B C 3 OP_CHECKMULTISIG</code> redemption script.
 +
** Input 1 has a <code>2 D E F 3 OP_CHECKMULTISIG</code> redemption script.
 +
* The second transaction has one input:
 +
** Input 0 has a <code>2 G H I 3 OP_CHECKMULTISIG</code> redemption script.
 +
* The wallet controlls private keys b, d, and i.
 +
 +
<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/data/siglist-01.json" />
 +
 +
[[Category:Voting Pool Technical Specifications]]

Latest revision as of 15:52, 26 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.
  • 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.
{
    "roundID": 42,
    "transactions": [
        {
            "ntxid": "0000000000000000000000000000000000000000000000000000000000000000",
            "inputs": [
                [ "", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "" ],
                [ "dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd", "", "" ]
            ]
        },
        {
            "ntxid": "1111111111111111111111111111111111111111111111111111111111111111",
            "inputs": [
                [ "", "", "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" ]
            ]
        }
    ]
}