chanbackup: always combine with on-disk state when swapping, refuse to start w/ invalid files #4379
Conversation
Roasbeef
added
safety
Roasbeef
changed the title
Roasbeef
force-pushed
the
scb-union-bug-fix
branch
from
0c1334c to
09fb32e
Compare
chanbackup/pubsub.go
Outdated
| } | ||
| } | ||
| for _, memChannel := range s.backupState { | ||
| combinedBackup[memChannel.FundingOutpoint] = memChannel |
There was a problem hiding this comment.
perhaps we should check that if we find a collision we are setting it with the same value? just as a sanity check
There was a problem hiding this comment.
What would the behavior be if the value is different? I think it's better to replace the existing, as the new one might have a new field, or be using a new SCB version. If we want to replace, then this logic implements that as is.
There was a problem hiding this comment.
It's also possible to just leave the duplicate there too.
There was a problem hiding this comment.
that's true, i was thinking even a warning would be nice to see. you're right though the newer one is probably more correct
There was a problem hiding this comment.
Realize now, that the way it is, it'll always print that log statement in the typical case...
In this commit, we fix a bug that could possibly cause a user's on disk back up file to be wiped out, if they ever started _another_ lnd node with different channel state. To remedy this, before we swap out the channel state with what's on disk, we'll first read out the contents of the on-disk SCB file and _combine_ that with what we have in memory. Fixes lightningnetwork#4377
In this commit, we add an additional defense against starting up with an invalid SCB state. With this commit, we'll now fail to start up if we're unable to update or read the existing SCB state from disk. This will prevent an lnd node from starting up with an invalid SCB file, an SCB file it can't decrypt, or an SCB left over from another node.
Roasbeef
force-pushed
the
scb-union-bug-fix
branch
from
09fb32e to
496e29d
Compare
In this commit, we fix a bug that could possibly cause a user's on disk
back up file to be wiped out, if they ever started another lnd node
with different channel state. To remedy this, before we swap out the
channel state with what's on disk, we'll first read out the contents of
the on-disk SCB file and combine that with what we have in memory.
We also add an additional defense against starting up with an
invalid SCB state. With this commit, we'll now fail to start up if we're
unable to update or read the existing SCB state from disk. This will
prevent an lnd node from starting up with an invalid SCB file, an SCB
file it can't decrypt, or an SCB left over from another node.
Fixes #4377