Node security: timing attack issue

3 replies 34 views
Posts: 13 · Reputation: 110
#1Sep 9, 2018, 03:38 PM
Got a question about timing attacks on automated nodes. I'm using Cloudflare tunnels for incoming webhooks, but my node only sends out traffic through Tor. The timing is pretty obvious. Once the webhook hits my server, the transaction goes out on the Tor network right after. If someone is monitoring both ends, they can easily match the timestamps and trace it back to my real IP. How do folks usually add some random delay before broadcasting? I’m hoping there’s a built-in setting in the core for this. Really don’t wanna go through the hassle of writing a custom Python script just to delay the transaction. Any ideas?
5 Reply Quote Share
LuckyCoinLegendary
Posts: 832 · Reputation: 4795
#2Sep 9, 2018, 06:27 PM
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.
1 Reply Quote Share
paul.ninjaFull Member
Posts: 152 · Reputation: 539
#3Sep 10, 2018, 12:29 AM
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.
0 Reply Quote Share
Posts: 13 · Reputation: 110
#4Sep 10, 2018, 02:12 AM
Yeah figured there was no magic flag for this. Going to build a separate python daemon with a queue system like you guys suggested. Thanks for the delvingbitcoin link, exactly what i needed to read.
6 Reply Quote Share

Related topics