This prevents a panic where an insert is attempted on a nil map via
updateActiveHTLCs. This panic would occur if the channel arbitrator
was in a buggy state, possibly introduced by power loss or via
SIGKILL.
Previously, in `migration25.OpenChannel`, there was a private field
`chanStatus` used to keep track of the channel status. The following
migrations, `migration26` and `migration27` also have their own
`OpenChannel` defined, with `migration26` inherited from `migration25`,
and `migration27` inherited from `migration26`. The private field
`chanStatus`, however, is NOT inherited and each of the migrations uses
its own. This is fine for reading and writing as, under the hood, the
`chanStatus` is just a `uint8` value. Because each migration has its own
fetcher and putter, it can safely access its private field to read and
write it correctly.
The issue pops up when we use the method
`migration25.FundingTxPresent()`. Because it's evaluating its channel
status using its own private field `chanStatus`, this field would always
be the default value(`ChanStatusDefault`), leading the statement
`!c.hasChanStatus(ChanStatusRestored)` to always be true. Thus a
restored channel will be mistakenly considered to have funding tx
present, causing failures in reading the channel info in the following
migrations.
We fix this by exporting the `ChanStatus` field so its value can be set
by following migrations.
This commit adds a new migration to patch the two balance fields,
`InitialLocalBalance` and `InitialRemoteBalance` for the historical
channels. Because they are not saved previously, for historical channels
prior to the revocation log PR, these fields will be empty.
This can cause an intermittent panic otherwise if bbolt remaps itself
via munmap and mmap. From bbolt's documentation:
* Byte slices returned from Bolt are only valid during a transaction.
Once the transaction has been committed or rolled back then the memory
they point to can be reused by a new page or can be unmapped from
virtual memory and you'll see an unexpected fault address panic when
accessing it.
Warning messages are intended to add "softer" failure modes for peers,
so to start with we simply log the warnings sent to us. While we "may"
disconnect from the peer according to the spec, we start with the least
extreme option (which is also not a change in behavior because
previously we'd just log that we received an unknown odd message).
This commit adds Warning messages to lnwire, as introduced in bolts/950.
It does not include reading/writing of warning messages, which will be
covered in followup commits.
This commit bumps the btcwallet version to the latest master branch that
contains the fixes to add Taproot related fields to a PSBT in the
FundPsbt method.
