Sep 4, 2026

The near-daily WTF discovery today is this... In the scantxoutset method Core returns the unspent outputs of an address. Of course it has no address index, so it just searches the entire utxo index. So just for fun it returns in the response, not just the relevant unspents, but the count of unspents that it searched (i.e. the size of the utxo index). This number isn't useful for anything, but they just have it so why not send it. So we have an implementation of the method that does the same - a full scan of the chain, about 25 sec, and returns the nonsense number. But with the address index enabled, we can return the answer immediately - but without the utxo set size. I've implemented it such that when there is an address index, the set size just returns the found size, and without it we do the full scan (just for this one method). But today there are two fun warts. http is half duplex, so you can't make a second call with a first call pending. But these calls are slow. So what Core does to get progress or cancellation for these calls is to accept those from an independent call. A second call asks if there are other calls outstanding on another channel, and allows a second call to cancel them (instead of the first caller just dropping the connection, which is what we do). And of course if the call hasn't returned yet, you know it's in progress still. So why do this? Because they don't monitor the socket for drop when there work in progress. As a result, when the first caller drops, there's no association to the work in progress. So the long-running query just keeps running! So a second caller can say hey - stop that other call that I dropped. And you might be wondering, can the orphaned calls accumulate? No, because they allow one channel scan to block scans on all other channels. Seriously, it's this stupid.