Hello,
I had a question about LN nodes and disk space. I am sure that nodes use up space over time on the hdd, what is it comprised of and can it be reduced from time-to-time to make a node "lean"?
Aside from the blockchain needed (in theory you could use pruning, but you have to be careful, and ensure that lightningd dying means that bitcoind is automatically stopped, somehow, and vice versa)?
Every channel needs the full history of every HTLC that ever passed through it. This is because revoking HTLCs requires revealing the hash and timelock involved. This is unprunable unless you close the channel (which you might not want to do since usual autopilots often use channel lifetime as a proxy for reliability). The revocation keys themselves are stored in a large data structure with constant space, which basically limits channels to 2^48 updates, which should be enough for everyone.
Otherwise, historical data like invoices that have been timed out or received, and payments/forwards that you have failed or passed, can be removed arbitrarily. Gossiped channel data (the routemap) can be removed arbitrarily as well in theory, but if you do, you have to turn off pruning on the blockchain (channel gossip uses short-channel-ids, which are tiny, but require a complete blockchain copy in order to validate; they cannot be validated using just the UTXO set, which is all that is retained in a pruning node).
The only security-required data is the HTLC data, which is unpruneable until a channel is deeply confirmed to be closed.
A data point: my C-Lightning node has been up for a little over a year, and…
lightning=> select count(*) from channels;
count
-------
919
(1 row)
lightning=> select sum(out_payments_fulfilled + in_payments_fulfilled) from channels;
sum
-------
86772
(1 row)
lightning=> select pg_size_pretty(pg_database_size('lightning'));
pg_size_pretty
----------------
933 MB
(1 row)
So the space requirements aren't that severe.
A side note to any curious onlookers: yes, I did migrate C-Lightning's SQLite database to PostgreSQL at some time in the middle of the life of my node. There were a few gotchas to watch out for, but I've had no database-related issues with my node since the migration (and performance is vastly improved).
@d4amenace has your question been satisfactorily answered?
Yes thank you
okay, closing as resolved.