AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 30 Bitcoin

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay

Add SubmitPackage to the lnwallet.WalletController interface and a new
WalletKit.SubmitPackage RPC, so a client of lnd can relay a package of
related transactions (parents first, child last) through lnd's own chain
connection. This lets a zero-fee v3/TRUC parent be accepted via its
fee-paying CPFP child without the caller needing a separate connection to
the chain backend.

BtcWallet.SubmitPackage forwards to the chain backend's submitpackage for
bitcoind/btcd, and broadcasts each transaction individually for neutrino
(no mempool; relies on the peer's 1p1c package relay). The WalletKit
handler maps the proto request/response to the btcjson result and is
gated by the onchain:write macaroon permission. Mock controllers and the
no-chain backend gain trivial implementations.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new RPC called SubmitPackage to LND's WalletKit. It lets users submit a group of related Bitcoin transactions together so a zero-fee parent can be accepted because a later child transaction pays its fee. This is a feature addition, not a fix for a known vulnerability. The code is careful about limits and permissions, but it does expose a new on-chain write capability that could be misused if an attacker already has a valid macaroon.

Recommended action

Review the new SubmitPackage RPC handler for robustness: ensure transaction deserialization cannot be abused for resource exhaustion, confirm the onchain:write macaroon gating is appropriate, and verify that the fee-rate conversion and neutrino fallback behavior are documented for callers. No immediate security patch appears necessary.

Security signals we found

01

New RPC endpoint gated by onchain:write macaroon permission

02

Package size bounded to 25 transactions to limit deserialization work

03

Fee-rate ceiling passed through to backend; explicit 0 disables limit

04

Neutrino path rejects caller-provided max fee rate rather than silently ignoring it

05

btcd backend unsupported for real package submission

06

No input validation beyond transaction deserialization and count limit

Risk score

Why this scored 30/100

Our methodology →
Potential impact 5/30
Exploitability 4/25
Stealth signal 3/15
Affected reach 6/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.