Obfuscate maker bot identities #422
Conversation
| self.reconnect_delay = 30 | ||
| self.newnyms = False | ||
| try: | ||
| self.reconnect_delaty = int(config.get("MESSAGING", "reconnect_delay")) |
There was a problem hiding this comment.
mispelling here, should be reconnect_delay
| @@ -116,11 +116,16 @@ def jm_single(): | |||
| socks5_host = localhost | |||
| socks5_port = 9050 | |||
| #for tor | |||
| #host = 6dvj6v5imhny3anf.onion | |||
There was a problem hiding this comment.
Why is the onion host gone? I think this is a mistake.
There was a problem hiding this comment.
Using hidserv publicly reveals the fact you're using tor, plus makes your bot unstable. Use HS only on irc networks which don't allow direct tor connections. Opionated I know, I'll revert this if you strongly disagree.
There was a problem hiding this comment.
Made check for .onion when newnym is used (and bail on it).
What do you mean by this? There is no identity attached, JoinMarket does not ask for any proof of ID before running. I assume you mean something else like IP address or bitcoin amounts(?) Why does your code only create a new tor circuit when the bot disconnects? It seems like an arbitrary time to do it. Would it maybe be better to disconnect and reconnect at random time intervals? I'm not sure cycling to a new tor circuit is helpful when the bitcoin amounts can be correlated very easily. Happy to be proven wrong though. |
|
@chris-belcher This patch is about the nyms of the comms channel, not with regards to JM protocol itself. Current weak attempts is retaining a nickname across reconnects, not changing Tor circuit on reconnect and keeping same orders across reconnect. Meaning the long term identity of a single pseudo nym is eagerly disclosed. The patch does the opposite of "eager". First, it's much harder for passive adversary to even determine you're using tor (which is now trivial). Second, if he starts probing Tor entry guards he can't (easily) tell the returning bot is the same he's trying to traffic confirm. Note that advertised orders need some fixing up to make it a bit harder, I'll keep elaborating ideas on irc and mention here if it's something worthwhile. Regarding traffic confirmation, see https://blog.torproject.org/blog/traffic-correlation-using-netflows and related google searches. In short, with interactive protocols like IRC it works like this: First, you confirm an entry guard. If you can confirm with high degree of certainty, you issue a court order on said guard to acquire netflow packet dumps. After that, it's a gameover for whomever is behind said guard. |
further obfuscate the long term identity of a bot
AdamISZ
force-pushed
the
develop
branch
3 times, most recently
from
97d2603
to
47479d5
Compare
Currently the codebase makes weak attempts to disclose the long term identity of a maker, which somewhat irks me.
These patches make the bot assume a new identity on every IRC reconnect. While the bot can be tracked through published orders, yield scripts must be fixed separately to not leak amount/utxo information. The following patches deal only with revealing stable nym through IRC.
The feature is optional and disabled by default.
I am aware this is a possible tool of sybil attackers. That would happen one way or another, massive sybils must be prevented through effective means - market forces, coin age and privately, F2F established identities - not nicknames and irc hostmasks...