CommitWatch RSS
MC
← Developer activityStrong match

Matt Corallo

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

335 commits1 monitored projects44 candidates1 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 Matt CoralloA visual map of monitored and externally discovered repositories.MCdeveloper335rust-lightning
Monitored evidence

CommitWatch projects

rust-lightningLightning Dev Kit335 commits44 candidates1 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.

Informational 15 AI analysisMessage 45 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Pin jobserver to 0.1.34 on pre-1.85 rustc

This commit adjusts the project's continuous integration (CI) test script to pin an older version of a build-time helper crate called `jobserver` when using older Rust compilers. It is a build compatibility fix, not a security patch, and d…

a4641403by Matt Corallo+3−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Require `htlc_value_satoshis` in [pending] `HTLCUpdate`s

This commit removes the 'Option' wrapper from several HTLC amount fields, making them required instead of optional. It is a cleanup/refactoring change that simplifies the code by assuming the amount is always known. The commit message fram…

Removal of Option wrapper for financial amount fieldsSerialization format change from optional to required TLV fieldsLoss of backward compatibility with older serialized monitor/channel state
40957aadby Matt Corallo+24−284 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Unify and simplify the application of simple chacha20 passes

This commit is a code cleanup: it moves repeated ChaCha20 encryption calls into a single helper function without changing the underlying math or behavior. There is no indication it fixes a security bug or introduces a new vulnerability.

Refactor only: identical ChaCha20 construction moved to helperNo change to key, nonce, or counter derivationNo new unwraps introduced; existing unwraps consolidated
4fac0fe1by Matt Corallo+23−583 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 53 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Use `saturating_mul` when multiplying feerates by the fee spike buf

This patch fixes a potential integer overflow when calculating Lightning channel fees. If a malicious or misconfigured peer set an extremely high transaction fee rate, the software could overflow a 32-bit integer while applying a safety bu…

Integer overflow in fee calculationUse of saturating_mul to prevent u32 wraparound/panicRemotely reachable input (peer-provided feerate) drives the overflow
b98d7b8aby Matt Corallo+7−52 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct blinded path forwarding CLTV expiry check

This commit fixes a bug in how Lightning Dev Kit checks expiry times for payments sent through 'blinded paths' (a privacy feature that hides the final recipient). The code was accidentally checking the outgoing expiry time instead of the i…

CLTV expiry check using wrong variable (outgoing vs inbound)Blinded path privacy/cost-protection bypassTest updated to reflect intended introduction-node rejection behavior
8d8313deby Matt Corallo+14−152 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Include MPP payment amount in `RecipientOnionFields`

This commit is a preparatory refactor in LDK's payment-sending code. It adds a new `total_mpp_amount_msat` field to `RecipientOnionFields` so that, in future commits, a payer can send an HTLC that is only one part of a larger multi-part pa…

New required field added to a core payment API (`RecipientOnionFields`)Serialization compatibility wrapper introduced for persisted `ClaimableHTLC` onion fieldsAssertion added that new `total_mpp_amount_msat` must equal existing amount (currently enforced)
abf258a6by Matt Corallo+504−34329 files
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Validate the `Router` is meeting MPP and max-fee limitations given

This commit adds safety checks inside the Lightning payment code to make sure the route finder (the 'Router') actually follows the rules it was given. Before sending a payment, the code now verifies that the chosen route does not exceed th…

Defensive validation of externally supplied router outputFee-bounds enforcement for routing feesMPP redundancy check preventing unnecessary payment parts
c31a7beeby Matt Corallo+106−246 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add an `ExpandedKey` key for phantom blinded path authentication

This commit adds a seventh cryptographic key to an existing key-expansion routine. The new key is intended for a future feature where multiple nodes can share a 'phantom' blinded payment path. The change itself only extends the HKDF output…

Cryptographic key material expansion changed (HKDF output count increased from 6 to 7)New secret key field added to `ExpandedKey` structNo security relevance disclosed by the vendor in commit message or diff
14a47405by Matt Corallo+18−72 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Export `outbound_payments` directly rather than via re-exports

This commit is a straightforward code cleanup in a Rust Lightning library. It stops hiding an internal module behind re-exports and exposes it directly in the public API. The change fixes an earlier accidental break in the public API where…

No memory-safety, cryptographic, or payment-state changesNo new input parsing or network message handlingNo change to consensus, channel, or HTLC logic
0bc5c954by Matt Corallo+68−5528 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Import `ChannelTransactionParameters` from its real path

This commit is a pure code cleanup: it changes where one internal type, ChannelTransactionParameters, is imported from. There is no functional change, no bug fix, and no security relevance visible in the diff or commit message.

