Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2P as additional transport layer for JoinMarket #1370

Open
kristapsk opened this issue Sep 29, 2022 · 11 comments
Open

I2P as additional transport layer for JoinMarket #1370

kristapsk opened this issue Sep 29, 2022 · 11 comments
Labels
protocol related to the communication between maker / taker

Comments

@kristapsk
Copy link
Member

kristapsk commented Sep 29, 2022

For some time there is active DDoS attack against Tor network and sometimes it is unreliable. See https://status.torproject.org/.

image

In fact, Tor is currently our single point of failure. If it is not working or not reliable, it affects JoinMarket, there are no alternatives provided (ok, users could still use IRC over clearnet, by using some VPNs, but that's neither suggested nor default config, anonimity set there will be small, only few power users will try that).

It makes sense to look at other anonymity dark nets. There are some discussion about them in #415.

The second most popular one after Tor currently seems to be I2P. It was recently added to Bitcoin Core. There was argument from @chris-belcher against I2P, but it was about original Java implementation of I2P, there is now alternative, which is complete reimplementation in C++ (i2pd).

I've been told i2p's privacy isn't that great:

<IRCNICK> I2P isn't nearly as secure as tor; i2p has no unbroken line of release keys; i2p's main devs went to zcash; major aspects of i2p have been broken for long periods of time; i2p is easily sybil'able; i2p is so unreliable that long-term nodes that have been up for weeks still can't connect to many of the sites inside the network; some of the people who contributed to i2p are straight up horrid people
<IRCNICK> (I left long ago though); i2p depends on code that either can't, or at the very least is VERY DIFFICULT to, be compiled from source and so other safer platforms are essentially barred from running it; i2p documentation for its internal protocols is so shitty that writing i2p support for things is basically impossible; etc.
<IRCNICK> simple tools and utilities to debug i2p problems are totally hidden and unknown. etc etc etc.

(related - #1038 and #1049).

In current circumstances I think it's worth restarting discussion about adding I2P support to JoinMarket, to have alternative for Tor. Yes, I'm also not so sure I2P privacy is at the same level as for Tor (haven't looked at that enough) and Bitcoin Core having support is weak argument also, as one thing is how you broadcast random transactions, another is how you talk about other peers and construct single collaborative transaction. But if choice is between non-working JoinMarket or JoinMarket over I2P, I definitely choose having I2P support.

As a first step we could add commented out instructions to default joinmarket.cfg about how to use IRC over I2P, so some people could start using that. If we agree this is good idea, we could then add I2P support to native JoinMarket messaging protocol. And then could even add --with-local-i2pd option for install.sh, like we already have with Tor.

@kristapsk kristapsk added the protocol related to the communication between maker / taker label Sep 29, 2022
@hellodarkness
Copy link
Contributor

Having read through the related issues.... I agree of the mentioned privacy projects I2P is best alternative to Tor.

In #415 Freenet and Matrix got mentions.

Freenet is more for censorship-resistant sharing of files, it's filling a different role to Tor. I don't think it suits Joinmarket's use case at all.

I'm a huge fan of Matrix, and run a homeserver for a small number of users. Thing is, even my small server is quite a resource hog. I suppose if it was optional, people with the resources could run a federated server for other users to connect to, but does that add much benefit over the current IRC solution?

I agree Joinmarket being reliant on Tor isn't ideal. I think having I2P as an option for those who wish to use it would be a good compromise. If it's not on by default and comes with a disclaimer that it's not an endorsement either way of I2P's privacy, would that be enough to start with?

I'd be willing to test IRC over I2P.

@AdamISZ
Copy link
Member

AdamISZ commented Oct 1, 2022

Thanks.

We do need access to some kind of library for connecting over I2P though. This looks relatively promising, though unsurprisingly, it's old: https://github.com/str4d/txi2p. The code snippets in the README match pretty well what we already do for Tor.

Edit: I just want to emphasize that I'm just chipping in here with a minor comment; I don't even know how I2P works yet, yet alone writing even a line of code to use it, or running it. Hopefully we'll get real world feedback on this at some point and/or do more detailed research.

@kristapsk
Copy link
Member Author

I also haven't yet studied I2P enough in detail so far, main difference is that Tor uses onion routing, but I2P uses garlic routing.

@kristapsk
Copy link
Member Author

Here's useful article by @jonatack on Tor vs I2P and CJDNS - https://jonatack.github.io/articles/using-alternative-p2p-networks-with-bitcoin-core.

@ghost
Copy link

ghost commented Dec 30, 2022

I also haven't yet studied I2P enough in detail so far, main difference is that Tor uses onion routing, but I2P uses garlic routing.

Two more differences:

Tor I2P
Network Database Trusted Directory Servers Distributed network database
Relay Two-way encrypted connections between each Relay One-way connections between every server in its tunnels

A recent answer on i2p subreddit related to denial of service by alreadyburnt:

I2P is not vulnerable to exactly the same DDOS attack which has been affecting Tor at this time. The attack involves flooding the network with "Introducer Cell" requests. I2P works differently from Tor here, and differently enough to make it more difficult to carry out this type of attack. There is a variant of the attack which might potentially work but it doesn't seem to be easy to carry out right now. For more information: http://zzz.i2p/topics/3464

https://www.reddit.com/r/i2p/comments/zvrqop/is_i2p_vulnerable_to_ddos_attacks/j1r8tmw

@hellodarkness
Copy link
Contributor

There's an IRC network, IRC2P (with I2P installed, it's connectable through localhost/6668 ), according to: https://geti2p.net/en/faq

Would adding support for that as a short-term test of the reliability of the network be an option?

@kristapsk
Copy link
Member Author

There's an IRC network, IRC2P (with I2P installed, it's connectable through localhost/6668 ),

I tried testing it while ago, but something wasn't working with JM there.

I2P is also supported by Ilita.

But, yes, adding commented out by default I2P options for IRC in default config could be the first step here.

See also #1038 and #1049.

@hellodarkness
Copy link
Contributor

I tried testing it while ago, but something wasn't working with JM there.

Were you using Java I2P or I2PD? I'm trying to test it myself and it's taken almost 48 hours to bootstrap enough to be able to access any sites and the number of tunnels I have open is still pretty poor. I'm going to try installing Java I2P on one of my servers (in case it's lack of bandwidth at home) to see if it's more reliable there.

