This will make it possible to
link between SpendableOuts and ChannelMonitor
- change channel_id to option so we dont break upgrade
- remove unused channel_id
- document channel_id
- extract channel id dynamically to pass test
- use contains to check channel_id in test as the events are not ordered
- update docs framing
- specify ldk version channel_id will be introduced in
Co-authored-by: Elias Rohrer <dev@tnull.de>
Update lightning/src/events/mod.rs
Co-authored-by: Elias Rohrer <dev@tnull.de>
BOLT 12 messages need to be signed in the following scenarios:
- constructing an InvoiceRequest after scanning an Offer,
- constructing an Invoice after scanning a Refund, and
- constructing an Invoice when handling an InvoiceRequest.
Extend the NodeSigner trait to support signing BOLT 12 invoices such
that it can be used in the latter contexts. The method could be used
in an OffersMessageHandler.
Bolt12Invoice can either be for an Offer (via an InvoiceRequest) or a
Refund. It wraps those types, so expose their methods on both
Bolt12Invoice and UnsignedBolt12Invoice.
Since Refund does not have all the Offer/InvoiceRequest methods, use an
Option return type such that None can returned for refund-based
invoices.
For methods that are duplicated between Offer/InvoiceRequest and
Bolt12Invoice, prefer the (non-Option, if applicable) method from
Bolt12Invoice (e.g., amount_msats, signing_pubkey).
Various messages wrap InvoiceRequestContents, which shouldn't be exposed
as it is an implementation detail. Define a macro for InvoiceRequest
accessor methods so that these messages can also define them.
InvoiceRequest wraps OfferContents, which shouldn't be exposed as it is
an implementation detail. Define a macro for Offer accessor methods so
that InvoiceRequest and UnsignedInvoiceRequest can also define them.
InvoiceBuilder is parameterized by a SigningPubkeyStrategy, either
ExplicitSigningPubkey and DerivedSigningPubkey. It also holds an
Option<KeyPair>, which may be None and Some for those strategies,
respectively. This leads to methods for InvoiceBuilder parameterized by
DerivedSigningPubkey needing to blindly unwrap the Option<KeyPair>.
Instead, have DerivedSigningPubkey wrap KeyPair.
The function used to sign BOLT 12 messages only takes a message digest.
This doesn't allow signers to independently verify the message before
signing nor does it allow them to derive the necessary signing keys, if
needed.
Introduce a TaggedHash wrapper for a message digest, which each unsigned
BOLT 12 message type constructs upon initialization. Change the signing
function to take AsRef<TaggedHash>, which each unsigned type implements.
This allows the signing function to take any unsigned message and obtain
its tagged hash.
Creates a new `events::ClaimedHTLC` struct that contains the relevant
information about a claimed HTLC; e.g., the channel it arrived on, its ID, the
amount of the HTLC, the overall amount of the payment, etc. Adds appropriate
serialization support.
Adds a `Vec<events::ClaimedHTLC>` to the `ClaimingPayment`
structure. Populates this when creating the struct by converting the
`payment.htlcs` (which are `ClaimingHTLC` structs) into `event::ClaimedHTLC`
structs. This is a straightforward transformation.
Adds a `Vec<events::ClaimedHTLC>` to the `events::Event::PaymentClaimed`
enum. This is populated directly from the `ClaimingPayment`'s `htlcs` vec.
Fixes#2477.
We don't bother actually parsing errors from within a blinded path, since all
errors should be wiped by the introduction node by the time it gets back to us
(the sender).
LND hasn't properly handled shutdown messages ever, and
force-closes any time we send one while HTLCs are still present.
The issue is tracked at
https://github.com/lightningnetwork/lnd/issues/6039 and has had
multiple patches to fix it but none so far have managed to land
upstream. The issue appears to be very low priority for the LND
team despite being marked "P1".
We're not going to bother handling this in a sensible way, instead
simply repeated the Shutdown message on repeat until morale
improves.
In 0ad1f4c943 we fixed a nasty bug
where a failure to persist a `ChannelManager` faster than a
`ChannelMonitor` could result in the loss of a `PaymentSent` event,
eventually resulting in a `PaymentFailed` instead!
As noted in that commit, there's still some risk, though its been
substantially reduced - if we receive an `update_fulfill_htlc`
message for an outbound payment, and persist the initial removal
`ChannelMonitorUpdate`, then respond with our own
`commitment_signed` + `revoke_and_ack`, followed by receiving our
peer's final `revoke_and_ack`, and then persist the
`ChannelMonitorUpdate` generated from that, all prior to completing
a `ChannelManager` persistence, we'll still forget the HTLC and
eventually trigger a `PaymentFailed` rather than the correct
`PaymentSent`.
Here we fully fix the issue by delaying the final
`ChannelMonitorUpdate` persistence until the `PaymentSent` event
has been processed and document the fact that a spurious
`PaymentFailed` event can still be generated for a sent payment.
The original fix in 0ad1f4c943 is
still incredibly useful here, allowing us to avoid blocking the
first `ChannelMonitorUpdate` until the event processing completes,
as this would cause us to add event-processing delay in our general
commitment update latency. Instead, we ultimately race the user
handling the `PaymentSent` event with how long it takes our
`revoke_and_ack` + `commitment_signed` to make it to our
counterparty and receive the response `revoke_and_ack`. This should
give the user plenty of time to handle the event before we need to
make progress.
Sadly, because we change our `ChannelMonitorUpdate` semantics, this
change requires a number of test changes, avoiding checking for a
post-RAA `ChannelMonitorUpdate` until after we process a
`PaymentSent` event. Note that this does not apply to payments we
learned the preimage for on-chain - ensuring `PaymentSent` events
from such resolutions will be addressed in a future PR. Thus, tests
which resolve payments on-chain switch to a direct call to the
`expect_payment_sent` function with the claim-expected flag unset.
Commit f560320b introduced changes that require users of
`impl_writeable_tlv_based`/`impl_writeable_tlv_based_enum` to import
`_encode_varint_length_prefixed_tlv` and `alloc` separately.
Here, we take care of the necessary imports in
`_encode_varint_length_prefixed_tlv` itself, allowing users to just
import the `impl_writeable_tlv_based` variant they need.
Don't collect iterators to compare, minorly simplify encoding the
keysend TLV, combine the _encode_tlv_stream variants to check that the
ordering of TLVs is correct including custom TLVs.
When reloading a node in the test framework, we end up with a new
`ChannelManager` that has references to various test util structs.
In order for the tests to compile reliably in the face of unrelated
changes, those test structs need to always be initialized before
both the new but also the original `ChannelManager`.
Here we make that change.
01847277b9 switched around the logic
for inbound channel construction to assign the outbound SCID alias
after constructing the `InboundV1Channel` object. Thus, the SCID
alias argument is now unused, and we remove it here.
If we have a pending inbound un-accepted channel but receive an
error message for it from our peer, or our peer disconnects, we
should remove the pending entry, ensuring any attempts to accept
it fail.
For some reason an unrelated PR caused all our tests with
`reload_node` calls to fail to compile. This is due, in part, to
the lifetimes on `reload_node` implying that the new and original
`ChannelManager` (or some of the structs they reference) must live
for the same lifetime.
This fixes that issue by correcting the lifetimes to be consistent
across `Node` and `_reload_node`.
The ChannelMonitor::get_claimable_balances method provides a more
straightforward approach to the balance of a channel, which satisfies
most use cases. The computation of AvailableBalances::balance_msat is
complex and originally had a different purpose that is not applicable
anymore.
