Difference between revisions of "Keyset (voting pools)"

From Open Transactions
Jump to navigation Jump to search
m (Fix category tag)
m (Make it explicit that it is the private keys that are online)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category::Building Blocks]]
+
==Keysets==
 +
 
 +
The multisig structure of a pool is called the keyset definition and is expressed in XML and stored in the OT asset contract:
 +
 
 +
<pre>
 +
<pool id=”uuid” version=”1”>
 +
<blockchain>bitcoin</blockchain>
 +
<color>0</color>
 +
<members>
 +
<server id=”server_id_y” />
 +
<server id=”server_id_z” />
 +
<server id=”server_id_w” />
 +
</members>
 +
<keyset schedule=”x”  m=”u” n=”v”>
 +
<series number=”1”>
 +
<key server=”server_id_y”>xpub_y1</key>
 +
<key server=”server_id_z”>xpub_z1</key>
 +
<key server=”server_id_w”>xpub_w1</key>
 +
</series>
 +
<series number=”2”>
 +
<key server=”server_id_y”>xpub_y2</key>
 +
<key server=”server_id_z”>xpub_z2</key>
 +
<key server=”server_id_w”>xpub_w2</key>
 +
</series>
 +
</keyset>
 +
</pool></pre>
 +
 
 +
In the above example there are three servers, y, z, and w. All decisions made by the pool must be signed by u of v members of the pool. Every server contributes a different xpub for each series defined in the keyset.
 +
 
 +
Each pool must explicitly define the crypto-currency being managed by the pool, and whether to treat the deposits as regular units or as colored units.
 +
 
 +
Regular pools have a <color> value of 0. Colored coin pools are designated by including a [[color definition]] in the <color> section.
 +
 
 +
Pool definitions are versioned for future extendibility.
 +
 
 +
x is time interval expressed in [http://www.nncron.ru/help/EN/working/cron-format.htm Cron] format, either a semicolon-separated list of column values, or one of the [http://en.wikipedia.org/wiki/Cron#Predefined_scheduling_definitions predefined patterns]. The default and recommended schedule is “@weekly”.
 +
 
 +
===Series===
 +
 
 +
[[File:Voting_Pools_Series_Progression.png|800px]]
 +
 
 +
The keyset contains a list of series numbers, each one of which contains an [[xpub]] for every member of the pool.
 +
 
 +
Series numbers are always monotonic (strictly increasing).
 +
 
 +
Series numbers are incremented on a schedule, shown above as “x”.
 +
 
 +
All series rotations are calculated based on UTC time.
 +
 
 +
At any given time, one series is “active”. This is the series containing the keys which will be used to create deposit and change addresses. Pool members will “fill up” this series with deposits until the next series rotation, then will begin filling up the next series.
 +
 
 +
At any given time, one series is “hot”. The hot series is the one whose private keys are online and is currently being used to process withdrawals. All series between the hot series and the active series are inactive. Slightly before the hot series is depleted of unspent outputs (to avoid withdrawal delays) the private keys for the next inactive series are brought online and that series becomes the new hot series.
 +
 
 +
Each series can be subdivided into two sub-series. The deposit series consists of n lists of deposit addresses, one for each member of the pool. The change series is a list of change outputs from previous withdrawal transactions.
 +
 
 +
 
 +
[[Category:Voting Pool Technical Specifications]]

Latest revision as of 13:03, 22 September 2014

Keysets

The multisig structure of a pool is called the keyset definition and is expressed in XML and stored in the OT asset contract:

<pool id=”uuid” version=”1”>
	<blockchain>bitcoin</blockchain>
	<color>0</color>
	<members>
		<server id=”server_id_y” />
		<server id=”server_id_z” />
		<server id=”server_id_w” />
	</members>
	<keyset schedule=”x”  m=”u” n=”v”>
		<series number=”1”>
			<key server=”server_id_y”>xpub_y1</key>
			<key server=”server_id_z”>xpub_z1</key>
			<key server=”server_id_w”>xpub_w1</key>
		</series>
		<series number=”2”>
			<key server=”server_id_y”>xpub_y2</key>
			<key server=”server_id_z”>xpub_z2</key>
			<key server=”server_id_w”>xpub_w2</key>
		</series>
	</keyset>
</pool>

In the above example there are three servers, y, z, and w. All decisions made by the pool must be signed by u of v members of the pool. Every server contributes a different xpub for each series defined in the keyset.

Each pool must explicitly define the crypto-currency being managed by the pool, and whether to treat the deposits as regular units or as colored units.

Regular pools have a <color> value of 0. Colored coin pools are designated by including a color definition in the <color> section.

Pool definitions are versioned for future extendibility.

x is time interval expressed in Cron format, either a semicolon-separated list of column values, or one of the predefined patterns. The default and recommended schedule is “@weekly”.

Series

Error creating thumbnail: File with dimensions greater than 12.5 MP

The keyset contains a list of series numbers, each one of which contains an xpub for every member of the pool.

Series numbers are always monotonic (strictly increasing).

Series numbers are incremented on a schedule, shown above as “x”.

All series rotations are calculated based on UTC time.

At any given time, one series is “active”. This is the series containing the keys which will be used to create deposit and change addresses. Pool members will “fill up” this series with deposits until the next series rotation, then will begin filling up the next series.

At any given time, one series is “hot”. The hot series is the one whose private keys are online and is currently being used to process withdrawals. All series between the hot series and the active series are inactive. Slightly before the hot series is depleted of unspent outputs (to avoid withdrawal delays) the private keys for the next inactive series are brought online and that series becomes the new hot series.

Each series can be subdivided into two sub-series. The deposit series consists of n lists of deposit addresses, one for each member of the pool. The change series is a list of change outputs from previous withdrawal transactions.