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 ...

Honestly, surprise on the up-side is nice. Unusual. But let's take our wins! ❤️

Honestly, I'm still struggling with Bitcoin soft fork proposals. I believe we will end up with full introspection: there are too many things people want to build which require it. But most current proposals are workarounds for current limitations, which will become vestigial when/if we actually fix things. They may be simply unused, or worse, not quite useful. And it's hard to know: if we had restored script and introspection, we could see what people build and then go "ah, this opcode would make this more efficient!", but without that we are guessing. So I really have to figure out if mevil is real. Serious people have concerns, esp @Matt Corallo, so they need serious consideration. If I can convince myself it is either not an issue or independent of script power, then I can reasonably purpose what Bitcoin would look like with maximal expressive power. After that, I can look *backwards* and see if any subsets of that power make sense as stepping stones. I initially thought CTV (well, a more straightforward variant) made sense, as a common case, but brief discussions with Jonas Nick have me questioning whether it actually is still useful with full introspection (or, more clearly, what the right form would be). As an aside: I think sponsors (done optimally) are necessary for any Bitcoin high-fee future. Feels like a side-quest though! Sorry I don't have answers. This stuff is *not* simple, the details are critical, and some of our best minds from previous eras are absent :(

FFS. Someone says someone said Trump said he holds a lot of Bitcoin. There is no signal in that noise. None.

I think it was after my first year at Blockstream I asked if I could have regular 1x1s with then-CTO Gregory Maxwell. I was, perhaps, too inexperienced at that point to take full advantage of that, but his form of thinking has been a model for me on how to think about Bitcoin, though I don't always agree with him. Needless to say, his receipt of the #finneyprize along with Pieter Wuille is fully deserved. It's hard to think of who could even follow that pair, to be honest! finneyprize.org

Wait, you haven't seen The Princess Bride? (Now I'm trying to figure out the easiest way to stream this while on vacation...)

I am a little surprised by those buying into the idea that Trump will lead a deficit-reducing administration. I expect conflict, chaos and massive falling out, with the result being business as usual.

I don't usually find Nic compelling, but I'm enjoying the thoughtful contrariness of this piece, opposing a Bitcoin Strategic Reserve (and predicting it won't happen):

Bitcoin Magazine

I Don’t Support A Strategic Bitcoin Reserve, And Neither Should You

Nic Carter lays out his arguments against a Bitcoin Strategic Reserve.

#CLN release 24.11.1, for those fans of xpay. I've been impressed how many people are testing it, and especially those who go all in on the #reckless "xpay-handle-pay" setting! BTW: did you know you can use the "config" command to set `xpay-handle-pay` *on the fly*?

GitHub

Release v24.11.1: The lightning-dev Mailing List II · ElementsProject/lightning

This is a quick release due to the popularity of xpay, especially using the (reckless!) `xpay-handle-pay option. Highlights: xpay compatibility im...

Antoine Poinsot

On Soft Forks

Some thoughts on Bitcoin soft forks, and Bitcoin Core, in light of the recent interest in introducing more expressiveness in Bitcoin Script.

In which Darosior explains quite coherently why there's not a great deal of *technical* motion on a Bitcoin soft-fork. Seems like a fair, rational summary.

The only thing dumber than talking about the Bitcoin price is making Bitcoin price predictions.

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.

BTW, Rearden (apparently from Jeremy?) pointed out that my simplified CTV-like scheme was flawed because it didn't commit to the order of input txids. You need to xor SHA(inputnum | intxid) for each input to fix this. I still like the scheme, because it clearly commits to everything the txid commits to (with modifications required by efficiency concerns). Like a "forward txid" to mirror the normal txids which are backwards references. I should write it up, for comparison with CTV. Maybe once I've done that I'll no longer think it's a significant simplification?

I'm slowly coming around to the following roadmap: 1. Simplified CTV for whole-tx commitments (ie you *will* spend this output using a tx which exactly like X. 2. Optimised sponsors for solving the "but how do I add fees" problem in a way that doesn't drive miner centralisation. 3. Script restoration so we can don't have arbitrary limits on things like amount arithmetic and examination sizes. 4. Introspection opcode(s) so we can examine txs flexibly. 5. Script enhancements for things like merkle proofs (e.g Taproot trees) and tweaks, checksig. You could argue that #1 is simply an optimisation of #3/#4, and that's true, but it's also an obvious case (once you have #2) that we will still want even when we have all the rest.