From 0c0b7b722e1967078097a38c7e3bf235327d93ed Mon Sep 17 00:00:00 2001
From: Justin <drakefjustin@gmail.com>
Date: Wed, 3 Oct 2018 21:32:56 +0100
Subject: [PATCH] Homogenise types to int64

See discussion here https://github.com/ethereum/eth2.0-specs/issues/34#issuecomment-426764152
---
 specs/beacon-chain.md | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/specs/beacon-chain.md b/specs/beacon-chain.md
index a7de5e8cd3..4a642d30f2 100644
--- a/specs/beacon-chain.md
+++ b/specs/beacon-chain.md
@@ -109,7 +109,7 @@ A `SpecialObject` looks as follows:
 
 ```python
 fields = {
-    'type': 'int8',
+    'type': 'int64',
     'data': ['bytes']
 }
 ```
@@ -121,7 +121,7 @@ fields = {
     # Slot number
     'slot': 'int64',
     # Shard ID
-    'shard_id': 'int16',
+    'shard_id': 'int64',
     # List of block hashes that this signature is signing over that
     # are NOT part of the current chain, in order of oldest to newest
     'oblique_parent_hashes': ['hash32'],
@@ -195,15 +195,15 @@ fields = {
     'pubkey': 'int256',
     # What shard the validator's balance will be sent to 
     # after withdrawal
-    'withdrawal_shard': 'int16',
+    'withdrawal_shard': 'int64',
     # And what address
     'withdrawal_address': 'address',
     # The validator's current RANDAO beacon commitment
     'randao_commitment': 'hash32',
-    # Current balance
-    'balance': 'int128',
+    # Current balance in Gwei
+    'balance': 'int64',
     # Status (see status codes in constants above)
-    'status': 'int8',
+    'status': 'int64',
     # Slot where this validator leaves
     'exit_slot': 'int64'
 }
@@ -214,12 +214,14 @@ A `ShardAndCommittee` object is of the form:
 ```python
 fields = {
     # The shard ID
-    'shard_id': 'int16',
+    'shard_id': 'int64',
     # Validator indices
-    'committee': ['int24']
+    'committee': ['int64']
 }
 ```
 
+**Implementation note**: For design simplicity and homogenity the spec uses the `int64` type even when smaller bit widths (e.g. `int32` or `int16`) are possible. This does not preclude implementations from using optimised types internally. For example in `ShardAndCommittee` above, one may use `int16` for `shard_id` and `int24` for `committee`.
+
 And a `CrosslinkRecord` contains information about the last fully formed crosslink to be submitted into the chain:
 
 ```python
@@ -533,8 +535,8 @@ Let `committees` be the set of committees processed and `time_since_last_confirm
 
 For each `SpecialObject` `obj` in `active_state.pending_specials`:
 
-* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot`
-* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then:
+* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int64` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot`
+* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int64` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then:
 
 1. Set its `exit_slot` to equal the current `slot`
 2. Set its `status` to `PENALIZED`