"Hand sanitizer smells sad." My 8yo said this, and they're right. Damn.

Another Lightning Spec Summit complete: this time Tokyo. The good-natured competition among the teams is a steady source of delight, for these are all brilliant people striving to bring something wonderful into the world. They are also respectful and appreciative of each others' achievements: kudos from people you respect has always been a key motivation for working on Open Source projects ❤️ I tried, and failed, to avoid committing to implementing or collaborating on more things. Many have partial implementations already, fortunately. In no particular order: 1. A "marketplace" bolt12 feature for a centralized marketplace to arrange a fee for payment. 2. Completing my draft implementation of the simplified update mechanism (particularly, reestablishment mechanics!). 3. "lnp" payment proof format. 4. Rebase recurrence proposal for BOLT12. 5. Implement v1.5 gossip (once Elle revises it again!) 6. Split keys for comms, messages and payments in node announcements. 7. Proxy support for BOLT 8 handshake. This doesn't count the tasks of reviewing what others are working on, which our team is not leading but are very interested in: bolt12 payment notifications and contact information sharing being two at the top of my mind. It was a productive three days. And, yes, a pile of fun!

BOLT 12 is merged into the spec To applause at the Lightning Spec Summit dinner! ❤️

Last three weeks I've been working on improving payments. Critical to this are five things: 1. Better payment routing, a-la min-cost-flow. 2. Better low-level payment injection API 3. Simpler, more reliable implementation. 4. Better simulation and realistic testing. 5. Better gossip maintenance. For the first, I took the heart off renepay to make "askrene" the payment oracle, which provides "getroutes" for other plugins to use. A primitive version shipped in the current release, but it's already getting better as I start to use it. Today I finished "injectpaymentonion" which takes incoming payments the same way we deal with incoming HTLCs, unifying things that were previously difficult, like self-pay and bolt12 blinded paths that begin at our own node. Tying these together is a new plug-in called "xpay". This calls getroutes then injectpaymentonion, then iterates as results come back, feeding back information to askrene as we learn more about the network. To figure out how well this actually performs, I've got a new format for representing topology, with minimal information (no node names, just channel capacities, details and topology). A simple tool compresses this from a node's gossip store (and decompress back for use). The result is small enough that we can include graph snapshots on our repository for testing. Then I have written a fake "channeld" which simulates payments through this graph (it knows all the secret keys). This needs to be enhanced with simulating capacity of the channels (deterministically, based on a seed value) and realistic network delays, but it already does MPP timeouts and checks fees and cltv delays. This should allow me to test this system's performance in a way that mirrors what people actually see, and also measure it against what we have now. It may uncover bugs, but even better it will let me know where to optimize (min cost flow can definitely be a CPU hog!). And @Alex is working on ideas for more aggressive gossip gathering: if we're missing part of the map we cannot expect to have reliable payments!

I'm working on a new pay plugin called xpay (working title). It's designed to use the new (very WIP) askrene plugin, which provides routes. Actually, most of the work is there, fixing and enhancing that. Especially diagnosis: *why* did it give a weird/no route? Common issues are: there's a good channel but it's offline, or doesn't have capacity, or you don't have enough capacity at all, or the recipient doesn't. We've had issues where gossip is missing, too: detecting when that happens is an open research question, but we'll start probing more aggressively. There have been many complaints about pay in the wild, and the code has grown quite complex. I've heard good things about Boltz's mpay, which is far simpler, so I'm inspired to go in that direction. Moving the routing (which *is* complex!) out is the first step. To be honest, I should have taken a direct interest in this earlier. I considered pay a simple problem, or at least not one I needed to concern myself with. But better late than never!

Started working my way though the classic "How to Win Friends and Influence People" with my 10-yo. I should have re-read this years ago! It's a classic for a reason. All self-help books have to spend 50% of their time convincing you it's worth reading, and the remainder is the actual content. This is why the title is so off-putting to many, BUT the book itself is a gentle admonition on the requirements for nuanced empathy in human interaction, with a very reasoned approach.

Always enlightening to hear directly from Gloria!

Coin Stories with Natalie Brunell • Gloria Zhao on Bitcoin Network Defense: Core Developers, Decentralized Nodes, and Emerging Tech Threats • Listen on Fountain

View quoted note →

I tried (and somewhat succeeded) in taking a week off work. Unfortunately, I did rework the nostrdb cursor code, because it annoyed my sensibilities of how iteration across protocols should be written. I'm still not happy with the results, but I did find some bugs! And reading code by changing stuff and reading the compiler errors has another problem: I still don't know exactly what this code is trying to *do*!

#gsr I had a quick call with Brink engineers, on my Script work. Now I just need to polish things a bit more and actually release a prototype that people can sink their brains into...

Rusty Russell on the Great Script Restoration

Rusty Russell discusses the Great Script Restoration proposal.

#cln #dev #someday Wallet "Intents" With anchor channels, lightning nodes were forced to get smarter about tx construction. (Kind of funny, nobody really wanted to write a Bitcoin wallet, but here we all are). You have a deadline, user wants to spend as little as possible, you have to use CPFP to boost the commitment tx, and bring your own fees for any HTLC txs (which are now single input/output ANYONECANPAY|SINGLE). I did the minimal things to get this to work, but it brings me back to the question of how these things *should* work. I don't think the primary interface for a wallet should be "spend these utxos to create this output" but "do this by this time, with this budget cap". The wallet should figure out how to do it. For example: sources include onchain funds, splicable channels and even closing channels. What if the wallet code had a rough "cost" for each of these? Sinks include splicing in, onchain outputs (maybe to cold storage?) or new channels. And there are also specific txs you might want. It should combine them opportunistically (and later, pull them apart if priorities change). There are several problems though. The first is complexity: this is not trivial to get all the cases correct, and all the combinations. The second is related: understandability and debugging is hard too: what did it do, what did it decide *not* to do, and was the result optimal? i.e. why? But mainly, how to present this to the user? Or the plugins that they use to direct it? They need to know that funds are coming to them (especially since we low-ball fees for non-urgent things). Plugins will want to see PSBTs before they get signed, so they can do clever things (coinjoin, open new channels, combine in other ways). The upside of all this is maximum efficiency, and a side-helping of more confusing transaction graphs. Both of which help everyone. This is currently an idle thought: it's not going to reach the top of my TODO this year, for sure!