This commit introduces the `CustomRecords` type in the `lnwire` package,
designed to hold arbitrary byte slices. Each entry in this map can
associate with TLV type values that are greater than or equal to 65536.
We need a new feature bit for BOLT11 invoices in order to indicate that
they contain the new blinded path tagged field. Tagged fields pre-date
TLV and so nodes who dont understand them will simply skip them.
Therefore the feature bit helps them to fail fast.
In this commit, the tlv extension of a channel update message is parsed.
If an inbound fee schedule is encountered, it is reported in the
graph rpc calls.
This commit adds an optional blinding point to payment descriptors and
persists them in our HTLC's extra data. A get/set pattern is used to
populate the ExtraData on our disk representation of the HTLC so that
callers do not need to worry about the underlying storage detail.
Add blinding points to update_add_htlc. This TLV will be set for
nodes that are relaying payments in blinded routes that are _not_
the introduction node.
This commit adds encoding and decoding for blinded route data blobs.
TLV fields such as path_id (which are only used for the final hop)
are omitted to minimize the change size.
We'll need to pack feature vectors for route blinding, so we pull
the encoding/decoding out into separate functions (currently
contained in ChannelType). Though it's more lines of code, we keep
most of the ChannelType assertions so that we strictly enforce
use of the alias.
The purpose of this interface is to distinguish messages that are
bound to a particular channel_id from those that are not. There is
no reason this ought to be a property of the peer package as it is
entirely determined by the contents of the message itself. Therefore
we move it to the lnwire package so it can be used without having
import cycles elsewhere in the codebase.
In this commit, we update new Taproot related TLVs (nonces, partial sig,
sig with nonce, etc). Along the way we were able to get rid of some
boiler plate, but most importantly, we're able to better protect against
API misuse (using a nonce that isn't initialized, etc) with the new
options API. In some areas this introduces a bit of extra boiler plate,
and where applicable I used some new helper functions to help cut down
on the noise.
Note to reviewers: this is done as a single commit, as changing the API
breaks all callers, so if we want things to compile it needs to be in a
wumbo commit.
These two messages will be used to implement the new and improved co-op
closing protocol. This PR also show cases how to use the new
`tlv.OptionalRecord` type to define and handle TLV level parsing.
I think we can make one additional helper function to clean up some of
the boiler plate for the encode/decode.
The test is identical to other onion failure fuzz tests, except that it
uses a custom equality function to get around the nil != []byte{} issue
with reflect.DeepEqual.
Fuzz tests for decoding and encoding of onion failure messages, based on
the fuzz harness for other lnwire messages. The onion failure messages
were uncovered by existing fuzz tests.
For about a year [1], the spec has prescribed encoding channel_updates
with their type prefix (0x0102) in onion failure messages. LND can
decode correctly with or without the prefix but hasn't been writing the
prefix during encoding. This commit starts writing the prefix.
[1] https://github.com/lightning/bolts/pull/979
In this commit, we carry out a new notion introduced during a recent
spec meeting to use a feature bit plus 100 before the feature has been
finalized in the spec.
We split into the Final and Staging bits.
