CommitWatch RSS
CK
← Developer activityVerified account

Carla Kirk-Cohen

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

@carlaKC on GitHub ↗
78 commits1 monitored projects3 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 Carla Kirk-CohenA visual map of monitored and externally discovered repositories.CKdeveloper78rust-lightning
Monitored evidence

CommitWatch projects

rust-lightningLightning Dev Kit78 commits3 candidates0 high risk
External discovery

Other public projects

No external sample loaded yet.

Authenticated GitHub discovery can enrich this profile.
Analyzed activity

Recent published watches

Message quality and risk characterize commits, never the person.

Informational 16 AI analysisMessage 35 · Opaque
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/refactor: remove BlindedTrampolineEntrypoint

This commit is a small internal code cleanup in the Lightning Dev Kit's Trampoline routing code. It removes a separate 'BlindedTrampolineEntrypoint' payload variant and folds an optional blinding point into the existing 'Forward' variant. …

Refactor-only change with no added bounds checks or validationNo mention of vulnerability, CVE, security fix, or bug in commit messageTLV field changed from required to optional, but only for a newly unified variant used in internal construction
3e0c2697by Carla Kirk-Cohen+8−263 files
No security note in commit
Open full analysis →Source commit ↗
Informational 13 AI analysisMessage 60 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/test: add tests for mpp accumulation of trampoline forwards

This commit only adds new unit tests for an existing trampoline forwarding feature in a Lightning network implementation. It does not change production behavior, fix a bug, or alter security logic. The tests exercise validation rules that …

b90152b0by Carla Kirk-Cohen+235−13 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 55 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/test: add test coverage for MPP trampoline

This commit only adds new test code for multi-path trampoline payments in the Lightning Dev Kit. It does not change any production logic, so it cannot introduce a security vulnerability on its own.

b975ff31by Carla Kirk-Cohen+277−41 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 75 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/tests: return BlindedPaymentPath from trampoline helper

This commit is a test-only refactor. It changes a helper function used in Lightning Dev Kit's internal tests so that it returns both a blinded payment tail and the full blinded payment path. This lets tests register the path in payment par…

19eefdefby Carla Kirk-Cohen+43−302 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: process added trampoline htlcs with CLTV validation in tests

This commit changes how the Lightning node handles a special kind of forwarded payment called a 'trampoline' payment. Previously, trampoline forwards were always rejected. Now, in test builds only, the code allows them through after checki…

Trampoline forwarding previously hard-rejected; now conditionally accepted in test builds with reduced validationCLTV and fee-skim checks added for trampoline forwards, but full channel-level forwarding checks still skippedProduction code path continues to reject trampoline forwards
4329fe92by Carla Kirk-Cohen+28−1262 files
No security note in commit
Open full analysis →Source commit ↗
Low 26 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: handle DecodedOnionFailure for local trampoline failures

This commit fixes a code path in the Lightning Dev Kit where a specific kind of local payment failure (called a 'TrampolineForward' failure) was not being handled. Previously, the code only expected failures from regular outbound routes an…

Removal of unreachable!() panic path for TrampolineForward HTLC sourceAddition of local trampoline failure decoding in onion error handlingIntentional non-setting of payment_failed_permanently for local failures to allow retry
4f2429eaby Carla Kirk-Cohen+28−171 file
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: double encrypt errors received from downstream failures

This commit adds missing encryption wrapping for error messages in the Lightning Dev Kit when acting as a 'trampoline' forwarding node. Previously, if a downstream node returned an error that the trampoline could not fully decrypt, the err…

Missing cryptographic wrapping of failure packets in trampoline forwarding pathPotential information leakage or unrecoverable error propagation for trampoline paymentsCommit describes the change as bare-minimum with followup proper error handling planned
c6adebfdby Carla Kirk-Cohen+4−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: add trampoline mpp accumulation with rejection on completion

This commit adds partial support in the Lightning Dev Kit node software for receiving and temporarily holding multi-part trampoline payments, then deliberately rejects them once all parts arrive because full outbound forwarding is not yet …

New trampoline forward handling path accumulates MPP parts before rejectingDebug assertion guards first-HTLC failure in MPP mergeTODO comment flags possible MPP inconsistency in next_node_id across trampoline parts
1afd35e6by Carla Kirk-Cohen+240−112 files
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: add awaiting_trampoline_forwards to accumulate inbound MPP

This commit adds a new internal bookkeeping map for a not-yet-enabled feature called trampoline routing. The commit itself is defensive: it documents that the new map is intentionally not saved to disk and warns that using it in production…

New non-persistent state map for pending trampoline MPP HTLCsCommit message explicitly warns of force-close risk if used in production before persistence/restart logic is addedTrampoline HTLCs are currently rejected earlier in the lifecycle, mitigating the documented risk
bfb4acb8by Carla Kirk-Cohen+63−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use outer onion values for trampoline NextPacketDetails

