') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); [0.1] Backports for 0.1.2 by TheBlueMatt · Pull Request #3697 · lightningdevkit/rust-lightning · GitHub
Skip to content

[0.1] Backports for 0.1.2 - #3697

Merged
TheBlueMatt merged 5 commits into
lightningdevkit:0.1from
TheBlueMatt:2025-04-0.1.2-backports-2
Apr 2, 2025
Merged

[0.1] Backports for 0.1.2#3697
TheBlueMatt merged 5 commits into
lightningdevkit:0.1from
TheBlueMatt:2025-04-0.1.2-backports-2

Conversation

@TheBlueMatt

@TheBlueMattTheBlueMatt commented Apr 1, 2025

Copy link
Copy Markdown
Collaborator

Backports of #3671, #3665, and #3680

phlip9and others added 2 commits April 1, 2025 18:41
@phlip9@TheBlueMatt
lightning-invoice: explicitly enforce a 7089 B max length on deser
7613161
The new `bech32-v0.11.0` version (prev: `v0.9.1`) now enforces a max length of
1023 bytes. Before there was no max.
BOLT11 invoices can definitely exceed 1023 B with a long-ish description and
2 route hints, so this limit is likely too low.
Having a limit is probably a good idea. What do other projects choose? Here's
a brief survey:
LDK (pre-0.1): (no limit)
LDK (post-0.1): 1023 B
LDK (post-PR): 7089 B
LND[1]: 7089 B
CLN[2]: (no limit)
ACINQ[3][4]: (no limit)
LND uses 7089 B, which was chosen to be "the max number of bytes that can fit
in a QR code". LND's rationale is technically incorrect as QR codes actually
have a max capacity of 7089 _numeric_ characters and only support up to 4296
all-uppercase alphanumeric characters. However, ecosystem-wide consistency
is more important.
A more conservative limit that would probably also suffice might be 2953 B,
the QR code length limit for a lowercase bech32-encoded invoice.
[1]: https://github.com/lightningnetwork/lnd/blob/6531d4505098eb14e6c24aedfd752fc15e85845d/zpay32/invoice.go#L87
[2]: https://github.com/ElementsProject/lightning/blob/0e7615b1b73eee161911763840d6260baf596755/common/bolt11.c#L683
[3]: https://github.com/ACINQ/lightning-kmp/blob/feda82c853660a792b911be518367a228ed6e0ee/modules/core/src/commonMain/kotlin/fr/acinq/lightning/payment/Bolt11Invoice.kt#L165
[4]: https://github.com/ACINQ/bitcoin-kmp/blob/master/src/commonMain/kotlin/fr/acinq/bitcoin/Bech32.kt#L122
@TheBlueMatt
Re-export lightning-invoice as bolt11-invoice from lightning
ff9f627
Now that `lightning` depends on `lightning-invoice`, we should
re-export it like we do `bitcoin` and `types`.
@ldk-reviews-bot

ldk-reviews-bot commented Apr 1, 2025•
edited
Loading

Copy link
Copy Markdown

👋 Thanks for assigning @G8XSU as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@TheBlueMatt
TheBlueMattforce-pushed the 2025-04-0.1.2-backports-2 branch from f751bae to 735b4a3CompareApril 1, 2025 18:52
This was referenced Apr 1, 2025
Merged
Merged
Merged
@ldk-reviews-bot

ldk-reviews-bot commented Apr 1, 2025

Copy link
Copy Markdown

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

@ldk-reviews-bot

ldk-reviews-bot commented Apr 1, 2025

Copy link
Copy Markdown

✅ Added second reviewer: @valentinewallace

@TheBlueMatt
TheBlueMatt removed the request for review from valentinewallaceApril 1, 2025 19:43
@TheBlueMattTheBlueMatt mentioned this pull request Apr 1, 2025
Merged
@TheBlueMatt
Make TestChannelManagerSync
74f9098
In a coming commit we'll need to hold references to
`TestChannelManager` in threads, requiring that it be `Sync`.
Fairly minor merge conflicts addressed in:
* `lightning/src/util/test_utils.rs`
@TheBlueMatt
Use fair unlocking (via parking_lot) in tests
1c50b9e
In a comming commit we'll add a test that relies heavily on lock
fairness, which is not provided by the default Rust `Mutex`.
Luckily, `parking_lot` provided an `unlock_fair`, which we use
here, though it implies we have to manually implement lock
poisoning.
Trivial merge conflict resolved in `lightning/Cargo.toml`
@TheBlueMatt
Do not track HTLC IDs as separate MPP parts which need claiming
5006c6b
When we claim an MPP payment, we need to track which channels have
had the preimage durably added to their `ChannelMonitor` to ensure
we don't remove the preimage from any `ChannelMonitor`s until all
`ChannelMonitor`s have the preimage.
Previously, we tracked each MPP part, down to the HTLC ID, as a
part which we needed to get the preimage on disk for. However, this
is not necessary - once a `ChannelMonitor` has a preimage, it
applies it to all inbound HTLCs with the same payment hash.
Further, this can cause a channel to wait on itself in cases of
high-latency synchronous persistence -
* If we have receive an MPP payment for which multiple parts came
to us over the same channel,
* and claim the MPP payment, creating a `ChannelMonitorUpdate` for
the first part but enqueueing the remaining HTLC claim(s) in the
channel's holding cell,
* and we receive a `revoke_and_ack` for the same channel before
the `ChannelManager::claim_payment` method completes (as each
claim waits for the `ChannelMonitorUpdate` persistence),
* we will cause the `ChannelMonitorUpdate` for that
`revoke_and_ack` to go into the blocked set, waiting on the MPP
parts to be fully claimed,
* but when `claim_payment` goes to add the next
`ChannelMonitorUpdate` for the MPP claim, it will be placed in
the blocked set, since the blocked set is non-empty.
Thus, we'll end up with a `ChannelMonitorUpdate` in the blocked set
which is needed to unblock the channel since it is a part of the
MPP set which blocked the channel.
Trivial conflicts resolved in `lightning/src/util/test_utils.rs`
@TheBlueMatt
TheBlueMattforce-pushed the 2025-04-0.1.2-backports-2 branch from 735b4a3 to 5006c6bCompareApril 2, 2025 00:31
@TheBlueMatt

TheBlueMatt commented Apr 2, 2025

Copy link
Copy Markdown
CollaboratorAuthor

Grrr, I misread a conflict and skipped a commit from #3680 which we did actually need. Pushed it as well now.

@TheBlueMatt
TheBlueMatt requested review from G8XSU and jkczyzApril 2, 2025 12:47
vincenzopalazzo
vincenzopalazzo approved these changes Apr 2, 2025
View reviewed changes

@vincenzopalazzovincenzopalazzo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM

@TheBlueMatt
TheBlueMatt merged commit 79857d2 into lightningdevkit:0.1Apr 2, 2025
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jkczyzjkczyzjkczyz approved these changes
@G8XSUG8XSUAwaiting requested review from G8XSU
+1 more reviewer
@vincenzopalazzovincenzopalazzovincenzopalazzo approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@TheBlueMatt@ldk-reviews-bot@G8XSU@jkczyz@vincenzopalazzo@phlip9