Difference between revisions of "Asset contract (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(correct links and add category)
m (correct off-by-one error)
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
  
Asset contract for voting pools differ from standard OT asset contracts in two ways: they contain a copy of the [[Keyset_(voting_pools)|keyset definition]], and they are not idenfitied by their hash.
+
Asset contract for voting pools differ from standard OT asset contracts in two ways: they contain a copy of the [[Keyset_(voting_pools)|keyset definition]], and they are not identified by their hash.
  
 
Since keyset definitions change over time, or when the pool is modified, this means voting pool asset contracts are mutable, This means the asset contracts can not be identified by their hash. Instead, voting pool contracts use a [[colored coin definition]] as their identifier.
 
Since keyset definitions change over time, or when the pool is modified, this means voting pool asset contracts are mutable, This means the asset contracts can not be identified by their hash. Instead, voting pool contracts use a [[colored coin definition]] as their identifier.
Line 7: Line 7:
 
==Identifying voting pool asset contracts==
 
==Identifying voting pool asset contracts==
  
Each valid version of the contract is known as an <code>instance</code> of the contract, and has an <code>instance identifier</code>. Prior to creating a voting pool asset contract, one of the creators of the pool must create a colored coin with a [[btfc]] [[kernel]]. This indivisible colored output is known as the <code>charter output</code>. The colored coin definition for the charter output is the permanent idenfitier that will be used as the asset contract ID.
+
Each valid version of the contract is known as an <code>instance</code> of the contract, and has an <code>instance identifier</code>. Prior to creating a voting pool asset contract, one of the creators of the pool must create a colored coin with a [[IFOC]] [[kernel]]. This indivisible colored output is known as the <code>charter output</code>. The colored coin definition for the charter output is the permanent identifier that will be used as the asset contract ID.
  
The inital pool asset contract instance is created with the charter output definition in its header. Each future instance must contain the same definition.
+
The initial pool asset contract instance is created with the charter output definition in its header. Each future instance must contain the same definition.
  
To activate the pool contract, the charter output must be moved to the first change address defined for the first series, and the corresponding transaction must include an [[OP_RETURN]] output containing the instance identifier.
+
To activate the pool contract, the charter output must be moved to the 0<sup>th</sup> change address defined for the first series, and the corresponding transaction must include an [[OP_RETURN]] output containing the instance identifier.
  
 
==Modifying the contract==
 
==Modifying the contract==
  
Clients validate the asset contract using the blockchain. The current location of the charter output is identified, and the transaction which contain it is checked for a valid instance identifier that matches the supplied instance of the contract. Additionally, the charter output must be located in the first [[Change_Address_(voting_pools)|change output]] for the current [[Keyset_(voting_pools)#series|series]].
+
Clients validate the asset contract using the blockchain. The current location of the charter output is identified, and the transaction which contain it is checked for a valid instance identifier that matches the supplied instance of the contract. Additionally, the charter output must be located in the 0<sup>th</sup> [[Change_Address_(voting_pools)|change output]] for the current [[Keyset_(voting_pools)#series|series]].
  
 
This means the only way the charter output can be moved is if <code>m-of-n</code> members of the voting pool, therefore it is possible to prove that the current instance of the contract is part of an uninterrupted continuity from the original version if the charter output is located at the correct address.
 
This means the only way the charter output can be moved is if <code>m-of-n</code> members of the voting pool, therefore it is possible to prove that the current instance of the contract is part of an uninterrupted continuity from the original version if the charter output is located at the correct address.
  
 
[[Category:Voting Pool Technical Specifications]]
 
[[Category:Voting Pool Technical Specifications]]

Revision as of 21:59, 16 October 2014

Introduction

Asset contract for voting pools differ from standard OT asset contracts in two ways: they contain a copy of the keyset definition, and they are not identified by their hash.

Since keyset definitions change over time, or when the pool is modified, this means voting pool asset contracts are mutable, This means the asset contracts can not be identified by their hash. Instead, voting pool contracts use a colored coin definition as their identifier.

Identifying voting pool asset contracts

Each valid version of the contract is known as an instance of the contract, and has an instance identifier. Prior to creating a voting pool asset contract, one of the creators of the pool must create a colored coin with a IFOC kernel. This indivisible colored output is known as the charter output. The colored coin definition for the charter output is the permanent identifier that will be used as the asset contract ID.

The initial pool asset contract instance is created with the charter output definition in its header. Each future instance must contain the same definition.

To activate the pool contract, the charter output must be moved to the 0th change address defined for the first series, and the corresponding transaction must include an OP_RETURN output containing the instance identifier.

Modifying the contract

Clients validate the asset contract using the blockchain. The current location of the charter output is identified, and the transaction which contain it is checked for a valid instance identifier that matches the supplied instance of the contract. Additionally, the charter output must be located in the 0th change output for the current series.

This means the only way the charter output can be moved is if m-of-n members of the voting pool, therefore it is possible to prove that the current instance of the contract is part of an uninterrupted continuity from the original version if the charter output is located at the correct address.