For a few years my wife and I tracked our finances using a Google Sheet built by Money With Katie, a personal finance resource connected to Morning Brew where my wife works. It was a great starting point - got us paying attention to our finances and actually talking about money in a useful way. I’d recommend it to anyone getting started.

After three years the cracks started to show - not in the spreadsheet, but in how we were using it. Our priorities had shifted toward investment tracking: allocations, savings rate, risk exposure across a portfolio. The spreadsheet had a lot of machinery for things we didn’t need anymore and not enough of what we did: a macro view of net worth, portfolio composition, and savings rate over time. The monthly update also took about an hour. Too many accounts, tedious entry, and we kept putting it off until we stopped altogether.

My first instinct was to hack the spreadsheet apart. I spent about 45 minutes on this before giving up and deciding to build something from scratch. And since I wanted to use this as a testbed for working more seriously with AI assisted development - something increasingly relevant professionally - I treated it as an opportunity to figure out how to build something real with Claude rather than just using it as a smarter autocomplete.

The Process

Planning Before Building

The first thing I did was not write any code. On walks with my dog I had planning conversations with Claude in a Project. Brain dumps about what I wanted, what I disliked about existing finance tools, what features were necessary vs. not. Claude interviewed me, I rambled, we worked backward toward requirements.

Those requirements got formalized into a PRD that lived in the repo. Not just features but constraints:

• Tech stack: Python and Flask. Things I’ve worked with and can read.
• Code structure: How the project should be organized, what patterns to follow.
• Framework decisions: Claude helped evaluate options. We landed on Bootstrap 5.

The goal was that by the time an agent was writing code it had enough context to not produce something unreadable or architecturally bizarre.

Iterative Development

From there:

1. Build something minimal
2. Get it running, use it
3. Note what’s missing or broken
4. Planning conversation to scope the fix or feature
5. Build it
6. Repeat

The UI went through a few passes. I’d look at Fidelity, Schwab, Wealthfront - not to copy them but to understand what information hierarchies made sense for finance dashboards. Feed those observations back into planning sessions, do some rough mocking, land on something I liked.

I also ran agent “personas” to critique the product - a financial advisor, a high net worth individual, a UI/UX designer. The financial advisor and HNW personas were useful for identifying requirements around net worth projections, FI calculations, and industry standard approaches I wasn’t familiar with. The UI/UX designer surfaced interface patterns and practices I wouldn’t have thought to include. More on this below.

When I started using the app for real I kept a running dialogue in the same chat context. “This is what I noticed. Here’s what I don’t like. Here’s what I want.” That became the backlog. Prioritize with the agent, let it execute.

Shipping from a Phone

With a newborn, sitting down at a laptop for hobby projects essentially stopped being an option. I was on paternity leave at a moment when AI tooling was moving fast and I wanted something more engaging to do during contact naps than watch TV - so by necessity, essentially all of this development happened on my phone. Claude helped me set up CI/CD scripts so the Raspberry Pi serving the app would pick up changes from GitHub and automatically redeploy. That meant I could start a development session from my phone, describe what I wanted, review a PR, and see the result running on the home network within minutes - no laptop required.

The other thing I hadn’t anticipated: you can offload more than just the interesting work. I’d been treating Claude as a tool for creative and architectural tasks - feature design, planning, writing code. What I hadn’t done was hand over the friction tasks: debugging, log triage, merge conflicts. All of those are things the model can handle when it already has the codebase and PR context loaded. Once I started doing that, I stopped having backlogs of unmerged branches and undiagnosed errors sitting around waiting for me to find time at a computer.

What I Built (And What I Didn’t)

The App

Ledger is a self-hosted personal finance dashboard. Monthly net worth tracking across account types (cash, retirement, investments, real estate, mortgage) with calculated metrics for savings rate and net worth change. There’s a holdings system for tracking individual securities, a projections view for modeling portfolio growth and FI timeline, and a dividends view for understanding portfolio income.

Tech stack:

• Backend: Python, Flask, SQLAlchemy, SQLite
• Frontend: Bootstrap 5, Plotly for charts, vanilla JS
• AI integration: Anthropic API (Haiku) for holdings classification; Yahoo Finance for price data

The architecture I’m most happy with: Haiku owns reasoning and classification tasks, Yahoo Finance owns price data. Clean separation, keeps costs low.

What I Left Out

Ledger has no budgeting features. No spending categories. No “you overspent $12 on groceries” notifications. No debt payoff calculator.

Monthly cash flow entry is intentionally blunt: total income, total expenses. I look at my credit card bills, add them up, enter the number. I look at my paycheck, enter the number. Five minutes, no categorization.

Most personal finance apps are built around budgeting and debt management - that’s a real and important problem for a lot of people. Ledger is built for a different use case: savings rate, risk exposure, asset allocation, and portfolio performance over time. Anything else would have been scope creep.

The holdings classification feature is a good example of what I built instead. Enter a ticker symbol, the Anthropic API pulls information about the fund and classifies it automatically - domestic equity, international, bonds, market cap, sector. Building this required stitching together Yahoo Finance and the Anthropic API in a way I might have dismissed as too difficult or time intensive without going through a planning session first. Planning with Claude made the path obvious, then we built it.

What I Learned About Working With LLMs

Before this project I used LLMs carefully and formally - writing prompts like drafting an email to a senior colleague. Part of this was that I wasn’t used to voice dictation, which is actually how I do most of my planning with Claude now: walking the dog, dictating into my phone. Once I started doing that the whole interaction changed. Stream of consciousness works. Clarity comes faster when you’re not spending energy on formality.

The other shift was around iteration. Failing fast and cheap iteration have always been hallmarks of software engineering - that’s part of what makes it different from traditional engineering. In professional contexts I’d internalized that. What I hadn’t applied it to was personal projects, where my time is genuinely limited and I’m not going to try five different approaches to see what sticks. Working with Claude changed that calculus for hobby development specifically. I can explore more ideas, move faster, and throw things away without it costing me a weekend.

A few things that made the process work:

Use a tech stack you know. The reason I could maintain engineering judgment over what the agent was producing - catch bad patterns, question architectural decisions, understand what was being built - is that I know Python and Flask. If I’d let Claude pick the stack I might have ended up with something I couldn’t read or maintain. Your expertise is what makes AI-assisted development more than just vibe coding.

Keep context alive. Using a persistent Project meant planning conversations, backlog items, and architectural decisions built on each other over time. The agent knew the codebase, knew the constraints, knew why decisions had been made. That’s what makes it a development partner rather than a code generator.

Use agent teams for perspectives you don’t have. Running a prompt through a single agent gives you one perspective. Running it through a team of agents with different personas gives you something closer to a real design review. I used this a few different ways: software engineer personas for code reviews (useful for catching things I’d let slide because I was moving fast), finance professional and HNW user personas for feature feedback and sanity checking the financial accuracy of the app, and to surface industry standard features I’d internalized from years of using finance apps but hadn’t thought to articulate as explicit requirements - the kind of thing you only notice when it’s missing.

Where It Stands

Ledger runs on a Raspberry Pi on my home network. CI/CD pipeline. Test suite. Backlog is alive and I’m still adding to it.

