CommitWatch RSS
EM
← Developer activityStrong match

Elle Mouton

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

268 commits2 monitored projects31 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 Elle MoutonA visual map of monitored and externally discovered repositories.EMdeveloper267LND1btcd
Monitored evidence

CommitWatch projects

LNDLightning Labs267 commits31 candidates0 high riskbtcdbtcsuite1 commits0 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 30 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay

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 featur…

New RPC endpoint gated by onchain:write macaroon permissionPackage size bounded to 25 transactions to limit deserialization workFee-rate ceiling passed through to backend; explicit 0 disables limit
f55c0565by Elle Mouton+1019−21517 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: add gossip version parameter to FilterKnownChanIDs

This commit refactors how a Lightning Network routing database method, FilterKnownChanIDs, receives the gossip protocol version. Previously the version was read from each individual channel record; now it is passed explicitly from the vers…

Defensive version-consistency check added for zombie channel recordsSQL zombie lookup now uses the caller-supplied gossip version rather than per-item version fieldKVStore now explicitly rejects unsupported gossip versions instead of silently using v1 behavior
12f8e509by Elle Mouton+177−1535 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

graph/db: convert TestLightningNodeSigVerification to versioned test

This commit only changes a test file. It renames an existing test and makes it run against two versions of the software's gossip protocol, adding Schnorr signature coverage for the newer version. There is no change to production code, so i…

a9c9e765by Elle Mouton+36−141 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: add v2 block-height path for NodeUpdatesInHorizon

This commit adds a new database query path for a planned v2 gossip protocol feature in LND. It is purely functional code that lets the node list other nodes by block-height range, similar to an existing time-based query. There is no indica…

c14a79c0by Elle Mouton+361−65 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

channeldb: add V2 (taproot) waiting proof codec support

This commit adds database support for a new kind of channel-announcement proof used by upcoming taproot channels. It does not change any live network behavior; it only prepares the code so future taproot features can store their proofs saf…

Codec/schema change for future taproot channel proofsGossiper explicitly rejects non-V1 waiting proofs, preventing accidental processing of unimplemented V2 proofsKey isolation between V1 and V2 proofs prevents same-key collisions
fd239c18by Elle Mouton+375−254 files
No security note in commit
Open full analysis →Source commit ↗
Low 26 AI analysisMessage 95 · Strong
LL Lightning LabsLND BitcoinLightning Network

channeldb: add type-prefix to waiting proof store records

This commit is a forward-looking database format change for LND's 'waiting proof store,' which holds channel announcement proofs. It adds a one-byte type marker to each stored record and its lookup key so that a future gossip v2/Taproot ve…

Database schema migration with key/value rewrite and key-format changeNew explicit type discriminator to prevent cross-version record misinterpretationDecode now rejects unknown waiting proof types
e0256a7dby Elle Mouton+498−107 files
No security note in commit
Open full analysis →Source commit ↗
Low 40 AI analysisMessage 63 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph,discovery: version IsZombieChannel

This commit updates how the Lightning Network Daemon (LND) decides whether a payment channel is a 'zombie'—meaning it has gone stale and should be ignored or pruned. Previously, zombie detection only looked at wall-clock timestamps, which …

Version-aware zombie pruning closes a correctness gap where v2 channel freshness was evaluated only by time, not block heightRemoval of a TODO noting that v2 block-height freshness was not handled in gossip syncRefactoring of a security-relevant predicate (zombie detection) across gossip and routing stacks
cb99637fby Elle Mouton+149−505 files
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: version FilterChannelRange

This commit changes how LND's graph database filters channel ranges by adding a 'gossip version' parameter. It is a preparatory/infrastructure change: the older KV database now explicitly refuses version 2 requests, while the newer SQL dat…

API signature change to enforce version-aware channel range filteringKV store hard-rejects unsupported gossip versions with a sentinel errorSQL store filters by version in application code but still queries a v1-specific SQL helper (TODO noted)
3c06daedby Elle Mouton+72−225 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: support v2 channel proofs in AddEdgeProof

This commit extends a database function in the LND Lightning node so it can store both old-style (v1) and new-style (v2) channel authentication proofs. Previously, the code only accepted v1 proofs and would reject v2 proofs with an error. …

Previously rejected v2 channel proofs, potentially leaving v2 channels without stored authentication proofAdds version-aware SQL dispatch for channel proof storageIncludes new unit tests covering both v1 and v2 proof insertion paths
99d622caby Elle Mouton+92−872 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 51 AI analysisMessage 100 · Strong
LL Lightning LabsLND BitcoinLightning Network

