Overview

The official Summer of Bitcoin (SoB) internship began on May 15, 2025; however, due to academic obligations and personal matters, I didn’t start the project until Sunday, May 18, 2025. Nonetheless, I’ve made solid progress over the past week. During my weekly meetings with my mentor, Matt Morehourse, we agreed on a basic work plan for the project. I didn’t have to face a lot of the initial hurdles that come when starting work on a new project—thanks to the work I put in pre-SoB—and started working right away on improving the tests. The enhancements I added to the fuzz tests may have uncovered some bugs, although this isn’t yet certain.

Goals accomplished

  • Added improvements to fuzz-addr: Before this improment, fuzz-addr only tested encoding via encode_scriptpubkey_to_addr(), without checking decoding. I added a round‑trip assertion: if encoding produces an address, decode it back with decode_scriptpubkey_from_addr() and confirm the result matches the original scriptpubkey. Full details of the change can be seen at PR #8297.

  • Add a test for amount-{sat, msat} arithmetic: While reviewing the fuzz-amount test, I noticed that many procedures in the target file, common/amount.{c,h}, were untested. I decided to write a test for the arithmetic operations, since they may receive input from untrusted sources.

    The test revealed two potential bugs: one in amount_(sat, msat)_scale(), where negative scale values aren’t handled properly, and another in amount_msat_sub_fee(), where certain parameter values can trigger assertion failures within the function. I’ve already submitted PR #8306 to fix the first issue; as for the second, I need to investigate further before confirming it as a bug. Details of this change can be seen at PR #8298.

  • Added improvements to fuzz-bigsize: Added a couple of small improvements to the fuzz-bigsize test. The resulting PR can be accessed at PR #8301.

  • Added improvements to fuzz-bech32: The existing test for fuzz-bech32 only tests 5-to-8 bit conversion. I added a roundtrip check for 8-to-5 bit conversion as well to test the conversion procedure more thoroughly. I plan on pushing this change in the near future.

  • Added a test for error/warn message handler: My current strategy for adding new tests to the suite is to go through the BOLT specifications and fuzz the message handler for each type of message. As such, I decided to start with BOLT #1 and discovered that handle_peer_error_or_warning() in common/read_peer_message.{c, h} is responsible for parsing any incoming error or warning messages, and hence added a test for it resulting in PR #8304.

    The test is WIP for now because the target crashes when run, potentially due to a bug in the message handler. I did some investigation around the breakage and concluded that there’s a good chance this isn’t a false positive, so I informed Matt and he told me he’d look into it later.

  • Reviewed other tests: Besides the ones above, I took a look at the following tests but couldn’t think of any ways to improve them so they’re off the checklist for now: fuzz-bolt12-bech32-decode, fuzz-bolt12-invoice-decode, fuzz-bolt12-invrequest-decode, and fuzz-bolt12-offer-decode.

  • Added a test for BOLT #12 check_signature(): common/bolt12.c::check_signature() verifies incoming peer signatures according to the BOLT #12 specification. While reviewing the fuzz-bolt12-* tests, I noticed that common/bolt12.c::check_signature() was untested by the current suite. Hence, I added a new fuzz test to ensure check_signature() correctly validates signatures received over the wire. I plan on pushing this test to upstream soon.

  • Polished previous patches: I received feedback on my previous work—like the differential test for HMAC-SHA256 that I developed before SoB, as well as some of the changes noted above—and spent time addressing them to secure an ACK for each update.

Next week’s goals

I plan on using the same strategy for the next week that I used this week, which is to divide my time into incrementally reviewing the existing tests and working towards writing a new one. With this being said, here are some of my immediate goals for the next week:

  • Investigate the potential bug in amount_msat_sub_fee(): After discussing this with Matt, we recognize that when one of CLN’s assertions fails, it typically indicates a bug—potentially severe if an attacker can provoke it. I will investigate whether an attacker can trigger this assertion failure. If so, it represents a DoS vulnerability that must be promptly reported to the CLN team. I attempted to simulate such an attack by adding a test late last week, but it proved inconclusive. I will continue from where I left off and aim to identify a substantive issue.

  • Investigate the potential bug in handle_peer_error_or_warning(): This “dereferencing NULL pointer” bug was detected by UBSAN. I’ve performed an initial investigation, but I have additional ideas that I believe will yield stronger conclusions. I plan to explore these over the next week.

  • Review fuzz-bip32 and fuzz-bolt11: I believe I’ve already reviewed these two tests, but I don’t have a commit or note to confirm it. I’ll revisit them to identify any possibilities for improvement. Going forward, I’ll note down each test I review—especially since I’ve been working through them out of order.

  • Review other tests: I plan to review at least five new tests next week. This will help me stay aligned with the schedule I outlined in my proposal.

  • Finish tests for BOLT #1 message handlers: I plan to complete the BOLT #1 message handlers by midweek. I’ve already identified where most of them live, so this shouldn’t be too difficult.

  • Start working on BOLT #2 message handlers: Given the timeline, I’ll begin work on the BOLT #2 messages next week. With twelve BOLT specifications in total, aiming to complete one spec per week is the reasonable goal.

Challenges

I encountered several challenges this week but made steady progress. Fixing the fuzz-amount-arith test proved difficult—while they still fail, I’m hopeful this reflects a genuine bug in CLN rather than my implementation. I also ran into linker errors, but after some digging I discovered tools/update-mocks.sh, which generates mocks for missing functions. Since it only covered unit tests, I updated the Makefile to include fuzz targets as well, alleviating many of my linker concerns.

Identifying the BOLT message handlers was tricky because of similar names across functions and files, but I think I have the hang of it now. Aside from these bigger hurdles, I encountered a few minor issues—but nothing I couldn’t resolve with assistance from Matt or AI tools. My prior work—including pre-SoB contributions and other open-source experience—proved invaluable for overcoming these day-to-day problems.

Matt is on vacation, so our next meeting is scheduled for next Monday. In the meantime, I hope to achieve solid results from my bug investigations and to review and add a substantial number of tests without compromising quality. If I stick to my plan, this should be entirely feasible.

Till next time,

Chandra.

<
Previous Post
Onto a Summer of Bitcoin
>
Next Post
SoB: Week 2