sortition_chains_implementation.md

WARNING

this is an old expired version of the documentation.

Please use the new documentation instead.

Here is the main page for the new documentation: https://github.com/zack-bitcoin/amoveo-docs

And here is the link for the newest version of the page you are currently looking at

Sortition Chains Implementation

sortition chains home

tx types

1. sortition new

• pubkey who initially owns all the value.
• amount of money for the lottery prize.
• expiration date for when it it becomes possible to make sortition-contract-txs for this sortition chain.

2. sortition split

This splits a sortition chain into two smaller sortition chains.

C = a binary chalang contract to determine how the old sortition chain is split.

for sortition chain 1, it selects a random value such that C is true. for sortition chain 2, it selects a random value such that C is false.

3. sortition claim

• show what height at which you had a claim to the winning part of the probabilistic value.
• You pay a safety deposit.
• this potential winner gets added to a list of potential winners.

4. sortition evidence

• which potential winner did not win.
• evidence to prove that they had signed away ownership of the winning part of the probability space.
• they get removed from the list of potential winners.

5. sortition timeout

• whichever potential winner has the highest priority claim to win, they win the lottery.
• a claim linked to an earlier block height has higher priority.
• this tx can only be made if you wait a sufficient amount of time after the RNG to choose the winner was generated.

6. proof of existence

• This allows the creator to publish 32 bytes of data into the proof of existence tree. It keeps a record of the block height at which this hash was recorded.
• This is used for hashlocking, because we need to prove at what height a pre-image was available.
• This is used for sortition operators to record the fact that they have signed a merkel root of a sortition database.

New Merkel Tree Data Structures in the Consensus State

1. probabilistic value space

id is a subset range of values in [0,1]

• pubkey of who owns this lottery ticket, or a pair of pubkeys if it is a channel, or a list of operators if it is a baby sortition chain.

2. waivers

id is generated from the sortition ID and pubkey of who is giving up control.

• signature
• sortition chain ID
• pubkey of who is giving up control

3. proof of existence

id is the 32 bytes being stored.

• arbitrary 32-bytes.
• the height where this was recorded.

4. potential_winners

for every potential winner there can be multiple layers of sortition chains in their proof that they won. for every layer of sortition chain, we need to remember a priority height as well as a list of pubkeys of accounts assigned to collect evidence for when users give up ownership of parts of that layer.

the priority height is the block height when this data was commited into the blockchain. Earlier heights are higher priority.

consensus state consumed O((number of potential winners)(# layers of sortition chains deep)(# accounts assigned to gather evidence in each layer))

each pw_root contains a pubkey of who could win.

so, every pw_root will point to the next pw_root in the linked list. it is ordered based on priority. and the pw_root also points to a pw_layer.

5. potential_winner_layer

each pw_layer contains a priority height for that layer.

each pw_layer has a pointer to the pw_root it is associated with.

the pw_layers are a linked list, each pointing to the next. they are ordered based on the order of the sortitoin chains inside of each other.

6. potential_winner_spent_proofs

each pw_spent_proof contains the pubkey of the account assigned to collect spent proofs into a merkel tree.

each pw_spent_proof_operator has a pointer to the pw_root it is associated with, and to the pw_layer it is associated with.

the pw_spent_proofs are a linked list, each pointing to the next.

Timeline for horizontal payment

Bob has veo in a sortition chain, he wants to spend to Alice, and he wants the option to hashlock this payment against something else.

1. Alice downloads all the history of all the merkel proofs of Bob's part of the probability space. She downloads this history from any of the operators, or from Bob.

2. Bob gives the operators a signed message explaining how he wants to pay part of his money to Alice. He makes a signed message saying that if a particular pre-image is revealed, he will give up ownership of his part of the probability space.

3. Alice verifies that the signed message about Bob giving up ownership is committed. She verifies that there was a commitment giving her 2nd highest priority ownership of Bob's part of the probabilistic value space. Now Alice can know if the pre-image is revealed, that she will own the value.

4. Alice sets up the other half of the hashlock using the same commitment. To pay Bob.

5. Bob reveals secret S to Alice. So now Alice controls the value Bob had wanted to spend to her.

Timeline for vertical payment

Bob has veo in a sortition chain, he wants to spend to Alice, and he wants the option to hashlock this payment against something else.

1. Bob gives a signed message to the operators explaining that he wants to convert his account into a baby sortition chain. He gives the new list of operators for the new sortition chain. This message gets committed on-chain by the operators.

2. Alice downloads all the merkel proofs for the sortition chain, so now she knows about the baby sortition chain.

Bob owns 100% of the value in the new sortition chain, so he can do horizontal payments like normal.