Holiday Party
The highlight of my week was definitely the Atlanta BitDevs + Atlanta BitPlebs holiday party.
I wanted to do something special for the folks who show up to the ATL meetups week after week. After fantasizing about making cryptographic puzzles or dabbling in generative art, I finally settled on making bitcoin fortune cookies.
Now, my fortune cookie baking skills aren’t the best. It was a learning experience. I think I mixed the batter much better on the first batch, so apologies if you received one of the more porous cookies.
What makes them bitcoin fortune cookies? When you crack it open, instead of a fortune, you find a slip of paper with a QR code to claim some bitcoin. Here’s how I made them.
The Process
Before I even fired up the oven, I had to make 40 payment links through Lightsats, the recent Legends of Lightning winner.
At the moment, Lightsats is built for making one-off tips to people and not the sorts of bulk-gift use-cases that I was about to embark on. To make this happen, I first transferred about $80 of bitcoin to my Alby wallet. Then, I held down “Command” and clicked the “create new tip” button on Lightsats 10 times to open it in 10 tabs. I was able to (somewhat) quickly generate 10 tips at a time by holding my mouse strategically over buttons and Control + Tabbing through the tabs.
After doing that process 4 times, I had 40 Lightsats tip links. While Lightsats provides a QR code for each one of your tips link, I felt that it would slow me down for this particular use-case. Instead, I manually copied all 40 Lightsats links into Figma, and use a QR code plugin to generate 40 QRs. I arranged the links and QRs 20 to a page and printed those out. I cut those out and then folded them over into fortune-sized tidbits.
The fortune cookie making process is fairly simple. I used equal parts flour and sugar, and sort of eyeballed the vanilla, almond, and egg-whites. If your batter feels too thick, then don’t cheap out on the egg whites: add more. You want it more on the liquid side.
I then took a baking sheet, dropped 3 drops of batter on them, and let them sit in the oven for about 5 minutes until the edges turned dark.
After pulling out of the oven, I took one of the discs, placed a “fortune” on it, and used a spatula to help fold the cookie over. Then, I let the fortune cookie cool down and harden.
Getting that perfect fortune cookie fold is difficult. I’ll need to practice at that. But functionally, they worked — it was a light brown cookie and you had to break the cookie to get the paper.
PayJoins
I had a call with Dan Gould this week about PayJoins. Dan worked on the Nolooking project, which was another of Legends of Lightning winner. (Nolooking incorporates PayJoins).
Anyways, PayJoins are an interesting privacy technique.
The basic gist: let’s say Alice is sending to Bob. Typically, Alice uses whatever inputs she needs to make the payment, and then one of the outputs goes to Bob and another output goes back to Alice as change. That’s a fairly common type of on-chain TX.
Well, in a PayJoin, Alice and Bob both contribute inputs to the transaction. Bob gets the amount he contributed plus the payment amount, and Alice gets her change. To an outside observer, this TX is a little ambiguous about what is actually happening in this TX. In theory, if enough on-chain transactions are done as PayJoins, then it begins to break the common input heuristic used for blockchain surveillance.
If you’re going to make an on-chain payment, it seems like there’s no harm in doing it as a PayJoin. It could help contribute to your privacy, and can help with UTXO consolidation.
Dan’s opened a PR here on the Guide for a design challenge for a UI flow that helps Bob privately purchase an engagement ring for Alice using a PayJoin. Speaking of the Guide…
The Guide
This week in Guide land:
- Merchants
- We looked at BTCPay this week on our merchant product review call. BTCPay is interesting because its a project that holds so close to its principles that there’s not a clear way to figure out who the users are and what they use it for. It’s a highly configurable tool that can serve a wide variety of use-cases. Maybe it’s more like a platform?
- Next merchant product review is on January 4th and we will look at Tiankii.
- Reviewed a bunch of PRs issue progress for folks.
- Worked on header images for the Guide to try and get a lot of these tiny issues wrapped up by year end. I have an idea for a unified look for the Daily Spending Wallet section. I’ve also taken this as an opportunity to try and get better at working with AI prompts with these header images. Progress narrated below:
Meta
Christoph and I fixed the Github calendar integration this week. It ran into some hiccups. After isolating the problem, I updated the script to leave behind more descriptive logs, so any future issues will hopefully be easier to troubleshoot.
Basic admin stuff. Not the super exciting side of open-source, but is the Github calendar is broke, then calls don’t get added to people’s calendars.
The spice must flow.
Async Payments
I worked on the UX async payments this week. What does that mean? Basically, async payments refers to a method for helping users “receive payments” when their lightning node is offline (e.g. the user has their phone in pocket or purse). What’s really happening is that there is some coordination behind the scenes where the sender’s LSP holds the payment (in-flight HTLC) and then finishes forwarding it once the receiver’s LSP signals that the receiver has come online (e.g. retrieved phone from pocket).
Async payments are an evolving idea. I’m not sure the exact status of the spec. But basically, you can imagine a scenario where some people’s wallets and LSPs support async payments and others do not. So what I’m trying to do here is map out what sorts of things could go wrong during the process of sending a payment and how we reflect that in a wallet’s UI.
Here’s me thinking through all the different entry points for a sender, and then some UI flows mocked up with BTC UI.
And here’s a video of me rambling about this stuff.