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 candidates4 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 candidates4 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 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add test framework coverage of `Listen` block connection replays

This commit only adds a new test mode to the project's internal testing framework. It lets developers simulate a specific way blocks are delivered to the Lightning node (a 'replay' through the Listen interface) so that behavior is covered …

bf6ad23eby Matt Corallo+18−32 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update functional test block connection to detect block replays

This commit changes only internal test helper code in the Lightning Dev Kit repository. It makes the functional test framework smarter about 'block replays'—situations where the same block is fed to a test node more than once—so the fake b…

No production code modifiedNo cryptographic, consensus, or networking changesCommit message frames change as test-framework correctness, not security
477facb4by Matt Corallo+41−333 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 66 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct HTLC confusion on unrevoked counterparty commitment txs

This patch fixes a bug in the Lightning Dev Kit where the software could confuse HTLCs (payment contracts) on live, unrevoked counterparty commitment transactions with ones from old, revoked transactions. Previously, it relied only on whet…

Incorrect revocation state detection for counterparty commitment transactionsHTLC direction not previously checked when matching against pending HTLCsPromotion of debug assertions to full assertions for HTLC claim path consistency
f06a08a6by Matt Corallo+26−192 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Return `Err`s` instead of panicking on oversized messages

This commit changes how the Lightning networking code handles oversized encrypted messages. Previously, certain conditions would cause the program to crash with a panic. Now the code returns errors instead, which is a defensive improvement…

panic-to-error conversion for oversized message encryption/decryptiondenial-of-service hardening against oversized peer messagesdebug_assert retained to preserve test coverage of invariant violations
08f12bc7by Matt Corallo+68−313 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panicking when attempting to send an oversized message

This commit fixes a crash bug in the Lightning Dev Kit's peer message handling. Previously, if a message grew too large to be sent over the encrypted peer connection, the code would panic (abruptly terminate the whole program). The patch m…

Replaces a `.expect()` panic path with a fallible `Result` in peer message encryptionAdds graceful peer disconnection when a critical message cannot be sentIncludes a regression test for oversized-message handling
c5fdc3bfby Matt Corallo+148−901 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 74 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid oversized relayed failure messages

This patch fixes a crash bug in the Lightning Dev Kit's handling of HTLC failure messages. A downstream peer could send a maximally-sized failure message without attribution data. When the node added its own attribution data while relaying…

Denial-of-service via remote-triggered panic in message encryptionOversized message exceeding Noise/Lightning wire framing limitMissing length validation before adding attribution data during relay
6b1dfb1aby Matt Corallo+64−191 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reject attempts to advance one-hop blinded forward paths

This commit fixes a denial-of-service bug in rust-lightning where a maliciously crafted one-hop blinded reply path could cause the node to panic when it tried to respond. The fix rejects paths with too few hops before advancing them, and a…

Denial-of-service vector via malformed blinded pathPanic in onion construction due to zero-hop pathUntrusted reply path input validation gap
969a40cfby Matt Corallo+49−14 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 57 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panic when reorged claims cannot merge

This commit fixes a crash bug in the Lightning Dev Kit's on-chain transaction handler. During a deep blockchain reorganization, a previously settled HTLC claim could be 'resurrected' at a block height where it could no longer be combined w…

Assertion/panic in reorg handling pathDeep blockchain reorg as trigger conditionHTLC claim resurrection after reorg
f1dc8487by Matt Corallo+219−52 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 65 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct docs on `ChannelSigner::get_per_commitment_point`

This commit only updates documentation comments for a Rust function called get_per_commitment_point. It removes an outdated warning that the method was non-asynchronous and that returning an error could cause a crash, and replaces it with …

Documentation-only changeRemoves outdated panic warningAdds retry/unblock guidance for signer errors
5057809bby Matt Corallo+6−31 file
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Generate `DNSSECError` messages when DNSSEC resolution fails

This commit adds a new error-reporting path in a Lightning DNS resolver. Previously, if a DNSSEC proof lookup failed, the resolver simply stayed silent. Now it sends back an explicit 'DNSSECError' message so the requester knows the lookup …

Eliminates silent failure on DNSSEC proof resolution errorsAdds authenticated NXDOMAIN signaling to prevent indefinite fallback waitsNo new unsafe code, unwraps, or cryptographic operations introduced
1a4694bfby Matt Corallo+99−71 file
No security note in commit
Open full analysis →Source commit ↗
Low 38 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct DNSSEC proof validity time gap applied to header time

This commit fixes a typo-like bug in how DNSSEC proofs are checked against the latest known block time. The code was meant to allow a two-hour time window but accidentally used a two-minute window. This could cause valid DNSSEC proofs to b…

Time-window validation bug in DNSSEC proof verificationIntended two-hour tolerance implemented as two-minute toleranceAffects only non-std or fuzzing build configurations
d14c22a3by Matt Corallo+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 65 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Rename `OMNameResolver::resolve_name` to `initiate_resolution`

This commit is a simple rename of a Rust method from `resolve_name` to `initiate_resolution`, plus matching updates to comments and test code. It does not change what the code does, only how it is named and described. There is no security …

0460fda6by Matt Corallo+33−202 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

f note that only one resolution will fail at a time

This commit only adds two explanatory comments to the code. It does not change any program behavior, fix any bug, or alter any logic. The comments clarify that although the code is written to handle multiple failed DNS resolutions at once,…

a2fe23f5by Matt Corallo+6−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 48 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

f names in test lookups

This is a tiny code cleanup inside a test file. It renames a local variable from `pending` to `pending_resolves` and introduces a helper variable `pending_queries_for_name` to avoid repeating the same lookup expression. There is no change …

081a8e10by Matt Corallo+9−41 file
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Report the used success probabilities in scorer accessor methods

This commit fixes two related issues in rust-lightning's payment scorer. First, two public accessor methods that report estimated payment success probabilities could trigger a debug-only assertion (a crash in debug builds) when asked about…

Debug assertion reachable through public API when amount_msat equals or exceeds channel capacity/max liquidityPublic probability accessors returned raw estimates inconsistent with internal scoring, potentially misleading callersNew lower-bound clamping aligns accessor output with actual routing penalty calculations
68123876by Matt Corallo+39−91 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 28 · Opaque
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Format changed functions

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations and lets rustfmt reformat several functions in the routing/scoring module. No logic, behavior, or security properties of the code are changed.

05ce4204by Matt Corallo+44−251 file
No security note in commit
Open full analysis →Source commit ↗
Informational 16 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct + update scoring attempts right at the maximum amounts

This commit tweaks how the Lightning payment router estimates whether a payment can fit through a channel. Previously, sending an amount exactly equal to a channel's maximum capacity or estimated liquidity upper bound was treated as imposs…

No security-relevant keywords in commit title or messageNo unsafe code, no input parsing, no serialization format changesNo bounds-checking or integer-overflow fixes
a6964ab9by Matt Corallo+19−131 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Change assign-reviewer authorized integration token to a bot acct

This commit swaps the ID number used by an automated workflow that randomly assigns code reviewers. The old number pointed to a real person's account, so the workflow's assignments appeared to come from that person. The new number points t…

f734d1ebby Matt Corallo+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Handle `DNSSECError` messages when attempting DNSSEC resolution

This commit adds support in the Lightning Dev Kit for a new DNSSEC error message type. Previously, if a DNS resolver couldn't resolve a human-readable Lightning address, the client would simply wait and eventually time out. Now, the client…

New message handling path added for DNSSECErrorMulti-resolver query tracking with per-query blinded-path contextsPrevents a single misbehaving resolver from failing a resolution prematurely
a705abdbby Matt Corallo+205−582 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add infrastructure for handling `DNSSECError` onion messages

This commit adds plumbing for a new Lightning onion message type called DNSSECError. It lets a DNS resolver tell a payer that a name could not be resolved, so the payer can fail or retry faster. The change is mostly new message framing and…

New network message type added with serialization/deserialization codeDefault handler is a no-op, so security relevance depends on future implementationsMessage is only processed when a valid DNSResolverContext is present
c37b0dc4by Matt Corallo+81−45 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 →