The five-minutes-a-month target is still a little aspirational - I’m working on it. The unexpected win has been the dividends view. I knew the portfolio generated some passive income but had never looked at it closely in aggregate. Seeing that number tracked over time was more clarifying than I expected. That’s the thing about building your own tools: sometimes you learn something about your finances just by making the data legible.

The Google Sheet is archived but not deleted.

Ledger is open source at github.com/panderson54/ledger_finance. Self-hosted, no authentication layer, designed for use on a trusted local network.

Passive Nuclear Proliferation Strategies

Technical Hedging:

““explicitly not now, but implicitly not never.””

Puts in place technological capabilities to enable a military program at a future date but no explicit military or weaponization programs are underway. Examples of technical hedges would be inclusive of civilian energy programs and infrastructure including enrichment of non weapons grade fissile materials. This is really nuclear latency, it’s a technical capability with a lack of intent for weaponization. Technical hedgers may have internal elements that would seek a bomb but lack the political consensus to do so.

Insurance Hedging:

““explicitly not now, but explicitly in the future if X happens.””

Insurance hedgers take steps to reduce breakout time should a threat (often specific) emerge. These steps include theoretical weaponization work, domestic nuclear fuel production and advanced enrichment capabilities, and work on dual use devices like delivery systems (typically ballistic missiles). Users of this strategy typically use the latent threat of breakout either as a deterrent effect on a potential adversary or a coercive measure to allies to ensure protection. A good example of an insurance hedger is South Korea, who uses its hedge to both deter the DPRK and ensure continued US involvement in the region.

Hard Hedging:

““explicitly not now, but explicitly not never.””

Threshold nuclear states with all/many of the pieces for a functional weapons program but that stop short of taking the final steps towards weaponization. They have the capabilities to produce weapons grade fissile material, weapon designs, delivery vehicles, and political/military command and control organizations to manage nuclear weapons. Nuclear armament for these states is part of mainstream political debate with some committing to a path of proliferation (India) while some abandon the pursuit (Sweden) and others remain in limbo (Iran).

Active Nuclear Proliferation Strategies

Sprinting:

An open and determined effort to develop nuclear weapons as quickly as possible. This is the strategy that most people think of when discussing nuclear weapons proliferation and is best exemplified by the Manhattan Project. This is an all out effort by which states seek to develop capabilities to enrich fissile material expressly for military reasons, delivery vehicles and command & control (C2) for the management of nuclear arms. If, like in the US, China and the USSR, a state is economically capable and geopolitically immune from attempts to halt these efforts, sprinting is very effective. That said successful sprints are rare as the immunity to counter proliferation efforts required has thus far only been present for first generation proliferators (P5 members).

Sheltered Pursuit:

Sheltered pursuit is the development of a nuclear weapon shielded by the tolerance of a major power. The major power not only does not seek to counter proliferate but also deters other powers from doing so shielding the proliferator from military, diplomatic and economic actions. The client state attempts to achieve a nuclear breakout prior to their period of shelter ending. It’s worth noting that it is rarely in the sheltering state’s interests for proliferation to occur, super powers often want to be the only ally with nukes in order to control the escalatory ladder, but proliferation may be seen by the sheltering state as preferable to some other outcome. Classic examples of sheltered pursuit are North Korea, China preferred a nuclear DPRK over a fallen north, and Israel/Pakistan with US regional interests overriding US non-proliferation interests.

Sheltered pursuit has a high chance of success if the sheltered state can complete development prior to that shelter eroding.

Hidden:

Secret bases and hidden efforts hiders attempt to develop nuclear capabilities in the shadows often due to fear of coercion or military action by regional or major powers. Hiders trade speed for stealth and often use methods that are slower but easier to hide (typically uranium rather than plutonium enrichment) and seek either to gain a significant head start or ideally complete a weapon prior to discovery. Notably, hiding has only ever worked for one nation, South Africa, a nation that is also noteworthy for being the only country to ever give up its nuclear capability entirely. Other examples of this strategy include Iraq, Syria, Taiwan, Iran (until 2003) and many more, oftentimes these efforts meet kinetic or coercive ends.

Iran:

Dr. Narang’s flow chart is a great tool here and I want to look at it in light of recent events in Iran. As noted above Iran was, at time or writing, classified as a hard hedger, a strategy characterized by a nation having all pieces in place for weapons development but not having made that last step to actively acquire a weapon.

Indeed Iran has all the pieces in place:

• A robust and well known enrichment program for fissile material capable of high levels of enrichment
• Known weapons designs including fairly advanced implosion designs suitable for missile use.
• Sophisticated ballistic missile program for delivery, mostly IRBMs and SRBMs
• C2 practices for management of weapons and delivery systems

Despite all of this remained a hedger because they did not have a political consensus around the development of nuclear weapons (despite conventional wisdom to the contrary). Iran was (at time of writing) a signatory of the NPT (non proliferation treaty) and domestically under a fatwa issued by Ali Khamenei preventing the development of nuclear arms and most significantly had signed and complied with the JCPOA until the Trump Administration pulled out of the deal during his first term (plug for The Deal a podcast on the JCPOA).

So where are we going? Iranian deterrence has utterly failed, their network of proxies has been mostly neutered in the last year with Hamas, Syria (Assad), Hezbollah, and the Houthis more or less being taken off the board and Iran’s conventional ballistic missile and drone capabilities have proved to be relatively ineffective against Israeli and US air and missile defence systems. Given that conventional and proxy deterrence has failed it would be logical for Iran to seek a more significant deterrent in the form of nuclear armament. Additionally in light of Iran’s current security situation it is not far-fetched to assume that Iranian political thought towards nuclear armament has likely changed in the last few days.

The next step on the flow chart above is sprinting, you’ll remember that sprinting requires permissive security and economic environments to work typically but I would not be so quick to discount an Iranian sprint. Short of a ground invasion the seizure and destruction of all Iranian nuclear material is, from my view, impossible. A ground invasion is politically unpalatable to the US and numerically impossible for the IDF; given the state of sanctions economic coercion probably can’t get much worse either. It seems possible that Iran could perform a ‘hidden sprint’ using its, currently unlocated, stockpile of HEU, distributed centrifuge systems, and existing nuclear knowledge to quickly produce a nuclear device.

Let’s say that the sprint is not possible given the total air dominance Israel and the US enjoy over Iran. We’ll skip sheltered pursuit, Russia and China have made no effort to support Iran in the current conflict, Russia’s lack of support went as far as this weird statement from Putin about Israeli russian speakers. Our final stop is a hidden program, a place Iran was in 2003, success in this is unlikely but not impossible and this time Iran is starting with more knowledge and more material.

Most importantly with either outcome it is likely Iran has moved from the latent proliferator camp into the active proliferation camp. The US and IDF by showing that conventional and proxy deterrence are insufficient to shelter Iran have ironically made a compelling case for nuclear deterrence. Probably should have stuck with the JCPOA.

Books Mentioned in this post:

• Seeking the Bomb; Strategies of Nuclear Proliferation by Vipin Narang

“The need for a nuclear weapon to be safe and the need for it to be reliable were often in conflict. A safety mechanism that made a bomb less likely to explode during an accident could also, during wartime, render it more likely to be a dud. The contradiction between these two design goals was succinctly expressed by the words “always/never.” Ideally, a nuclear weapon would always detonate when it was supposed to—and never detonate when it wasn’t supposed to.””

