In this commit we add an extra config for enabling logging to an
external file when using embedded etcd. This can be useful when running
integration tests to see more details about etcd related issues.
This PR changes a link in the section Developer Resources from dev.lightning.community (unmaintained) to docs.lightning.engineering.
It also specifies more clearly what readers can expect to find there.
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.
This commit fixes a buggy scenario where:
- a spend of the desired outpoint occurs
- RegisterSpend is called, not immediately notifying
- caller performs a historical dispatch, calling UpdateSpendDetails
- caller is notified on the Spend channel
- re-org occurs
- caller is not notified of the re-org
We fix this by correctly populating the spendsByHeight map when
dispatchSpendDetails is called. This mirrors the confirmation case.
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.