graph/db: treat empty channel signatures as missing

This commit fixes a bug in LND's Lightning Network graph database where empty channel signatures were being treated as valid proof that a channel was publicly announced. Because the code previously treated empty byte slices the same as rea…

Logic flaw: empty byte slice treated as valid authentication proofPublic-node/channel classification depends on signature presenceSQL NULL vs empty bytea inconsistency in stored proof data
6328c4d8by Elle Mouton+85−275 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

sqldb/sqlc: add AddV2ChannelProof query

This commit adds a new database query to support v2 Lightning channel proofs. It simply updates a single signature column for v2 channels, whereas the older v1 proof format required four separate signatures. There is no security issue visi…

315f5ed7by Elle Mouton+23−03 files
No security note in commit
Open full analysis →Source commit ↗
Informational 3 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

sqldb/sqlc: add IsPublicV2Node query

This commit adds a new database query helper that checks whether a Lightning node has any 'version 2' public channels. It is purely additive and does not change any existing behavior or fix a known bug. There is no indication in the commit…

No security-relevant signals observed in the diff or commit message.Change is additive only and introduces no new attack surface by itself.
a99604c7by Elle Mouton+53−03 files
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: add version parameter to IsPublicNode

This commit updates how LND decides whether a Lightning node is 'public' so that the decision respects the network's gossip protocol version. In the older v1 protocol, a node needed four signatures to be considered public; in the newer v2 …

Protocol-version-specific logic added to node publicity classificationPreviously v2 gossip nodes could be evaluated under v1 four-signature ruleKVStore explicitly rejects non-v1 gossip versions for this query
971c0f6eby Elle Mouton+46−246 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

graph/db: add version parameter to createEdge test helper

This commit only changes test code. It extends a helper function used in unit tests so it can create both old-style (v1) and new-style (v2) fake Lightning channels for testing. No production code is modified, so it cannot directly affect r…

6bb3bdc8by Elle Mouton+125−531 file
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

multi: update models.ChannelAuthProof with v2 field

This commit refactors how Lightning Network channel authentication proofs are represented in the lnd codebase. It adds support for a future v2 channel announcement format (using a single Schnorr signature) while keeping v1 (four ECDSA sign…

Refactoring of security-critical data structure (channel authentication proof)Explicit rejection of unsupported v2 proofs in both database storesUse of option types to prevent accidental use of absent v1/v2 fields
7a260ee1by Elle Mouton+300−17511 files
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: update SQLStore to read and write v2 channels

This commit extends LND's SQL graph database to store and retrieve a newer type of Lightning channel announcement (called 'v2' or 'taproot' channels). It adds support for new fields like funding scripts, Merkle root hashes, and a single si…

Input validation added: AddChannelEdge rejects unknown gossip versions before DB operations.Version-specific handling replaces a hard-coded v1-only path, reducing the chance of version mismatch or data corruption when v2 announcements are received.Optional fields are length-checked before conversion, which is defensive but not obviously fixing a known vulnerability.
fa24d336by Elle Mouton+147−582 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

sqldb/sqlc: update graph CreateChannel query for v2

This commit updates a database query used to store Lightning Network channel announcements. It adds three new optional fields needed for newer 'v2' channel types (a single Schnorr signature, the funding output script, and a Merkle root has…

ec46480aby Elle Mouton+10−42 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

graph/db: remove unused sig field from ChannelEdgePolicy

This commit removes an unused internal cache field that stored a parsed cryptographic signature alongside the raw signature bytes. It is a straightforward code cleanup with no security-relevant behavior change: callers still access the raw…

6fda2e8dby Elle Mouton+2−342 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 95 · Strong
LL Lightning LabsLND BitcoinLightning Network

itest+lntest: add coordinator pattern test for combined nonce

This commit only adds new integration tests and test helper wrappers for the MuSig2 'coordinator pattern' RPCs. It does not change any production code, wallet logic, or consensus behavior. There is no security vulnerability here.

fb48697fby Elle Mouton+262−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

signrpc: implement combined nonce RPC server handlers

This commit adds two new server-side RPC handlers for an advanced multi-signature signing feature called MuSig2. The handlers let a caller register a pre-aggregated combined nonce and retrieve the combined nonce for a signing session. The …

New RPC surface added to signer subsystemMacaroon permissions assigned: generate for register, read for getInput validation performed for session ID and combined nonce length
16b9192dby Elle Mouton+64−01 file
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 →