- Eric Schlosser, Command And Control

Technologies or procedures that enable one end of the always/never spectrum typically move you away from the other. A code needed to launch a missile introduces some mechanism to render said missile inert should the code not be present, that is a failure point as well as an introduction of a delay. Keeping nuclear bombs strapped to planes on the flight line reduces the time needed to respond to an attack, it also means that a pilot could hop in and fly it off, starting World War III. In a bit of family history my paternal grandfather was the custodian of such weapons mounted to F-86Fs in West Germany at the height of the Cold War.

“At a NATO base in Germany, Agnew looked out at the runway and, in his own words, “nearly wet my pants.” The F-84F fighter planes on alert, each carrying a fully assembled Mark 7 bomb, were being guarded by a single American soldier. Agnew walked over and asked the young enlisted man, who carried an old-fashioned, bolt-action rifle, what he’d do if somebody jumped into one of the planes and tried to take off. Would he shoot at the pilot—or the bomb? The soldier had never been told what to do”

- Eric Schlosser, Command And Control

We actually deal with this concept in less extreme forms all the time, ‘fail-safe’ is the common word for engineering something to default to a safe rather than dangerous state. For example my space heater when moved, tilted or knocked over, shuts off. This is a value consideration by the engineers who built the device, it means that they’ve decided it’s better to render a device inoperable in certain instances than it is to allow it to function potentially dangerously, placing them firmly on the never end of the always/never spectrum.

In the perverse world of nuclear arms we have the concept of ‘fail-deadly’, which describes policies and practices that without outside inputs reach a deadly state, in this case usually a launch order. The most shocking example of this is found in the Soviet ‘Dead Hand’ or ‘Perimeter’ system, which you can read more about in The Dead Hand by David E Hoffman, this is an extreme example of the always end of the spectrum.

“The Strategic Air Command wanted bombs that were safe and reliable. But most of all, it wanted bombs that worked. A willingness to take personal risks was deeply embedded in SAC’s institutional culture […] they would not be pleased, amid the chaos of thermonuclear warfare, to learn that the bombs they dropped didn’t detonate because of a safety device. Civilian weapon designers, on the other hand, were bound to have a different perspective—to think about the peacetime risk of an accident and err on the side of never.”

- Eric Schlosser, Command And Control

Where does this concept intersect with platform trust and safety?

The removal of speech from social media platforms is, to put it lightly, a hot button issue. In the US we have two political blocks both feeling that platforms are falling down on the job, but from opposite ends of the spectrum. I’m not going to touch Section 230, which shields platforms from liability for the speech they host, or the 1st Amendment, which does not require a platform to carry your speech, other than to say the mix of public feelings around freedom of expression and platforms relative immunity to the consequences of hosting that speech have created a lose-lose situation for social media platforms in the United States.

Platform trust and safety teams must wrestle with the always/never paradox when it comes to regulation of speech. In an ideal world we’d have a perfect system that always found and eliminated harmful speech on a platform (CSAM, terrorism, calls for violence, disinformation etc…) while never touching legitimate speech about those same subjects. A real world example would be the removal of ISIS recruitment videos while leaving up legitimate discourse or journalism that uses those same videos. This perfect system is a fantasy, careful moderation by discerning individuals does not scale to billions of users so we try to solve these problems at scale with technology but technology, just like people, has built in values.

When building systems to deal with speech on platforms you need to choose which end of the spectrum you are comfortable defaulting to, do you fail-safe or fail-deadly? Failing safe (biasing towards harm reduction) will mean the removal of more speech and the potential suppression of legitimate discourse on incredibly important subjects, failing deadly (biasing towards freedom of expression) will allow for and potentially promote harmful content with real world consequences. Any system will be imperfect, but we can choose how some of those imperfections manifest.

I am not going to express a viewpoint on how an ideal system would walk this line, the issues are complex and I am no expert in the problem set technically or socially. I don’t work directly in trust and safety and I am not a lawyer, but I like this framework for thinking about these issues and it’s an easy connection to make between my hobbies and professional life. If you want to listen to vastly more competent people talk about these difficult issues I’d encourage you to check out the following podcasts and publications.

• Moderated Content from Stanford Law School a podcast content about content moderation, moderated by assistant professor Evelyn Douek. The community standards of this podcast prohibit anything except the wonkiest conversations about the regulation—both public and private—of what you see, hear and do online.
• Lawfare’s Arbiters of Truth an occasional Lawfare podcast series on the online information ecosystem featuring interviews with experts about the legal and policy aspects of the debates around political discourse, online speech and social media platforms.
• Dual-use regulation: Managing hate and terrorism online before and after Section 230 reform by Brian Fishman. Brian’s article was published by Brookings and then he was interviewed by Quinta Jurecic on Arbiters of Truth. His interview and article percipitated the above train of thought.

Books Mentioned in this post:

• Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety by Eric Schlosser
• The Dead Hand: The Untold Story of the Cold War Arms Race and its Dangerous Legacy by David E. Hoffman

https://tidbyt.com/

This is just going to be a stream of me trying to get some stuff to work, if anything get published to the TidByt app store I’ll link all source code here. If not I either gave up or am running it locally and so embarrassed of my hack job code I didn’t link it.

1/24/23

Installed Pixlet CLI and got starlark syntax highlighting functioning on VSCode. I’d clearly not done any python development on this machine in a long time as pip was super out of date. Luckily powershell seems to have come a long way, I don’t have a non-work unix machine lying around currently so this will all be done on windows for bonus points.

Pixlet’s CLI works really seamlessly, point it at a starlark file and it runs and prints the output locally to http://127.0.0.1:8080

Dev Documentation

I’ve got a couple ideas of applets to build

Specific NCAA Basketball Teams: There are a bunch of sports scoring apps on the marketplace but I want to only show scores on the day my college basketball team is playing. The only other NCAA applet just shows either the top 25 or an entire conference, frankly unless it’s Gonzaga I could care less so one option would be to build my ideal NCAA Basketball display. There are a few things to solve here, there is a scheduling tool within the TidByt config app but it’s date driven, the calendar applet has an option to hide it in your display order if there are no other events that day, I’d like to build a similar function to hide my potential app if my team is not playing.

Book Progress: A goodreads based progress tracker for my current book. Kindle -> Goodreads -> TidByt. I’ve been wanting to use the goodreads API to drive a display for a while but ran into some issues with getting cover art from their API, I might just go with a stats display for the current year.

NASDAQ Composite Tracker: The only trackers in game right now are stock specific, I’d like to be able to have updates on the S&P500 + NASDAQ as well. This might be my first go as it’s a very straight forward display to build.

I’ll take a look at some existing apps and see what’s already been done: GitHub: tidbyt/community

1/25/23

Spent a lot of time trying to find a stock API will serve me index scores like NASDAQ, DJI, S&P500 etc.. There appears to be one Financial Modeling Prep - Indexes but it looks like the index tickers are all in a premium tier. This probably won’t work as all users of the applet will need to provide their own API key, this is a pattern I’ve seen across other apps in the community apps repo. I may have to code something up with static numbers and come back to the API problem as the pattern for fetching some JSON from an endpoint is simple.

