CommitWatch RSS
RR
← Developer activityStrong match

Rusty Russell

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

959 commits2 monitored projects75 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 Rusty RussellA visual map of monitored and externally discovered repositories.RRdeveloper958Core Lightning1Eclair
Monitored evidence

CommitWatch projects

Core LightningElements Project958 commits75 candidates1 high riskEclairACINQ1 commits0 candidates0 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.

Informational 15 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

pytest: add tests for what we want askrene to do.

This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capa…

518620aeby Rusty Russell+67−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist hash_str helper into its own header.

This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.

581bbb1fby Rusty Russell+16−176 files
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

xpay: actually tell askrene when a payment succeeded.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas abou…

Missing success feedback to routing layer can degrade payment reliabilityStale negative impressions may bias future path selection toward worse or failing routesNo direct funds-loss primitive is introduced or fixed
a66fabd4by Rusty Russell+40−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 58 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: correctly order constraints.

This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impression…

Routing decision bug caused by incorrect ordering of time-relative channel statePotential payment failure or acceptance of an over-capacity routeRegression test added demonstrating incorrect route acceptance before fix
4b6fe4a1by Rusty Russell+211−1182 files
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit invoices to 10 minutes for recurring offers in other currencies.

This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the…

Fixes stale exchange-rate exposure for currency-denominated recurring invoicesAdds configurable expiry cap for recurring currency invoicesDistinguishes user-cancellation (0s expiry) from natural expiry to avoid misleading errors
446312cfby Rusty Russell+134−148 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit expiry to offer limit, or 10 minutes with currency conversion.

This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and …

BOLT12 invoice expiry now bounded by offer absolute expiryCurrency-converted invoices use short expiry to limit exchange-rate exposureNew regression test added for expiry behavior
a6cf4915by Rusty Russell+55−22 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: don't bother with checking recurrence timing.

This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change i…

Removal of local input-validation checks for recurring invoice requestsReliance on remote-party enforcement for recurrence period limits and pay windowsTest expectations changed from local rejection to remote failure messages
3e49d908by Rusty Russell+2−682 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: don't do previous invoice checking in createinvoicerequest.

This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence wa…

Removal of local payment-state validation for recurring invoice requestsParameter rename from recurrence_label to label in internal RPC callsTest expectations changed from local 'previous invoice has not been paid' errors to remote failure messages
4348d8acby Rusty Russell+5−1224 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: handle weird labels in recurrence_label parameter.

This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding…

JSON injection / improper escaping of user-controlled input passed between RPC componentsPotential mismatch between label parsing and label serialization leading to functional failures or unexpected behaviorFix is narrowly scoped to a single plugin and parameter
d7f87f2dby Rusty Russell+37−102 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: give clearer error codes.

This commit improves the error messages returned by Core Lightning's routing plugin (askrene) when a payment cannot be routed. It adds two new, more specific error codes: one for 'not enough local funds' and one for 'destination cannot rec…

New error codes improve API observability but do not change access control or trust boundariesNo buffer overflow, use-after-free, or input-validation changes observedNo cryptographic or secret-handling changes observed
b0a7a6a9by Rusty Russell+118−278 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: implement str_to_u64, make json_to_u64 use it.

This commit fixes a bug in how Core Lightning parsed unsigned 64-bit integers from JSON. The old code used a standard C library function (strtoull) that could read beyond the intended token boundary. The commit author notes this is not cur…

Out-of-bounds read risk in JSON numeric parsingUse of unbounded C library string-to-number conversion on non-null-terminated inputDefensive hardening of integer parsing helpers
529ae2b7by Rusty Russell+31−233 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 80 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

libplugins: JSON ids are always strings.

This commit cleans up how Core Lightning plugins handle JSON-RPC request IDs. Previously, IDs could be passed around as raw JSON fragments (with quotes included), which caused mismatches when method names contained unusual characters. The …

JSON-RPC id handling changed from raw JSON literal to stringMethod names with special characters are now escaped or replaced to prevent reply mismatchIncoming JSON-RPC ids are validated to be strings
395f99d7by Rusty Russell+72−618 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: add APIs for "impressions" which are *relative* constraints.

This commit adds a new 'impressions' feature to the askrene routing plugin in Core Lightning. It is a normal feature addition that lets the node remember how much capacity was used by successful payments, separate from existing 'constraint…

95769649by Rusty Russell+1002−32918 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist amount+currency parsing into common code.

This commit moves existing code that parses payment amounts (Bitcoin millisatoshis, 'any' amount, or fiat currency amounts) from one plugin file into a shared library so it can be reused by a future feature. It is a code refactoring with n…

Refactoring of amount-parsing code into a shared helperAddition of explicit u64 overflow guards (mul_overflows_u64, add_overflows_u64) in the new common codeNo change to wire protocol or RPC interface semantics
e0f86c17by Rusty Russell+112−723 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: internal cleanups since all non-command JSON IDs are strings.

This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. …

No security-relevant keywords in commit title or messageNo CVE, advisory, or bug reference presentChanges are refactor/cleanup in nature
a70ae963by Rusty Russell+25−378 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.

This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches th…

Database downgrade path could leave incompatible records in older schemaOffline tool only; no remote or on-chain triggerFix prevents potential node startup failure after version rollback
4d926285by Rusty Russell+43−111 file
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

multiwithdraw: use unique ids on requests.

This patch fixes a bug in the multiwithdraw plugin where it reused the JSON-RPC command ID as its own internal request identifier. Because command IDs can be arbitrary strings (for example, a double-quote character becomes the number 34), …

Use of attacker-influenced pointer/value as internal identifier (CWE-20 / CWE-99 style logic error)Potential ID collision / request confusion in multiwithdraw pluginRemoval of leftover assertion in related plugin
e13df371by Rusty Russell+4−52 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

autogenerate-rpc-examples.py: disable entropy for generation.

This commit changes Core Lightning's internal test tooling so that automatically generated RPC documentation examples use predictable randomness and a fixed clock time. It only affects test/example generation code, not the production Light…

81443075by Rusty Russell+14−12 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

autogenerate-rpc-examples.py: remove example mangling.

This commit is a cleanup of a test script that generates example outputs for documentation. It removes a large amount of code that was manually replacing real test values with fake placeholder values in the generated examples. The script n…

145edea5by Rusty Russell+13−8841 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 60 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

autogenerate-rpc-examples.py: remove unused vars

This commit is a routine cleanup of a test script. It removes variables that were assigned but never used, and deletes a couple of unused example data structures. There is no change to the actual Core Lightning node software, no change to …

68507fe2by Rusty Russell+61−901 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 →