CommitWatch RSS
TH
← Developer activityStrong match

Thomas HUET

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

@thomash-acinq on GitHub ↗
16 commits1 monitored projects1 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 Thomas HUETA visual map of monitored and externally discovered repositories.THdeveloper16Eclair
Monitored evidence

CommitWatch projects

EclairACINQ16 commits1 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 15 AI analysisMessage 78 · Adequate
AQ ACINQEclair BitcoinLightning Network

More tests for accountability (#3240)

This commit only adds new test cases for an existing feature called 'accountability' in the Eclair Lightning node software. It does not change any production code, so it cannot introduce a new security vulnerability or directly fix one. Th…

No production code changesTest-only addition of serialization/deserialization vectorsReferences existing 'accountability' / 'UpgradeAccountability' feature already present in codebase
0214a1e7by Thomas HUET+25−44 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 58 · Thin
AQ ACINQEclair BitcoinLightning Network

Accountable HTLCs (#3217)

This commit replaces an older 'endorsement' anti-jamming signal with a new 'accountable' signal for Lightning HTLCs, following a draft specification update. It changes how invoices, payment onions, and channel messages carry and propagate …

Protocol-level anti-jamming signal redesign (endorsement -> accountable)New TLVs added to HTLC, payment onion, route blinding, and invoice codecsReputation algorithm simplified to binary accountability and outgoing-only scoring
e3fd1867by Thomas HUET+827−91468 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Identify failing node by its index (#3224)

This commit fixes a routing bug in the Eclair Lightning node. When a payment failed somewhere along the path, the software used to identify the failing node only by its public key. That caused confusion when the same node appeared more tha…

Failure attribution ambiguity when a node appears multiple times in a routePotential incorrect hop/channel blacklisting due to node-id-only failure identificationRouting/liquidity learning could be poisoned by misattributed failures
856e236fby Thomas HUET+89−9116 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 54 AI analysisMessage 53 · Thin
AQ ACINQEclair BitcoinLightning Network

Check that relay fees are nonnegative (#3209)

This commit adds a server-side check to make sure users cannot set negative Lightning Network routing fees through the API. Previously, the API accepted negative values for base and proportional relay fees, which could cause a node to pay …

Input validation added for API fee parametersNegative fee values previously accepted by updateRelayFee endpointPotential for fee policy manipulation leading to unintended payment forwarding losses
ff1ce1feby Thomas HUET+6−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 73 · Adequate
AQ ACINQEclair BitcoinLightning Network

Split MPP by maximizing expected delivered amount (#2792)

This commit changes how the Eclair Lightning node splits a single large payment across multiple routes. It adds a new optional strategy that tries to maximize the expected amount that actually gets delivered, and refactors the existing ran…

Refactors payment-route splitting logic, which affects how funds are allocated across HTLCsChanges capacity-bounding logic in `maxEdgeAmount` (previously `maxHtlcAmount`)Adjusts `updateUsedCapacity` to account for blinded final-hop fees and dummy channel IDs
51a144c8by Thomas HUET+276−12816 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 52 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Reject offers with some fields present but empty (#3175)

This commit tightens validation of Bitcoin Lightning 'Bolt 12' offers and invoices. Previously, an offer or invoice could include certain list fields (such as payment paths or supported chains) that were technically present but contained z…

Input validation hardening for TLV parsingRejection of malformed Bolt 12 offers/invoices that cannot be paidPrevention of empty-but-present routing/path fields that could cause downstream logic errors
abe2cc9cby Thomas HUET+29−76 files
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Remove `PaymentWeightRatios` from the routing config (#3171)

This commit removes an older, less effective way of choosing Lightning payment routes (called PaymentWeightRatios) and switches the code to use a newer route-scoring system based on estimated success probability. It is a routine cleanup/re…

No security-relevant code change identifiedRemoval of deprecated routing heuristic configuration optionTest-only and configuration-only refactor
fa1b0eefby Thomas HUET+86−27912 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 73 · Adequate
AQ ACINQEclair BitcoinLightning Network

Always count local CLTV delta in route finding (#3174)

This change fixes how Eclair counts time-lock delays when finding payment routes through the Lightning network. Previously, when calculating a route starting from the user's own node, the software ignored the delay on the first local chann…

Route-finding cost accounting corrected for local CLTV deltaSpecial-case bypass removed that zeroed first-hop time-lock costRisk-cost formula now uses actual edge CLTV for local channel
9f00ebf9by Thomas HUET+11−132 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 91 · Strong
AQ ACINQEclair BitcoinLightning Network

Increase timeout for flaky onion message tests (#3167)

This commit only changes test configuration and test code. It increases the timeout used in automated tests for onion message handling from milliseconds to seconds, and adds a way for one specific test to keep using a very short timeout. T…

e3513205by Thomas HUET+7−52 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 63 · Adequate
AQ ACINQEclair BitcoinLightning Network

Fix flaky test in `OfferPaymentSpec` (#3165)

This commit only adds extra checks to a test file to make an existing integration test more reliable. It does not change production code, user-facing behavior, or any security mechanism. There is no security issue here.

c13d530fby Thomas HUET+4−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 11 AI analysisMessage 98 · Strong
AQ ACINQEclair BitcoinLightning Network

Fix flaky `ReputationRecorder` test (#3166)

This commit fixes a flaky automated test and makes a tiny production-code ordering change. The main code now subscribes to 'HTLC settled' events before 'HTLC added' events, so a very brief race during startup cannot leave a payment stuck. …

Race-condition mitigation in event subscription orderingTest-only refactor to bypass EventStreamNo input validation, cryptographic, or authorization changes
d3ac75dfby Thomas HUET+24−242 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 43 · Thin
AQ ACINQEclair BitcoinLightning Network

Fix flaky `OfferPaymentSpec` (#3164)

This commit fixes a flaky test, not a security issue. The test simulates three Lightning nodes (Alice, Bob, Carol) and previously did not give all nodes complete knowledge of each other's funding transactions. The change makes the test set…

f32e0b68by Thomas HUET+3−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Use balance estimates from past payments in path-finding (#2308)

This commit improves Eclair's Lightning payment routing by optionally using past payment successes and failures to estimate how much money each channel can forward, instead of assuming balances are random. It is a feature enhancement, not …

Removal of a runtime log.error guard in BalanceEstimate.canSend that previously flagged out-of-range probability estimatesNew heuristic uses historical payment metadata to influence route selection, which could be manipulated if an attacker can induce many failed/successful probesNo bounds check is visible in the diff for the probability returned by balance.canSend; the removed guard was the only explicit one
d4dfb864by Thomas HUET+295−24110 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Add `GossipTimestampFilter` buffer during gossip queries to fix flaky tests (#3152)

This commit tweaks how Eclair nodes request network routing gossip from peers. It subtracts one minute from the starting timestamp filter so that very recent routing announcements that haven't yet reached the peer are still forwarded. The …

Routing/gossip synchronization logic changedTimestamp filter boundary adjusted to include older recent messagesCommit message frames change as test reliability fix, not security vulnerability
50f16cbdby Thomas HUET+3−21 file
No security note in commit
Open full analysis →Source commit ↗
Low 40 AI analysisMessage 78 · Adequate
AQ ACINQEclair BitcoinLightning Network

Offers with currency must set amount. (#3140)

This commit adds a missing validation rule for a type of Bitcoin Lightning payment request called a BOLT12 offer. Previously, Eclair would accept offers that named a fiat currency (like USD) but did not include an amount. That combination …

Missing input validation on structured protocol messageSpec non-compliance in BOLT12 offer parsingPotential for ambiguous payment request interpretation
b651e5b9by Thomas HUET+6−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 41 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Use actual CLTV delta for reputation (#3134)

This commit changes how Eclair estimates the trustworthiness (reputation) of other Lightning nodes when deciding whether to forward payments. Previously, pending payments were penalized using a fixed multiplier that did not reflect how lon…

Anti-jamming / reputation-system hardeningRemoval of fixed pending-multiplier in favor of CLTV-based expected settlement timeConfiguration change: half-life 15 days -> 30 days, max-relay-duration 12 seconds -> 5 minutes
5703cd45by Thomas HUET+161−14111 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 →