CommitWatch RSS
ER
← Developer activityStrong match

Elias Rohrer

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

153 commits1 monitored projects15 candidates6 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 Elias RohrerA visual map of monitored and externally discovered repositories.ERdeveloper153rust-lightning
Monitored evidence

CommitWatch projects

rust-lightningLightning Dev Kit153 commits15 candidates6 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.

Moderate 60 AI analysisMessage 88 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Allow filtered block rescans at the current tip

This commit fixes a bug where replaying the current blockchain block through a normal listener callback could crash two core Lightning components (ChannelManager and OutputSweeper) with a panic. The fix recognizes a same-block replay as a …

panic in chain listener callbacksame-block replay/rescan mishandlingassertion failure on valid chain input
686f9860by Elias Rohrer+118−123 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

offers: Allow disabling invoice response MPP

This commit adds a new option for Lightning invoice creators to explicitly tell payers not to use multi-path payments (MPP) when paying an invoice. It does not change any enforcement rules; it only changes what feature bits are advertised …

New API surface for feature advertisement controlExplicit documentation that the method does not enforce single-HTLC receipt, shifting enforcement responsibility to callersNo removal or weakening of existing validation logic
00aabf81by Elias Rohrer+9−01 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

Fix Joost's Forgejo username

This commit simply corrects a username in an automated reviewer assignment workflow. It changes one reviewer handle from 'joost_spiral' to 'joostjager' so the right person stays in the rotation. There is no security issue here.

ade3b6bdby Elias Rohrer+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Use Forgejo OIDC for review requests

This commit changes the project's automated reviewer-assignment workflow to stop using a long-lived secret token and instead request a short-lived authentication token from the Forgejo CI service. This is a security-hardening improvement: …

Removal of long-lived repository secret from CI workflowAdoption of OIDC-based short-lived token for API authorizationWorkflow runs in pull_request_target context with no code checkout
57c84bcaby Elias Rohrer+17−81 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 58 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reduce LSPS5 reset cooldown

This commit shortens a rate-limiting cooldown in the LSPS5 webhook notification system from 10 seconds down to 100 milliseconds, and fixes a time-calculation bug that previously dropped sub-second precision. The change is described by the …

Rate-limit/amplification throttle weakened (10s -> 100ms)Time/duration arithmetic precision fixWebhook notification cooldown reset logic changed
773c08acby Elias Rohrer+18−113 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 52 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Truncate logged peer message strings

This commit fixes a minor denial-of-service issue where a malicious peer could send very long text strings inside Lightning network messages (errors, warnings, transaction aborts). Those strings were written to log files without any length…

Counterparty-controlled strings logged without length limitsInconsistent sanitization across logging sites for untrusted peer dataPotential log-file bloat / disk-filling from malicious peer messages
e2f611e9by Elias Rohrer+97−123 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 76 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reject pre-epoch `LSPSDateTime` at parse time

This commit fixes a remote denial-of-service bug in rust-lightning's LSPS (Lightning Service Provider Specification) code. An attacker could send a specially crafted date string from before 1970 (like "1900-01-01T00:00:00Z") in certain pee…

Remote-triggerable panic (DoS) via peer-controlled inputInteger conversion panic: i64 negative timestamp coerced to u64 with .expect()Input validation bypass: serde transparent deserialization skipped custom parser
837763a6by Elias Rohrer+29−31 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Return optional recovered BOLT11 payee keys

This commit changes how a Bitcoin Lightning invoice library exposes the payee's public key. Previously, a function called recover_payee_pub_key always returned a public key, even when mathematically recovering it from the invoice signature…

API semantics changed from non-optional to optional return for a cryptographic recovery operationPrevious behavior could silently return an explicitly included key instead of a recovered keyNew behavior surfaces recovery failure rather than masking it
851d03f3by Elias Rohrer+23−131 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Use BOLT11 invoice payee keys for payment params

This commit fixes a bug in how Lightning payment parameters are built from BOLT11 invoices. Previously, the code always tried to recover the payee's public key from the invoice signature, even when the invoice already explicitly included t…

BOLT11 invoice payee public key derivation changed from signature recovery to explicit key preferencePaymentParameters::from_bolt11_invoice now uses get_payee_pub_key instead of recover_payee_pub_keyTest cases demonstrate handling of invoices with valid included payee key but invalid recovery ID
06393ebaby Elias Rohrer+105−93 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add pending changelog entry for PR 4656

This commit only adds a pending changelog entry describing an API change in a previous pull request. It contains no code changes, no bug fixes, and no security-related content.

