CommitWatch RSS
B
← Developer activityStrong match

bitromortac

Public commit activity attributed with strong match confidence. This page describes observable work, not personal trustworthiness.

46 commits1 monitored projects5 candidates0 high-risk analyses
Project constellation

Where the commits appear

Amber nodes are monitored by CommitWatch. Gray nodes are sampled from authenticated GitHub public commit search and may not represent complete contribution history.

Monitored External sample
Projects connected to bitromortacA visual map of monitored and externally discovered repositories.Bdeveloper46LND
Monitored evidence

CommitWatch projects

LNDLightning Labs46 commits5 candidates0 high risk
External discovery

Other public projects

No external sample loaded yet.

A verified GitHub handle is needed before external discovery.
Analyzed activity

Recent published watches

Message quality and risk characterize commits, never the person.

Low 33 AI analysisMessage 47 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update release notes

This commit updates the release notes for LND 0.21.2 to describe a fix for a bug in the HTLC interceptor RPC. The bug caused LND to fail to forward payments in blinded routes when the next hop was identified by node ID instead of channel I…

Blinded route forwarding failure could disrupt payment routing or be used to probe path structure.Sentinel value change in RPC API could cause client misclassification of forwards if not handled.Release notes describe the change as a fix for a forwarding issue, not as a security vulnerability.
f42b4298by bitromortac+20−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 14 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

itest: cover blinded route next_node_id forwarding

This commit only adds new integration tests for an existing feature in LND: forwarding blinded payments where the next hop is identified by node ID rather than channel ID. It does not change production code, fix a bug, or introduce any new…

da6a40c0by bitromortac+432−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

witness beacon: report node-ID next hop to the on-chain HTLC interceptor

This change fixes a reporting gap in LND's 'witness beacon,' a component that watches on-chain transactions and tells the HTLC interceptor where a payment should go next. Previously, when the next hop was identified by a node ID rather tha…

Missing security-critical metadata in on-chain interception pathBehavioral parity between on-chain and off-chain HTLC interceptionPotential misclassification of node-ID forwards as final receives
9c4b8bfeby bitromortac+59−52 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 81 · Strong
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: forward node-ID blinded hops via non-strict forwarding

This commit fixes a bug in LND's payment forwarding for 'blinded routes'—a privacy feature in the Lightning Network. Previously, if the next hop was identified by node ID rather than a specific channel ID, the payment could not be forwarde…

