Hey @ODELL should I be pitching @Century Metadata to OpenSats?

I'm back wearing a Pebble watch! I loved the original, and wanted to support the reboot. Let's see how we go after a month...

This is really touching! I loved working on #bitcoinlightning and #CLN over the years, and I leave both in excellent hands. Lightning is going to be so much more than it is now... View quoted note →

I don't understand why @jb55, @ODELL and @Ben Arc hate each other, and at this point I'm afraid to ask...

Official Bitcoin Twitter Self-Worth Chart $70k: your hairline recedes. $60k: gangrene develops. $50k: you lose the ability to make coherent sentences, and all you can say to your panicked loved ones is "Bitcoin is digital energy". $150k: erectile dysfunction vanishes. $250k: your wife returns with the kids, saying she made a terrible mistake. $500k: your long-dead father rises from the grave, tells you that he was wrong and you were right, and he's proud of you.

Don't support things you don't want to see more of.

I love BIP 93, with its ability to store any secrets with super-high redundancy and natively handle multiple shares by hand. But I also love BIP 39 for the simplicity of 12 words, and the universality of the standard. I want a word scheme for BIP 93. It would be 20-23 words(depending on what scheme is used), but highly redundant. You could recover with 3 or 4 unknown words. Ideally the word list would avoid near-miss words, and be distinct from BIP-39 enough that it would likely be distinguishable, rather than relying on the strange number of words. Should this exist?

So, there's a place offering Bitcoin-denominated life insurance. Here's the problem though: they invest the funds to make return in *Bitcoin*. But there are few if any Bitcoin-native opportunities. We also know that Bitcoin's gains are in a handful of market days per year. IOW I cannot see a way of making "conservative" investments and outperforming Bitcoin, since such investments will be dollars. If it seems too good to be true ...

I mainly end up hiring workaholics. This is a consequence of seeking passionate, smart people who love their work. So as a manager I mainly find myself telling them to take more leave and asking pointed questions if I receive an email from them far outside hours in their TZ. But it also means I model the behavior I want, which helps me regulate my own hours. I have youngish kids, and my wife has her own career, so I try to stick to my weekly work hours. And I broadcast that to my team. I want to work with these people for a decade, so it's a marathon not a sprint.

xpay (not *coat*, thanks autocorrect!) bug reports trickle in. I'll try for a .1 release this week with fixes. I am impressed by the number of people banging on it: some of the things I knew were sub-optimal (esp if you tell it to override the pay command) now seem more important. Away early January, and Blockstream gave us all the Xmas week off, so this week is critical. Like, y'know, every other week!

So, a lovely interaction with Jeremy Rubin where he shattered my XOR simplified CTV scheme. Damn. So I'm banging my head against the problem some more. I want "txid with this input txid zeroed" but that can involve too much hashing in the worst case. Even if you move the txids to the end: about 250 GB according to my rough calc. Jeremy suggested a merkle tree, which can work, but we're getting uncomfortably far from "simple" now. Specifically, my bar is "how hard would it to be to produce this *in Script*, assuming that's fully re-enabled?". Not too bad with a known number of inputs, but I don't want to even think about dealing with arbitrary numbers. Varops budget doesn't really help here, either. Everywhere else, you can't hit the varops limit unless *your input script* is doing wild things: this would mean you can hit the limit with a single opcode in a reasonable script :( You're better off just saying "your tx which uses this opcode must have no more than 64 inputs" or "no larger than 10k", but that feels totally arbitrary. For those following along at home: CTV solves this by committing to just the number of inputs, and if that's not 1 you're kind of on your own. It's not *banned*, just shrugged. I dislike this hole, but do I dislike complexity more? This is what I ponder over morning coffee before Real Work.

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!