carlbeek / eth2.0-deposit-tooling Goto Github PK

Relevant XKCD:

It is worth considering whether or not to use the existing (v3) Ethereum standard for keystores vs creating a new one.

Pros for a new standard:

• Remove the dependency on Keccak: v3 uses Keccak for checksumming the password. This is drags another hash function into the dependencies of Eth2. (Keccak lives longer in Ethereum)
• Removal of AES: v3 uses AES128 in counter mode which is an over-complicated way of mixing in the derived key to obtain the secret (BLS privkey). XOR can achieve the same mixing without introducing an extra crypto assumption (AES assumption) and crypto library dependency. (As far as I can see, AES only exists in keystores due it's historical use in the original Ethereum-sale keystore generation)
• SHA256 - the only assumption: By making the above changes, SHA256 would be the only assumption required for the security of the system (assuming the use of Scrypt as a KDF (BTW, the Scyrpt paper its a fun and witty read if you're feeling bored.) That said, Scrypt's difficulty advantage is rapidly being reduced on account of Script-mining ASICs.)

Pros for existing standard

• Not introducing a new standard
• Ability to use existing test vectors

Regarding BLS/ETH2.0 keys that are BIP44 compliant, there a few possibilities I have come up with:

0. Use it as it is:

We keep m / 44' / 60' / 0' / 0 and have no distinguishment between Eth1 and Eth2.
Pros:

• Simple

Cons:

• No way of distinguishing between Eth1 and Eth2

1. Spend the change :

Start using the (currently unused) change field (dependent on EIP84)
m / 44' / 60' / 0' / 1'
Pros:

• Uses unused field
• Reuses coin type

Cons:

• Abuse of the change field
• "Requires" hardening of change (Non BIP44 compliant)
• Confusing
• Breaks compatibility with those who have not adopted EIP 84

2. Use a new coin type:

Chose a new coin type (my proposal is 60^2=3600) to indicate the new version:
m / 44' / 3600' / 0' / 0
Pros:

• Complete separation between Eth1 and Eth2
• Doesn't break compatibility with anyone (including those that haven't adopted EIP 84)

Cons:

• New coin

According to specification the first byte of the withdrawal credential should be a prefix (see https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md#withdrawal-credentials) where here
https://github.com/CarlBeek/eth2.0-deposit-tooling/blob/master/deposit.py#L95 it's the plain hash without prefix.

I think a worthwhile goal is to have validator signing keys that can be derived from the corresponding withdrawal privkey. This gives the benefit of not having to keep track of two sets of keys. There are two alternatives, either unrelated keys are used or the withdrawal and signing keys are at the same (hardened) depth in the key-tree.

BIP44 defines the tree traversal path as (also see issue #2 for more discussion on the path):
m / purpose' / coin_type' / account' / change / address_index

Options for a signing key that is derived from a withdrawal key:

• Go a layer deeper in the tree: The index 0 child of a withdrawal key (an address in BIP44) is the signing key
• Use the change: Leverage the change level from the tree as the withdrawal and the address as the signing. (Requires hardening of change (not BIP44 compliant?))

Related, but non derivable keys:

• Partition the address space: Withdrawal at index 2*x; Signing at index 2*x + 1
• Use different change: Withdrawal: change=0; Signing: change=1

When the tests for BLS12-381 are released via the standardisation efforts, transition tests to use those tests where possible.

This is possible in:

• hkdf_mod_r tests can be lifted from KeyGen in standard