Hi, As far as I understand your answer is "let's try to use what exists", this is not what I am proposing and not the Tor network, no "standard" exit nodes, different hidden services, decentralized anonymizer network unlike the Tor network, nodes are anonymizing themselves
Comments below, please let me know what is unclear in the description of the project so I can modify it because all the time I get the impression that it is mixed with the Tor network while it just has a very little to do with it, and I don't get that the simple principle of communicating between nodes using the Tor protocol without RDV points is never considered Regards, Le 05/06/2020 à 13:44, ZmnSCPxj a écrit : > Good morning Aymeric, > >> The issue each time there are discussions/research linking to Tor is that it >> is biased since the beginning because based on a wrong postulate: using the >> Tor network >> > Well, in the interest of using the wrong tool for a highly important job, let > me present this thought: Then for an important job people should use the right tool... > > * The Tor network is weakened due to its dependence on a limited set of exit > nodes. And centralized structure, limited set of nodes to make it short, for some (or a lot) misbehaving, not designed for bitcoin, nothing prevents bitcoin from operating its own anonymizer system, which I am proposing > * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services. Good to a certain extent... if you want to hide that you are operating a bitcoin node you can use RDV points (ie hidden services) but if you don't care you just connect anonymized circuits between bitcoin nodes, this is more "direct" and does not exist in the Tor network, this includes light clients that can act as relays also > * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet > connections, the issue is with Tor-to-clearnet connections. There are plenty of Tor-to-Tor issues, not theoretical but in the real world, "Tor-to-clearnet" can be done outside of the Tor network, ie the bitcoin network > * Of course, no miner is going to run over Tor because latency, so all the > miners will be on clearnet. Probably, again I am not proposing a remake of the Tor network, I don't see the use for a miner to hide (neither for a bitcoin node to use RDV points), but they can be part of the global anonymized system, please see below > * So make your own bridge between Tor and clearnet. > * Run two fullnodes on your computer (with sufficient ingenuity, you can > probably share their block storages, or make one pruning). > * One fullnode is on the public network but runs in `blocksonly` so it does > not propagate any transactions (which might be attached to your public IP). > * The other fullnode is on the Tor network and has an `-addnode` to the > public-network node via `localhost`, which I assume is very hard for an > eclipse attacker to get at. > * Use the Tor-fullnode to propagate your transactions. Yes but one full node should be able to do this alone, ie implement both interfaces, like miners and everybody in fact (or Peersm bridges with bittorrent if you look at the history of the project) > > Of course, the eclipse attacker can still attack all Tor exit nodes and block > outgoing transaction traffic to perform eclipse attacks. > And if you decide to propagate transactions to the public-network node then > you pretty much lose your privacy there. Please see the convergence link, it's not based on the assumption that "the more you are the better you can hide and the lesser you can get attacked", this does not work at all, it's based on the assumption that even with a reduced set of peers it becomes very difficult to know who is doing what and whom is talking to whom, the concept of exiting/bridging to clearnet(s) is not clearly detailed in this version but appears on the drawings _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev