Automated node opsec: timing correlation flaw

[CryptoVoyager24]

Timing attacks on automated nodes. need some advice.
Im using cloudflare tunnels for inbound webhooks. Node only uses tor for outbound.
But the timing is a dead giveaway. Webhook hits the server, tx hits the tor network right after. Anyone watching both sides can just link the timestamps and dox the real ip.
How do people add random delay to the broadcast? Hoping there is a native core setting for this. Really dont want to build a custom python script just to hold the tx. Thoughts?

[NotATether]

It does not exist, unfortunately.

Here is a thread by another guy asking people if they would want this feature: https://delvingbitcoin.org/t/scheduled-delayed-transaction-broadcast/2148/4

The only way you'll get reliable delayed broadcasting that doesn't hang up your server-side request is by utilizing cron jobs which read and write transacion hashes to files in a queue (just put the timestamp at the end for order purposes or something) and then a custom script reads one TX file off at a schedule and broadcasts it. Use locks so that the two programs don't access a file at the same time.

[BattleDog]

You can try to decouple the webhook from the broadcast (have the webhook just drop the raw tx into a queue and then just return instantly, and have a separate scheduled job broadcasts on its own cadence with some randomized delay). That gets you jitter without hanging requests and without needing a big custom daemon.

Just keep in mind jitter only beats casual correlators. If someone can repeatedly trigger your webhook and watch the mempool, they can still narrow you down unless you batch at fixed intervals or blend with other outbound noise. The best defense is still not letting your origin be reachable and keeping the broadcast path isolated from whatever receives the webhook.