What changed, and why it matters
This commit removes an experimental developer-only feature called 'uniform padding' that was intended to make network traffic between Lightning nodes look more uniform as a defense against traffic analysis. It is a clean revert of three earlier commits and does not introduce any security vulnerability or fix one. The feature was gated behind a hidden developer flag and was never active in normal operation.
No security action required. Treat as a normal feature revert. If traffic-analysis resistance is a project goal, track the revert in release notes and consider whether an improved padding design will replace it.
Security signals we found
Removal of an experimental traffic-analysis countermeasure (uniform message padding)
No changes to authentication, encryption, parsing, or state handling
No bug fix or vulnerability remediation evident in the diff
Evidence from the diff
The commit reverts the ‘–dev-uniform-padding’ option and the associated ‘dev_uniform_padding’ flag from connectd and lightningd. The feature padded outgoing peer messages to uniform 1460-byte segments. The revert removes the option registration, the struct fields, the wire protocol field, and updates the test that relied on the flag. No cryptographic, network, or consensus code is changed.
Changed components
connectdlightningd option handlingconnectd/lightningd wire protocol initializationtests/test_connection.pyInspect captured patch +3 / −19
diff --git a/connectd/connectd.c b/connectd/connectd.c
index 1dbc660c..343a59ec 100644
--- a/connectd/connectd.c
+++ b/connectd/connectd.c
@@ -1695,8 +1695,7 @@ static void connect_init(struct daemon *daemon, const u8 *msg)
&daemon->dev_no_reconnect,
&daemon->dev_fast_reconnect,
&dev_limit_connections_inflight,
- &daemon->dev_keep_nagle,
- &daemon->dev_uniform_padding)) {
+ &daemon->dev_keep_nagle)) {
/* This is a helper which prints the type expected and the actual
* message, then exits (it should never be called!). */
master_badmsg(WIRE_CONNECTD_INIT, msg);
@@ -2532,7 +2531,6 @@ int main(int argc, char *argv[])
daemon->dev_exhausted_fds = false;
daemon->dev_lightningd_is_slow = false;
daemon->dev_keep_nagle = false;
- daemon->dev_uniform_padding = false;
/* We generally allow 1MB per second per peer, except for dev testing */
daemon->gossip_stream_limit = 1000000;
daemon->incoming_stream_limit = 1000000;
diff --git a/connectd/connectd.h b/connectd/connectd.h
index 2ea40eef..d3885c17 100644
--- a/connectd/connectd.h
+++ b/connectd/connectd.h
@@ -320,9 +320,6 @@ struct daemon {
/* Allow localhost to be considered "public", only with --developer */
bool dev_allow_localhost;
- /* Pad outgoing messages to uniform 1460-byte segments (traffic analysis defence) */
- bool dev_uniform_padding;
-
/* How much to gossip allow a peer every second (bytes) */
size_t gossip_stream_limit;
diff --git a/connectd/connectd_wire.csv b/connectd/connectd_wire.csv
index 700e6829..d5f6aee3 100644
--- a/connectd/connectd_wire.csv
+++ b/connectd/connectd_wire.csv
@@ -29,8 +29,6 @@ msgdata,connectd_init,dev_no_reconnect,bool,
msgdata,connectd_init,dev_fast_reconnect,bool,
msgdata,connectd_init,dev_limit_connections_inflight,bool,
msgdata,connectd_init,dev_keep_nagle,bool,
-# Pad outgoing messages to uniform 1460-byte segments (traffic analysis defence)
-msgdata,connectd_init,dev_uniform_padding,bool,
# Connectd->master, here are the addresses I bound, can announce.
msgtype,connectd_init_reply,2100
diff --git a/lightningd/connect_control.c b/lightningd/connect_control.c
index 58b3b446..e95a04db 100644
--- a/lightningd/connect_control.c
+++ b/lightningd/connect_control.c
@@ -727,8 +727,7 @@ int connectd_init(struct lightningd *ld)
!ld->reconnect,
ld->dev_fast_reconnect,
ld->dev_limit_connections_inflight,
- ld->dev_keep_nagle,
- ld->dev_uniform_padding);
+ ld->dev_keep_nagle);
subd_req(ld->connectd, ld->connectd, take(msg), -1, 0,
connect_init_done, NULL);
diff --git a/lightningd/lightningd.c b/lightningd/lightningd.c
index 03ebdd1e..b0b2030a 100644
--- a/lightningd/lightningd.c
+++ b/lightningd/lightningd.c
@@ -150,7 +150,6 @@ static struct lightningd *new_lightningd(const tal_t *ctx)
ld->dev_strict_forwarding = false;
ld->dev_limit_connections_inflight = false;
ld->dev_keep_nagle = false;
- ld->dev_uniform_padding = false;
/*~ We try to ensure enough fds for twice the number of channels
* we start with. We have a developer option to change that factor
diff --git a/lightningd/lightningd.h b/lightningd/lightningd.h
index 3a00f9f3..9edba38d 100644
--- a/lightningd/lightningd.h
+++ b/lightningd/lightningd.h
@@ -369,9 +369,6 @@ struct lightningd {
/* Tell connectd we don't want TCP_NODELAY */
bool dev_keep_nagle;
- /* Pad outgoing messages to uniform 1460-byte segments (traffic analysis defence) */
- bool dev_uniform_padding;
-
/* tor support */
struct wireaddr *proxyaddr;
bool always_use_proxy;
diff --git a/lightningd/options.c b/lightningd/options.c
index deacfdfd..b185d7ea 100644
--- a/lightningd/options.c
+++ b/lightningd/options.c
@@ -952,10 +952,6 @@ static void dev_register_opts(struct lightningd *ld)
opt_set_bool,
&ld->dev_keep_nagle,
"Tell connectd not to set TCP_NODELAY.");
- clnopt_noarg("--dev-uniform-padding", OPT_DEV,
- opt_set_bool,
- &ld->dev_uniform_padding,
- "Pad all outgoing peer messages to uniform 1460-byte segments");
/* This is handled directly in daemon_developer_mode(), so we ignore it here */
clnopt_noarg("--dev-debug-self", OPT_DEV,
opt_ignore,
diff --git a/tests/test_connection.py b/tests/test_connection.py
index db51651c..2aef8568 100644
--- a/tests/test_connection.py
+++ b/tests/test_connection.py
@@ -4823,7 +4823,7 @@ def test_constant_packet_size(node_factory, tcp_capture):
Test that TCP packets between nodes are constant size. This will be skipped unless
you can run `dumpcap` (usually means you have to be in the `wireshark` group).
"""
- l1, l2, l3, l4 = node_factory.get_nodes(4, opts={'dev-uniform-padding': None})
+ l1, l2, l3, l4 = node_factory.get_nodes(4)
# Encrypted setup BOLT 8 has some short packets.
l1.connect(l2)
Why this scored 12/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.