Indigenous node based cover traffic enforcing the privacy guarantees.

Is your feature related to a problem?

The problem arises in a network that does not have sufficient throughput. If within the mixing window of a single packet another packet does not arrive into the mixer, the packet leaves without enforcing the metadata privacy safe-guards, because no mixing has occurred. Even when an externally running cover traffic generator is running, it can not ensure that some packets occur alone in the mixer and this are not mixed.

Describe the feature you'd like

The indigenous node originating cover traffic. If a single packet is present in a mixer and should leave the mixer, a randomly generated "junk" cover traffic 0-hop packet is taken from the "junk queue" and sent to a random different peer towards which the node has an open channel.

Because the cover traffic packets are 0-hop, they incur no price for sending and cannot be refused by the receiver, because they are structurally indiscernible from a packet originating from a normal traffic, before the target peer decrypts it.

By making the cover traffic packet count per solo mixer packet configurable, it is possible to significantly alter the structure of network traffic improving overall privacy.

Describe alternatives you've considered

Significantly increasing the externally generated cover traffic throughput.

Additional context

The cover traffic packets could be sent over a newly designated range of "service application tags", which would not be generally accepted as an input for the send_message command or endpoint, but could in the future be used to actually distribute actual peer negotiation data (e.g. channel tree updates...).

The cover traffic generated in this manner:

1. does not flood the network globally, but increases the privacy of the transport metadata locally.
2. is inexpensive - it costs only the processing time
3. is truly locally scalable
4. can be extended to incentivization distributing mechanism easily by adding 1-hop
5. service tags can be extended in the future to distribute peer negotiation mechanisms

Caveats

Reasonable anti-DOS and anti-flooding strategies on a peer level would be needed to make sure that an adversary does not flood the network with junk cover traffic.