This summer, we hosted our first internship program at Chaincode Labs. After an extensive interview and technical code challenge process, we selected Troy Giorshev, studying at Queens University, and Hope Yen, studying at Carnegie Mellon, to work alongside Chaincode mentors while becoming immersed in the Bitcoin Core and Lightning communities. Their time with us came to an end in August, and we’re excited to see what they do next.
Before he left us for his final year at university, we spoke to Troy about his experience at Chaincode, and what future interns and Bitcoin open source contributors can expect.
Q: What were your overall impressions of working at Chaincode on open source software?
The summer was rewarding beyond my wildest dreams. I was embraced by a worldwide community, whose skilled members advised me as I proposed projects and supported me as I built them, I dove deep into a storied codebase, learning and pushing my limits every step of the way, and despite having only worked for a few months, I was able to review the work of others and influence the future of Bitcoin.
Q: What software project were you contributing to?
I worked on Bitcoin Core, which is the predominant software Bitcoin users run to interact with the blockchain, wallet, and network. It’s an open source project, and the process for contributing is a little different from working on a proprietary project.
Q: What was your summer project? How did you propose that to the community?
In my previous experiences as a developer, I was assigned tasks and had very little say over the direction of development efforts. So proposing a project in this capacity is not something I’d ever done before. Even the few times I had proposed projects, the stakeholders were clear. When working on Bitcoin Core, I had to propose my project to other developers with far more knowledge of the codebase! Consistently, though, the community was willing to give me a shot and motivated me to see the project through.
One thing that’s obviously different is that there are no Project Managers here! The maintainers (people who have the ability to merge changes into the repository) do not give direction. The best contributors to Bitcoin are self-driven and flexible.
After some guidance from my mentor, I had a project picked out. I’d add message dumping and usage statistics to our P2P connections, allowing developers and users to debug P2P issues and gain visibility into what’s happening on those connections.
I started by writing up and posting a design document, outlining the goals of the project and its capabilities, which gave everyone in the community a chance to review my proposal. It showed I was open to critique and willing to work towards a solution with others. After getting feedback, the next step was to make a proof of concept so that other developers could try the functionality for themselves. I built my proof of concept, wrote a clear description, and opened the Pull Request (PR).
Q: And what happens after you’ve opened a PR?
With my PR open, contributors started leaving review comments. Oh so many review comments! I grew tremendously as a developer by defending my design decisions. When I was asked why I was focused on a minimal file descriptor usage, I was able to point at both the history of the project and to a currently open issue to justify my choice. With Bitcoin Core being a security-critical application, I was given the chance to critically examine whether my work could open up a DoS vector, and I had to justify why what I had written was safe. The questions were tough but fair. Consistently reviewers were respectful, and it was clear they had the best interests of Bitcoin in mind. As long as I was clear and responded with the same amount of respect, the conversations came to something useful.
At the time of writing, my PR is still open. I am still making changes, and others are still reviewing it. Bitcoin is a long-running project, and the cost of a bug is immense, so it does not move quickly. Only when a PR has an abundance of review and when maintainers are confident that all aspects of the addition have been explored will a PR be merged.
Q: What was your day-to-day work like?
Bitcoin Core is a security-critical and highly performant application. Because of this, the opportunity repeatedly arose to have technical discussions and make considerations that, in other projects, may be passed over. One example of this was a small change in one of my PRs, changing the return value of a function to be an Optional. An Optional type allows you to return either a value or a null, and is an alternative to, say, returning a Boolean and passing out a value by reference. When implementing this change, I had to verify it was being done in a sufficiently performant way (i.e. that the method was not needlessly making copies of the object it was returning). I verified this not by simply trusting documentation but by digging deep into the implementation of the Optional type. As someone who had not worked significantly in C++ before, this gave me lots to explore. In the end, I was able to justify to others that my code was the best it could be.
Q: How else did you contribute to the Bitcoin Core project this summer?
The best way to participate in the community and to help out Bitcoin is to review PRs. Bitcoin’s community is filled with world-class developers and applied cryptographers. They come from a variety of backgrounds, but all come together under the common purpose of pushing Bitcoin forward. The success of open source development projects like Bitcoin rests on good review, and there is no shortage of interesting PRs waiting to be explored.
When reviewing a PR, it’s not enough just to review the changes themselves. The changes need to be understood in context with the rest of the project, and the changes need to be approved both in concept and in implementation. As a reviewer, this gave me a great opportunity to explore new parts of the codebase. It was occasionally necessary to perform “code archaeology” by digging through the git history of the project, exploring when a feature was introduced and how it evolved. I was consistently surprised by what I learned! Overall, it has taken many years for this process to become what it is today. Bitcoin has had an eventful past and given the hard work of contributors, I know it will continue to have an exciting future!
Q: What are some concrete steps aspiring contributors can take to get more involved in the Bitcoin development process?
First, get yourself set up with an IRC client. A good command line option is
irssi, but if you are someone who would rather use a
mouse, there are various GUI options available. Join us on
Freenode over at
#bitcoin-core-dev. Another great
place to get started is the Bitcoin Core PR Review
Club, which is an open meeting that happens every
Wednesday at 1700 UTC on
#bitcoin-core-pr-reviews. Each week the host will go
over an interesting or unique PR, accompanied by notes and questions, with the
goal of helping you get used to Bitcoin’s PR review process. The review club is
designed for newcomers and everyone is welcome to come and ask questions. Check
out the intro guide for more
on how to get started.
Eventually, you will want to join other communication channels. The best option is the Bitcoin Optech Newsletter. It posts every week, giving a curated summary of everything going on in the Bitcoin space including discussions occurring on the bitcoin-core-dev mailing list. On the mailing list itself, you can find the unfiltered technical discussions on the cutting-edge of Bitcoin development.
Once you have a node set up, a great resource is Learning Bitcoin from the Command Line. If you are ever confused, check out Jameson Lopp’s Bitcoin Information and Resources page, which is a gold mine of Bitcoin knowledge. And when you’re ready to start working on the code, go read CONTRIBUTING.md. It will be your best friend going forward.
There are mentors out there, but sometimes they are hard to find. I can not stress the value of mentorship enough, especially for someone new to development. I had the privilege of working under John Newbery, who guided me through navigating both the codebase and the unique world of open source development.
If you need a hand, reach out to me. You can find me on twitter at
@troygiorshev and on IRC at
And last but certainly not least:
Go review a PR!