-
Notifications
You must be signed in to change notification settings - Fork 405
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
RawBolt11Invoice serialization utilities #3549
Conversation
lightning-invoice/src/lib.rs
Outdated
let parsed = UncheckedHrpstring::new(s) | ||
.map_err(|_| Bolt11ParseError::MalformedHRP)?; | ||
let hrp = parsed.hrp(); | ||
let raw_hrp: RawHrp = hrp.to_string().to_lowercase().parse()?; |
There was a problem hiding this comment.
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.
lightning-invoice/src/lib.rs
Outdated
|
||
/// 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> { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
67d736a
to
c16f1c6
Compare
This is super trivial and I would land it, but + 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 })
}
} |
c16f1c6
to
a55ea1a
Compare
done |
for remote signing of invoices
a55ea1a
to
80f6f38
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Backported in #3567 |
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.
for remote signing of invoices