CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 17 Bitcoin

mod: bump protobuf hex display fork

LL3f3718ca View source ↗
Public commit record

What the developer wrote

Authored by ziggie

68/100 · Adequate
mod: bump protobuf hex display fork

Update google.golang.org/protobuf to v1.36.11 and point the replace
directive at the matching lightninglabs/protobuf-go-hex-display
v1.36.11-hex-display tag.

This keeps the fork aligned with the latest upstream protobuf-go release
while preserving the UseHexForBytes option used by the CLI JSON marshal
and unmarshal paths.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a routine dependency update. It bumps the project's custom protobuf (protocol buffer) code generator fork from version 1.33.0 to 1.36.11 of the upstream Google library, while keeping a Lightning Labs-specific tweak that displays raw bytes as hexadecimal in CLI JSON output. The only code changes are regenerated version strings in generated files; no application logic was modified.

Recommended action

No security action required. Treat as normal maintenance. If reviewing for supply-chain risk, verify the upstream protobuf v1.36.11 release notes and the diff of the lightninglabs/protobuf-go-hex-display fork for any security fixes or behavioral changes not shown in this commit.

Security signals we found

01

Dependency bump only

02

No application logic changes

03

Regenerated generated protobuf code

04

Maintains existing hex-display fork behavior

Risk score

Why this scored 17/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/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.

More from LND

Related watches

Moderate 63 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11024 from ziggie1984/invoices-update-validation

This commit tightens how LND processes invoice payments, especially for newer multi-path (MPP) and AMP invoices, keysend payments, and replayed payments. It adds checks that ensure the right payment preimage is used for each invoice type a…

Preimage validation added for AMP and regular invoice replaysAMP invoices forced into MPP update path, preventing legacy-path processingLegacy settlement now fails when invoice-level preimage is missing
61f3b5a7by ziggieXXX+482−114 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 35 · Opaque
LL Lightning LabsLND BitcoinLightning Network

invoices: refine update handling

This commit tightens how LND handles invoice payment updates, especially for newer 'AMP' invoices and old-style 'keysend' payments. It adds checks so that the wrong kind of payment cannot be processed against the wrong kind of invoice, and…

Added preimage/hash mismatch checks for both regular and AMP invoice replaysAMP records now require an MPP payload, preventing AMP processing on the legacy pathLegacy path now rejects AMP invoices and invoices missing invoice-level preimages
6be6350eby ziggie+476−113 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: add InvoiceError onion message replies

This commit adds support in LND for a new Lightning protocol message called InvoiceError. It is used to politely tell another node why their payment invoice or invoice request was rejected, sent privately through an onion-routed message. T…

New unsigned onion message type added with no cryptographic signature or bech32 formWriter-side validation prevents empty or non-UTF-8 error strings and disallowed suggested_value without erroneous_fieldReader-side BOLT 1 must-understand rule enforced: unknown even TLVs rejected, unknown odd TLVs tolerated
e279cdf1by bitromortac+567−04 files
No security note in commit
Open full analysis →Source commit ↗