Introduction

The purpose of this report is to outline the selection process for the project I have chosen to pursue as a fellow. My name is Gbolahan, and my area of focus is Cryptography. In this report, I will discuss the projects considered for the fellowship and explain why I eventually chose the specific project.

Projects Considered

During the exploration phase, several project ideas were considered. Two notable projects in the project ideas suggested by mentors that caught my attention were:

1. Help Solve Practical Challenges with SSLE by DappLion:
   This project idea aimed to address practical challenges with Secret Single Leader Election (SSLE). Although it aligned with the field of cryptography, it lacked detailed information and discussions, making it difficult to evaluate its potential. The project's timeline in relation to the Ethereum roadmap also raised concerns. However, further investigation is still ongoing.

2. Nim Projects by Zahary:
   The Nim projects suggested by Zahary presented an interesting opportunity. Although unfamiliar with Nim, the clear and concise project suggestions, particularly the Verkle tree library, sparked interest. Learning Nim was considered a feasible option due to ample learning resources available in the Nim documentation.

Selection of the Chosen Project

I also turned my attention to the Cryptography channel. While exploring its content, I came across a proposal by Paul Miller that greatly interested me. The proposal, titled "Nested Key Generation. Improving on BIP32 HDKey" aims to enhance technology adoption by providing a user-friendly developer experience. BIP32/BIP44 (Hierarchical Deterministic Wallets) serves as an example of an unfriendly developer experience, prompting the need for a new standard.

The following issues with BIP32 were identified:

• Protocol Name Indexing Challenge:
  BIP32 employs numerical indexes for protocol names, which lack a standard assignment method. This decentralized approach leads to compatibility issues when protocol indices change over time, potentially causing complications and expenses when migrating old keys.

• Unnecessary Complexity in Key Derivation:
  BIP32 introduces unnecessary complexity by specifying different cases for deriving private child keys from private or public parents. Simplifying the scheme and leaving private-public key derivation to applications was considered more appropriate.

• Non-Hardened vs. Hardened Keys:
  The distinction between non-hardened and hardened keys, along with extended keys, adds unnecessary complexity. A more streamlined scheme focused on hardened keys was deemed favorable, as non-hardened keys may present security and privacy risks if used incorrectly.

• Multiple Execution of the Derivator:
  The repetitive execution of the derivator in BIP32 introduces further complications to the scheme, suggesting the need for a more straightforward approach.

Furthermore, BIP32 lacks interoperability with non-secp curves, as evidenced by the adoption of EIP2333 by the BLS keygen to address compatibility issues with BLS12-381 keys.

Solution: Nested Key Generation

The proposed solution involved using the HMAC-based Key Derivation Function (HKDF) specified in RFC 5869. HKDF was considered the appropriate choice for deriving keys from existing keys, given sufficient underlying entropy.

To explore the proposal further, I sent an email to Paul Miller, expressing interest in implementing the project and contributing to its development.

Secondary Interest

While the chosen project on Nested Key Generation takes priority, I am interested in the Nim projects suggested by Zahary. Specifically, the Verkle tree library project. I am going to start learning Nim so that I can pick up this project. I'm also looking to collaborate with other fellows interested in this project and other Nim projects suggested by Zahary