They're fixing it: after some testing, apparently this one wasn't our fault (on CLN v24.08rc3)

Surprised me too!

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*!

Audio should be fine. There's one graph, I think.

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

https://brink.dev/blog/2024/08/22/eng-call-great-script-restoration/

And of course, since it's making a tx already it might be a good time to cross-splice funds from once channel to another...

Absolutely. You can theoretically do that already, but I don't want to have to do the math, I want to just say "open a channel to X" and have it figure out where to get the funds. It might be optimal to use onchain funds, or even close down a low-utilization channel entirely into the new one.

Then it depends entirely on who will watch? Neither Schiff's regular audience nor Bitcoiners are going to be persuaded.

Are you going to change anyone's mind?

#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!

The fundamental difference is between defined benefit (pension scheme) and defined contribution (super). The latter *is* thought of as an entitlement, but the separate accounting makes that closer to the truth?

Ofc, poor overall economic performance will hurt super (in Australia, this means if property prices ever go down, we're screwed).

I suspect the govt will raid the outliers during some crisis ("who needs $10m of super?" they will cry) probably using exit taxation. This political risk from here to my retirement is significant, which is why I've never topped up mine.

Yeah I've been reading your parsing code. We have to talk 🤣

If you put it that way: I guess I'm also betting 2M sats it won't work :)

Australia transitioned away from defined benefit schemes in the eighties and early nineties, and has increased retirement age (not a legal concept here, but when you can access a pension or your benefits) has been increasing too, from 55 when I was young to 67 currently.

I'm not a huge fan of the resulting system in its details, but it's a sign that people and politicians used to care about longer-term thinking. (Interestingly, these reforms were from the Left, not Right, which maybe explains why they happened?).

nostr:nprofile1qqsda57m8y2cga9g6807kdqquhcuyphcn5wff4tecx8t9fu6j5pqg0spzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcprpmhxue69uhkummnw3ezuendwsh8w6t69e3xj730qyt8wumn8ghj7un9d3shjtnwdaehgu3wdejhgtcdr6h5g put his hand up first, hes taking a look. I think the coding might be the easy part though: getting the PR merged is another thing altogether...

Simple rework PR up. I also want to update your BOLT11 parser to the latest (it's buggy).

I need to think harder about your cursor API: my instinct is to split it into two types, one for reading, one for writing. But you do a lot of lookahead in your parsing, so the classic "mark cursor invalid if we hit an error" pattern doesn't fit. Hmm....

Let's see what I can do after lunch then. Fun!

Me! I wrote an Android app years ago, but not my jam. Someone who knows what they're doing can probably do this in 1/100th of the time I can...

Any Android devs out there? I will pay 2 million sats for someone to implement the option to customize Signal notifications for *reactions* separately from new messages.

Conditions:

1. Ping me first! It's not a race, you gotta get public agreement from me to enter.

2. Gotta get it merged and shipped so I can install it on my Android phone.

3. You have to have fun!

References:

https://community.signalusers.org/t/mute-custom-reaction-notifications/14931/20

Yeah, it's a well-kept secret unfortunately.

Rough skimming code review:

1. bool is your friend, int is for old people :(

2. You should use ccan/ directly not in pieces: easier to update.

3. Your cursor API makes me cry, can I rewrite it? It's going to hurt somebody.

4. Do you want neatening pull requests?

Reviewing. You should have used tdb, of course, but as Tridge said, you don't need an excuse to rewrite something!