Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Have methods take AChannelManager as Deref::Target #2652

Merged
merged 1 commit into from
Oct 8, 2023
Merged

Have methods take AChannelManager as Deref::Target #2652

merged 1 commit into from
Oct 8, 2023

Conversation

tnull
Copy link
Contributor

@tnull tnull commented Oct 6, 2023

In #2535, we had lightning-invoice use the AChannelManager trait to clean up the trait boundaries.

While we now gave it as a &C, we can relax that requirement further and instead have C: Deref targetting AChannelManager.

@codecov-commenter
Copy link

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (6016101) 89.03% compared to head (808e72a) 90.07%.
Report is 80 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #2652      +/-   ##
==========================================
+ Coverage   89.03%   90.07%   +1.03%     
==========================================
  Files         112      112              
  Lines       86351    94845    +8494     
  Branches    86351    94845    +8494     
==========================================
+ Hits        76879    85427    +8548     
+ Misses       7235     7131     -104     
- Partials     2237     2287      +50
Files Coverage Δ
lightning-invoice/src/payment.rs 77.48% <66.66%> (+0.17%) ⬆️

... and 37 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tnull tnull merged commit 989304e into lightningdevkit:main Oct 8, 2023
k0k0ne pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
@zoedberg
Merge tag 'v0.0.118' into 6b4f5ab
d1145ee 
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"

API Updates
===========

 * BOLT12 sending and receiving is now supported as an alpha feature. You may
   run into unexpected issues and will need to have a direct connection with
   the offer's blinded path introduction points as messages are not yet routed.
   We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
 * `ConfirmationTarget` has been rewritten to provide information about the
   specific use LDK needs the feerate estimate for, rather than the generic
   low-, medium-, and high-priority estimates. This allows LDK users to more
   accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
   retain their existing behavior, see the table below for conversion.
 * `ChainHash` is now used in place of `BlockHash` where it represents the
   genesis block (lightningdevkit#2662).
 * `lightning-invoice` payment utilities now take a `Deref` to
   `AChannelManager` (lightningdevkit#2652).
 * `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
 * `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
 * `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
 * `Features::from_be_bytes` is now provided (lightningdevkit#2640).

For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
 * `OnChainSweep` = `HighPriority`
 * `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
 * `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
 * `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
 * `AnchorChannelFee` = `Background`
 * `NonAnchorChannelFee` = `Normal`
 * `ChannelCloseMinimum` = `Background`

Bug Fixes
=========

 * Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
   channel which did not exist would immediately hang holding several key
   `ChannelManager`-internal locks (lightningdevkit#2657).
 * Channel information updates received from a failing HTLC are no longer
   applied to our `NetworkGraph`. This prevents a node which we attempted to
   route a payment through from being able to learn the sender of the payment.
   In some rare cases, this may result in marginally reduced payment success
   rates (lightningdevkit#2666).
 * Anchor outputs are now properly considered when calculating the amount
   available to send in HTLCs. This can prevent force-closes in anchor channels
   when sending payments which overflow the available balance (lightningdevkit#2674).
 * A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
   then reconnects prior to sending a `commitment_signed` (thus retransmitting
   their `update_fulfill_htlc`) may result in the channel stalling and being
   unable to make progress (lightningdevkit#2661).
 * In exceedingly rare circumstances, messages intended to be sent to a peer
   prior to reconnection can be sent after reconnection. This could result in
   undefined channel state and force-closes (lightningdevkit#2663).

Backwards Compatibility
=======================

 * Creating a blinded path to receive a payment then downgrading to LDK prior to
   0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
 * Calling `ChannelManager::pay_for_offer` or
   `ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
   to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).

Node Compatibility
==================

 * LDK now sends a bogus `channel_reestablish` message to peers when they ask to
   resume an unknown channel. This should cause LND nodes to force-close and
   broadcast the latest channel state to the chain. In order to trigger this
   when we wish to force-close a channel, LDK now disconnects immediately after
   sending a channel-closing `error` message. This should result in cooperative
   peers also working to confirm the latest commitment transaction when we wish
   to force-close (lightningdevkit#2658).

Security
========

0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
 * In order to mitigate against transaction cycling attacks, non-anchor HTLC
   transactions are now properly re-signed before broadcasting (lightningdevkit#2667).

In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
 * Antonio Yang
 * Elias Rohrer
 * Evan Feenstra
 * Fedeparma74
 * Gursharan Singh
 * Jeffrey Czyz
 * Matt Corallo
 * Sergi Delgado Segura
 * Vladimir Fomene
 * Wilmer Paulino
 * benthecarman
 * slanesuke
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@TheBlueMatt TheBlueMatt TheBlueMatt approved these changes

@wpaulino wpaulino wpaulino approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@tnull @codecov-commenter @TheBlueMatt @wpaulino