Siglist - Revision history

Justusranvier: hotlink json to GitHub

2014-09-26T15:52:58Z

hotlink json to GitHub

Justusranvier at 22:20, 9 September 2014

2014-09-09T22:20:41Z

Justusranvier: /* Example */

2014-09-09T20:28:11Z

‎Example

Justusranvier: /* Schema */

2014-09-09T20:23:55Z

‎Schema

Justusranvier: /* Schema */

2014-09-09T20:23:28Z

‎Schema

Justusranvier: Add example

2014-09-09T20:18:51Z

Add example

Justusranvier at 19:00, 9 September 2014

2014-09-09T19:00:23Z

Justusranvier: Initial page creation

2014-09-09T18:59:18Z

Initial page creation

New page

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==

<code><pre>
{
"$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==

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 <code>siglist</code> '''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.

@@ Line 5: / Line 5: @@
 ==Schema==
-<code><pre>
+<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/schema/siglist-01.json" />
 ==Determinism==
@@ Line 66: / Line 29: @@
 * The wallet controlls private keys b, d, and i.
-<code><pre>
+<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/draft/json/data/siglist-01.json" />
 [[Category:Voting Pool Technical Specifications]]

← Older revision		Revision as of 22:20, 9 September 2014
Line 83:		Line 83:
	]}		]}
	</pre></code>		</pre></code>
		+
		+
		+	[[Category:Voting Pool Technical Specifications]]

@@ Line 33: / Line 33: @@
                              "items": {
                                  "type": "string"
-                                 "description": "hex-encoded ECDSA signature"
+                                 "description": "Hex-encoded ECDSA signature"
+                             }
+                         }

← Older revision		Revision as of 20:18, 9 September 2014
Line 54:		Line 54:
	* 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.
		+
		+	<code><pre>
		+	{[
		+	{
		+	"ntxid": "0000000000000000000000000000000000000000000000000000000000000000",
		+	"inputs": {[
		+	{[ "", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "" ]},
		+	{[ "dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd", "", "" ]}
		+	]}
		+	},
		+	{
		+	"ntxid": "1111111111111111111111111111111111111111111111111111111111111111",
		+	"inputs": {[
		+	{[ "", "", "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" ]}
		+	]}
		+	},
		+	]
		+	}
		+	</pre></code>

@@ Line 81: / Line 81: @@
          ]}
      },
 ]}
 </pre></code>

@@ Line 25: / Line 25: @@
                      "ntxid" {
                          "type": "string",
-                         "description": "Normalized transaction id associated with the withdrawal"
+                         "description": "Hex-encoded normalized transaction id associated with the withdrawal"
+                     }
                      "inputs" {
@@ Line 33: / Line 33: @@
                              "items": {
                                  "type": "string"
+                             }
+                         }