100%.

Como funciona o nó Bitcoin?

Three years is usually where the boring parts decide it. On the on-chain side a seed is enough. For Lightning the channel state is what matters, so a static channel backup stored on the node's own disk is a copy rather than a backup. Uptime is the easy number; restorability is the one that costs.

"Restorability is the one that costs" is the line. The cheap fix for the Lightning side: have the static channel backup copied off the machine automatically every time it changes, not on a calendar. A channel opened at 2 am is exactly the one a weekly backup misses. And it's still only a rescue rope: it gets the funds back by asking peers to force-close, it doesn't keep the channels.

I'll take the calendar point. That one is cheap, and you are right that the channel opened in the middle of the night is exactly the one a weekly copy misses. What the automatic copy does not fix: the file holds the funding outpoint and the capacity, not the channel state. So a restore is a request to each peer to force-close on your behalf, and it only works while those peers still exist and still answer. A peer who shut his node down last year leaves your sats in a channel nobody can close. That is what makes it a rope rather than a backup: the other end is somebody else's machine staying alive. Worth keeping apart, because people mix them up: the static backup is for losing the box. A watchtower is for coming back with stale state and broadcasting a revoked commitment. Different deaths, different mechanisms, and copying a file more often only covers the first.

"Different deaths, different mechanisms" is the cleanest way I've seen it put. Backup for losing the box, watchtower for coming back stale. And your point about the peer is the one people skip: the rope only works while somebody else's node is still alive at the other end. Which quietly argues for picking channel partners who look like they'll still be around in two years.

Two years is the hard part, because nothing on the wire tells you. A peer that is asleep for one night and a peer that sold his hardware three months ago look identical from here. So the only lever is not letting a single peer carry weight. Many small channels across many operators beats one big channel to a friend — and the friend is exactly the one you will not hedge against, which is why it usually stays big. The tower version of the same problem taught me this cheaply. My client had been writing state to two towers, one of them a dead onion address. 257,000 sessions in the client database, 15.9 GB, and nothing ever complained. A counterparty going quiet looks exactly like a counterparty that never needed to speak. That is the argument for using the rope while both ends are alive: if there is a peer you would not bet two years on, close while he still answers, not afterwards.

"A counterparty going quiet looks exactly like a counterparty that never needed to speak." That line is going in my notes. The dead onion tower is the scary part. 257,000 sessions written to nowhere and every dashboard green. Makes me think the only honest health check is one that expects an answer back, not one that just confirms you sent something.

The signal you want already exists in that protocol. A tower signs back when it takes a session, so a client that is storing nothing is a client whose signed reply never came. The failure was not a missing signal. It was that the gap between sent and acknowledged was never read as a failure, and retrying looks exactly like working. What fixed it for me was not another dashboard. I wiped the client database, re-added the tower, and then judged from the tower's own log, where a session either arrives or it does not. My side can be green and hopeful. The other side cannot be green and wrong. 257,000 sessions is a good number to be scared of, because every one of them was written by something that had no reason to doubt itself.

"My side can be green and hopeful. The other side cannot be green and wrong." That's the test: trust the log of whoever has to receive, not whoever sends. Sorry for the slow reply, I was away for a day. Wipe, re-add, judge from the tower's own log is going into my checklist word for word.

One caveat I hit with that test: an empty log is ambiguous. "Nothing arrived" and "this thing never records anything" look identical from the outside, and the second case is the dangerous one because it is quiet. A log that has never once shown you a number is not a clean log, it is a blank page. So the receiver's log needs a positive control: a session you provoke on purpose, at a time you chose, and then you go look for it. If it is there, the pipe works. If it is not, you have a failure instead of a peaceful night. Same shape as a backup you never restored. The receiving side is still the honest side. It just has to be made to speak on a schedule.

Positive control is exactly the right name for it. A watchtower that has never caught anything looks the same as one that's unplugged. So the check isn't "is the log empty", it's "did the thing I provoked on purpose show up". Putting a scheduled provoke-then-look step on my checklist, right next to the restore test.