b07111e3by Matt Corallo+3−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Require the high-level sign traits instead of `SignFn` in bindings

This commit is a documentation-only change in the Rust Lightning library. It adds a comment explaining that a generic signing helper trait called SignFn is intentionally not exposed to language bindings (for users of other programming lang…

2bf737ceby Matt Corallo+3−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add missing documentation for sigs-ready event to `splice_channel`

This commit only adds a missing documentation comment to the splice_channel function. It explains that a FundingTransactionReadyForSigning event will be generated after signatures are exchanged, and that funding_transaction_signed should t…

00e06a06by Matt Corallo+3−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix `generated_by_local` arg to build commmitment during splicing

A single boolean argument in a function call was corrected during a process called 'splicing' (a way to resize a Lightning channel). The argument tells the code whether the local side is the one creating the commitment transaction. The com…

Argument-correctness fix in commitment-building codeNo async HTLC state changes during affected code path per commit messageNo validation bypass, overflow, or authorization change visible in diff
0f4e6c22by Matt Corallo+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Properly handle funding key rotation during splices

This commit fixes a bug in how the Lightning Dev Kit (LDK) handles key rotation when splicing a channel. Splicing is a way to resize a Lightning channel on-chain. The protocol only allows changing the 'funding key' during a splice, but LDK…

Protocol violation: non-funding keys rotated during splicePotential commitment signature mismatch after spliceAPI ambiguity allowed signer to return incompatible key set
e95ebf8bby Matt Corallo+112−767 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 79 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix panic when deserializing `Duration`

This commit fixes a bug where a specially crafted network message could cause the Lightning Dev Kit software to crash. The crash happens while reading a time duration from the message. The fix rejects obviously invalid duration values befo…

Remote denial-of-service (panic/crash) via deserialization of untrusted inputInteger overflow-like panic in standard-library wrapper (`Duration::new`)Missing input validation before constructing `Duration`
7b9bde12by Matt Corallo+8−11 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 33 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add support for deriving and signing a new static remote key

This commit changes how a Lightning wallet (LDK) derives one of the keys that receives funds when the other party force-closes a channel. Previously, that key depended on per-channel state, so if a user lost all state except their main see…

New key derivation path added for disaster recovery of counterparty-force-closed fundsSpending code updated to support both old and new derivation formatsTODO comment indicates the actually-used key is not yet dynamic
7ff74d5cby Matt Corallo+120−256 files
No security note in commit
Open full analysis →Source commit ↗
Low 31 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Allow `KeysManager` to opt-into the new `remote_key` derivation

This commit adds an opt-in feature to LDK's key manager that changes how on-chain backup addresses are derived when a channel is force-closed by the other party. The new derivation makes these addresses come from a small, predictable set, …

New key derivation flag added to `KeysManager::new` and `PhantomKeysManager::new`Old `remote_key` derivation depended on `channel_keys_id`, making funds unrecoverable if channel state is lostNew derivation uses a static set of keys, enabling blockchain scanning for disaster recovery
189b8ac4by Matt Corallo+118−5120 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Convert `ChannelSigner::pubkeys` to only fetch *new* pubkeys

This commit is a preparatory refactor in LDK's key-handling code. It renames a trait method from `pubkeys` to `new_pubkeys` and changes the default signer so it no longer caches a fixed set of holder public keys. The stated goal is to allo…

API rename from `pubkeys` to `new_pubkeys` with semantic contract changeRemoval of cached `holder_channel_pubkeys` from `InMemorySigner`Documentation now allows `new_pubkeys` to return different keys per call
9d291e01by Matt Corallo+56−899 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 88 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correctly handle new `ChannelMonitorUpdate`s to old post-FC chans

This patch fixes an integer overflow bug in the Lightning Dev Kit (LDK) rust-lightning implementation. For very old channels that were closed before version 0.1, an internal counter used to track channel monitor updates could be set to the…

Integer overflow in update_id generation for pre-0.1 closed channelsPotential panic/crash when processing monitor updates for legacy closed channelsPost-closure ChannelMonitorUpdate ID collision risk acknowledged by author
dd21fce8by Matt Corallo+10−31 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct EOF handling in stream read in `ChaChaDualPolyReadAdapter`

This commit fixes a bug in rust-lightning's encrypted stream reader where reaching the end of a data stream could cause the program to get stuck in an endless loop instead of stopping cleanly. The fix makes the reader recognize the end-of-…

Infinite loop / denial-of-service condition on malformed or truncated encrypted inputMissing EOF handling in a stream-draining loopDiscovered by fuzzing (`onion_message_target`)
423844deby Matt Corallo+20−11 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Wrong identity?Names can collide and public author strings can be misleading.Contact commitwatch@karma-x.io →