Skip to content

RawBolt11Invoice serialization utilities #3549

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.

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

Merged

Conversation

devrandom
Copy link
Member

for remote signing of invoices

let parsed = UncheckedHrpstring::new(s)
.map_err(|_| Bolt11ParseError::MalformedHRP)?;
let hrp = parsed.hrp();
let raw_hrp: RawHrp = hrp.to_string().to_lowercase().parse()?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gah we need to make the HRP decoder support mixed-case strings...allocating a new string just to lower-case it before parsing it is absurd...Doesn't have to happen here, but the over-allocations in this crate irritate me.


/// Convert from ascii bytes with HRP prefix and base32 encoded data part.
/// Can be used to receive unsigned invoices for remote signing.
pub fn from_ascii(s: &str) -> Result<Self, Bolt11ParseError> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kinda prefer we call this from_bytes or something. The fact that its a string is a bit weird to expose in the API - there's no string serialization for an unsigned invoice, we're just supporting serializing them to bytes for programatic use.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so there are no low-level utilities to ser/de the data part to bytes, so this would add significant amount of code. I changed this to be [Fe32] for the data part, and str for the hrp. see what you think.

@devrandom devrandom force-pushed the 2025-01-invoice-base32 branch 2 times, most recently from 67d736a to c16f1c6 Compare January 17, 2025 22:45
@devrandom devrandom changed the title RawBolt11Invoice to/from ascii utilities RawBolt11Invoice serialization utilities Jan 23, 2025
TheBlueMatt
TheBlueMatt previously approved these changes Jan 24, 2025
@TheBlueMatt
Copy link
Collaborator

This is super trivial and I would land it, but rustfmt is sad, so you'll need to apply this (+squash):

+ rustfmt +1.63.0 --edition 2021 --check lightning-invoice/src/lib.rs
Diff in /home/runner/work/rust-lightning/rust-lightning/lightning-invoice/src/lib.rs at line 79:
 /// 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))]
Diff in /home/runner/work/rust-lightning/rust-lightning/lightning-invoice/src/lib.rs at line 85:
-use crate::de::FromBase32;
-#[cfg(not(fuzzing))]
 use crate::ser::Base32Iterable;
 
 /// Errors that indicate what is wrong with the invoice. They have some granularity for debug
Diff in /home/runner/work/rust-lightning/rust-lightning/lightning-invoice/src/lib.rs at line 1207:
 		let raw_hrp: RawHrp = RawHrp::from_str(hrp)?;
 		let data_part = RawDataPart::from_base32(data)?;
 
-		Ok(Self {
-			hrp: raw_hrp,
-			data: data_part,
-		})
+		Ok(Self { hrp: raw_hrp, data: data_part })
 	}
 }

@devrandom
Copy link
Member Author

done

for remote signing of invoices
@devrandom devrandom force-pushed the 2025-01-invoice-base32 branch from a55ea1a to 80f6f38 Compare January 27, 2025 15:28
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@TheBlueMatt TheBlueMatt merged commit 39ff602 into lightningdevkit:main Jan 27, 2025
24 of 25 checks passed
@TheBlueMatt TheBlueMatt mentioned this pull request Jan 28, 2025
@TheBlueMatt
Copy link
Collaborator

Backported in #3567

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this pull request Jan 29, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants