pull down to refresh

103 sats \ 3 replies \ @Murch 28 Feb \ parent \ on: How to set up a Raspberry Pi node lightning bitcoin_beginners

txin verification would indeed make me think that it’s the retrieval of UTXO cache misses. I’ve been hearing that the disk interface of Raspberry Pis is pretty slow, so the disk itself might not be the issue, but rather the speed at which the Pi talks to the disk?

the main issue are secp256k1 functions

Is this during the full validation part of IBD after passing the assumevalid block? Otherwise, I wouldn’t expect many calls to secp.

write
compose
45 sats \ 2 replies \ @optimism 28 Feb

It starts slowing down before that (around block 790k), but it gets real nasty after it (840k+ on 29.x). I'm not 100% convinced that it is only secp - am natively compiling bench right now for 26, 27, 28, 29 and 30 - see if I can spot a regression

reply
103 sats \ 1 reply \ @Murch 28 Feb

Mh, the default assumevalid block was 886'157 in v29.0.

Oh, you know what? I have a theory. There was a period of time when people started to churn UTXOs to sift for rare sats. Perhaps the slowdown coincides with a big increase of old UTXOs being spent?

Looking at a UTXO Age band chart, the number of coins held in UTXOs older than one year peaked in November 2023. I haven’t found data on UTXO counts itself yet.

reply
45 sats \ 0 replies \ @optimism 28 Feb
There was a period of time when people started to churn UTXOs to sift for rare sats.

This is plausible, as well as massive consolidation of near-dust. The first ones I found that were slow going were blocks that were heavy on consolidation txs.

reply