Add support for option_message_padding

[tnull]

We add support for option_message_padding (feature ??) as proposed in lightning/bolts#1304.

When both parties signal support for `option_message_padding`, we pad
any sent messages to a fixed size to improve privacy in the face of
an adversary monitoring network traffic.

To this end we utilize an optional TLV-stream extension with an odd
field number of `u64::max_value()` that simply will be discarded by the
counterparty. The padding threshold is chosen to fit even the largest
standard Lightning messages (UpdateAddHtlc) whith some leeway to
guarantee package size uniformity even when some of the optional fields
are set.

[ldk-reviews-bot]

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Why even bother with a feature flag for this? We could just include a fixed, high, TLV in every (non-gossip) message based on config and the spec can reserve that TLV for "never to be used, specifically for padding".

[tnull]

Why even bother with a feature flag for this?

One argument could be that bandwidth-restricted can use the feature to completely opt-out of the overhead. The current approach is basically the most minimally invasive it could get, though making this non-optional might of course improve privacy. I hope to get some initial feedback on the approach in the next spec meeting though. Especially if consensus is that making padding a mandatory / core concept it might also be worth to aim to do it at the Noise layer, at least mid-term. But for this initial draft, it seemed a bit rude to propose sending everybody more data without prior concept ACKs from the implementations.

We could just include a fixed, high, TLV in every (non-gossip) message based on config and the spec can reserve that TLV for "never to be used, specifically for padding".

Right, that's what the current BOLTs draft (and this PR) are doing, mod the feature.

in every (non-gossip) message

Why wouldn't we use gossip messages to increase the anonymity set size, i.e., also pad them? Btw, as noted on the BOLTs draft, a logical secondary step would of course be to still make use of the padding bytes to improve goodput, e.g., by transmitting queued gossip data whenever it fits.

[TheBlueMatt]

One argument could be that bandwidth-restricted can use the feature to completely opt-out of the overhead. The current approach is basically the most minimally invasive it could get, though making this non-optional might of course improve privacy. I hope to get some initial feedback on the approach in the next spec meeting though. Especially if consensus is that making padding a mandatory / core concept it might also be worth to aim to do it at the Noise layer, at least mid-term. But for this initial draft, it seemed a bit rude to propose sending everybody more data without prior concept ACKs from the implementations.

Yea, okay, should be discussed in the spec meeting. IMO the overhead should be low enough that no one should care (is anyone really bandwidth-restricted in a way that a few Kbps is fine but a few + 2 Kbps isn't?), but even if it is one end can opt out and the other end can still send it, imo.

Why wouldn't we use gossip messages to increase the anonymity set size, i.e., also pad them? Btw, as noted on the BOLTs draft, a logical secondary step would of course be to still make use of the padding bytes to improve goodput, e.g., by transmitting queued gossip data whenever it fits.

Well, I was just talking about it int he context of the feature flag. Gossip messages are entirely signed, including the extra TLVs, so there has to be a feature flag to signal "ignore TLV type X, its not signed, and not a part of the gossip message". Tho even that has backwards compat concerns (I guess we don't care about someone's gossip getting dropped by half the nodes because they started including the padding field in their message?)