For years in corporate jobs I would send a weekly email. These mailers focused on what I'd learned, what had stuck out to me as the high value opportunities for the company, and what I planned to focus on next.
At first these emails were painful to write, because I had such limited understanding of a company when I was new. They also started out small — only to my boss or only to my team. But over time I found a voice, began to uncover findings, and more people would ask to read what I was writing.
I mostly vividly remember two stories about these emails. First, once when a report went viral and the then CFO of Facebook emailed me out of the blue — a man I had never met or worked with — and told me he’d read it and wanted to read all of my writing going forward.
And second, years later, and actually in the same coffee shop in the Lower East Side of New York where I sit writing this now — when another former Facebook leader, venture capitalist, and founder told me that I changed his perception of what analytics could do, the actual impact it could have on the world, through the expository analysis he saw in my emails.
I share these stories mostly to pump myself up at the beginning of a journey which is scary to me. I’ve been afraid to write in public for a while. In my mind, many nice comments from people rarely balance out the hostile behaviors of a few.
Today I write to you from an interesting time in my life. I’ve made a few big career changes in the last few years and am now in a “what’s next?” phase.
I don’t fully know what’s next for me. That’s exciting and also scary. But I have a strong belief that putting words on the screen as honestly and rationally as I can will be a critical part of me figuring it out.
So — welcome!
I completely understand if you want to unsubscribe and not read these random thoughts, but I thought I’d make it opt-out since so many readers have stuck through w/ this list for years.
How I’ve Spent my Time.
I left my full time job at a company in NYC on Jan 22 and am, for now, focused full time on understanding the technology stack behind Bitcoin. As part of this, I’m in an engineering bootcamp at Chaincode Labs. This is exciting because I haven’t done real systems engineering in years — manipulating actual bits and bytes with compiled code — and because I’ve been Bitcoin curious since at least 2013.
The program is split into weekly exercises. So far we have learned how to use the Bitcoin RPC interface, created a rudimentary wallet with hierarchical deterministic keys, created and published SegWit transactions, and packed optimal bitcoin blocks from raw transaction data. You can view the full curriculum from a few years ago here.
What I’ve Learned.
On how Bitcoin works as software, as an organization, and and as a consensus system…
The Bitcoin software is remarkably efficient. You can run Bitcoin Core, the actual node software, on almost any computer. If you wanted really good hardware to run it on, there’s not much reason to spend more than $100 for a Raspberry Pi or just buying an old laptop on Amazon for <$200. This is important because nodes secure the network, and because you can never really trust someone else’s node to be telling you the truth.
You do not need to store the whole blockchain to have a full node. There’s a misconception, which I also had, that in order to run Bitcoin properly you need ~650GB of storage to keep the whole blockchain on your machine. It’s better to have every block if you need to understand the full history of the chain, but the actual data that matters is the set of unspent transactions (UTXOs) and the headers of every block. These fit into about 30GB. This means almost any computer can run a full node!
Bitcoin’s consensus is multi-layered. By design, the node software on your computer doesn’t automatically update. This prevents hostile developers from rolling out a change to the whole node network and taking it over. Also by design, many of the substantive changes to Bitcoin’s network need to be made “signaled for” by miners before the network turns the change “on.” This prevents the network from running software in an inconsistent state which could lead to unexpected chain forks.
Some obvious changes are hard to make. I was surprised to find out that the bitcoin protocol uses 8 bytes to store transaction value. This means each transaction is big enough to represent 2^64 ~= 10^19 total satoshis, even though there are only 21*10^15 ~= 2^51 total satoshis in existence. You could in theory trim several bytes from this, the transaction version, and the outpoint index by using CompactSize encodings, but it would probably require a hard fork and would take a long time to push through the consensus system.
On Rust…
Rust is an incredible language. One I wish I’d learned earlier. I’m faster at writing code that runs in Python, but I expect I am better at writing code that works properly in Rust.
Rust prevents a lot of problems. One company I was at had a bug where a variable created in one part of the code was accidentally mutable, and was later mutated across many thousands of lines away in an unexpected place, leading to a semi-random failure that impacted users. It took us over a week to fix this bug, during which time we couldn’t make any other progress. Rust would only let this kind of bug sneak into the code if you were very intentional about allowing it to. So it’s worth considering: do you value quick iteration on code that kinda works, or slower iteration on code that’s far more likely to work?
A favorite Rust pattern is how it strongly encourages you to handle every error that your program might produce. For example, in many languages you would write
foo = bar();andfoohas no idea of the exceptions or errors that might occur inbar(). In rust, you can’t writefoo = bar();. If you want to ignore the errors produce bybar(), you could writefoo = bar().unwrap();, where “unwrap” is implicitly acknowledging that you’re OK with unforeseen errors. If you want to write “good” code, you writelet foo = match bar() { Ok() => …, Err(e) => …};where Ok and Err cases are handled separately. As I’ve gotten better at Rust and adopted the second pattern, I’ve seen the bugs in my code go way down.
What’s Next.
The next set of exercises are out for the Chaincode Residency, including building Lightning network transactions and a multi-player “game” over the weekend.
I’m not fully sure where I’ll dedicate time outside of the program’s exercises, spending time outdoors during NYC’s limited sunlight, and reading more about the Bitcoin stack to understand what software contributions are needed. I expect I’ll get better at predicting the future as I keep writing.
Useful Links and Readings.
I enjoyed Marc Andreessen’s interview with Lex Fridman, especially the part about preference falsification (40 minutes in).
I’ve been trying to get away from most Bitcoin social media, it feels too focused on “number goes up”, but I do like Macroscope’s analyses.
Mastering Bitcoin is a book freely available on Github (and also of course Amazon) about the underlying engineering behind Bitcoin. We’ve been reading the entire thing as part of the Chaincode residency, and it’s very helpful to grasp the actual engineering decisions.
If you made it this far, thanks for reading! Drop me an email with any thoughts — and please let me know if you pass through New York.