Fixes a functional forwarding failure for blinded-route payments using node-ID next hops (issue #10937).Prevents private channel SCID leakage in failure messages for node-ID blinded hops by returning FailUnknownNextPeer instead of a channel_update.Adds circular-route filtering for node-ID next hops before non-strict forwarding selection.
dbc57040by bitromortac+334−416 files
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: classify a node-ID forward as a forward event

This commit fixes a bookkeeping bug in LND's HTLC event stream. When a payment is forwarded to a 'blinded' next hop identified only by a node public key (not a channel ID), and it fails before the switch picks an outgoing channel, the even…

Event misclassification in HTLC event stream (forward reported as receive)Blinded/node-ID forwarding path introduced prior to this fixFailure and resolution packets dropped next-hop metadata before fix
a4844ef5by bitromortac+149−04 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch+lnrpc: report node-ID next hop to the off-chain HTLC interceptor

This change improves how the Lightning Network Daemon (LND) reports forwarding details to external plugins that inspect HTLCs (payment packets). For a new type of blinded route where the next hop is identified by node ID rather than a spec…

Information-correctness fix for HTLC interceptor APIPrevents misclassification of node-ID forwards as exit hopsAdds explicit sentinel to disambiguate zero SCID semantics
32373b76by bitromortac+29−13 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch/hop: decode next_node_id blinded hops

This commit adds support in LND for a different way of identifying the next hop in a private ('blinded') Lightning payment route. Previously LND expected the next hop to be identified by a channel ID; now it also accepts the next node's pu…

New validation enforces BOLT 4 mutual exclusivity of short_channel_id and next_node_id in blinded route dataPreviously ambiguous or unhandled next_node_id forwarding case now explicitly decodedNo memory-safety, cryptographic, or authorization changes observed
4fd4289aby bitromortac+471−86 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

multi: represent the blinded forwarding next hop as an fn.Either

This commit is a behind-the-scenes code cleanup in the LND Lightning node. It changes how the 'next hop' for forwarding payments is stored internally so that, in the future, blinded routes can identify the next hop by a node's public key i…

Refactor of core HTLC forwarding data structure (ForwardingInfo.NextHop)Preparation for blinded route next-hop identification by node public keyEncapsulation of Either type behind IsExit() and NextHopChannel() to centralize exit-hop detection
d28a7176by bitromortac+83−2612 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 85 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnrpc/routerrpc: add outgoing_node_id to HTLC intercept request

This commit only updates the API definition and auto-generated code for LND's HTLC interceptor. It adds a new optional field, outgoing_requested_node_id, and documents that when a blinded route uses a node ID instead of a channel ID, the e…

No runtime logic changed; only protobuf schema and generated stubsNew field is explicitly documented as unpopulated until later commitsSentinel value (MaxUint64) introduced to prevent misclassification of final receive vs node-addressed forward
14640a50by bitromortac+48−73 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: key the aux traffic shaper on the evaluated channel

This commit fixes a routing bug in LND's Lightning payment forwarding. When a payment could take any of several parallel channels to the same next peer, the node was accidentally asking an optional 'auxiliary traffic shaper' about the chan…

Logic error: wrong channel identifier used for auxiliary policy/bandwidth checkPotential information disclosure: real SCID could leak if passed to shaper-driven wire messages; commit explicitly prevents thisParallel-channel forwarding correctness issue
b1667800by bitromortac+133−12 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 47 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update release notes

This commit only updates the release notes document. It adds a one-line description mentioning that a new feature for handling BOLT 12 invoice errors was added. There are no code changes, no bug fixes, and no security-related content in th…

5fcdc16aby bitromortac+4−01 file
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 ↗
Low 36 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: validate Invoice messages

This commit adds validation checks for BOLT 12 invoices in the LND Lightning node software. It ensures invoices contain required fields (creation time, amount, payment hash, node ID, payment paths), match their originating invoice requests…

New validation gate added to Invoice.Encode() to reject malformed invoices before serializationReader rejects unknown even invoice TLV types and unknown even feature bitsReader enforces chain compatibility against activeChain
e0f04f17by bitromortac+1642−74 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 72 · Adequate
LL Lightning LabsLND BitcoinLightning Network

docs: add BOLT 12 invoice release notes

This commit only adds documentation to the release notes. It describes a new BOLT 12 invoice feature that was added in a previous code change, and explicitly notes that signature verification is not yet implemented. There is no code change…

1ed6719bby bitromortac+7−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 47 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update release notes

This commit only adds a release notes document. It does not change any program code. The notes mention that a separate pull request fixed bugs in how LND decodes onion-routed Lightning messages, but this commit itself is purely documentati…

68bc7691by bitromortac+71−01 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 85 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwire: reject onion message payloads with unknown even types

This commit fixes a standards-compliance bug in how LND decodes onion-routed messages in the Lightning Network. The relevant protocol rule (BOLT 4) says that if a message contains an unknown even-numbered data field, the receiver must reje…

Protocol compliance fix for BOLT 4 'must understand' even TLV typesPreviously accepted malformed/ambiguous onion message payloadsPotential for protocol confusion or forwarding of invalid onion messages
33c510faby bitromortac+68−62 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwire: preserve unknown odd zero-length final hop TLVs

This commit fixes a small but real bug in how LND decodes onion-routed messages (used in Lightning Network offers and blinded paths). Unknown extra data fields with a valid but empty value were accidentally dropped because the code used a …

Loss of protocol data: valid unknown odd zero-length TLVs were dropped during decodeTLV parsing logic conflated 'recognized type' (nil map entry) with 'zero-length value' (empty byte slice)Fix changes skip condition from length check to nil check
bc5cfb5aby bitromortac+30−42 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwire: reject onion message payloads with multiple final hop fields

This change tightens how LND handles special 'final hop' data in onion-routed Lightning messages. Previously, a message could bundle several final-hop payload types (such as an invoice request, an invoice, and an invoice error) together an…

Protocol-conformance fix enforcing BOLT 4 final-hop payload count rulePrevents ambiguous or conflicting final-hop message interpretationRejects bundled invoice_request/invoice/invoice_error payloads
233e3777by bitromortac+29−222 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: inject feature-bit catalogues into Offer and InvoiceRequest validators

This change updates how the LND code checks feature bits in BOLT 12 offers and invoice requests. Previously, the read-side validator treated every even feature bit as unknown and would reject it, because it had no list of known features. N…

Feature-bit validation logic changed from hard-coded nil catalogue to caller-supplied catalogueWrite-side feature enforcement removed entirelyRead-side now accepts even feature bits that the local node knows, rejects only unknown even bits
732b0413by bitromortac+61−182 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: add TUint32 and invoice subtypes

This commit adds new data-encoding helpers for the BOLT 12 Lightning invoice format, including a truncated uint32 type, blinded payment info records, and fallback address records. It is a pure feature-addition patch with no bug fixes or se…

New codec code for untrusted wire data includes length caps and minimal-encoding validationNo CVE, advisory, or vendor security disclosure referenced in commit or supplied materialsNo removal of unsafe code or correction of prior behavior observed
e548d62dby bitromortac+639−03 files
No security note in commit
Open full analysis →Source commit ↗
Wrong identity?Names can collide and public author strings can be misleading.Contact commitwatch@karma-x.io →