In other news the Pixlet APIs provide some cool features with regard to caching and encryption of things like API keys. All apps actually run on the TidByt servers and push frames out to your device forcing a refresh if the cache has been invalidated. Likewise any data pulled from other sources is cached with a TTL set within the app code. The part I’m most worried about is the visuals, the code is easy but my art skills are lacking.

1/29/23

I decided to skip to hacking around in pixlet and I’ll come back to finding an API that provides something I want to display. I used the tutorial + reading through some community code to make a stock app that takes in a few parameters (symbol, shares and an API key for alphavantage) and returns the value of the stock multiplied by the number of shares. This exact app is already in the community repo but for some reason it was not working on my TidByt device. I added in some caching and checks to make sure the cached price data is for the current stock symbol, we throw out the cached data if the symbol changes in the config. As expected the actual formatting of the output involved the most trial and error, not because the docs are bad but because I’m not particularly frontend minded. I think I’ll move onto trying to use Goodreads/Kindle’s API to display my reading progress, not a useful app but I like tracking my reading goals and it’s not something anyone else has built. I’ll need to pull the community repo to get started.

1/31/23

I embarked on my Goodreads journey without realizing that Goodreads had killed off its public API in 2020. Not to be deterred, I decided to use this as a reason to learn a little more Starlark and built a web scraper aftering sorting out where the data I wanted lived publicly on Goodreads. Turns out , given what I am calling a challenge ID (not a user ID) Goodreads will serve up any public profile yearly reading challenge at https://www.goodreads.com/user_challenges/ . Using this I set up an applet to take in the challenge ID, make a GET request and parse the returned HTML to show how far along any given user is on their reading goals.

This is what it looks like in Starlark

 challenge_page = http.get(GOODREADS_PROGRESS_URL + config.str("user_challenge_id", DEFAULT_CHALLENGE_ID))


        if challenge_page.status_code != 200:
            fail("Request failed with status %d", challenge_page.status_code)


        body = challenge_page.body()
        progress_div = re.findall(r"<div class='progressText'>([\s\S]*?)</div>", body)


        if not progress_div:
             fail("No challenge found at {}".format(config.str("user_challenge_id", DEFAULT_CHALLENGE_ID)))


        progress_nums = re.findall(r"\d+", progress_div[0])
        progress = progress_nums[0]
        goal = progress_nums[1]

It’s pretty readable as it’s basically python, including a ported over regular expressions library. I then did basically 0 work to display it as such. There is a toggle for an as of yet un implemented “are you on track function” which I’ll do later.

All in all not bad for a evening messing around, most information was either from the previously linked TidByt docs and the Starlark spec

2/2/23

I decided I wanted to work on the visuals of this goodreads applet and thought it’d be fun if your little bookshelf filled up as you read books over the course of the year. This gave me a good chance to sort out how the different render functions worked and how to position things on the screen. I made a bunch of book art using PixelArt as my editor (see my files here: gallery) and wrote a very dumb if statement that takes in the number of completed books from my Goodreads scraper and renders between 0 and 13 books. The average adult reads 12 books a year and my art skills ran out of steam so displaying more than that is task for later (if ever). What I was left with is a fun display that will update once a day if this app is running on your TidByt. I used some basic transformations to keep my 4 assets fresh-ish despite a lot of reuse.

You can render your applet locally and then push that asset to your TidByt from the Pixlet CLI to see how it will look! This is a good time to talk about how this code will eventually be executed. The TidByt device does not run anything locally, rather it gets frames pushed to it from TidByts servers and the device simply renders the frame. This has some obvious limits to it, you’re not going to be doing a bunch of computation on TidByt’s dime and thus they have app efficiency requirements prior to merging into their community app repos. Additionally they enforce quality standards for caching and encryption of API keys. This is good in that everything that can run on your device is open sourced and adheres to similar standards. If you really wanted to leave the ecosystem you can flash the firmware on the device itself and do whatever you like.

2/19/23

I polished up what I had written the other week and forked tidbyt’s community repo. Running the pixlet create script sets up a folder and does some basic scaffolding for you, I copy and pasted my code into the generated file and did a little clean up. First on the agenda was to remove all testing code and any references to my own account. In order to make this run out of the box for people I encrypted my personal challenge ID using pixlet’s encrypt command from the CLI. This (I’m guessing here) encrypts the passed data with a public key from Tidbyt and is only able to be decrypted by a private key, at runtime, which resides with them. Because apps all ultimately run on tidbyt’s servers this is a sensible way to let developers store API keys and other data with them without revealing it in code.

I ran pixlet’s code profiling, formatting, linting and checking commands to make sure things were running properly and up to TidByt’s style standards and submitted a PR. I give my PR a 50/50 chance of being accepted. While I don’t think my solution is terrible (or I’d not have submitted it) the use of what is essentially a web scraper to get the progress data is not a great practice and certainly not something I’d let go into production for any sort of real service. That said there is no public API to get this data and short of reverse engineering Goodreads’ private API it’s the best option I’ve got.

I’ll check back in when I get feedback on my PR from the pixlet community.

2/22/23

Turns out the cache keys are on a per app basis, all users of the app share a cache, this means that my storing of progress and goal are global unless we append some sort of unique indentifier to the cache key. To solve this I just appened the challenge ID when cacheing progress and goals. The shared cache per app makes a ton of sense if you are doing something like stock prices or other data that would be the same regardless of user but still requires some sort of calculation or API call.

3/2/23

My PR was merged! The Goodreads Challenge Tracker will appear in the next version of the TidByt app released. I’ll update this post when that happens but for now I’m considering this little project done. If I build something next it’ll be an NCAA basketball scoreboard for specific teams but seeing as March Madness is about to start that is probably a project for the ‘23-‘24 season. I don’t often code outside of work as usually that itch is scratched (and then some) by my day to day contributions at Meta but this was a fun project where I got to learn something new and publish it out to a wider community.

3/6/23

My app is live in the TidByt app! Happy reading.

The desire of people to keep secrets, and to read the secrets of others, is an urge that has helped shape history. We can find uses of codes and ciphers dating back thousands of years, generals, kings, advisors, spies and diplomats all needed ways to communicate safely without fear of their message being read by prying eyes. The word cryptography comes from the Greek word kryptos meaning hidden. Cryptography is the practice of hiding the meaning of a message, not the message itself. The process by which this is done is called encryption, the aim of encryption is to take a message and render it unintelligible to all but the intended recipient. Anyone who reads an encrypted message that does not know how the message was scrambled will be unable to decipher it.

BASICS

Encryption falls into two general camps, transposition, the act of moving characters around, and substitution, the act of swamping one character for another in the alphabet.

Some quick terminology: Plaintext: The unscrambled, original, message.

Ciphertext: Then scrambled message, this is the result of using an encryption process on a plaintext.

Algorithm: The method by which something is encrypted

Key: The details of a particular encryption, this could be the number of places a letter is shifted or the substitution alphabet (aka a cipher alphabet).

Classic examples of both types are rail fence cypher (transposition) and the Caesar cipher (substitution). Both are quite simple, the rail fence involves creating two strings from alternating letters and then combining the two strings as a ciphertext.

