Voluntary Mind

Areas of focus 2021 - 2022

Authenticated seeds (censorship-resistance)

A Bitcoin node has impressive protection against eclipse attacks that are rooted in it’s Sybil resistance (a node knows the truth so long as 1/N of its peers are honest) and proof-of-work consensus. My work on seeding has led me to conclude that seeding a brand new node is still tricky. Today, bitcoind queries some trusted DNS seeds (domains owned by long-term Bitcoin Core contributors) to discover (hopefully honest) peers. Most people use their ISPs(or Google/Cloudflare) as DNS resolvers. A DNS resolver (under the direction of a government or otherwise) could easily co-opt a full node into a dishonest network. The current method is also susceptible to BGP attacks.

Money is the good with most marketability-per-utility that is durable, portable, divisible, verifiable and scarce. Bitcoin supersedes monetary metals on all these axes(except maybe durability). Every Bitcoin Core project strengthens one of these properties. Improving the detection of backbone attacks on seed nodes increases the verifiability of Bitcoin using a full node.

A solution I have explored is to shoehorn a cryptographic signature for the DNS results into the results themselves (the public key would be embedded in Core code) by changing the commonly used seeder implementation. I learnt from those discussions that the preferred method in the community is to work on BIP324 implementation. I’d like to contribute to review and implementation. With BIP324 merged, if the public keys for the seeds are in the Bitcoin Core binary, every new bitcoin node can be confident in connecting to the honest Bitcoin network (leaving behind only social risk).

My roadmap: - Research and internalize BIP324 - Contribute to review of existing PRs. - Contribute to BIP324 implementation - Prepare a technical proposal for adding BIP324 ChaCha20-Poly1305 authenticated encryption, service bit and v2 Messages to the bitcoin-seeder. - Implement BIP324 for bitcoin-seeder

Fuzz testing

I’ve been ramping up on fuzz testing and I’d like to review more in this area as well as grow my understanding so I can add meaningful fuzz coverage by adding tests and/or refactoring the code interfaces. Fuzz testing can help us and our adversaries find bugs in Bitcoin Core. Today, MarcoFalke and practicalswift are the only 2 developers with significant contributions to Bitcoin Core fuzzing. I’d like to join them in making sure we are always fuzzing Bitcoin Core more than our adversaries.

My roadmap: - Review any PRs that increase fuzz test coverage - Find under-fuzzed areas that can increase coverage without refactoring and add fuzz tests - Figure out simple refactors that can increase fuzz coverage significantly - Help organizations with capital to deploy towards Bitcoin Core contribute to a 24x7 fuzzing cluster so we are always ahead of the enemies.

Review

It has been repeatedly made clear that the largest bottleneck on the project is code review. I’d like to get comfortable with larger, on-going reviews. To start, I am interested in supporting the community in:

Community and Learning

I’d like to continue hosting PR review club meetings. Everyday in Bitcoin is full of learning. I will pursue deliberate education in: - Advancing C++ skills - Lightning (finish chaincode course, read BOLTs) - Rust (to try contributing to bdk/rust-lightning)