Arthur C Clarke, in 1953, writing about a post-scarcity future. The last few words are interesting to a bitcoiner! (In this paragraph, "drone" means a lazy person)

I just discovered BIP-42. Good fun, with nice digs at Satoshi

BIP 42: A finite monetary supply for Bitcoin

Read BIPs like a pro.

As I'm going to Madeira in March to meet some freedom-tech folks, I'm going to try to make a plan for what to do this month on the cashu spilman channel - First, write and share an INTEGRATION.md, to explain how to easily integrate payment-receiving code into your service provider. I wouldn't use it for real sats yet, just testing! But I think it's ready for some feedback on the engineering side - While there is blinding of pubkeys already and it's working, it's not identical to the spec in the P2BK nut; it will be easy to synchronize them, I just need to get around to doing it soon. This would be a breaking change, so while it's not urgent, it definitely has to be done - Integrate it into another fun demo. I've made a lot of progress understanding the protocol that is used by many of the LLM providers, so I'll finish a little demo showing how I can resell access to an LLM api key. This might help with getting this tech into Routstr - Then, I should really review all the code again, to tidy up the AI slop 😀. Some parts have received a lot of attention from me, others I've ignored. - And I generally need to get it out there, and get people to review the protocol properly Very rough overview of the architecture: 1. A 'cryptographic' core, which does all the singing and verification and constructs all the outputs deterministically. Has no opinion on transport (JSON, websockets, http), nor on pricing, nor on the service being sold. Written in Rust 2. A 'Bridge' system - written in four languages currently - to expose a convenient wrapper on the server side of things, making it easy to process a payment and either succeed (updating records of the balance and the usage of the channel) or fail (returning a suitable error message). Again, this tries to be *un*-opinionated. It manages the state, but you tell it exactly how to store things (in memory, in sqlite, ..., you just plug in whatever you want). Also, this doesn't care what you're "pricing policy" is; maybe you charge per request, or per megabyte, or per token. You provide the code what computes the price. 3. There are automated tests of the Bridge - via a demo server selling ASCII art - in Python, Go, Rust, and Typescript

Been using Kimi K2.5 today a lot (free now, via OpenCode Zen). Very happy with it. Much better and faster than I expected from an open source model I didn't really try anything complex today, so maybe I'll change my mind when I try something more complex

The blob discovery in Blossom will eventually need to be made more scalable I think. Imagine the nostr/blossom decentralized equivalent of CDN systems like Cloudfare, where your client keeps a large set of servers in a list, prioritizing those with the lowest latency and the best reliability, constantly hopping around as needed to get the blobs And, when we're paying for blossom servers and nostr relays with micropayments, you can prioritize for low cost too of course View article →

X not allowing me to post about coinjoins? (See the blue text at the bottom. I've retried a couple of times)

The cashu spilman channel uses public keys and so we're using P2BK ( @Rob Woodgate ) , Cashu's version of Bitcoin's 'Silent Payments', so that the mint doesn't see the real public keys of the channel participants. Nice to see that the LLM understands that it's working across all four languages that I'm testing with (Rust, Go, Python, Typescript)

Reading a little about how Tor works, thinking of having the user pay the relays via Cashu channel micropayments

Getting started with Arti | Arti

---

I'm genuinely struggling to stop coding every evening. With LLMs, it's just too much fun to continue. I think I'll initiate a 9pm coding curfew