Plaintext: THIS IS  A SECRET:
String 1: T I I A E R T
String 2:  H S S S C E
Ciphertext: TIIAERTHSSSCE

The Caesar cipher is similarly simple, it involves shifting the alphabet a predetermined number of spaces and substituting the letters of the plaintext with the letters in the cipher alphabet. The classic example, used by Caesar himself, was 3 places.

Plain Alphabet:    ABCDEFGHIJKLMNOPQRSTUVWXYZ 
Cipher Alphabet: XYZABCDEFGHIJKLMNOPQRSTUVW 
Plaintext: THIS IS A SECRET
Ciphertext: WKLV LV D VHFUHW

You are probably familiar with these from grade school, they are fun, easy to learn and use and for thousands of years were state of the art. Both of these are kept secret not by knowing the algorithm by which they were encrypted but by the key used to do the encryption. This brings us to a core tenet of cryptography, know as Kerckhoff’s principle, which can be paraphrased as:

A cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.

The assumption is that a potential snooper can know everything about how a message was encrypted, except the key, and they will be no closer to the plaintext. This is core to how all modern encryption works. When data is sent securely over the internet, anyone can intercept those messages but only the person holding the proper key can actually read them.

HISTORY

We are all familiar with famous historical examples like Enigma from World War 2, the Zimmerman Telegram, or Mary Queen of Scots’ hidden messages to her supporters. But the stories that are told about these uses of cryptography are not how effective they were but rather how they were broken.

Code breaking books date back to 9th century Baghdad where Arab thinkers such as Al-Kindi (author of A Manuscript on Deciphering Cryptographic Messages) pioneered the field of cryptanalysis. Al-Kindi wrote about a method now known as frequency analysis, this is a method that uses linguistics and statistics to determine how a given letter was substituted based on the frequency of that letter’s occurrence. In any language some letters occur more than others, in english e is the most commonly used letter, by taking a ciphertext and counting the occurrence of each letter a code breaker can start to reveal the underlying key.

The Arab codebreakers kicked off a cycle of attack and defense that lasts to this day, at various points in history one side or the other has held the upper hand. Following the breaking of simple substitution and transposition ciphers there was a period of relatively little secrecy with code breakers able to read secret messages with impunity (provided you had a code breaker on staff that is, not exactly a common medieval profession). This battle has continued throughout history, Phelippes vs Mary Queen of Scots, Babbage & Kasiski vs the Vignere Cipher, ADFGX vs Painvin and Turing vs Enigma. During some periods cryptographers had the upper hand but for the most part search for an unbreakable code was driven by cryptanalysts ability to break codes with greater and greater efficiency. This all culminates in the invention of a truly unbreakable, and truly unwieldy, form of encryption called a One-Time Pad (OTP).

OTP

Rules for unbreakable cryptography:

• The key must be at least as long as the plaintext.
• The key must be random
• The key must never be reused in whole or in part.
• The key must be kept completely secret by the communicating parties.

These rules describe a technique called a One-Time Pad, this is essentially a substitution cipher that uses a cipher alphabet made of entirely random letters once and then never again. The only instances of one-time pads being broken involved American cryptanalysts sifting through burned scraps of Soviet one-time pads and after painstaking work finding that the soviet cryptographers had messed up and reused some pads.

Randomness is key here, random number generators found in standard programming libraries are not sufficiently random for this purpose. In brief the number of bits of entropy in the cipher alphabet must be equal to the bits in the plain text. Specific methods for truly random number generation are complex and beyond our scope but they’re interesting and you should look them up. Now this all sounds great, congrats everyone we have unbreakable codes!

Well yes and no. If the key must be as long as the plaintext and you can secretly get a key to someone why not just send the plaintext? Additionally the total number of plaintext characters you can send is limited to the number of characters on the pads after that a new pad must be created and distributed. Modern encryption algorithms trade some security for usability at scale. One time pads are still very much used but their requirements for physical security and transportation of the pad make them impractical for general use or use between parties that don’t already know each other. This last problem is what needed to be solved for secure communication to be useful in the internet age.

The age of computing has created a revolution in cryptography with modern cryptosystems becoming incredibly complex and math heavy. They are not ‘perfect’ in the same way that an OTP can be; modern cryptosystems’ strength is that the work required to break them is simply unobtainable (for most actors), typically strong modern encryption measures it’s strength in millennia of computing time needed to brute force a given key. At least until the next great leap in computing is made the defense currently has the high ground.

All of the cryptosystems we’ve talked about thus far hinge on two parties agreeing on a key and then using that shared knowledge to encode and decode messages. Obviously this is easy to do in person but how do you agree on a key, securly, without ever meeting someone?

MEET ALICE, BOB, AND EVE

The entire story about how this was solved is fascinating and I encourage you to read both Steven Levy’s book Crypto about the development of Key Exchanges, PGP, and RSA. The story involves MIT, British spies from GCHQ, American spooks at Ft. Mead, and some radical dudes in California.

What we know about encryption so far is that keeping a key secret is the most important part of keeping a message secure, but keys are needed to encrypt and decrypt a message which is something both parties need. The solution is called public key cryptography and the problem was solved in two ways by two different teams on opposite coasts of the US around the same time. Here are the two initial approaches:

• Two parties establish a shared key independently prior to sending information that needs to be secured.
• Everyone brings their own lock and their own key

The solution to both of these comes down to math. There is a mathematical concept called a one-way function, this is a function that is very easy to compute in one direction and very difficult to invert. Given the output of one of these functions you are (practically) unable to determine what the inputs are.

Diffie-Hellman Key Exchange

Diffie-Hellman Key Exchange allows two people to develop a shared secret key while never communicating that secret key between one another. The shared key is then used to encrypt and decrypt messages between the two parties. The development of the shared key is easily illustrated as follows:

1) Both communicate in the open to choose some base numbers for their shared function p and g
2) Alice selects a secret number a and computes A = g^a mod p
3) Alice selects a secret number b and computes B = g^b mod p
4) Alice sends Bob A in the clear 
5) Bob sends Alice B in the clear
6) Alice computes S = B^a mod p 
7) Bob computes S = A^b mod p 
8) Both now have secret key S

The underlying one-way function at work here is called the Diffie-Hellman Problem. Our eves dropper, Eve, does not have enough information, even if they monitor the entire exchange, to compute the key S.

Diffie-Hellman is still widely used in various permutations and parts of it are how apps like Signal and WhatsApp secure their communications (aka the Signal protocol). The disadvantage of Diffie-Hellman is that symmetric key encryption is that it is generally less secure than asymmetric key encryption and that it is not asynchronous.

RSA

RSA attacks this problem in a different way, what if everyone distributed their own locks for free but kept their keys private? There is a subset of one-way functions called trapdoor functions, a trapdoor function is a one-way function that has once caveat, there exists an additional value (the trapdoor) that makes determining the original values trivial. This trapdoor function is key to what is known as asymmetric key encryption.

Asymmetric keys have two components: a public key used for encrypting data and a private key for decrypting data. Everything talked about previously would fall into the category of symmetric key encryption where both parties use a single shared key. The private key is our trapdoor and must be kept secret, but the public key can be shared to anyone who wants to send you a message. Messages encrypted using your public key can only be decrypted by your private key. The exchange works as follows:

