What format/how do I create "queries"?

Otoh, I can't see your replies in gossip. So...

Otherwise I'd be posting my adventures in trying to install notedeck here...

(Cargo gets egui-winit, which wants a newer rustc (!!) than the Ubuntu install, so now I'm trying to use rustup. Which doesn't do anything until you read the docs...)

Wow.

I take it back. gossip is not clunky!

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.

https://wikipedia.org/wiki/The_Elements_of_Programming_Style

In those cases, iterate. Almost everywhere else became non-dups, so will now assert if you try to insert a duplicate...

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

Sorry for the delay, I've been dwelling on this a little. I think that self-custody is easier than many alternatives, unlike with cash: I use Green wallet myself which shows how you can have support while still having ultimate control. I believe Casa have a similar product for larger custody. I hope to see this kind of offering mature, and be attractive beyond the DIY crowd: Bitcoin insurance will be necessarily limited, there are going to be more high profile custody disasters. Also, there's a possibility of generational attitude change: if fiat becomes noticably worse, many people will expend effort looking after their money.

However, that's somewhat of an aside. The question was not those who choose not to custody, but those who can't. What guarantees can we give them, if we can't give them a UTXO? I think, and hope, we can do better than "you all need to trust one of these few people". But I agree this will only get its due attention when enough people are in that group: for now, the low hanging fruit is improving lightning and other L2s which can simply fall back to a UTXO each.

In that model, you never have full custody. Someone sends money into the mint and they hold it on your behalf.

I've had both, but my Logitech trackball is at least 20 years old and still going strong...

(Hi, Lyn, long time fan!)

I'd push back on this, a little. There are definitely cases where I won't have a UTXO, but all the cryptographic solutions I've seen to handle others' failure (malice or incompetence) devolve to me obtaining a UTXO.

In times (and places) of high trust people may forgo this security, but if you can afford it, why would you? "Verify, don't trust" is our entire motto at Blockstream, and while I am not my employer, it resonates.

In my mind, forgoing cryptographic protection for your Bitcoin, if enough people do it, is akin to detaching your issued currency from gold. Seemingly a minor technical detail which has no immediate effect, perhaps. Obviously nobody would be foolish enough to do that, though! 😬

So far I've got the RPI3, RPI5, my Intel laptop and my AMD build machine. Neither of the last two are recent, but I'm not really interested in speed records.

There's some variance: the RPI5 wins at SHA256 for example. The RPI3 loses at everything:) There's real variance in the "fast" ops between RPi and x86. I'll post more when I'm at my desktop.

Importantly, I'm benchmarking the actual opcodes, run through the script interpreter. I really want to benchmark the complete set to make sure there are no surprises...

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 seconds, doing OP_". 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 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.

Yes, just need a round tuit...

I somewhat agree: "trust somebody" can be quite efficient. But it's prone to bad incentives (undeclared fractional reserve) which can drive out good actors (who are not as profitable) *then* collapse. I know nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap09krt7g has thought about this a fair bit, and has a rotating ecash solution which may address it well enough?

Not really, that I can tell. The custodian you are trusting there is the miners.

It's hard to get exact numbers, but a significant fraction of the world will not have enough money at one time to spend a single UTXO. This is clear from the uneven distribution of wealth and the inevitable rise in Bitcoin fees.

Indeed, that's the current effort, in every direction. But it definitely has limits.

British vs American English, sorry.

Lazy content-free post. Blocked.