Keystore finalization

[ethers]

Draft EIP 2333 has been started to be implemented by teams.

When should EIP 2333 status be moved to Last Call (then Accepted and Finalized)?

ethereum/EIPs#2337 (comment) should also be answered.
IANAC (I'm not a cryptographer) and for above issue, what is the impact of sticking with draft0 vs draft2 (or a future draft if this same function is updated)?

Since EIP 2333 has a dependency on a draft IETF standard as mentioned in above comment, are there other precautions that implementers and users of such keystores should be aware of?

[mcdee]

It would be nice to have a pass on 2333, 2334, 2335, 2386 and define a standard on-disk layout for wallets (I have a file somewhere around to do this) so that keys are truly interchangeable between clients. Happy to be involved in this effort.

[hwwhww]

/cc @CarlBeek

[zah]

We considered reusing our KeyStore implementation from the Nimbus Ethereum 1.0 codebase, but minor differences in the standards made this difficult. Bringing the requirements of Eth1 into the picture and considering a possible upgrade path that unifies the standards may be beneficial.

[ethers]

Should one of the EIPS also include this suggestion prysmaticlabs/prysm#6078 ?

[mcdee]

@ethers That's an implementation detail and shouldn't be part of an EIP.

EIP 2680 is up and provides a layout format. Comments welcome.

[ethers]

EIP 2333 was updated ethereum/EIPs#2337 (comment) so I'll close this.