CommitWatch RSS
VW
← Developer activityVerified account

Valentine Wallace

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

@valentinewallace on GitHub ↗
137 commits1 monitored projects10 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 Valentine WallaceA visual map of monitored and externally discovered repositories.VWdeveloper137rust-lightning
Monitored evidence

CommitWatch projects

rust-lightningLightning Dev Kit137 commits10 candidates1 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 18 AI analysisMessage 72 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Set max fee in route params for probes

This change sets a maximum routing fee for Lightning payment probes. Previously, probes used a dummy RouteParameters object with no fee limit. Now the fee cap is set to the actual fee of the fixed probe path. This is a minor hardening/clea…

Fee budget now enforced/recorded for probe routesRemoval of justification comment for unbounded probe feeDefensive consistency between probe and normal payment route parameters
47f58f34by Valentine Wallace+1−41 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 55 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fuzz: remove unnecessary route_params clones

This commit removes two unnecessary .clone() calls on route_params inside a fuzz test file. It is a code cleanup change in test-only code and does not affect production behavior, security, or user funds.

cc4312a7by Valentine Wallace+2−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Remove now-redundant PaymentParameters params

This is a routine internal code cleanup in the Lightning Dev Kit's payment-sending logic. It removes a now-unnecessary duplicate argument from a few private functions because the same information is already stored inside the Route object. …

d5d502a9by Valentine Wallace+11−121 file
No security note in commit
Open full analysis →Source commit ↗
Informational 22 AI analysisMessage 58 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Require Route::route_params

This commit makes a piece of routing data called route_params mandatory in the Lightning Dev Kit library. Previously it was optional, and the code would silently invent a dummy value if it was missing. Now it must always be provided, and o…

API hardening: removes silent fallback to dummy RouteParametersBackwards-compatibility break for pre-0.0.117 serialized Route objectsNo new bounds checks, cryptographic operations, or network parsing changes
41f0809aby Valentine Wallace+229−25213 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 40 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Rustfmt send_payment_with_route

This commit is purely a formatting cleanup: it removes a 'skip rustfmt' marker and re-indents a function so the code is easier to read. No behavior, logic, or security properties of the payment-sending code were changed.

e90ab9d2by Valentine Wallace+33−121 file
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix invalid dummy pubkey in send_to_route

This commit fixes a programming bug in rust-lightning's send_to_route function. When a user supplied a payment route with no paths or an empty first path, the code tried to create a fallback 'dummy' public key using 32 bytes of data, but p…

panic due to invalid public-key byte lengthdenial-of-service via malformed route inputunwrap on fallible public-key parsing
54cdd85fby Valentine Wallace+1−11 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 65 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Document that Route::route_params will be required soon

This commit only updates a documentation comment in the source code. It warns developers that a field called route_params on the Route struct will become mandatory in a future release. There are no code changes, no bug fixes, and no securi…

b18ad8b3by Valentine Wallace+2−11 file
No security note in commit
Open full analysis →Source commit ↗
High 70 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix underflow in blinded path amt_to_forward

This commit fixes a subtraction underflow bug in the code that decides how much of a Lightning payment a blinded intermediate node should forward. With extremely high proportional fees and a small incoming payment amount, the code subtract…

Integer underflow in fee/amount calculationDebug-build panic / release-build silent wraparoundPotential relay of under-funded payment in release builds
e560ec17by Valentine Wallace+16−11 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix: reject fake scids with invalid vout

This commit fixes a validation bug in how Lightning Dev Kit checks 'fake' short channel IDs (SCIDs) used for routing tricks like phantom and intercept payments. The old check compared only the lowest byte of the vout field, so an attacker …

Input validation bypass in fake SCID checksType-cast truncation bug (u16 to u8) leading to incorrect equality checkPotential for spurious HTLCIntercepted event generation
6aea1020by Valentine Wallace+20−21 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Set PaymentSent::fee_paid_msat in abandoned case

This commit fixes a small bookkeeping bug in the Lightning Dev Kit. When a user abandoned an in-flight payment but the payment still succeeded later, the reported fee field was incorrectly left blank (None), even though the documentation p…

Incorrect/incomplete API contract between documented behavior and returned event dataPotential for downstream accounting or fee-reporting logic to misbehave if it assumes fee_paid_msat is always Some for modern versionsRegression test added for the fixed behavior
3e9e6e93by Valentine Wallace+40−24 files
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Don't persist inbound committed onions in prod

