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:

Signal Community

Mute / custom reaction notifications

Just opened a feature request that got closed as a dupe of this. I want a separate custom notification for reactions. This would be a killer addit...

Linux desktop nostr apps? I'm using gossip, but it feels clunky. Prefer desktop for writing detailed posts: mobile is optimized for consumption, not production :(

It's 50 years since the greatest book on programming was published! Elements of Programming Style. A few years back, when I couldn't find mine, I swept up a half dozen copies and Niftynei mailed them to me.

The Elements of Programming Style - Wikipedia

#cln #dev So, we've had this annoying intermittent bug where UTXO spends would get missed. Sometimes it meant that we would keep gossip for channels which had been spent, and sometimes we'd miss opportunities to sweep funds (more concerning!). Eventually I started to suspect our (my!) hash table implementation. It's extremely efficient, but if it had some bug it could explain the issues: it has a random seed for the hash function, so weird corner cases would appear random. I wrote some random churn tests, nothing. I could get more elaborate, of course, but then something else happened. Shahana wrote some code to create all our new documentation examples, which involved getting nodes into all kinds of weird states, and hit a strange bug. I tracked it down to a case where the recovery code was putting a new peer into the hash table, where one already exists. Easy bug fix, but it made me wonder: were we doing this elsewhere? My hash table code allows duplicate keys just fine. But it's actually unusual to want that, and there are APIs (get, delkey) which only handle the first one vs getfirst, getnext which are fully generic. So, I wondered. Did we make this mistake anywhere else? I bit the bullet and split the APIs: up front you now declare what type of hash table you want (duplicate keys or nodups) and you don't even get the deceptive APIs for each case. As you might expect, the only code which had a problem was the various places where we watch UTXOs. You can absolutely be watching for the same thing in multiple places, and indeed the code was not iterating, but only handling the "first" one. And this was all my own code, front to back. Mea culpa. APIs matter. The natural use of an API should be the correct one. And of course "don't patch bad code, rewrite it" a-la Elements of Programming Style.

Jeremy Rubin asked on Twitter what was happening with #GSR. Good q! After far too much fiddling with benchmarks I now have preliminary numbers. Budget is 5200 varops per weight. Fast ops (compare, zero fill, copy) cost 1 varop per stack byte. SHA256 costs 10 per byte. Everything else costs 2 per byte. I need to clean up my benchmarks so everyone can run them, and get "on your machine the worst case validation would be <X> seconds, doing OP_<Y>". That's concrete and gives us a chance to find any wild machines which are unexpectedly slow, and gives a tangible worst case, which should allow fruitful discussion I also need to write code to answer "what input size (if any) would cause <this script> to exhaust it's varops budget?". This again enables us to think concretely about my thesis (yet to be proven to my satisfaction!) that it's possible to have a budget which allows any reasonable scripts not to worry about it.

I'm disappointed that @Peter McCormack never got an answer to his question about what Bitcoin looks like to those who can't afford a UTXO. This is an important question, maybe *the* important question. But it also underscores how much he diverged from his "pleb everyman" origins: this is very much not a newcomer question! Guess I won't be on WBD to answer it, either!* *Spoiler: I don't know the answer, but I can describe the possibilities and issues people can (and are!) exploring...

I am sometimes haunted by the phrase I heard log ago from Eben Moglen: It's wrong to be right too soon.

Just got a "call" from "Ledger Live Support". MtGox bringing them all out, I guess. Be careful!