If it always takes > 24 hours to bootstrap (and takes time to 'catch up' if you shut the node down for a while) it might not be ideal for people who want to be able to just spin up their laptop, do a quick mix, and disconnect.

@kristapsk
Copy link
Member Author

Tried with Java I2P first, later switched to I2PD, it seems better and more reliable. Got to the point JM could connect to IRC, join channels, but coinjoin attempts failed. But it was some time ago, don't remember exact details anymore.

@kristapsk
Copy link
Member Author

It looks to me there is difference in I2P vs Tor that server sees source of the connection. Doesn't change anything for takers, as you always create new identity, but for makers it means, when switching nicks, also new I2P identity needs to be created and bot should reconnect, otherwise you have worse privacy vs Tor. Likely with some smart delays or lazy closing of old connection, so that disconnects / connects cannot be correlated. Means that for IRC to just change proxy and server address will not be enough for makers, some additional logic is needed. Probably it's better to just go straight for native I2P messaging, like onionmc for Tor, instead of using IRC over I2P.

@Tracachang
Copy link

Tracachang commented Jan 8, 2023

It looks to me there is difference in I2P vs Tor that server sees source of the connection.

Creating an irc server in I2P network using Ergo IRC Server could solve this?

If it always takes > 24 hours to bootstrap (and takes time to 'catch up' if you shut the node down for a while) it might not be ideal for people who want to be able to just spin up their laptop, do a quick mix, and disconnect.

I use both implementations javai2p and i2pd daily and never had any issue . It bootstraps fast, the only thing that I've noticed is a bit of network congestion but should improve in the coming days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocol related to the communication between maker / taker
Projects
None yet
Development

No branches or pull requests

4 participants