1) Alice wants to send Bob a message 
2) Alice requests Bob's public key 
3) Bob sends Alice his private key in the open
3) Alice write's her message to Bob and encrypts it using Bob's public key 
4) Bob receives Alice's encrypted message and decrypts using his private key 

RSA relies on the Prime Factorization Problem for it’s security, simply put it’s very difficult to find the factors from the product of two very large prime numbers. In this case Eve has Alice and Bob’s public keys but no information about their private key and thus cannot read their messages.

Asymmetric key encryption is generally viewed as very secure but it’s a slower process and thus not suitable for all use cases. Asymmetric key encryption also has a major advantage because it does not require the active exchange of data (provided you already know someone’s public key) it can be used asynchronously.

END

Cryptography is fascinating both for its history and for its modern advancements. Without public key cryptography the modern secure communications that power our everyday lives would simply not be possible. Ubiquitous secure communications also have a lot of civil implications. We’ve seen spats between the FBI and tech companies like Apple due to their secure devices. The US Government has a long history of limiting the export of cryptographic tools (under ITAR) lest it harm their ability to gather intelligence internationally. Some countries have key escrow services where keys are held by a ‘trusted’ third party and eligible to be seized by the government should they deem it necessary to read certain communications. The security of data and how it’s transported, stored, and secured should be of interest to all of us. If you’re interested in learning more I would point you to the main sources for this post.

Sources:

• Crypto by Steven Levy
• The Code Book by Simon Singh
• Serious Cryptography: A Practical Introduction to Modern Encryption by Jean-Philippe Aumasson
• Diffie-Hellman Key Exchange - Wikipedia
• RSA - Wikipedia

I wanted to write down some of my thoughts on the facts, as I understand them, of distributed ledger tech and draw some conclusions. Unlike when writing about nukes, on this subject I don’t have the shield of amateurism to protect me from my hot takes. I have a degree in computer science, I have been a professional software engineer for 8 years, and I should be generally better equipped than the average person off the street to understand these topics. If you disagree with my conclusions, do it with the happy knowledge that I should have known better.

I am going to write this with the goal of being both accurate and understandable. That said accuracy means we are not going to gloss over some of the underlying computer science or cryptographic underpinnings of these systems. What’s happening under the hood is what drives much of my skepticism. I’ll try and quickly define relevant concepts but some tangential items are beyond our scope.

Caveat: I am aware that there are blockchain implementations that are not distributed (ie Git is basically on a blockchain) but the common vernacular has conflated the term blockchain with crpytocurrencies and distributed ledgers so that is the terminology I am using.

What is a Blockchain?

A blockchain, for the purposes of this discussion, is a distributed ledger. Ledgers keep a chronological record of transactions between accounts, it’s a concept as old as writing and ancient ledgers can give us fascinating glimpse into how people in the past lived. To put it obviously a blockchain is, as it sounds, a chain of blocks. Each block contains some data and a reference to the previous block in the chain. If you’ve studied computer science we have a name for this structure, it’s called a linked list.

One of the core components of a ledger is trust. When looking up an account in a ledger you look for that account’s latest balance. Inherent in this operation is your trust that the ledger, up to this point, has kept an accurate accounting of all transactions such that the balance you see for any given account is accurate. The way we build trust into this structure is through cryptography, hence “crypto” being a moniker for these structures.

Finally the “distributed” part of distributed ledgers is in how they are managed. Traditionally you have a single entity that is responsible for the upkeep of the ledger, this might be a bank or a government. The community relying on the ledger places their trust in that entity to determine if a transaction is valid (does Bob have 10 coins to pay Alice) and keep the ledger up to date. A distributed ledger does the opposite, it places the responsibility of validating transactions and adding valid transactions to the ledger onto the community. The core issues, and strengths, of distributed ledgers are in how they deal with this problem of trust.

So let’s talk about how blockchains are put together focusing on the most famous of them, Bitcoin.

The structure of a block:

In the case of a Bitcoin’s blockchain each block has a header that is made up of three main components (there are additional components):

• The previous blocks hash
• The current blocks data (in the form of a Merkle tree)
• A nonce
• Target hash

The first component is the hash of the previous block in the chain. This serves as a link to the rest of the ledger, in the linked list diagram above we’d call this a pointer as it points back down the chain. Hashes are the output of a hash function, these functions (think math formula) can take in multiple pieces of information and output a string (a series of characters) that is representative of the input but often shorter and of a fixed length. Hashes are used for a variety of reasons including storage and access of data and encryption.

1600 Pennsylvania Avenue NW
Washington, D.C. 20500
U.S.

SHA256 hash of the above data:

2c76193c4ead6909afa629eda14e6d176dfddfdbb0ebad58c68dcbc8e14a19b4

Second we have the data of the current block, for Bitcoin this contains a list of transactions that are to be added to the ledger. Alice gives Bob 10 coins, Bob gives Kelly 2 coins etc.. Before being added to the ledger these transactions have to be validated, Alice can’t give Bob 10 coins they don’t have.

Finally we have a nonce and the target hash. A nonce is a “Number Used Once”, they are arbitrary numbers used a single time in cryptography. The target hash is a number (in hexadecimal) that the resulting hash of the block must be lower than. In blockchain’s that use a proof of work system (like Bitcoin) the nonce combined with the target hash are the underpinning of the entire system.

Trust:

The integrity of the Bitcoin blockchain relies on an idea called “proof of work”, this system relies on the difficulty of adding new blocks to the chain to keep the entire chain honest.

“Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.”

- Bitcoin: A Peer-to-Peer Electronic Cash System

The idea is that the effort required to add a new block containing a fraudulent transaction to the chain and then to keep adding new blocks, such that your fraudulent transaction is on the longest chain, is prohibitive. The work in this case is artificial, the actual validation of transactions is relatively trivial for a computer.

“The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.”

- Bitcoin: A Peer-to-Peer Electronic Cash System

This is where we get to cryptography, one way functions like SHA256 are designed such that determining the input from a given output is impossible short of guessing all possible inputs. Any change in the input will produce wildly different outputs meaning the guesser has no idea if they are close to or far from the original value. The only way to find a nonce that when included in the blocks data produces a hash of the correct value is to guess and check. Nonce’s are 32 bits in size and can hold a value between 0 and 2^32.

To give you an idea of how much work goes into finding a valid hash currently:

Time = difficulty * (2^32) / hashrate

As of 4/1/2022 Bitcoin’s difficulty is = 27,452,707,696,466

Using a rough hashrate (this number depends on a lot of factors) for my computer of 30,000,000 guesses a second (30Mh/s) if I were the only person trying to find a valid hash it would take:

((((27,452,707,696,466 * 2^32) / (30,000,000)) /60) /60)/8760 =  124,628,447.64 years

It’s important to remember that the number is “years of computer work” and that number has real world costs attached to it in terms of power consumption and hardware. In reality this workload is spread across all computers on the network but the sum total of their efforts in a worst case scenario will be the same as above. Additionally difficulty is adjusted by the network every 2 weeks such that time = 10m/block, as more computing power works on the chain the difficulty must increase in order to keep the rate at 10m per block added.