This commit disables a feature that was temporarily storing extra routing data (onion packets) for every incoming payment in Lightning channels. The developers decided not to keep writing that data in production yet because they may not ne…

Disables persistence of sensitive routing onion data in productionPrevents potential data-retention or state-bloat risk from persisting onions on every manager writeChanges forward-compatibility version constant from a concrete value to None, delaying automatic rejection of old/missing data
b82b6a46by Valentine Wallace+23−223 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 57 AI analysisMessage 88 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix async release before HTLC decode

This commit fixes a race condition in Lightning Dev Kit's async payments feature. When a user wants to receive a payment while offline, their LSP (Lightning Service Provider) holds the payment until they come back online. The bug occurred …

Race condition in async payment release handlingHeld HTLC could be left stuck instead of releasedNew defensive state-clearing path for pre-commitment release messages
2ebc372fby Valentine Wallace+213−03 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 55 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Hold peer lock when pushing to decode_update_adds

This change fixes a timing issue in how the Lightning node hands off payment packets (HTLCs) between two internal components. Previously, an HTLC could be in an in-between state where one part of the code thought it had been forwarded whil…

Race condition in HTLC state handoff between Channel and ChannelManagerAtomicity fix for decode_update_add_htlcs queueing under peer lockPotential inconsistent HTLC state update during monitor update completion
2bd09e4eby Valentine Wallace+12−141 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

Rename to StaticInvoice::held_htlc_available_paths

This commit is a simple rename of a field and method from `message_paths` to `held_htlc_available_paths` in the code that handles a specific type of Lightning invoice (a 'static invoice'). The change was made because two different invoice …

42ca4b79by Valentine Wallace+42−323 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 75 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update RECONSTRUCT_HTLCS_FROM_CHANS_VERSION 5 -> 2

This commit changes a single internal version number constant from 5 to 2. It is a cleanup/refactoring change with no security relevance. The constant tracks which serialization format version of a Lightning node manager can reconstruct pa…

ab0ba659by Valentine Wallace+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Test restart-claim of two MPP holding cell HTLCs

This commit is a new regression test, not a fix. It verifies that a forwarding Lightning node can still claim two parts of a multi-path payment backwards after restarting, even if the node's temporary 'holding cell' state was lost during t…

Regression test for crash/recovery behavior of MPP HTLC backward claimsHolding-cell loss simulation via test-only `test_clear_channel_holding_cell`No changes to cryptographic, network, or state-machine logic
5daf51c0by Valentine Wallace+161−93 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix missing user_channel_id in PaymentForwarded

This commit fixes a bug where a forwarding Lightning node, after restarting mid-payment, could emit a 'PaymentForwarded' event that was missing the identifier (next_user_channel_id) of the next channel the payment went through. The fix ens…

Missing event field after node restart mid-HTLC forwardState reconstruction from channel monitors on reloadRegression test added asserting field presence
0d6dcc91by Valentine Wallace+13−62 files
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 60 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix PaymentForwarded fields on restart claim

This commit fixes a bug in the Lightning Dev Kit where, after a node restarts, it was using the wrong payment channel's details when reconstructing forwarded payments. Specifically, it used the upstream (incoming) channel's information whe…

Incorrect channel metadata used in post-reload claim replayPaymentForwarded event fields could be wrong after restartDownstream closure detection used upstream counterparty lookup
48010cbaby Valentine Wallace+16−233 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Persist outbound channel info in inbound HTLCs

This commit fixes a data-loss bug in the Lightning Dev Kit (LDK) routing/payment-forwarding logic. When LDK forwards a payment through a node and then restarts, it may need to claim the inbound payment (HTLC) even though the outbound side …

Data persistence gap in cross-channel HTLC statePost-restart event reconstruction could be incorrect or incompleteFix is additive and backward-compatible via TLV upgradable enum
b3b59e6dby Valentine Wallace+72−232 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 63 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Trivial: user_channel_id in pending_claims_to_replay

This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It adds a placeholder field called user_channel_id to a list of pending payment claims that get replayed when the node starts up. The commit explicitly says …

70ae54fbby Valentine Wallace+5−31 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 →