Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 18 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
47ab467b · Nov 20, 2025 · 1 fileInformational 15db: don't actually create an explicit transaction for read commands.
Since we are the only writer, we don't need one.
Name (time in s) Min Max Mean StdDev Median
sqlite: test_spam_listcommands (before) 2.1193 2.4524 2.2343 0.1341 2.2229
sqlite: test_spam_listcommands (after) 2.0140 2.2349 2.1001 0.0893 2.0644
Postgres: test_spam_listcommands (before) 6.5572 6.8440 6.7067 0.1032 6.6967
Postgres: test_spam_listcommands (after) 4.4237 5.0024 4.6495 0.2278 4.6717
A nice 31% speedup!
Changelog-Changed: Postgres: significant speedup on read-only operations (e.g. 30% on empty SELECTs)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a performance optimization, not a security fix. The change removes an unnecessary explicit transaction wrapper around read-only database queries because the software is already the only writer to the database. The commit message and diff show only speed improvements and no security relevance.
576f48cb · Nov 20, 2025 · 4 filesInformational 20lightningd: log when we have to defer hook registration.
If livelock ever *does* become an issue, we will see it in the logs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change only adds log messages when Core Lightning has to delay updating a plugin hook because the hook is currently in use. It does not fix or change any behavior; it is purely diagnostic observability to help detect a potential future 'livelock' problem. There is no security vulnerability being patched here.
8707b731 · Nov 20, 2025 · 4 filesLow 27lightningd: handle large numbers of command outputs gracefully.
Profiling shows us spending all our time in tal_arr_remove when dealing
with a giant number of output streams. This applies both for RPC output
and plugin output.
Use linked list instead.
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 239 seconds **WAS 518**
Worst latency: 56.9 seconds **WAS 353**
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change is a performance fix, not a direct security patch. It swaps a slow array for a linked list when handling large numbers of output streams for RPC responses and plugin messages. The old array approach caused severe slowdowns—up to hundreds of seconds of delay in extreme cases—which could be abused to make the node sluggish or unresponsive. The fix removes that bottleneck, making large-output operations finish much faster and reducing the chance of a denial-of-service via resource exhaustion.
a877e285 · Nov 20, 2025 · 1 fileInformational 23sql: limit how many chainmoves/channelmoves entries we ask for at once.
This avoids latency spikes when we ask lightningd to give us 2M entries.
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 88 seconds (was 95)
Worst latency: 0.028 seconds **WAS 4.5**
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change is a performance fix, not a security fix. It caps how many records the SQL plugin fetches from lightningd in one go (to 10,000), then loops if more are needed. The commit message explicitly frames it as avoiding latency spikes: worst-case response time dropped from 4.5 seconds to 0.028 seconds. There is no evidence it closes a vulnerability.
b03562b9 · Nov 20, 2025 · 2 filesInformational 15pytest: test for 1M JSONRPC calls which don't need transactions.
To measure the improvement (if any) if we don't actually create empty transactions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new internal test to Core Lightning that exercises one million JSON-RPC plugin calls. It is purely a performance benchmark and test infrastructure change; it does not fix any bug, change production behavior, or introduce any security-relevant code path that an external user could reach.
bfbee055 · Nov 20, 2025 · 5 filesInformational 12db: don't start transactions unless we really need to.
We always start a transaction before processing, but there are cases where
we don't need to. Switch to doing it on-demand.
This doesn't make a big difference for sqlite3, but it can for Postgres because
of the latency: 12% or so. Every bit helps!
30 runs, min-max(mean+/-stddev):
Postgres before: 8.842773-9.769030(9.19531+/-0.21)
Postgres after: 8.007967-8.321856(8.14172+/-0.066)
sqlite3 before: 7.486042-8.371831(8.15544+/-0.19)
sqlite3 after: 7.973411-8.576135(8.3025+/-0.12)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change is a performance optimization, not a security fix. It delays starting a database transaction until the software actually needs to write or read data, rather than starting one automatically at the beginning of every operation. The commit message explicitly frames this as a speed improvement, especially for PostgreSQL, and provides benchmark numbers. There is no indication of a vulnerability being fixed.
213cbba5 · Nov 20, 2025 · 4 filesInformational 19lightningd: allow filtering on custommsg hook too.
Changelog-Added: Plugins: "filters" can be specified on the `custommsg` hook to limit what message types the hook will be called for.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new plugin feature: the ability for plugin authors to register a 'custommsg' hook with a filter list, so the hook is only invoked for specific custom message types. It is a feature enhancement, not a security fix. There is no indication in the commit or supplied references that this resolves a known vulnerability.
f49818c0 · Nov 20, 2025 · 2 filesInformational 15Python: update pyproject.toml so we can run tests/benchmarks.py.
I had forgotten this file existed, but it needs tqdm and pytest-benchmark, so add those dev
requirements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply adds two Python development-only packages (tqdm and pytest-benchmark) to the project's dependency list so an existing benchmark script can run. It does not change any runtime code, network behavior, or security-sensitive logic.
19f0b04a · Nov 20, 2025 · 1 fileInformational 15pyln-testing: don't assume we're doing debug logging for fundwallet and line_graph helpers.
We want to use log-level info for benchmarking, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small test-framework cleanup. Two helper functions in the Python testing utilities used to wait for certain events by scanning daemon debug logs. The change makes them check the actual RPC/API state instead, so the helpers still work when debug logging is disabled (e.g., when running benchmarks at log level 'info'). There is no change to production node code, no security fix, and no vulnerability.
5fd95b3d · Nov 20, 2025 · 1 fileInformational 15tests/benchmark.py: tune nodes a little.
Drop the log level, don't do extra memory checks, don't dump I/O. These are not
realistic for testing non-development nodes.
Here's the comparison, using:
VALGRIND=0 eatmydata uv run pytest -v --benchmark-compare=0001_baseline tests/benchmark.py
Name (time in us) Min Max Mean StdDev Median IQR Outliers OPS Rounds Iterations
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
test_invoice (NOW) 414.9430 (1.0) 39,115.6150 (12.35) 834.7296 (1.0) 2,274.1198 (6.59) 611.7745 (1.0) 162.0230 (1.0) 1;33 1,197.9927 (1.0) 290 1
test_invoice (0001_baselin) 951.9740 (2.29) 3,166.4061 (1.0) 1,366.7944 (1.64) 345.1460 (1.0) 1,328.6110 (2.17) 339.3517 (2.09) 48;15 731.6389 (0.61) 221 1
test_pay (NOW) 36,339.2329 (87.58) 69,477.8530 (21.94) 51,719.9459 (61.96) 8,033.4262 (23.28) 52,639.5601 (86.04) 9,590.1425 (59.19) 6;0 19.3349 (0.02) 17 1
test_pay (0001_baselin) 61,741.5591 (148.80) 108,801.6961 (34.36) 88,284.6752 (105.76) 15,875.4417 (46.00) 96,006.0760 (156.93) 27,500.9771 (169.74) 6;0 11.3270 (0.01) 13 1
test_single_payment (NOW) 46,721.4010 (112.60) 66,027.6250 (20.85) 56,699.4597 (67.93) 5,829.7234 (16.89) 54,659.9385 (89.35) 9,810.9820 (60.55) 6;0 17.6369 (0.01) 14 1
test_single_payment (0001_baselin) 52,215.3670 (125.84) 109,608.0400 (34.62) 74,521.8032 (89.28) 16,175.6833 (46.87) 72,881.5976 (119.13) 17,668.8581 (109.05) 4;1 13.4189 (0.01) 12 1
test_forward_payment (NOW) 108,338.2401 (261.09) 115,570.7800 (36.50) 111,353.7021 (133.40) 2,483.2338 (7.19) 111,981.6790 (183.04) 3,360.6182 (20.74) 3;0 8.9804 (0.01) 11 1
test_forward_payment (0001_baselin) 108,917.7490 (262.49) 168,348.2911 (53.17) 140,321.5990 (168.10) 22,375.2216 (64.83) 143,746.4900 (234.97) 36,363.4459 (224.43) 3;0 7.1265 (0.01) 7 1
test_start (NOW) 299,278.4000 (721.25) 330,340.2610 (104.33) 314,121.8292 (376.32) 11,385.4700 (32.99) 314,603.4899 (514.25) 13,876.4871 (85.65) 2;0 3.1835 (0.00) 5 1
test_start (0001_baselin) 305,928.9111 (737.28) 575,270.0820 (181.68) 419,496.8460 (502.55) 138,248.1937 (400.55) 334,207.0500 (546.29) 254,339.0035 (>1000.0) 2;0 2.3838 (0.00) 5 1
test_long_forward_payment (NOW) 1,088,077.8680 (>1000.0) 1,131,035.0260 (357.20) 1,108,896.7970 (>1000.0) 20,494.1195 (59.38) 1,098,544.8329 (>1000.0) 36,904.4899 (227.77) 3;0 0.9018 (0.00) 5 1
test_long_forward_payment (0001_baselin) 1,282,326.5721 (>1000.0) 1,450,350.8301 (458.04) 1,369,618.5776 (>1000.0) 73,432.8716 (212.76) 1,380,547.3910 (>1000.0) 132,647.3573 (818.69) 2;0 0.7301 (0.00) 5 1
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only changes the project's internal benchmarking test script. It makes benchmark runs faster by reducing logging, disabling memory-leak detection, and turning off I/O recording during tests. There is no change to the actual Core Lightning node software that users run, and nothing in the commit affects security.
ce425b46 · Nov 20, 2025 · 3 filesInformational 15pytest: move test_coinmoves.py::test_generate_coinmoves and test_plugin.py::test_spam_commands to benchmark.py
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply moves two existing performance tests from their original test files into a dedicated benchmark file. It does not change any production code, fix bugs, or alter security behavior. The tests themselves are unchanged in substance; only their location and some benchmark plumbing are adjusted.
7910ee44 · Nov 20, 2025 · 1 fileInformational 15sql: use wait RPC so we don't have to check listchannelmoves/listchainmoves each time.
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 102 seconds **WAS 126**
Worst latency: 4.5 seconds **WAS 5.1**
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a performance optimization for the SQL plugin in Core Lightning. It replaces repeated polling of `listchainmoves` and `listchannelmoves` with a new 'wait' RPC that notifies the plugin only when there are actually new entries. The commit message shows benchmark improvements (faster test completion and lower latency), and there is no indication of any security fix or vulnerability being addressed.
bb7db392 · Nov 20, 2025 · 1 fileInformational 18sql: if we use `dev-sqlfilename`, don't bother syncing it to disk.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes a developer-only test feature (`dev-sqlfilename`) so that when it is used, the SQLite database does not write changes to disk as carefully. This makes tests run faster but increases the risk of losing data if the program crashes. It only affects a special testing option, not normal operation.
b63034bd · Nov 20, 2025 · 1 fileInformational 15plugins/sql: use modern data style, not globals.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a straightforward internal cleanup in the SQL plugin of Core Lightning. It replaces global variables (shared data that any part of the program could accidentally touch) with a dedicated data structure attached to the plugin instance. There is no security fix here; it is a code-quality and maintainability change.
94d582f2 · Nov 20, 2025 · 1 fileLow 36lightningd: don't process more than 100 commands from a plugin at once.
Now that ccan/io rotates through callbacks, we can call io_always() to
yield.
We're now fast enough that this doesn't have any effect on this test,
bit it's still good to have.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change adds a limit so that Core Lightning processes at most 100 plugin responses in one go before yielding control back to the main event loop. The stated goal is to prevent a misbehaving or malicious plugin from flooding the daemon with responses and starving other work. It is framed by the author as a hardening measure rather than a fix for a known exploitable bug.
b51e2827 · Nov 20, 2025 · 1 fileLow 37lightningd: don't process more than 100 commands from a JSONRPC at once.
Now that ccan/io rotates through callbacks, we can call io_always() to yield.
Though it doesn't fire on our benchmark, it's a good thing to do.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change tweaks how Core Lightning handles incoming JSON-RPC commands so it never processes more than 100 commands or 250 milliseconds in one go without taking a break to let other connections and tasks run. The goal is to prevent a single busy connection from starving the rest of the node. The commit itself frames it as a hardening improvement rather than a fix for a known active bug or vulnerability.
5fc9e5a4 · Nov 20, 2025 · 2 filesInformational 16ccan: update to get io_loop fairness.
This rotates through fds explicitly, to avoid unfairness.
This doesn't really make a difference until we start using it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit updates an internal helper library (CCAN) used by Core Lightning to make the program's main event loop fairer when handling many network connections. Previously, lower-numbered file descriptors could be serviced first every time, which in extreme cases might let one connection starve others. The change rotates through connections and interleaves 'always-run' callbacks. The commit message explicitly says this is not currently security-relevant for Core Lightning ('This doesn't really make a difference until we start using it').
54d4bf11 · Nov 20, 2025 · 1 fileInformational 15common: optimize json parsing.
We would keep parsing if we were out of tokens, even if we had actually
finished one object!
These are comparison against the "xpay: use filtering on rpc_command
so we only get called on "pay"." not the disasterous previous one!
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 126 seconds (was 135)
Worst latency: 5.1 seconds **WAS 12.1**
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a performance optimization for JSON parsing in Core Lightning. The change fixes a bug where the parser would keep re-parsing unnecessarily when it ran out of tokens, even though it had already successfully parsed a complete JSON object. The commit message frames this as an optimization, not a security fix, and shows benchmark improvements (worst latency dropping from 12.1 seconds to 5.1 seconds).
aff1d6b9 · Nov 20, 2025 · 2 filesLow 29commando, chanbackup: use custommsg hooks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes two Core Lightning plugins—commando and chanbackup—so they only process specific peer message types instead of listening to every custom peer message. It is a hardening/refactoring change that narrows what each plugin handles, likely improving performance and reducing the attack surface, but the diff alone does not show a fix for an exploitable vulnerability.
1d4a1cdd · Nov 20, 2025 · 1 fileLow 29libplugin: don't wait for clean_tmpctx() to free requests as we process them.
xpay is relying on the destructor to send another request. This means
that it doesn't actually submit the request until *next time* we wake.
This has been in xpay from the start, but it is not noticeable until
xpay stops subscribing to every command on the rpc_command hook.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a bug-fix patch for Core Lightning's plugin library. It changes when plugin-to-JSON-RPC request objects are freed so that an internal plugin called xpay can immediately send follow-up commands instead of waiting until the next event loop wakeup. The commit describes it as a functional bug that was hidden until xpay stopped monitoring every command, not as a security vulnerability.
ebe5f2e6 · Nov 20, 2025 · 2 filesInformational 12libplugin: allow plugins to register optional filters for each hook they want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new plugin-library feature that lets plugin authors register optional filters when subscribing to hooks. It is a straightforward API extension: plugins can now declare string or integer filters in their hook manifest, which the main daemon can use to decide whether to invoke the hook. There is no indication in the commit that this fixes a bug or addresses a security issue; it appears to be a normal feature addition.
d9d82ac5 · Nov 20, 2025 · 2 filesInformational 15lightningd: add support for filters on "rpc_command" hook.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Plugins: the `rpc_command` hook can now specify a "filter" on what commands it is interested in.
This commit adds a new optional feature to Core Lightning plugins. Plugin authors can now tell the 'rpc_command' hook to only intercept specific RPC commands by name, rather than being sent every single command. This is a convenience/performance improvement, not a security fix or vulnerability.
673729bd · Nov 20, 2025 · 1 fileInformational 18Revert "bookkeeper: don't flood logs if we have many channelmoves all at once."
This reverts commit 1dda0c07530d01dfa50f6121ba30530659a1475b so we can test
what its like to be flooded with logs again.
This benefits from other improvements we've made this release, to handling
plugin input (i.e. converting to use common/jsonrpc_io), so this doesn't
make much difference.
tests/test_coinmoves.py::test_generate_coinmoves (100,000, sqlite3):
Time (from start to end of l2 node): 211 seconds
Worst latency: 108 seconds
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes a small log-throttling feature in Core Lightning's bookkeeper plugin. Previously, if many channel balance updates arrived at once, the plugin only logged the first and last one to avoid spamming debug logs. This change reverts that behavior so every update is logged again. The author says this is acceptable because other performance improvements this release make the flood less of a problem. There is no direct security vulnerability here; the main effect is more debug log output, which could slightly increase disk use or log-noise under heavy load.
9e04d044 · Nov 20, 2025 · 1 fileInformational 18JSONRPC: use a bigger default buffer.
This potentially saves us some reads (not measurably though), at cost
of less fairness. It's important to measure though, because a single
large request will increase buffer size for successive requests, so we
can see this pattern in real usage.
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 227 seconds (was 239)
Worst latency: 62.4 seconds (was 56.9)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply increases the default memory buffer size used when reading JSON-RPC messages. The change is described by the author as a performance tweak to reduce the number of small reads, not a security fix. There is no indication in the commit or supplied references that this resolves a vulnerability.
d2a60911 · Nov 20, 2025 · 1 fileInformational 21common: increase jsonrpc_io buffer size temporarily to aggrevate perf issues.
A client can do this by sending a large request, so this allows us to see what
happens if they do that, even though 1MB (2MB buffer) is more than we need.
This drives our performance through the floor: see next patch which gets
us back on track.
tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 271 seconds **WAS 135**
Worst latency: 105 seconds **WAS 12.1**
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a temporary debugging change that increases an internal buffer size from 2 KB to 1 MB. The author explicitly states it is meant to expose and measure performance problems caused by large JSON-RPC requests, not to fix a security bug. By itself, it makes the node slower when handling big requests, but it does not introduce a clear vulnerability such as a crash or memory corruption.