In short, in order to insert a fraudulent transaction into the blockchain the fraudster not only needs to be faster than every other validator they need to keep being faster in order to maintain the longest chain. Unless a single entity controls > 50% of the computing power on a chain the ledger should be secure. This is so incredibly difficult to do that the longest chain can be trusted based on the mathematical likelihood of its validity.

Finally here is a summary of the entire trust workflow from the Bitcoin whitepaper:

“The steps to run the network are as follows: 1) New transactions are broadcast to all nodes. 2) Each node collects new transactions into a block. 3) Each node works on finding a difficult proof-of-work for its block. 4) When a node finds a proof-of-work, it broadcasts the block to all nodes. 5) Nodes accept the block only if all transactions in it are valid and not already spent. 6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.”

- Bitcoin: A Peer-to-Peer Electronic Cash System

So where are the coins?

We’ve established a few facts above:

• In order for the blockchain to be trustworthy, creating new blocks must meet a threshold of difficulty.
• Distributed ledgers require many nodes working together to be secure
• There are real world monetary costs to finding a valid hash

The question you should be asking is why would anyone want to run a node in this set up if it’s going to consume power (and therefore money) and hardware to do so? The answer is that the first node that finds a valid hash gets to add one last transaction to the block, this is a bounty for validating the block and grants a reward to the validator. This is where the term “mining” comes from, new coins are mined/created every time a block is added to the chain as an incentive for people to run a node (or many nodes).

So we’ve arrived at cryptocurrencies. A cryptocurrency is the incentive for individuals to contribute computing power to the ledger.

Wrapping up:

There are a lot of things I’ve not touched on such as:

• How difficulty is set and adjusted
• Nodes and how they coordinate/communicate
• How transactions are conducted and validated
• How data is stored and accessed on the chain
• Extra nonce and other steps for generating an valid hash aside from the nonce
• There are other systems of trust used in other distributed ledgers like proof of stake
• Privacy etc..

If you are interested in the inner workings of blockchains I would advise you to use sources that are as removed from the monetary aspects of the ecosystem as possible. I’d start with the source I’ve most referenced here which is the Bitcoin whitepaper.

Now that we’ve laid the groundwork I want to talk about why I don’t think blockchain is the wave of the future and what blockchains might actually be useful for. That said I don’t write these on a schedule so don’t hold your breath.

Sources:

• Bitcoin Whitepaper - Satoshi Nakamoto
• CEE380 Talk - Dr. David Rosenthal
• Computer Security 161 Cryptocurrency Lecture - Dr. Nicholas Weaver
• But how does bitcoin actually work? - Youtube

Good books on cryptography:

• Crypto by Steven Levy
• The Code Book by Simon Singh
• Serious Cryptography: A Practical Introduction to Modern Encryption by Jean-Philippe Aumasson

Nukes are back in the news again as Vladimir Putin has ordered his tactical nuclear forces into a higher state of readiness. This came about after slower than expected progress made by Russian forces during their invasion of Ukraine and an increase in western sanctions as well as lethal support for the Ukrainian armed forces.

Most people don’t think very much about nuclear arms until they explode onto our headlines, seemingly at random, once or twice a year. Usually this is in the form of a North Korean test, or a new round of talks about the Iranian nuclear program. Luckily there exists a committed group of academics and experts, outside of a military or political apparatus, who do think about nuclear arms on a regular basis who we can learn from.

I want to write a series of posts for lay people, by a lay person, to talk about some of the different facets of the field in slightly more complexity, and hopefully with more competency, than your local news broadcast.

A couple of ground rules:

• Complexity isn’t to be shunned & ambiguity isn’t a failing. Hard problems often don’t present absolute answers, this holds for the subject of nuclear arms.

• I will be pulling from the far deeper work of the academics and thinkers in this field, all sources will be cited.

• I am open to being wrong in my interpretations. I don’t understand this subject as well as many other people.

• I will try and use, as well as explain, the language used by experts in this field. Words have specific meanings in highly technical subjects. Sticking to those meanings and explaining them is better than reducing their precision by translating terminology into more common wording.

Cool, so where do we start?

What is Nuclear Posture:

I want to start here because it’s relevant to current events and frankly I need to start somewhere. What is nuclear posture? How can it be used to interpret current events? Let’s start by defining the term. For this post I am going to rely on Dr. Vipin Narang’s Optimization Theory of Nuclear Posture.

“Nuclear posture is the incorporation of some number and type of nuclear warheads and delivery vehicles, the state’s overall military structure, the rules and procedures governing how those weapons are deployed, when and under what conditions they might be used, against what targets, and who has the authority to make those decisions. Nuclear posture is best thought of as the operational, rather than the declaratory, nuclear doctrine of a country; while the two can overlap, it is the operational doctrine that generates deterrent power against an opponent.”

- Vipin Narang, Nuclear Strategy in the Modern Era

That’s a lot of jargon right out of the gate, let’s try and reduce this very technical definition to its core components.

Nuclear posture is the combination of:

1. What a nation’s equipment allows its nuclear forces to do.
2. How a nation’s policies and organizations allow for that equipment to be used.

Additionally Dr. Narang notes that a nuclear posture and what a nation or government says about how it will use its nuclear weapons (aka declaratory nuclear doctrine) can be different. For example, proclaiming to your coworkers that you are going to ride a bike to work is a declaratory doctrine. The fact that you neither own or know how to ride a bike would indicate that your operational doctrine is in fact going to be car based.

The difference between these two is important and the effects of this gap are observable. North Korea’s declaration that it will use its nuclear arsenal against targets in the US doesn’t provide the same deterrent power as the same threat from Russia. The difference here is that Russia has a nuclear posture capable of making good on that threat, they have missiles capable of reaching the US, warheads that can survive the trip, and a reliable system for ordering the launch. On the other side there are questions about the reliability of North Korea ICBMs, their ability to make a small enough nuke, and if their warhead would survive reentry. In Dr. Narang’s words:

“To put it bluntly, states care more about what an adversary can credibly do with its nuclear weapons than what it says about them.”

Nuclear posture provides us a way to understand the deterrent capability of a nation’s nuclear forces, and the components of a nuclear posture give us some insight into how a state thinks about its nuclear arms.

Types of nuclear posture:

^{Table credit Vipin Narang, Nuclear Strategy in the Modern Era}

Catalytic:

Catalytic states use the ambiguity of their nuclear capabilities and their position as a client state to a major power to get prompt intercession by said power on their behalf. Typically a catalytic nuclear force is shrouded in secrecy with the number, types and operability of their nuclear weapons left deliberately ambiguous. The goal of a catalytic posture is not to actually use nuclear weapons directly but rather to use the threat of nuclear escalation to bring a more powerful patron state into a conflict as a mediator, supporter or belligerent.

Catalytic postures require a patron state to function and thus isn’t operational for the higher rungs of the geopolitical ladder. Additionally catalytic postures are relatively cheap, you don’t actually need to build an arsenal or complex systems for managing one, all you need is a few nukes and a friend in a high place.

^{Bomb casings at South Africa’s abandoned nuclear bomb production facility near Pretoria, original source photojournalist Mungo Poore}

Examples: Israel (pre-1990), South Africa

Assured Retaliation:

