In this commit, we migrate all the code in `channeldb` to only reference
the new `kvdb` package rather than `bbolt` directly.
In many instances, we need to add two version to fetch a bucket as both
read and write when needed. As an example, we add a new
`fetchChanBucketRw` function. This function is identical to
`fetchChanBucket`, but it will be used to fetch the main channel bucket
for all _write_ transactions. We need a new method as you can pass a
write transaction where a read is accepted, but not the other way around
due to the stronger typing of the new `kvdb` package.
In this commit, we create a new package `kvdb`, which is meant to serve
as the basis for any future database abstractions within `lnd`. Rather
than directly use the `walletdb` package (which we base off of), we
instead use a series of type-aliases to re-type the fundamental
types/interfaces of the `walletdb` package. This lets us type
`kvdb.RwTx` instead of `walletdb.ReadWriteTransaction` everywhere.
Additionally, our usage of type-aliases is also intended to create an
easy pathway in the future wherein we can gradually re-defined or
re-implement these types to wean off of the `walletdb` package.
Sweeping anchors and being able to bump the fee was already added in a
previous commit. This commit extends anchor sweeping with an anchor
resolver object that becomes active after the commitment tx confirms.
At that point, the anchors do not serve the purpose of getting the
commitment tranaction confirmed anymore. It is however still possible to
reclaim some of their value if using a low fee rate.
Preparation for anchor resolver. The recovered anchor amount should
still be included in the pending channel report even after it has been
resolved.
This also fixes an existing bug that in some cases caused the recovered
amount from an htlc resolver not to be included in the total.
Start anchor sweep attempts immediately after the commitment transaction
has been published. This makes the anchor known to the sweeper and
allows the user to bump the fee on it to get their commitment
transaction confirmed in case the fee committed too is insufficient for
timely confirmation.
There was a recent change merged into btcd that isn't backward
compatible with older RPC clients. To make sure our docker quick
start example still works, we need to pin down btcd to the version
that is still compatible with lnd.
Prior to this change, the trigger height for closed channels was set to
the current best block height. As this height is in some cases used as a
height hint, the spend may have been missed.
Exclusive group is a static property that doesn't need to be updated.
Requiring the exclusive group to be passed into UpdateParams creates a
burden for the caller to make sure they supply the existing group.
This change will be beneficial for users that bump anchor sweeps that
have exclusive groups set.
This change adds a set of errors to the peer struct returned by list
peers. A latest error boolean is added to allow for more succinct
default lncli responses.
Add an error buffer to the peer struct which will store errors for
peers that we have active channels with. We do not store these errors
with peers that we do not have channels open with to prevent peers from
connecting and costlessly spamming us with error messages. When the peer
disconnects, the error buffer is offloaded to the server so that we can
track errors across connections. When peers reconnect, they are created
with their historic error buffer.
This commit introduces a fixed size circular buffer which stores
elements in a fixed size underlying array, wrapping to overwrite items
when the buffer gets full.
In this commit, we extend the current SCB recovery tests to also cover
the new anchor commitment type. We only add a single test that covers
the most common case to avoid needing to tests all cases for all
commitment types which is being done in a follow up PR.
If a peer receives a channel reestablish message shortly after the
channel has been closed, it will resend its own channel reestablish
message. In the meantime the other peer could also have seen the channel
being closed and will also resend its own message. This leads to a
resend loop that never terminates.
To avoid two peers getting into this situation, we now allow only one
such resent message per conection.
