Matt Corallo [Sun, 1 Aug 2021 02:42:42 +0000 (02:42 +0000)]
Make BackgroundProcessor `#[must_use]` to avoid dropping immediately
It is easy for users to have a bug where they drop a
`BackgroundProcessor` immediately, causing it to start and then
immediately stop. Instead, add a `#[must_use]` tag to provide a
compiler warning for such instances.
Matt Corallo [Sun, 1 Aug 2021 02:13:36 +0000 (02:13 +0000)]
Log when a channel is closed on startup due to stale ChannelManager
This is one of the riskiest parts of our API from the perspective
of accidental force-closes - if users delay persisting the
ChannelManager much at all after a ChannelMonitor we may hit a
force-close after restart.
The fact that we don't log at all when this happens is criminal.
Matt Corallo [Sat, 31 Jul 2021 20:42:59 +0000 (20:42 +0000)]
Merge pull request #1012 from TheBlueMatt/2021-07-bump-deps
Bump dependencies to bitcoin 0.27 and bech32 0.8
Matt Corallo [Thu, 22 Jul 2021 15:18:22 +0000 (15:18 +0000)]
Add a `#[macro_use]` on the `alloc` import for `format!()`
Matt Corallo [Thu, 22 Jul 2021 15:13:37 +0000 (15:13 +0000)]
Fix no_std warnings due to unused includes
Matt Corallo [Thu, 22 Jul 2021 15:01:03 +0000 (15:01 +0000)]
Drop MSRV for no_std to 1.47 as that's what Ubuntu LTS ships with
...but disable it for now given core2 is broken (it claims an MSRV
of 1.47 but does not build).
Matt Corallo [Thu, 22 Jul 2021 14:31:37 +0000 (14:31 +0000)]
Bump dependencies to bitcoin 0.27 and bech32 0.8
Matt Corallo [Fri, 30 Jul 2021 20:53:30 +0000 (20:53 +0000)]
Merge pull request #1024 from TheBlueMatt/2021-07-always-connect-in-tests
Connect peers on startup in tests
Matt Corallo [Fri, 30 Jul 2021 18:21:12 +0000 (18:21 +0000)]
Connect peers on startup in tests
This avoids `ChannelManager` ever being confused by the fact that
it received a message from a peer which it didn't think it was
connected to.
Matt Corallo [Thu, 29 Jul 2021 18:06:05 +0000 (18:06 +0000)]
Merge pull request #1021 from TheBlueMatt/2021-07-broken-beta
Disable fast-fail to let CI actually run even though beta is broken
Matt Corallo [Thu, 29 Jul 2021 17:49:05 +0000 (17:49 +0000)]
Merge pull request #1007 from jkczyz/2021-07-stop-drop-shutem-down
Stop BackgroundProcessor's thread on drop
Matt Corallo [Thu, 29 Jul 2021 17:40:14 +0000 (17:40 +0000)]
Disable fast-fail to let CI actually run even though beta is broken
Matt Corallo [Wed, 28 Jul 2021 21:58:31 +0000 (21:58 +0000)]
Merge pull request #1020 from TheBlueMatt/2021-07-log-features-more
Macroize feature printing to ensure we don't miss new flags
Jeffrey Czyz [Mon, 19 Jul 2021 17:50:56 +0000 (12:50 -0500)]
Add join method to BackgroundProcessor
The previous commit wraps the background thread's JoinHandle in an
Option. Providing a dedicated method to join hides this implementation
detail from users.
Matt Corallo [Wed, 28 Jul 2021 21:06:49 +0000 (21:06 +0000)]
Macroize feature printing to ensure we don't miss new flags
Matt Corallo [Wed, 28 Jul 2021 01:24:27 +0000 (01:24 +0000)]
Merge pull request #977 from TheBlueMatt/2021-06-fix-double-claim-close
Handle double-HTLC-claims without failing the backwards channel
Matt Corallo [Thu, 15 Jul 2021 22:26:51 +0000 (22:26 +0000)]
Fail channel if we can't sign a new commitment tx during HTLC claim
Previously, we could fail to generate a new commitment transaction
but it simply indicated we had gone to doule-claim an HTLC. Now
that double-claims are returned instead as Ok(None), we should
handle the error case and fail the channel, as the only way to hit
the error case is if key derivation failed or the user refused to
sign the new commitment transaction.
This also resolves an issue where we wouldn't inform our
ChannelMonitor of the new payment preimage in case we failed to
fetch a signature for the new commitment transaction.
Matt Corallo [Thu, 15 Jul 2021 21:56:42 +0000 (21:56 +0000)]
Simplify call graph of get_update_fulfill_htlc since it can't Err.
Matt Corallo [Tue, 29 Jun 2021 21:05:45 +0000 (21:05 +0000)]
Handle double-HTLC-claims without failing the backwards channel
When receiving an update_fulfill_htlc message, we immediately
forward the claim backwards along the payment path before waiting
for a full commitment_signed dance. This is great, but can cause
duplicative claims if a node sends an update_fulfill_htlc message,
disconnects, reconnects, and then has to re-send its
update_fulfill_htlc message again.
While there was code to handle this, it treated it as a channel
error on the inbound channel, which is incorrect - this is an
expected, albeit incredibly rare, condition. Instead, we handle
these double-claims correctly, simply ignoring them.
With debug_assertions enabled, we also check that the previous
close of the same HTLC was a fulfill, and that we are not moving
from a HTLC failure to an HTLC claim after its too late.
A test is also added, which hits all three failure cases in
`Channel::get_update_fulfill_htlc`.
Found by the chanmon_consistency fuzzer.
Matt Corallo [Wed, 28 Jul 2021 00:32:27 +0000 (00:32 +0000)]
Merge pull request #967 from valentinewallace/2021-06-keysend
Keysend
Valentine Wallace [Mon, 19 Jul 2021 22:37:55 +0000 (18:37 -0400)]
Clarify decode_update_add_htlc_onion comment
Clearer phrasing
Valentine Wallace [Thu, 8 Jul 2021 16:44:39 +0000 (12:44 -0400)]
tests: make PaymentSecret optional in pass_along path
and use it to make more keysend tests
Valentine Wallace [Fri, 25 Jun 2021 23:43:55 +0000 (19:43 -0400)]
Implement utilities for keysending to private nodes
Valentine Wallace [Wed, 23 Jun 2021 19:15:16 +0000 (15:15 -0400)]
Implement sending keysend payments (to public nodes)
Valentine Wallace [Fri, 25 Jun 2021 20:36:18 +0000 (16:36 -0400)]
test utils: add optional PaymentPreimage param to pass_along_path
This will allow keysend tests to assert that the PaymentReceived payment preimage is
as expected in upcoming commits.
Valentine Wallace [Sun, 4 Jul 2021 21:42:26 +0000 (17:42 -0400)]
Implement receiving keysend payments
Valentine Wallace [Wed, 30 Jun 2021 22:35:36 +0000 (18:35 -0400)]
Refactor PaymentReceived event for keysend receives
Valentine Wallace [Wed, 30 Jun 2021 18:05:53 +0000 (14:05 -0400)]
Add PendingHTLCRouting variant for receiving keysend payments
Valentine Wallace [Wed, 30 Jun 2021 17:50:09 +0000 (13:50 -0400)]
Fix indentation in decode_update_add_htlc_onion
Valentine Wallace [Fri, 14 May 2021 20:34:56 +0000 (16:34 -0400)]
Advertise keysend feature
C-Lightning requires us to advertise this feature before they'll
attempt a keysend payment to us.
Valentine Wallace [Thu, 13 May 2021 19:38:31 +0000 (15:38 -0400)]
Parse keysend TLV field in onion.
This doesn't yet use the field, but it will be used in upcoming commits.
Matt Corallo [Mon, 26 Jul 2021 16:03:22 +0000 (16:03 +0000)]
Merge pull request #998 from TheBlueMatt/2021-07-fix-chan-reserve-msat-sat
Fix channel reserve calculation on the sending side
Matt Corallo [Mon, 26 Jul 2021 16:02:41 +0000 (16:02 +0000)]
Merge pull request #986 from TheBlueMatt/2021-07-route-lasthop-value
[router] Use the invoice value for last-hop hint channel capacity
Matt Corallo [Thu, 22 Jul 2021 14:17:09 +0000 (14:17 +0000)]
Merge pull request #1008 from lightning-signer/2021-07-sync-no-std
Dummy sync implementation for no_std
Matt Corallo [Tue, 20 Jul 2021 23:25:40 +0000 (23:25 +0000)]
Merge pull request #1010 from sr-gi/enforce_signature_length
Devrandom [Mon, 19 Jul 2021 17:28:06 +0000 (19:28 +0200)]
Test no_std instead of just hashbrown
Devrandom [Mon, 19 Jul 2021 14:13:00 +0000 (16:13 +0200)]
Implement dummy Mutex, Condvar and RwLock
Sergi Delgado Segura [Tue, 20 Jul 2021 09:05:47 +0000 (11:05 +0200)]
Enforces sig_rec length in message_signing
Devrandom [Mon, 19 Jul 2021 13:01:58 +0000 (15:01 +0200)]
Collect all lightning std::sync imports under crate::sync
in preparation for no-std sync dummies
Jeffrey Czyz [Sun, 18 Jul 2021 18:11:01 +0000 (13:11 -0500)]
Stop BackgroundProcessor's thread on drop
Without stopping the thread when BackgroundProcessor is dropped, it will
run free. In the context of language bindings, it is difficult to know
how long references held by the thread should live. Implement Drop to
stop the thread just as is done when explicitly calling stop().
Jeffrey Czyz [Sun, 18 Jul 2021 17:59:27 +0000 (12:59 -0500)]
Correctly assert BackgroundProcessor error
The specific error from the ChannelManager persister is not asserted for
in test_persist_error. Rather, any error will do. Update the test to use
BackgroundProcessor::stop and assert for the expected value.
Matt Corallo [Thu, 15 Jul 2021 20:14:35 +0000 (20:14 +0000)]
Merge pull request #1003 from jkczyz/2021-known-features-mask
Expand tests for Features::to_context
Matt Corallo [Thu, 15 Jul 2021 12:59:45 +0000 (12:59 +0000)]
Merge pull request #1002 from valentinewallace/2021-07-fix-features-index-bounds
Jeffrey Czyz [Wed, 14 Jul 2021 23:18:33 +0000 (16:18 -0700)]
Test index-out-of-bounds in Features::to_context
When there are fewer known `from` feature bytes than known `to` feature
bytes, an index-out-of-bounds error can occur if the `from` features
have unknown features set in a byte past the greatest known `from`
feature byte.
Jeffrey Czyz [Wed, 14 Jul 2021 23:15:00 +0000 (16:15 -0700)]
Remove unnecessary feature test-only methods
Valentine Wallace [Wed, 14 Jul 2021 20:23:38 +0000 (16:23 -0400)]
Fix crash due to index-out-of-bounds in feature translation
This was reported by a user when trying to send a payment using the LDK
sample (specifically during route generation when translating a Features
from one context to another)
The problem was we didn't check T::KNOWN_FEATURE_MASK vec length before
indexing into it, due likely to the assumption that known feature vec
lengths are the same across contexts, when they may not be
Matt Corallo [Wed, 14 Jul 2021 18:19:45 +0000 (18:19 +0000)]
Support pending update_fail_htlcs in reconnect_nodes test util
Matt Corallo [Sun, 4 Jul 2021 14:46:17 +0000 (14:46 +0000)]
Fix channel reserve calculation on the sending side
As the variable name implies holder_selected_chan_reserve_msat is
intended to be in millisatoshis, but is instead calculated in
satoshis.
We fix that error here and update the relevant tests to more
accurately calculate the expected reserve value and test both
success and failure cases.
Bug discovered by chanmon_consistency fuzz target.
Matt Corallo [Fri, 9 Jul 2021 17:29:38 +0000 (17:29 +0000)]
Merge pull request #990 from TheBlueMatt/2021-07-0.0.99
Cut 0.0.99
Matt Corallo [Fri, 9 Jul 2021 14:03:46 +0000 (14:03 +0000)]
Bump most crate versions to 0.0.99 and lightning-invoice to 0.7.0
Matt Corallo [Thu, 8 Jul 2021 19:18:49 +0000 (19:18 +0000)]
Add documentation for all PRs slated to land for 0.0.99
Matt Corallo [Fri, 9 Jul 2021 02:11:57 +0000 (02:11 +0000)]
Merge pull request #975 from TheBlueMatt/2021-06-fix-fee-calc
Make the base fee configurable in ChannelConfig
Matt Corallo [Tue, 6 Jul 2021 00:27:35 +0000 (00:27 +0000)]
Change serialization backwards compat in Channel to use new version
Instead of interpreting the backwards compatibility data in Channel
serialization, use the serialization version bump present in 0.0.99
as the flag to indicate if a channel should be read in backwards
compatibility.
Matt Corallo [Sat, 26 Jun 2021 16:21:34 +0000 (16:21 +0000)]
Add a note clarifying the API guarantees of create_channel
Matt Corallo [Sat, 26 Jun 2021 14:15:30 +0000 (14:15 +0000)]
Optionally reject HTLC forwards over priv chans with a new config
Private nodes should never wish to forward HTLCs at all, which we
support here by disabling forwards out over private channels by
default. As private nodes should not have any public channels, this
suffices, without allowing users to disable forwarding over
channels announced in the routing graph already.
Closes #969
Matt Corallo [Sat, 3 Jul 2021 01:13:14 +0000 (01:13 +0000)]
Update full_stack_target demo input to match new, fewer, fee gets
Matt Corallo [Mon, 21 Jun 2021 20:20:29 +0000 (20:20 +0000)]
Make the base fee configurable in ChannelConfig
Currently the base fee we apply is always the expected cost to
claim an HTLC on-chain in case of closure. This results in
significantly higher than market rate fees [1], and doesn't really
match the actual forwarding trust model anyway - as long as
channel counterparties are honest, our HTLCs shouldn't end up
on-chain no matter what the HTLC sender/recipient do.
While some users may wish to use a feerate that implies they will
not lose funds even if they go to chain (assuming no flood-and-loot
style attacks), they should do so by calculating fees themselves;
since they're already charging well above market-rate,
over-estimating some won't have a large impact.
Worse, we current re-calculate fees at forward-time, not based on
the fee we set in the channel_update. This means that the fees
others expect to pay us (and which they calculate their route based
on), is not what we actually want to charge, and that any attempt
to forward through us is inherently race-y.
This commit adds a configuration knob to set the base fee
explicitly, defaulting to 1 sat, which appears to be market-rate
today.
[1] Note that due to an msat-vs-sat bug we currently actually
charge 1000x *less* than the calculated cost.
Matt Corallo [Mon, 21 Jun 2021 19:55:45 +0000 (19:55 +0000)]
Update ChannelConfig serialization to be TLV-based
This was missed prior to 0.0.98, so requires a
backwards-compatibility wrapper inside the `Channel` serialization
logic, but it's not very complicated to do so.
Matt Corallo [Thu, 8 Jul 2021 17:25:53 +0000 (17:25 +0000)]
Merge pull request #988 from TheBlueMatt/2021-07-chan-details-usability
Improve ChannelDetails readability significantly.
Matt Corallo [Tue, 6 Jul 2021 23:41:27 +0000 (23:41 +0000)]
Improve ChannelDetails readability significantly.
After the merge of #984, Jeff pointed out that `ChannelDetails` has
become a bit of a "bag of variables", and that a few of the variable
names in #984 were more confusing than necessary in context.
This addresses several issues by:
* Splitting counterparty parameters into a separate
`ChannelCounterpartyParameters` struct,
* using the name `unspendable_punishment_reserve` for both outbound
and inbound channel reserves, differentiating them based on their
position in the counterparty parameters struct or not,
* Using the name `force_close_spend_delay` instead of
`spend_csv_on_our_commitment_funds` to better communicate what
is occurring.
Matt Corallo [Thu, 8 Jul 2021 14:51:47 +0000 (14:51 +0000)]
Merge pull request #961 from TheBlueMatt/2021-06-workaround-broken-cln
Use the query start block for ReplyChannelRange response messages
Matt Corallo [Sat, 19 Jun 2021 15:48:23 +0000 (15:48 +0000)]
Use the query start block for ReplyChannelRange response messages
C-Lightning versions prior to 0.10 (incorrectly) enforce that the
reply_channel_range first_blocknum field is set to at least the
value they sent in their query_channel_range message. Sending a 0
results in them responding with an Error message, closing open
channels spuriously.
Further, C-Lightning versions prior to 0.10 require that the
reply_channel_range first_blocknum is either the same block implied
as the last block of the previous reply_channel_range or one
greater. This is not only a creative interpretation of the spec,
but a perfectly reasonable implementation might still receive an
Error message in the case of replies split by an empty block.
This code is extracted and modified from a previous version of
the original query_channel_range PR in commit
44ba52ccf10bb0362ed2964b66ec2ae51e388161. The original commit is by
`bmancini55 <bmancini@gmail.com>`.
Matt Corallo [Wed, 7 Jul 2021 20:17:10 +0000 (20:17 +0000)]
Merge pull request #949 from TheBlueMatt/2021-06-send-priv-update
Send channel_update messages to direct peers on private channels
Matt Corallo [Wed, 30 Jun 2021 00:27:24 +0000 (00:27 +0000)]
Ignore our own gossip if it is sent to us from our counterparty
If our channel party sends us our own channel_update message, we'll
erroneously use the information in that message to update our view
of the forwarding parameters our counterparty requires of us,
ultimately generating invoices with bogus forwarding information.
This fixes that behavior by checking the channel_update's
directionality before handling it.
Matt Corallo [Mon, 14 Jun 2021 15:14:18 +0000 (15:14 +0000)]
Fix spelling in ChannelManager comment
Matt Corallo [Sat, 12 Jun 2021 21:58:50 +0000 (21:58 +0000)]
Send channel_update messages to direct peers on private channels
If we are a public node and have a private channel, our
counterparty needs to know the fees which we will charge to forward
payments to them. Without sending them a channel_update, they have
no way to learn that information, resulting in the channel being
effectively useless for outbound-from-us payments.
This commit fixes our lack of channel_update messages to private
channel counterparties, ensuring we always send them a
channel_update after the channel funding is confirmed.
Matt Corallo [Tue, 6 Jul 2021 00:53:12 +0000 (00:53 +0000)]
Merge pull request #984 from TheBlueMatt/2021-06-more-chan-data
Expose More Information about Channels and structs
Matt Corallo [Mon, 5 Jul 2021 18:31:32 +0000 (18:31 +0000)]
Tweak documentation in `BestBlock` to be a bit more clear
Matt Corallo [Sat, 3 Jul 2021 01:58:30 +0000 (01:58 +0000)]
Expose the current best chain tip from ChannelManager + Monitors
Fixes #979
Matt Corallo [Fri, 2 Jul 2021 23:54:57 +0000 (23:54 +0000)]
Expand the fields exposed to users in `ChannelDetails`
This adds four new fields in `ChannelDetails`:
1. holder_selected_ and counterparty_selected_channel_reserve_delay
are useful to determine what amount of the channel is
unavailable for payments.
2. confirmations_required is useful when awaiting funding
confirmation to determine how long you will need to wait.
3. to_self_delay is useful to determine how long it will take to
receive funds after a force-close.
Fixes #983.
Matt Corallo [Sun, 4 Jul 2021 14:13:10 +0000 (14:13 +0000)]
Drop Channel HTLC transaction building thin wrapper function
Matt Corallo [Sat, 3 Jul 2021 15:27:12 +0000 (15:27 +0000)]
Make channel fields which are from accept_channel Optional
These fields are set with a dummy value, which we should generally
be avoiding since Rust gives us a nice `Option` type to use
instead.
Further, we stop rejecting channel_update messages outright when
the htlc_maximum_msat field includes the reserve values, which
nodes could reasonably do without it meriting a channel closure.
Matt Corallo [Mon, 5 Jul 2021 18:10:34 +0000 (18:10 +0000)]
[router] Use the invoice value for last-hop hint channel capacity
If an invoice contains route hints, we should assume the channel
capacity is sufficient to route the invoice's value.
Matt Corallo [Mon, 5 Jul 2021 00:01:43 +0000 (00:01 +0000)]
Merge pull request #958 from TheBlueMatt/2021-06-fix-router-panic
Fix panic in router given to bogus last-hop hints
Matt Corallo [Fri, 18 Jun 2021 04:31:50 +0000 (04:31 +0000)]
Fix panic in router given to bogus last-hop hints
See new comments and test cases for more info
Matt Corallo [Sun, 4 Jul 2021 14:13:45 +0000 (14:13 +0000)]
Reject minimum_depth of 0 on channel opens
We don't support turbo channels so this is a pretty clear
indication that there is some incompatibility.
Matt Corallo [Fri, 11 Jun 2021 16:03:34 +0000 (16:03 +0000)]
Never generate a `BroadcastChannelUpdate` for priv channels
Currently we always generate a
`MessageSendEvent::BroadcastChannelUpdate` when a channel is closed
even if the channel is private. Our immediate peers should ignore
such messages as they haven't seen a corresponding
`channel_announcement`, but we are still giving up some privacy by
informing our immediate peers of which channels were ours.
Here we split `ChannelManager::get_channel_update` into a
`get_channel_update_for_broadcast` and
`get_channel_update_for_unicast`. The first is used when we are
broadcasting a `channel_update`, allowing us to refuse to do so
for private channels. The second is used when failing a payment (in
which case the recipient has already shown that they are aware of
the channel so no such privacy concerns exist).
Matt Corallo [Fri, 2 Jul 2021 17:55:17 +0000 (17:55 +0000)]
Merge pull request #970 from TheBlueMatt/2021-06-no-confirmed-csv-delay
Create SpendableOutputs events no matter the chain::Confirm order
Matt Corallo [Sat, 26 Jun 2021 00:56:52 +0000 (00:56 +0000)]
Clean up get_broadcasted_holder_claims confirmation height param use
Matt Corallo [Fri, 25 Jun 2021 20:27:38 +0000 (20:27 +0000)]
Clarify when height is the *current* vs a *confirmation* height
Matt Corallo [Fri, 25 Jun 2021 04:16:35 +0000 (04:16 +0000)]
Create SpendableOutputs events no matter the chain::Confirm order
We had a user who pointed out that we weren't creating
`SpendableOutputs` events when we should have been after they
called `ChannelMonitor::best_block_updated` with a block well
after a CSV locktime and then called
`ChannelMonitor::transactions_confirmed` with the transaction which
we should have been spending (with a block height/hash a ways in
the past).
This was due to `ChannelMonitor::transactions_confirmed` only
calling `ChannelMonitor::block_confirmed` with the height at which
the transactions were confirmed, resulting in all checks being done
against that, not the current height.
Further, in the same scenario, we also would not fail-back and HTLC
where the HTLC-Timeout transaction was confirmed more than
ANTI_REORG_DELAY blocks ago.
To address this, we use the best block height for confirmation
threshold checks in `ChannelMonitor::block_confirmed` and pass both
the confirmation and current heights through to
`OnchainTx::update_claims_view`, using each as appropriate.
Fixes #962.
Matt Corallo [Mon, 28 Jun 2021 16:23:19 +0000 (16:23 +0000)]
Update `ChannelMonitor::best_block` before calling block_confirmed
No matter the context, if we're told about a block which is
guaranteed by our API semantics to be on the best chain, and it has
a higher height than our current understanding of the best chain,
we should update our understanding. This avoids complexity
in `block_confirmed` by never having a height set which is *higher*
than our current best chain, potentially avoiding some bugs in the
rather-complicated code.
It also requires a minor test tweak as we in some cases now no
longer broadcast a conflicting transaction after the original has
reached the ANTI_REORG_DELAY.
Matt Corallo [Fri, 25 Jun 2021 04:14:50 +0000 (04:14 +0000)]
Avoid calling OnchainTx::block_disconnected if no block was discon'd
There are no visible effects of this, but it seems like good code
hygiene to not call a disconnect function in a different file if no
disconnect happened.
Matt Corallo [Fri, 25 Jun 2021 16:48:34 +0000 (16:48 +0000)]
Add new expect_payment_failure_chan_update!() macro in tests
This further DRYs up some functional_test code and increases
coverage.
Matt Corallo [Thu, 1 Jul 2021 03:33:15 +0000 (03:33 +0000)]
Merge pull request #976 from TheBlueMatt/2021-06-actionable-errors
Make errors actionable when failing to deserialize a ChannelManager
Matt Corallo [Thu, 1 Jul 2021 03:28:30 +0000 (03:28 +0000)]
Merge pull request #954 from TheBlueMatt/2021-06-no-spurious-forward-fails
Consider channels "live" even if they are awaiting a monitor update
Matt Corallo [Wed, 16 Jun 2021 22:57:38 +0000 (22:57 +0000)]
Consider channels "live" even if they are awaiting a monitor update
We use `Channel::is_live()` to gate inclusion of a channel in
`ChannelManager::list_usable_channels()` and when sending an
HTLC to select whether a channel is available for
forwarding through/sending to.
In both of these cases, we should consider a channel `is_live()` when
they are pending a monitor update. Some clients may update monitors
asynchronously, thus we may simply be waiting a short duration for a
monitor update to complete, and shouldn't fail all forwarding HTLCs
during that time.
After #851, we always ensure any holding cells are free'd when
sending P2P messages, making this change much more trivially
correct - instead of having to ensure that we always free the holding
cell when a channel becomes live again after adding something to the
holding cell, we can simply rely on the fact that it always happens.
Fixes #661.
Matt Corallo [Wed, 30 Jun 2021 20:32:35 +0000 (20:32 +0000)]
Merge pull request #972 from TheBlueMatt/2021-06-skip-notify-chansync
Do not always persist ChannelManager on channel_update messages
Matt Corallo [Tue, 29 Jun 2021 23:44:31 +0000 (23:44 +0000)]
Fix unused import in peer_handler introduced in
1f592b045fb6b2788c5
Matt Corallo [Mon, 28 Jun 2021 00:54:24 +0000 (00:54 +0000)]
Do not always persist ChannelManager on channel_update messages
If we receive a `channel_update` message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
`ChannelManager`. This avoids significant persistence traffic during
initial node startup.
Matt Corallo [Wed, 30 Jun 2021 02:19:28 +0000 (02:19 +0000)]
Correct test log printing due to inverted comparison
We changed the sort order of log levels to be more natural, but this
comparison wasn't updated accordingly. Likely the reason it was
left strange for so long is it also had the comparison argument
ordering flipped.
Matt Corallo [Wed, 30 Jun 2021 00:38:49 +0000 (00:38 +0000)]
Make errors actionable when failing to deserialize a ChannelManager
Matt Corallo [Wed, 30 Jun 2021 01:19:30 +0000 (01:19 +0000)]
Merge pull request #973 from TheBlueMatt/2021-06-fix-broken-event-ser
Fix bogus `Event::PaymentSent` serialization
Matt Corallo [Fri, 25 Jun 2021 03:45:52 +0000 (03:45 +0000)]
Clean up check_spendable_outputs!() test macro somewhat
Matt Corallo [Tue, 29 Jun 2021 20:13:50 +0000 (20:13 +0000)]
Merge pull request #965 from TheBlueMatt/2021-06-log-cleanups
Cleanup logging
Matt Corallo [Sun, 27 Jun 2021 22:02:15 +0000 (22:02 +0000)]
Add debug log when we stop tracking confirmed on-chain packages
Matt Corallo [Sun, 27 Jun 2021 03:20:36 +0000 (03:20 +0000)]
Correct inbound HTLC upgrade logs on revoke_and_ack receipt
Matt Corallo [Wed, 23 Jun 2021 03:32:32 +0000 (03:32 +0000)]
Increase the log level of several channelmonitor/onchain logs.
ChannelMonitor and related log entries can generally lean towards
being higher log levels than they necessarily need to be, as they
should be exceedingly rare, if only because they require
confirmation of an on-chain transaction.
Matt Corallo [Wed, 23 Jun 2021 03:24:31 +0000 (03:24 +0000)]
Add additional TRACE-level logging during pathfinding in router
Matt Corallo [Tue, 22 Jun 2021 03:35:52 +0000 (03:35 +0000)]
Update logging in channel and channelmanager to better levels
This updates a number of log sites in channel and channelmanager to
* Be a bit more verbose at the TRACE level,
* Move some error/useful messages to the ERROR/WARN/INFO level,
* Add new logs to always log once at the DEBUG level when we
send/receive a commitment_signed (with some extra data),
* Include the channel id being operated on in more log messages.