Merge tag 'v0.1.1' into 2024-12-0.1-bindings

v0.1.1 - Jan 28, 2025 - "Onchain Matters"

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

 * A `ChannelManager::send_payment_with_route` was (re-)added, with semantics
   similar to `ChannelManager::send_payment` (rather than like the pre-0.1
   `send_payent_with_route`, lightningdevkit#3534).
 * `RawBolt11Invoice::{to,from}_raw` were added (lightningdevkit#3549).

Bug Fixes
=========

 * HTLCs which were forwarded where the inbound edge times out within the next
   three blocks will have the inbound HTLC failed backwards irrespective of the
   status of the outbound HTLC. This avoids the peer force-closing the channel
   (and claiming the inbound edge HTLC on-chain) even if we have not yet managed
   to claim the outbound edge on chain (lightningdevkit#3556).
 * On restart, replay of `Event::SpendableOutput`s could have caused
   `OutputSweeper` to generate double-spending transactions, making it unable to
   claim any delayed claims. This was resolved by retaining old claims for more
   than four weeks after they are claimed on-chain to detect replays (lightningdevkit#3559).
 * Fixed the additional feerate we will pay each time we RBF on-chain claims to
   match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (lightningdevkit#3457).
 * Fixed a cased where a custom `Router` which returns an invalid `Route`,
   provided to `ChannelManager`, can result in an outbound payment remaining
   pending forever despite no HTLCs being pending (lightningdevkit#3531).

Security
========

0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
cause force-closure of unrelated channels.
 * If a malicious channel counterparty force-closes a channel, broadcasting a
   revoked commitment transaction while the channel at closure time included
   multiple non-dust forwarded outbound HTLCs with identical payment hashes and
   amounts, failure to fail the HTLCs backwards could cause the channels on
   which we recieved the corresponding inbound HTLCs to be force-closed. Note
   that we'll receive, at a minimum, the malicious counterparty's reserve value
   when they broadcast the stale commitment (lightningdevkit#3556). Thanks to Matt Morehouse for
   reporting this issue.

Author: TheBlueMatt

CHANGELOG.md

@@ -1,3 +1,39 @@
+# 0.1.1 - Jan 28, 2025 - "Onchain Matters"
+
+## API Updates
+ * A `ChannelManager::send_payment_with_route` was (re-)added, with semantics
+   similar to `ChannelManager::send_payment` (rather than like the pre-0.1
+   `send_payent_with_route`, #3534).
+ * `RawBolt11Invoice::{to,from}_raw` were added (#3549).
+
+## Bug Fixes
+ * HTLCs which were forwarded where the inbound edge times out within the next
+   three blocks will have the inbound HTLC failed backwards irrespective of the
+   status of the outbound HTLC. This avoids the peer force-closing the channel
+   (and claiming the inbound edge HTLC on-chain) even if we have not yet managed
+   to claim the outbound edge on chain (#3556).
+ * On restart, replay of `Event::SpendableOutput`s could have caused
+   `OutputSweeper` to generate double-spending transactions, making it unable to
+   claim any delayed claims. This was resolved by retaining old claims for more
+   than four weeks after they are claimed on-chain to detect replays (#3559).
+ * Fixed the additional feerate we will pay each time we RBF on-chain claims to
+   match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (#3457).
+ * Fixed a cased where a custom `Router` which returns an invalid `Route`,
+   provided to `ChannelManager`, can result in an outbound payment remaining
+   pending forever despite no HTLCs being pending (#3531).
+
+## Security
+0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
+cause force-closure of unrelated channels.
+ * If a malicious channel counterparty force-closes a channel, broadcasting a
+   revoked commitment transaction while the channel at closure time included
+   multiple non-dust forwarded outbound HTLCs with identical payment hashes and
+   amounts, failure to fail the HTLCs backwards could cause the channels on
+   which we recieved the corresponding inbound HTLCs to be force-closed. Note
+   that we'll receive, at a minimum, the malicious counterparty's reserve value
+   when they broadcast the stale commitment (#3556). Thanks to Matt Morehouse for
+   reporting this issue.
+
 # 0.1 - Jan 15, 2025 - "Human Readable Version Numbers"
 
 The LDK 0.1 release represents an important milestone for the LDK project. While

fuzz/src/chanmon_consistency.rs

@@ -48,6 +48,7 @@ use lightning::ln::channel::FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE;
 use lightning::ln::channel_state::ChannelDetails;
 use lightning::ln::channelmanager::{
 	ChainParameters, ChannelManager, ChannelManagerReadArgs, PaymentId, RecentPaymentDetails,
+	RecipientOnionFields,
 };
 use lightning::ln::functional_test_utils::*;
 use lightning::ln::inbound_payment::ExpandedKey;
@@ -82,7 +83,6 @@ use bitcoin::secp256k1::{self, Message, PublicKey, Scalar, Secp256k1, SecretKey}
 
 use lightning::io::Cursor;
 use std::cmp::{self, Ordering};
-use std::collections::VecDeque;
 use std::mem;
 use std::sync::atomic;
 use std::sync::{Arc, Mutex};
@@ -113,22 +113,14 @@ impl FeeEstimator for FuzzEstimator {
 	}
 }
 
-struct FuzzRouter {
-	pub next_routes: Mutex<VecDeque<Route>>,
-}
+struct FuzzRouter {}
 
 impl Router for FuzzRouter {
 	fn find_route(
 		&self, _payer: &PublicKey, _params: &RouteParameters,
 		_first_hops: Option<&[&ChannelDetails]>, _inflight_htlcs: InFlightHtlcs,
 	) -> Result<Route, msgs::LightningError> {
-		if let Some(route) = self.next_routes.lock().unwrap().pop_front() {
-			return Ok(route);
-		}
-		Err(msgs::LightningError {
-			err: String::from("Not implemented"),
-			action: msgs::ErrorAction::IgnoreError,
-		})
+		unreachable!()
 	}
 
 	fn create_blinded_payment_paths<T: secp256k1::Signing + secp256k1::Verification>(
@@ -518,7 +510,7 @@ fn send_payment(
 		PaymentParameters::from_node_id(source.get_our_node_id(), TEST_FINAL_CLTV),
 		amt,
 	);
-	source.router.next_routes.lock().unwrap().push_back(Route {
+	let route = Route {
 		paths: vec![Path {
 			hops: vec![RouteHop {
 				pubkey: dest.get_our_node_id(),
@@ -532,11 +524,10 @@ fn send_payment(
 			blinded_tail: None,
 		}],
 		route_params: Some(route_params.clone()),
-	});
+	};
 	let onion = RecipientOnionFields::secret_only(payment_secret);
 	let payment_id = PaymentId(payment_id);
-	let res =
-		source.send_payment(payment_hash, onion, payment_id, route_params, Retry::Attempts(0));
+	let res = source.send_payment_with_route(route, payment_hash, onion, payment_id);
 	match res {
 		Err(err) => {
 			panic!("Errored with {:?} on initial payment send", err);
@@ -592,7 +583,7 @@ fn send_hop_payment(
 		PaymentParameters::from_node_id(source.get_our_node_id(), TEST_FINAL_CLTV),
 		amt,
 	);
-	source.router.next_routes.lock().unwrap().push_back(Route {
+	let route = Route {
 		paths: vec![Path {
 			hops: vec![
 				RouteHop {
@@ -617,11 +608,10 @@ fn send_hop_payment(
 			blinded_tail: None,
 		}],
 		route_params: Some(route_params.clone()),
-	});
+	};
 	let onion = RecipientOnionFields::secret_only(payment_secret);
 	let payment_id = PaymentId(payment_id);
-	let res =
-		source.send_payment(payment_hash, onion, payment_id, route_params, Retry::Attempts(0));
+	let res = source.send_payment_with_route(route, payment_hash, onion, payment_id);
 	match res {
 		Err(err) => {
 			panic!("Errored with {:?} on initial payment send", err);
@@ -640,7 +630,7 @@ fn send_hop_payment(
 pub fn do_test<Out: Output>(data: &[u8], underlying_out: Out, anchors: bool) {
 	let out = SearchingOutput::new(underlying_out);
 	let broadcast = Arc::new(TestBroadcaster {});
-	let router = FuzzRouter { next_routes: Mutex::new(VecDeque::new()) };
+	let router = FuzzRouter {};
 
 	macro_rules! make_node {
 		($node_id: expr, $fee_estimator: expr) => {{

lightning-background-processor/src/lib.rs

@@ -1092,7 +1092,7 @@ mod tests {
 		SCORER_PERSISTENCE_SECONDARY_NAMESPACE,
 	};
 	use lightning::util::ser::Writeable;
-	use lightning::util::sweep::{OutputSpendStatus, OutputSweeper};
+	use lightning::util::sweep::{OutputSpendStatus, OutputSweeper, PRUNE_DELAY_BLOCKS};
 	use lightning::util::test_utils;
 	use lightning::{get_event, get_event_msg};
 	use lightning_persister::fs_store::FilesystemStore;
@@ -2274,8 +2274,8 @@ mod tests {
 		}
 
 		// Check we stop tracking the spendable outputs when one of the txs reaches
-		// ANTI_REORG_DELAY confirmations.
-		confirm_transaction_depth(&mut nodes[0], &sweep_tx_0, ANTI_REORG_DELAY);
+		// PRUNE_DELAY_BLOCKS confirmations.
+		confirm_transaction_depth(&mut nodes[0], &sweep_tx_0, PRUNE_DELAY_BLOCKS);
 		assert_eq!(nodes[0].sweeper.tracked_spendable_outputs().len(), 0);
 
 		if !std::thread::panicking() {

lightning-invoice/Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "lightning-invoice"
 description = "Data structures to parse and serialize BOLT11 lightning invoices"
-version = "0.33.0"
+version = "0.33.1"
 authors = ["Sebastian Geisler <sgeisler@wh2.tu-dresden.de>"]
 documentation = "https://docs.rs/lightning-invoice/"
 license = "MIT OR Apache-2.0"

lightning-invoice/src/lib.rs

@@ -48,6 +48,7 @@ use core::iter::FilterMap;
 use core::num::ParseIntError;
 use core::ops::Deref;
 use core::slice::Iter;
+use core::str::FromStr;
 use core::time::Duration;
 
 #[cfg(feature = "serde")]
@@ -78,8 +79,12 @@ use crate::prelude::*;
 /// Re-export serialization traits
 #[cfg(fuzzing)]
 pub use crate::de::FromBase32;
+#[cfg(not(fuzzing))]
+use crate::de::FromBase32;
 #[cfg(fuzzing)]
 pub use crate::ser::Base32Iterable;
+#[cfg(not(fuzzing))]
+use crate::ser::Base32Iterable;
 
 /// Errors that indicate what is wrong with the invoice. They have some granularity for debug
 /// reasons, but should generally result in an "invalid BOLT11 invoice" message for the user.
@@ -1088,9 +1093,6 @@ impl RawBolt11Invoice {
 
 	/// Calculate the hash of the encoded `RawBolt11Invoice` which should be signed.
 	pub fn signable_hash(&self) -> [u8; 32] {
-		#[cfg(not(fuzzing))]
-		use crate::ser::Base32Iterable;
-
 		Self::hash_from_parts(self.hrp.to_string().as_bytes(), self.data.fe_iter())
 	}
 
@@ -1191,6 +1193,21 @@ impl RawBolt11Invoice {
 	pub fn currency(&self) -> Currency {
 		self.hrp.currency.clone()
 	}
+
+	/// Convert to HRP prefix and Fe32 encoded data part.
+	/// Can be used to transmit unsigned invoices for remote signing.
+	pub fn to_raw(&self) -> (String, Vec<Fe32>) {
+		(self.hrp.to_string(), self.data.fe_iter().collect())
+	}
+
+	/// Convert from HRP prefix and Fe32 encoded data part.
+	/// Can be used to receive unsigned invoices for remote signing.
+	pub fn from_raw(hrp: &str, data: &[Fe32]) -> Result<Self, Bolt11ParseError> {
+		let raw_hrp: RawHrp = RawHrp::from_str(hrp)?;
+		let data_part = RawDataPart::from_base32(data)?;
+
+		Ok(Self { hrp: raw_hrp, data: data_part })
+	}
 }
 
 impl PositiveTimestamp {

lightning/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "lightning"
-version = "0.1.0"
+version = "0.1.1"
 authors = ["Matt Corallo"]
 license = "MIT OR Apache-2.0"
 repository = "https://github.com/lightningdevkit/rust-lightning/"

lightning/src/chain/chaininterface.rs

@@ -176,7 +176,7 @@ pub trait FeeEstimator {
 }
 
 /// Minimum relay fee as required by bitcoin network mempool policy.
-pub const MIN_RELAY_FEE_SAT_PER_1000_WEIGHT: u64 = 4000;
+pub const MIN_RELAY_FEE_SAT_PER_1000_WEIGHT: u64 = 253;
 /// Minimum feerate that takes a sane approach to bitcoind weight-to-vbytes rounding.
 /// See the following Core Lightning commit for an explanation:
 /// <https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0>