Assured retaliation envisions a survivable nuclear force that can credibly hit back after a nuclear first strike. This posture deters by demonstrating a near certain ability to deliver nuclear weapons into an adversary’s territory while at the same time concealing or fortifying it’s forces to a degree that an opponent cannot eliminate a retaliatory threat with a first strike.

States using this posture keep their arsenals under assertive political control. This centralized control minimizes the risk of an accidental launch by giving non military leadership the sole authority to fire nuclear weapons. Oftentime warheads and delivery systems are kept apart, launch codes or keys are likewise kept by separate agencies from those controlling the weapons themselves. The trade off of assertive control is speed, this is an acceptable tradeoff for a state planning on shooting second.

Assured retaliation is the most expensive posture listed here, it requires advanced technology and infrastructure such as long range missiles, ballistic missile submarines (SSBNs), hardened storage & launch facilities like underground silos, or movable missiles on gigantic transporter/launchers (TELs). Most importantly this system needs a reliable system for launching missiles by a central authority, this means planning, drills, hardened communication lines, means of authentication etc.. Any one of these items are a significant investment of both money and time, systems like long range missiles take decades to develop, and places assured retaliation out of reach for many nations.

^{Indian Arihant class balistic missile submarine, credit Zee News India}

Examples: China, India

Asymmetric Escalation:

Asymmetric escalators threaten the use of nuclear weapons in response to any significant attack, conventional or otherwise. These states deter through the credible threat of immediate nuclear use should they come under attack.

Asymmetric escalators prize speed over security of nuclear forces and delegate launch authority and assets to military commanders. Nuclear weapons must be able to be launched quickly and with little warning so their usage is built into military doctrine and their systems integrated into military forces. The tradeoff of this speed is safety, accidental launch is a greater risk in delegatory systems as the decision making is “farmed out” to more individuals.

From a cost perspective asymmetric escalation is somewhat of a middle ground. Nuclear weapons need to be produced in quantity and systems for using them on the battlefield must be developed and deployed but these are much cheaper than the more advanced and hardened systems for a second strike force. Additionally there more complex apparatus for command and control seen in assured retaliatory states isn’t needed here.

^{A Pakistani TEL (Transporter Erector Launcher), credit defencetalk.com}

Examples: France, Pakistan, North Korea

You’ll notice that several major nuclear powers are not listed as examples, particularly the US and Russia. Both the US and Russian arsenals are so vast they essentially pursue both asymmetric escalation and assured retaliation simultaneously, however both maintain strong political control over their arsenal. If you are interested in why a state might select a specific posture and a deeper understanding of the Optimization Theory of Nuclear Posture please read Dr. Narangs book on the subject Nuclear Strategy in the Modern Era from which most of this information was gleaned.

How can we apply this today?

Nuclear Posture can be a lens through which we interpret a state’s actions and declarations surrounding its nuclear force. An example of this are the various interpretations of recent developments in China. In July 2021 new satellite imagery taken by Planet and analyzed by arms control experts from the James Martin Center for Nonproliferation Studies at the Middlebury Institute of International Studies at Monterey (CNS/MIIS) revealed 120 silos under construction by China’s PLA Rocket Force (Article).

^{120 silos under construction in Yumen, China. Credit Planet & James Martin Center for Nonproliferation Studies}

This represents a significant increase in the number of ICBM silos operated by China. On the surface building 100+ missile silos would seem to indicate an intent to threaten the would-be adversaries with a vast nuclear arsenal. Some pundits, lawmakers and observers were shocked by what they saw as a drastic and threatening move by China signaling a new more aggressive nuclear strategy to the west.

“Nicholas Burns, the Biden administration’s nominee to be US Ambassador to China, said during his confirmation hearing last month that the Chinese “are blasting past that definition (of a minimum nuclear deterrent), and they’re rapidly engaged in the buildup of their nuclear arsenal, including the disturbing reports of the hypersonic technology.”

- CNN A change in China’s approach?

However when looking at this development through the lens of Chinese nuclear posture we can come to a different conclusion as to why these silos might be built.

Chinese declared nuclear posture is that of assured retaliation:

“The most recent Defense White Paper, alongside some Chinese texts, makes clear that China plans on using alert levels to signal resolve. ‘If China comes under a nuclear threat’ the 2013 paper states, ‘nuclear missile force will act upon the orders of the [Central Military Commission], go into higher level of readiness, and get ready for a nuclear counterattack to deter the enemy from using nuclear weapons against China.’ “

- Paper Tigers: China’s Nuclear Posture by Jeffery Lewis

Navigating our grid above we can see that this means that China has:

• Assertive political control of launch authority
• Survivable nuclear forces
• Unambiguous capabilities with ambiguous deployment strategies

Silos are certainly not ambiguous deployments at first glance but the layout of the field, particularly the spacing (approx 3km) between silos, indicates that this may be a shell game approach to missile basing. Not every silo needs a missile, but every silo would have to be destroyed in order to assure China couldn’t strike back at an adversary. This aligns with current Chinese nuclear posture as these new silos would be an unambiguous capability with an ambiguous deployment strategy. I subscribe to this view especially given China’s relatively small arsenal of nuclear warheads which number around 350 in total (Source).

While building more ICBM silos certainly isn’t a good thing by applying what we know about nuclear posture we can make a good argument that this is in fact not a drastic change from what China has been doing for decades and probably not cause for great alarm.

For further reading on the history and thinking behind Chinese nuclear forces I highly recommend Paper Tigers: China’s Nuclear Posture by Dr. Jeffery Lewis.

Hopefully this was relatively understandable, I’ll return to the subject of nuclear weapons in the near future. If you want to talk with other amateur (and some professional) arms control nerds come join an awesome OSINT community at the Arms Control Wonk slack channel. If you are interested in this stuff and want to hear from the actual experts I can highly recommend the following podcasts:

• The Arms Control Wonk Podcast
• The Diplomat: Asian Geopolitcs Podcast
• The Chain Reaction Podcast from FPRI
• At The Brink Podcast from the William J Perry Project

Books Mentioned in this post:

• Paper Tigers: China’s Nuclear Posture by Jeffery Lewis
• Nuclear Strategy in the Modern Era by Vipin Narang

“What is the last thing you taught yourself?”

My wife mentioned that this was her new favorite question to ask during interviews. It’s a great question and thinking about it had me going back over what I’d tried, under my own initiative, to learn over the past year. The answer doesn’t need to be some serious or grand undertaking. Learning anything new is an achievement and the goal of the question is for the interviewee to teach the interviewer something, not to pass some arbitrary bar of scholarship.

Talking to others about things you’ve learned is often a sure way of sorting out how well you’ve actually learned something. The ability to explain, even to yourself, is a surer test of understanding than finishing a book or following a tutorial. That’s the entire reason this site exists, as a vehicle and a reason for me to explore, organize and relearn through writing.

Why not just keep a journal? If I’m being honest it’s mostly vanity (why anyone would want to read my musings is beyond me) but something about the act of writing and putting it up for people to see, even obscurely, scratches a creative itch.

So, this website is about whatever I feel like writing about. I’m not going to keep to a schedule or plan (shocking to those who know me). I’m not going to theme or otherwise confine it’s subjects. The content, or lack thereof, hosted here is a reflection of whatever catches my eye.