CommitWatch RSS
BT
← Developer activityVerified account

Bastien Teinturier

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

@t-bast on GitHub ↗
114 commits1 monitored projects23 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 Bastien TeinturierA visual map of monitored and externally discovered repositories.BTdeveloper114Eclair
Monitored evidence

CommitWatch projects

EclairACINQ114 commits23 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.

Moderate 64 AI analysisMessage 98 · Strong
AQ ACINQEclair BitcoinLightning Network

Correctly handle unknown flags in `channel_update` (#3341)

This commit fixes a bug in how Eclair handled unknown flag bits in Lightning 'channel_update' messages. Previously, the software silently cleared any flag bits it did not recognize when re-encoding a message before forwarding it. Because t…

Signature invalidation through lossy codec round-tripUnknown protocol flag bits silently zeroed before forwardingFuture protocol compatibility / forward-compatibility fix
54912ef2by Bastien Teinturier+118−1710 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 36 · Opaque
AQ ACINQEclair BitcoinLightning Network

Back to dev (#3339)

This commit is a routine post-release housekeeping change. It bumps the project version from 0.14.1 to 0.15.0-SNAPSHOT, re-enables a Maven trusted-checksum feature used for build verification, adds a placeholder release-notes file, and inc…

ee7d9f6dby Bastien Teinturier+74−68 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 53 · Thin
AQ ACINQEclair BitcoinLightning Network

Eclair v0.14.1 release (#3338)

This commit is the packaging of Eclair v0.14.1. It mostly changes version numbers and release notes, plus two operational tweaks: it turns off Maven's trusted-checksum post-processor and removes a startup guard that previously refused to r…

Release notes explicitly warn that custom Bolt12 offer-handler plugins setting feeOverride_opt put the node 'at risk' (#3332).Startup safety guard removed: Boot.scala no longer requires eclair.allow-unsafe-startup=true to run.Maven trusted-checksum post-processor disabled (Daether.artifactResolver.postProcessor.trustedChecksums=false).
d769db07by Bastien Teinturier+85−869 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Disable Bolt12 recipient path fee discount (#3332)

This commit removes a fee-discount feature for a new kind of Lightning payment (Bolt12 offers). The old feature let the seller pay routing fees for the hidden 'blinded' path they chose for privacy. But when a payer split a payment into man…

Economic/fee griefing via MPP splitting against Bolt12 blinded-path fee discountRecipient-chosen privacy path fees incorrectly applied per payment part instead of per paymentFeature disablement pending protocol redesign
3397b1a6by Bastien Teinturier+16−123 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 78 · Adequate
AQ ACINQEclair BitcoinLightning Network

Prevent `channel_id` collisions (#3337)

This commit hardens the Eclair Lightning node against two related problems when opening payment channels: it prevents the same channel ID from being reused by two different channels at the same time, and it aborts channel creation if the v…

State overwrite / collision prevention for channel identifiersAbort-on-first-DB-write-failure to avoid inconsistent persistenceGlobal concurrent map guarding temporary and final channel_id usage
45ea9fbfby Bastien Teinturier+468−19419 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 52 AI analysisMessage 93 · Strong
AQ ACINQEclair BitcoinLightning Network

Apply RBF limits to remote closing transactions (#3331)

This commit adds rate limits and maximum attempt caps for Replace-By-Fee (RBF) closing transactions in the Eclair Lightning node. Previously, a peer could repeatedly propose new closing transactions without strict limits, which could waste…

Resource exhaustion via unbounded RBF attempts is now cappedRemote peer closing transaction rate-limiting addedLocal closing transaction count bounded by BOLT recommendation
687485fcby Bastien Teinturier+94−103 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Reject `start_batch` with size <= 1 (#3333)

This commit tightens validation of a Lightning network peer message called start_batch. Previously, the software only rejected batch sizes larger than 20. Now it also rejects batch sizes of 0 or 1, which the protocol specification says mus…

Protocol compliance fix for BOLT 2 start_batch validationAdds lower-bound validation that was previously missingPrevents acceptance of degenerate batch sizes (0, 1)
e4e1a19dby Bastien Teinturier+25−32 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Don't store duplicate settlement messages (#3336)

This patch fixes a bug in Eclair's Lightning payment channel code. If a buggy peer (or internal message queue bug) sent the same HTLC settlement message twice, Eclair would store the duplicate in its list of pending remote changes. Later, …

Avoids unilateral channel force-close due to duplicate settlement messagesPrevents duplicate remote proposal accumulation in commitment changesMaintains relay of first valid settlement to downstream HTLC origin
3eebbe96by Bastien Teinturier+51−02 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Accept Bolt12 invoices with reply path (#3325)

This commit loosens Eclair's validation of BOLT12 invoice onion messages so that invoices may now include a reply path. Previously, Eclair rejected invoices that carried a reply path, which caused compatibility problems with LDK nodes. The…

Loosened TLV validation for BOLT12 Invoice messages now permits ReplyPath presenceAdded explicit rejection of unknown records (even odd ones) in final payloadAdded explicit requirement for ReplyPath when an InvoiceRequest is present
79519244by Bastien Teinturier+14−62 files
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Ignore repeated invalid `tx_signatures` (#3328)

This update changes how the Eclair Lightning node handles repeated bad 'tx_signatures' messages from a peer during dual-funded channel opens and splices. Previously, every bad signature was processed and logged, which could waste CPU and d…

Rate-limiting of invalid peer messages (tx_signatures) to prevent repeated CPU/disk consumptionRemoval of unnecessary DB writes on shutdown receipt, reducing disk-wear and potential DoS surfaceNo channel force-close on invalid signatures; node remains open and waits for on-chain confirmation
823341e6by Bastien Teinturier+74−402 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
AQ ACINQEclair BitcoinLightning Network

Update Bitcoin Core to v31.1 (#3327)

This commit simply updates Eclair's required Bitcoin Core version from 30.x to 31.1. It changes download URLs, SHA-256 checksums, documentation, a runtime version check, and a test path. There is no security vulnerability in this change it…

cbafa93aby Bastien Teinturier+13−105 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 93 · Strong
AQ ACINQEclair BitcoinLightning Network

Reject `temporary_channel_id` duplicates early (#3324)

This change tightens how Eclair handles incoming Lightning channel requests. It now rejects a new channel's temporary ID if it collides with an existing final channel ID for the same peer, and it re-checks for collisions after rate-limitin…

duplicate identifier collision now rejected earliernon-atomic interceptor step followed by re-checkfinal channel ID included in collision detection
9b0bcec4by Bastien Teinturier+79−572 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 52 AI analysisMessage 93 · Strong
AQ ACINQEclair BitcoinLightning Network

Reject incoming HTLCs with a high `cltv_expiry` (#3323)

This change tightens a safety limit on the Bitcoin Lightning Network node Eclair. Previously, Eclair already refused to send outgoing payments whose refund deadline (the 'cltv_expiry') was more than about two weeks in the future, because t…

Adds upper-bound validation for cltv_expiry on incoming HTLCsPrevents long fund lock-up in case of peer force-closeMitigates slow jamming by capping maximum expiry delta
7fb94601by Bastien Teinturier+52−94 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Refactor attribution data (#3320)

This commit is a code refactor of how Eclair handles 'attribution data'—extra encrypted timing and accountability information attached to Lightning payment success and failure messages. It restructures the code to support future trampoline…

Refactor of cryptographic attribution-data creation/verificationNew shared-secret extraction path parses trampoline onion and path-key/blinded-path stateAttribution data now explicitly suppressed for blinded-route intermediate nodes
4b9ba010by Bastien Teinturier+228−1096 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 55 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Send `splice_locked` if necessary while reconnecting (#3318)

This commit fixes a bug in Eclair, a Bitcoin Lightning Network node implementation. During reconnection after a splice (a way to resize a payment channel), if a funding transaction became confirmed at a specific moment, the node would fail…

State-machine bug in channel reconnection handshakeMissing protocol message (`splice_locked`) during `SYNCING` stateCan lead to unwanted channel force-close and on-chain settlement
7fb62fc5by Bastien Teinturier+106−402 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 36 · Opaque
AQ ACINQEclair BitcoinLightning Network

Back to dev (#3313)

This commit is a routine post-release housekeeping change. It bumps the software version from 0.14.0 to 0.15.0-SNAPSHOT across build files, creates a placeholder for future release notes, re-enables a Maven trusted-checksum feature used fo…

2dda7946by Bastien Teinturier+74−68 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 53 · Thin
AQ ACINQEclair BitcoinLightning Network

Eclair v0.14.0 release (#3312)

This commit is a routine version-bump release tag for Eclair v0.14.0. It updates Maven project versions from 0.14.0-SNAPSHOT to 0.14.0, removes a temporary 'unsafe startup' guard that was only meant for pre-release builds, renames the rele…

ec8c63b2by Bastien Teinturier+433−3448 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 98 · Strong
AQ ACINQEclair BitcoinLightning Network

Fix Bolt12 path fee hiding (#3311)

This commit fixes a rounding bug in Eclair's handling of Bolt12 (a newer Lightning Network invoice format) blinded-path fees. When a recipient hides their real node behind a private payment path, they can choose to pay those path fees them…

Logic error in fee-bound computation for Bolt12 blinded pathsCould cause denial of service for legitimate incoming paymentsNo direct funds loss or theft path evident from diff
0896d03bby Bastien Teinturier+8−84 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Add support for zero-fee commitment format (#3192)

This commit adds an experimental new Lightning channel type to Eclair called 'zero-fee commitments.' It is a large feature patch implementing a draft BOLT specification (PR 1228), not a fix for a known vulnerability. The change introduces …

Large feature addition (+1618/-276 across 42 files) touching consensus-sensitive transaction construction and signingNew experimental channel type disabled by default; requires explicit opt-in via eclair.confImplements draft BOLT specification (lightning/bolts#1228), not a finalized standard
35403401by Bastien Teinturier+1618−27642 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Change RBF feerate bump rule to match BIP125 (#3298)

This commit fixes how Eclair increases transaction fees when replacing a funding transaction via RBF (Replace-By-Fee). Previously, Eclair only required the new fee rate to be 25/24 (about 4.17%) higher than the old one. Under recent Bitcoi…

RBF fee-bump rule updated to satisfy Bitcoin Core relay policyBOLT 2 spec alignment via minimum additive fee incrementPotential liveness issue: replacement transactions could be rejected by the network
06538adaby Bastien Teinturier+4−21 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 →