selectHopHints is the function which constructs hophints otherwise found
in an invoice created with the private flag.
In this commit, we expose that functionality a little more to workaround
needing to create an invoice to retrieve routing hints. Of course, this
is not a perfect solution as the functionality is exposed exclusively to
go users.
We'll want to re-use the abandon channel functionality for the batch
funding, as a cleanup in case the funding is aborted before publishing
any transaction.
We'll want to re-use the PSBT funding functionality from the wallet kit
sub server in the main RPC server. To be able to dynamically obtain an
instance of the wallet kit server we need to know its name under which
it registers itself in the list of sub server. We export the name so we
don't have to hard code it in the main server.
In this commit, we modify the existing logic that defaults to implicit
commitment type negotiation to support explicit negotiation if the new
feature bit is set. This change allows us to ditch the notion of a
"default" commitment type, as we'll now use feature bits to signal our
understanding of a commiment type, but allow peers to select which
commitment type they actually wish to use.
In addition, this explicit negotiation removes the need for using the
required bit of any commitment types. Instead, if an implementation
wishes to no longer support a commitment type, they should simply stop
advertising the optional bit.
This commit adds the ability for a channel initiator/responder to
determine whether the channel to be opened can use a specific commitment
type through explicit negotiation. It also includes the existing
implicit negotiation logic to fall back on if explicit negotiation is
not supported.
This field will be examined later down the stack along with the set of
feature bits to determine if explicit channel commitment type
negotiation is possible or not.
If these bits are present, then both sides can examine the new
CommitmentType TLV field that's present and use this in place of the
existing implicit commiment type negotiation. With this change, it's now
possible to actually deprecate old unsupported commitment types
properly.
In this commit, we add a new ChannelType field as a new TLV record to
the OpenChannel message. During this change, we make a few tweaks to the
generic TLV encode/decode methods for the ExtraOpaqueData struct to have
it work on the level of tlv.RecordProducer instead of tlv.Record, as
this reduces line noise a bit.
We also partially undo existing logic that would attempt to "prepend"
any new TLV records to the end of the ExtraOpaqueData if one was already
present within the struct. This is based on the assumption that if we've
read a message from disk to order to re-send/transmit it, then the
ExtraOpaqueData is fully populated so we'll write that as is. Otherwise,
a message is being encoded for the first time, and we expect all fields
that are known TLV fields to be specified within the struct itself.
This change required the unit tests to be modified slightly, as we'll
always encode a fresh set of TLV records if none was already specified
within the struct.
In this commit, we add a new TLV record that's intended to be used as an
explicit channel commitment type for a new form of funding negotiation,
and later on a dynamic commitment upgrade protocol. As defined, we have
3 channel types: base (the OG), tweakless, and anchors w/ zero fee
HTLCs. We omit the original variant of anchors as it was never truly
deployed from the PoV of lnd.
In this commit, which builds on top of the prior commit, rather than
using the returned buffer outside of the closure (which means it'll be
copied), we instead use it within the `Submit` closure instead. With the
recent changes to the `brontide` package, we won't allocate any new
buffer when we decrypt, as a result, the `rawMsg` byte slice actually
just slices into the passed `buf` slice (obtained from the pool)`.
With this change, we ensure that the buffer pool can release the slice
back to the pool and eliminate any extra allocations along the way.
In this commit, we implement a simple optimization that dramatically
reduces the number of allocations we need to make when we decrypt a new
message. Before this commit, we would pass in a `nil` value to the
`Decrypt` method which meant that it would always allocate a new
buffers.
Rather than force this behavior, in this commit, we pass in the
ciphertext buffer (with a length of zero), such that the decryption
operation will simply copy the plaintext bytes over the cipher text in
place. This works as the cipher text is always larger than the
plaintext, since the plaintext doesn't have a MAC attached.
The amount the perf increase, amount of allocations, and amount of bytes
allocated are pretty nice:
```
benchmark old ns/op new ns/op delta
BenchmarkReadHeaderAndBody-8 88652 75896 -14.39%
benchmark old allocs new allocs delta
BenchmarkReadHeaderAndBody-8 6 4 -33.33%
benchmark old bytes new bytes delta
BenchmarkReadHeaderAndBody-8 65664 128 -99.81%
```
Here old is without this change, and new with it.
After the error is received on the filter update errChan, update the
EndHeight if we're performing a historical scan. If a block was mined
after the call to RegisterConf/RegisterSpend but before the filter was
updated, then the block would not have the filter applied. This means
that a block containing the desired conf/spend parameters would be
undetected. Fix this by ensuring the historical scan also includes this
height, as it would previously not be included.
Moves filter handling logic for connecting blocks to the
connectFilteredBlock method. The disconnect logic now lives in
disconnectFilteredBlock. After updating the filter, drainChainUpdates
is called which will drain everything from the chainUpdates chan and
apply all updates by calling either connectFilteredBlock or
disconnectFilteredBlock. This will allow callers to update their
EndHeight if performing a historical dispatch, as blocks up to this
height may not have had the filter applied.
ConcurrentQueue has internal structures so if a filterUpdate exists
in it, the idea of draining the queue may not work reliably. The
update may exist in the ConcurrentQueue but may not be available via
ChanOut() when we're ready to drain the ConcurrentQueue. Fix this by
using a regular buffered chan, which will either have the update or
not have the update. Its size is set to 100 as our tests may generate
quite a bit of updates.
This mirrors the logic for the spend case. This prevents a double
dispatch scenario when combined with a later commit. Otherwise, the
confirmation would linger in the buffer which is not ideal.
In this commit, we start to optimistically use the new private key cache
that was added to btcwallet. As is, btcwallet will cache the decrypted
account keys for each scope in memory. However, the existing methods
to derive a child key from those account keys requires a write database
transaction, and will re-derive the private key using BIP-32 each time.
The newly added `DeriveFromKeyPathCache` lets us skip all this and
directly use a cache assuming the account info is already cached. The
new logic will try to use this method, but if it fails fall back to the
existing `DeriveFromKeyPath` method. All calls after this will use this
new cached key.
Fixes https://github.com/lightningnetwork/lnd/issues/5125.
Basic benchmark before the btcwallet change and after:
```
benchmark old ns/op new ns/op delta
BenchmarkDerivePrivKey-8 22840583 125 -100.00%
benchmark old allocs new allocs delta
BenchmarkDerivePrivKey-8 89 2 -97.75%
benchmark old bytes new bytes delta
BenchmarkDerivePrivKey-8 10225 24 -99.77%
```
In this commit, we implement a long discussed mechanism to use the
Lightning Network as a redundant block header source. By sending our
latest block header with each ping message, we give peers another source
(outside of the Bitcoin P2P network) they can use to spot check their
chain state. Peers can also use this information to detect if they've
been eclipsed from the traditional Bitcoin P2P network itself.
As is, we only send this data in Ping messages (which are periodically
sent), in the future we could also move to send them as the partial
payload for our pong messages, and also randomize the payload size
requested as well.
