Check correct merkle leaf size and validate txids on Electrum

[tnull]

Just a few minor Electrum/Esplora fixes.

These findings were discovered by Project Loupe.

[ldk-reviews-bot]

👋 Thanks for assigning @wpaulino 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.

[ldk-claude-review-bot]

Summary

I re-reviewed the current commit (1d13150) against my prior findings and verified the actual code state.

Correction to a prior finding: My earlier "output-spend path lacks the merkle-leaf check" asymmetry finding (inline at electrum.rs:376) was a false positive. The is_potentially_unsafe_merkle_leaf base-size check lives inside get_confirmed_tx (electrum.rs:468), and both the watched-transactions path (electrum.rs:343) and the watched-output spend path (electrum.rs:393) route through it. The output-spend path is therefore protected, so there is no residual 64-byte-leaf attack surface there. Please disregard that prior comment.

New inline comment posted:

• lightning-transaction-sync/src/esplora.rs:394-395 — Stale comment ("at least 65 bytes in length") no longer matches the actual check (base_size() == 64).

Still standing (minor, previously noted, not re-posted inline):

• The transaction_get_responses_are_verified_at_call_sites test (electrum.rs:545) asserts on source text via include_str! + concat! rather than behavior — brittle to refactors.

The core fix is correct: base_size() is the right metric for the 64-byte merkle-leaf weakness, and the added Electrum txid verifications correctly mirror Esplora's. No functional bugs found in this pass.

[wpaulino]

LGTM once the bot's comment is addressed

[tnull]

Updated to line-wrap commit messages.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[TheBlueMatt]

Thanks. Given these are just validation against a malicious server, which can certainly screw us in many other ways, is there a strong reason to want to backport this? Note that this does not resolve the issue of the merkle-tree-extension attack, where a valid transaction included in a block is 64 bytes and collides with a hash such that a proof can be forged for a different transaction. That is ultimately only solved by requesting a proof for the coinbase transaction in parallel, which I don't think is worth doing.