8270c7cdby Elias Rohrer+2−01 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 56 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid re-locking same UTXO future

This commit fixes a potential deadlock in how Lightning Dev Kit handles repeated lookups of the same short channel ID. When a custom UTXO lookup service returns the same in-flight future object for repeated requests, and a replacement chan…

Potential self-deadlock in async UTXO lookup pathRe-entrant mutex lock on same Arc<Mutex<UtxoMessages>>Custom UtxoLookup returning cached future could trigger lock ordering violation
dce31b72by Elias Rohrer+105−281 file
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 58 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Report LSPS5 fallback persistence

This is a tiny one-line fix in a Lightning Service Provider feature (LSPS5). Previously, when the code had to force-save peer state for a client that was about to be removed, it saved the data but forgot to report that it had done so. The …

Incorrect boolean return value for persistence statusState-management bookkeeping fix in prunable client lifecycleNo cryptographic, signature, or channel-funding logic changed
d7571912by Elias Rohrer+1−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 58 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Report LSPS2 fallback persistence

This one-line change fixes a bookkeeping bug in the LSPS2 (Lightning Service Provider Specification 2) service code. Previously, when the code had to force-save a peer's state before removing that peer, it performed the save but forgot to …

State-tracking inconsistency between actual persistence and reported persistence flagPotential for downstream logic to act on stale/incorrect persistence statusFix located in LSPS2 service provider state-pruning code path
a1cda953by Elias Rohrer+1−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 58 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Document LiquidityManager persist result

This commit only fixes two typos in documentation comments ('sevice' to 'service') and slightly rewords the description of what the return value means. No code behavior changes, no security relevance.

12815f38by Elias Rohrer+2−21 file
No security note in commit
Open full analysis →Source commit ↗
High 74 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Verify Electrum transaction responses before use

This commit fixes a security hole in how a Bitcoin Lightning wallet talks to Electrum servers. Previously, the wallet asked a server for a specific transaction by its ID, but it did not check that the returned transaction actually matched …

Commit title and message explicitly describe a security-relevant verification failureFix adds txid recomputation and equality check against requested txidFix is applied at multiple call sites where `transaction_get` results are consumed
1d131506by Elias Rohrer+30−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Check Esplora Merkle leaf risk by base size

This commit fixes a guard condition in LDK's Esplora transaction-sync code. The code tries to skip 64-byte transactions because such transactions can be abused in a known Bitcoin Merkle-tree weakness. The bug was that it measured total tra…

Bypass of explicit security guardWitness vs non-witness size confusionMerkle leaf weakness protection
bc05d9d9by Elias Rohrer+2−21 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Check Electrum Merkle leaf risk by base size

This commit fixes a bug in how rust-lightning's Electrum transaction sync checks for a known Bitcoin Merkle-tree weakness. The old code rejected transactions whose total byte size was exactly 64, but an attacker could pad a transaction wit…

Fixes incorrect size check that could be bypassed with witness paddingAddresses known Bitcoin Merkle leaf-node weakness (bitslog 2018)Changes total_size to base_size for txid-relevant serialization
4636d6c9by Elias Rohrer+31−152 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 50 AI analysisMessage 48 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid leaking stale filesystem store temp files

This change fixes a cleanup problem in the Lightning Dev Kit's file-saving code. When two saves for the same file happen at nearly the same time, an earlier, out-of-date save could leave behind a temporary file containing plain data. The p…

Temporary file leak of historical plaintext dataBest-effort cleanup added on write failure and stale write pathsAsync write ordering can produce stale temp files
1a875a7aby Elias Rohrer+91−412 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Intercept onion messages for unknown SCID hops

This commit adds a new optional feature to LDK's onion message forwarding. Previously, if an onion message's next hop was identified by a short channel ID (SCID) that the node didn't know, the message was silently dropped. Now, if a user e…

New interception path for onion messages with unresolvable SCID next hopsEvent serialization change with backward-incompatible ShortChannelId variantBehavior gated by explicit opt-in flag intercept_for_unknown_scids
2e7cc44cby Elias Rohrer+364−336 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 56 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

f - Prevent stale fs-store writes

This commit is a follow-up ('f') that strengthens a regression test for a filesystem persistence bug in rust-lightning. The bug being tested is a race condition where an older, delayed write could overwrite a newer write after a lock was c…

Race condition in filesystem persistence layerStale write could overwrite newer writeRegression test for data consistency bug
2c09a261by Elias Rohrer+65−201 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 →