Bitcoin full node and query server

Oct 12, 2024

View in context in the libbitcoin Slack #general mirror.

evoskuil12:37

It is likely that the default settings will be suboptimal for your machine, even resulting in thrashing. If you post your basic specs I can make suggestions. One of the aspects we are working on is automatically tuning what is presently manual configuration for given platform. Also note that if your CPU supports sha native (shani), which is about 5x faster individual hashing, it will distort realistic benchmarking, since shani is not yet integrated into the hashing library.

cguida01:55

The point is that the utxoset ballooning from 4GB to 12GB has made it no longer feasible to use a RPi 4B as a bitcoin node, whereas before the recent spam attack, it worked just fine. Keeping a high-availability utxoset in RAM makes the sync much faster on low-resource devices. On higher-end devices, sure, perhaps the difference is not massive. Anyway it obviously has no effect on devices with more than <utxoset size> GB of RAM. So if a 12GB utxoset can make a $100 device (the RPi 4B) incapable of syncing the blockchain in a reasonable amount of time, and the utxoset can grow at 40GB/year (the current limit), then in a few years the utxoset might be larger than 100GB, at which point only high-end devices (such as the ones you use to test libbitcoin) will be able to sync the chain in a reasonable amount of time.

FWIW, I haven’t seen the passive LN thing working, and not because nodes are expensive.

It will happen, but we need more time to build automated Lightning agents. These already exist but are primitive.

And keep in mind that libbitcoin is just one project. We have specific objectives. We don’t stop anyone else from making nodes that optimize for a pi with 4MB. But there is no reason a modest PC should take forever to sync.

No one can make the chain sync quickly on a RPi 4B anymore, because the utxoset does not fit in RAM. There are some promising research directions such as utreexo and assumeutxo, but these seem to be far from production-ready and user-friendly. The only actual fixes, that I know of, are to filter spam, make the blocks smaller, or both. Or just give up on low-resource devices being able to sync the chain, until Moore's Law catches up to the 40GB/year utxoset growth cap, in several decades.