This change fixes how trampoline-style Lightning payments decide how much money and when (time lock) to forward to the next hop. Previously the code used values from the inner trampoline onion, which could differ from what the forwarding n…

Amount/CLTV mismatch between outer and inner trampoline onionsRemoval of blinded-forward amount/cltv recalculation in favor of outer onion valuesTrampoline forwarding logic change in payment onion decoding
52f2394aby Carla Kirk-Cohen+6−151 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: store next trampoline amount and cltv in PendingHTLCRouting

This commit changes how Lightning trampoline payments are tracked internally. It stores the amount and expiry time that the next trampoline hop expects, so the node remembers them when forwarding a payment. The change looks like a correctn…

Previously computed next-hop amount/CLTV values were intentionally discarded, suggesting a latent routing-state gap.New fields are marked `required` in serialization, which can affect backward compatibility and persistence recovery.Trampoline forwarding involves fee and timelock checks; missing expected values could theoretically lead to incorrect forwarding decisions.
e14a28ddby Carla Kirk-Cohen+17−22 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use outer onion values in PendingHTLCInfo for trampoline

This commit fixes a bug in how trampoline routing nodes validate incoming Lightning payments. Previously, the node used values from the inner (trampoline) onion, which included the fee budget, to check whether it received the correct amoun…

Use of incorrect payment amount source for validation (inner vs outer onion)Potential fee-budget underpayment by upstream peerFix changes which amount value is stored in pending HTLC state for trampoline forwarding
c58d1d83by Carla Kirk-Cohen+5−51 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: store incoming mpp data in PendingHTLCRouting

This commit is a small code change that stores extra multi-path payment (MPP) information when a trampoline forward is received. It appears to be a preparatory step for validating incoming payment parts before forwarding them onward. There…

Adds MPP data plumbing for trampoline forwardsNo validation logic is visible in this commitNo mention of security, CVE, bug, or vulnerability in commit message
a1260ed1by Carla Kirk-Cohen+12−52 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use total_msat to calculate the amount for our next trampoline

This commit fixes a bug in how the Lightning Dev Kit calculates the amount to forward when acting as a trampoline node for blinded multi-path payments. Previously, the code used the amount from a single incoming payment packet, which could…

Logic error in payment amount validation for blinded trampoline forwardsMulti-path payment (MPP) aggregation not accounted for in forward amount calculationPotential incorrect HTLC rejection or under-forwarding for trampoline payments
3e162db9by Carla Kirk-Cohen+5−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: remove incoming trampoline secret from HTLCSource

This commit removes a redundant 32-byte shared secret field from an internal data structure used when forwarding trampoline payments in the Lightning Dev Kit. The developers realized the secret was already stored inside each previous hop's…

Removes redundant secret field from in-memory/persisted stateChanges TLV serialization layout for HTLCSource::TrampolineForwardBreaking persistence change acknowledged by commit author
816b866dby Carla Kirk-Cohen+10−221 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/refactor: use amount_msat and counterparty_skimmed_fee_msat vars

This is a small code cleanup that replaces two computed expressions with variables already available in scope. It does not change behavior, fix a bug, or address any security issue.

53ce5590by Carla Kirk-Cohen+2−71 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/test: add multi-purpose trampoline test helper

This commit is a test-only refactor. It moves a helper function that builds synthetic blinded payment paths for trampoline routing tests into a shared test utilities file and generalizes it so it can be reused for both forwarding and singl…

07925700by Carla Kirk-Cohen+61−503 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

blinded_path: add constructor for trampoline blinded path

This commit adds a new internal test-only helper function to create a special kind of private payment path (called a 'trampoline blinded path') in the Lightning Dev Kit library. It does not change any existing behavior, fix a bug, or expos…

95ae963fby Carla Kirk-Cohen+23−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 14 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

blinded_path/refactor: make construction generic over forwarding type

This commit is a routine internal code cleanup in the rust-lightning library. It makes the construction of blinded payment paths generic so the same helper functions can be used for both regular Lightning paths and newer 'trampoline' paths…

82bec57aby Carla Kirk-Cohen+83−211 file
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/refactor: pass minimum delta into check_incoming_htlc_cltv

This commit is a code refactor that prepares for future 'trampoline' Lightning payments. It changes an internal CLTV (timelock) check so the caller can specify a minimum time delta, instead of always using a hardcoded minimum. The commit i…

CLTV/timelock validation logic touchedRefactor enables future zero-delta path for trampoline paymentsNo change to current enforcement value at existing call sites
80c35072by Carla Kirk-Cohen+9−52 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 →