Integrate with I2P-Java via libsam3

[knaccc]

I2P-Java is a relatively mature project with active developers.

A few years ago, it would have been unthinkable to have to ask people to separately install a 200 MB JVM on their machine before being able to run a Monero wallet that wanted to route connections through I2P-Java.

Things have changed since then. Java 9 implemented modularization to allow zero dependency native apps with small footprints. This brings the footprint of an app with a bundled JVM down to as low as 22 MB (11 MB with compression). The end user will have no idea they're running a JVM, and no JVM will be installed. This means no conflicts with any other JVMs they may previously have installed. Even better, we now have the open source (GPLv2) OpenJDK. See https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/

zab, one of the I2P developers, has noted in the Monero reddit that we could interface with I2P-Java via the SAM library https://github.com/i2p/libsam3 or via the lower level I2CP protocol https://geti2p.net/en/docs/protocol/i2cp (zab's comment here).

[SamsungGalaxyPlayer]

Hide the originating node for a specific transaction?

Yes, this is the primary goal.

Hide the existence of a Monero node?

This is a "reach goal" that most users won't bother with.

What parts of the network traffic of a Monero node will go through this network, just the "mempool" additions?

Yes, generally the mempool additions will go through I2P unless configured otherwise.

What about wallets communicating with remote nodes? Do wallets communicate with a "hidden service" of sorts? Or do those transactions go over the regular internet?

It would depend on the configuration. Remote node over I2P is a clear use-case, though it comes with efficiency tradeoffs. Another "nice to have."

If over regular internet, how are those communications encrypted? Are the different packets going between light wallets and full nodes distinguishable or uniform?

The relevant packets of data communicated here are encrypted iirc, but normal node sync data between nodes is not encrypted.

Will each full node be a "hidden service"?

It will not be a requirement, but having a network of Monero nodes connected over both clearnet and I2P would substantially increase the resiliency of the network. Monero users benefit from high I2P adoption.

If you have an IP hosting a hidden service also send corresponding traffic over the regular internet, is that good/bad/neutral for the security of this network?

Mostly neutral. Though it could be "good" in that less data needs to be transferred over the less-efficient I2P network.

Dandelion protocol, inferior or can it be used in unison with this network to improve security or will it just be not needed?

Dandelion works similarly though to a less-rigorous extent. It's a simpler solution that may be "good enough" for most use-cases. I2P integration should provide more metadata protection than Dandelion, and much better protection against sybil attacks. Dandelion however works more simply with the existing nodes.

[zlatinb]

I hope this bad blood doesn't extend to the I2P-Java team.

I wouldn't be here if that were the case! There is no bad blood between the Monero project as a whole and I2P-java, although our interactions with the Kovri team specifically over the years leave a lot to be desired. But I'm feeling significantly better after reading the comments by @coneiric .

If you choose to go with us we will try to dedicate a full-time resource to the maintenance of libsam3.

[fluffypony]

I don't think any of the routers should be "bundled" or "embedded" into Monero other than a link on the download page, or submodule branch on the repository. Something like "here are the routers Monero is compatible with, pick one (or many)". As long as the routers support SOCKS, IPC, SAM or some other common API.

This is the same as non-mandatory privacy. I'd support optional Tor support if we're going to bundle i2p, but we must bundle something so that it's effortless and on by default, else nobody will use it.

What parts of the network traffic of a Monero node will go through this network, just the "mempool" additions?

When a node handshakes with another node, over ipv4 or over Tor / i2p, it will specify what it wants on that connection, either blocks or transactions or both. By default, it will ask for transactions only over hidden services, and it will ask for blocks only over ipv4.

What about wallets communicating with remote nodes? Do wallets communicate with a "hidden service" of sorts? Or do those transactions go over the regular internet?

Absolutely - one of the things that MyMonero wants to add to the open-source light wallet server is the ability to leverage a bundled hidden service, and show a QR code for that service address. You can then scan the QR code with the MyMonero app, and it will use your backend, without you needing to forward ports on your router or do anything like that!

Dandelion works similarly though to a less-rigorous extent. It's a simpler solution that may be "good enough" for most use-cases. I2P integration should provide more metadata protection than Dandelion, and much better protection against sybil attacks. Dandelion however works more simply with the existing nodes.

In addition, I'm of the opinion that we should implement Dandelion regardless, as it will defeat many of the fingerprinting attacks that try determine whether a machine broadcasting a tx on a hidden service is the same machine broadcasting blocks on a particular ipv4 address.

[JustFranz]

Than you for the clear answers, one more question.

If a light wallet client creates a transaction and sends it to a full node either over ipv4 or i2p/tor, if you are monitoring the outgoing packets of that light wallet, is it an identifiable event? Or is there constant back and forth indistinguishable data transmission where you can't tell?

What I mean is especially if a wallet goes through i2p/tor only to broadcast its transaction. With sufficient surveillance you can tie a wallet (IP, phone, person, entity) to one of the transactions in the block (or mempool addition) after the observed tx broadcasting event over i2p/tor. Knowing that a certain entity just constructed a transaction seems like the best you can hope for, considering the nature of the Monero blockchain. Correct me if I am have misunderstood something.

[x1ddos]

over ipv4

what happened to ipv6? very surprised it's left out.

[lessless]

the aforementioned SAM patches for i2pd are on a branch that needs to be (non trivially) rebased atop the recent protocol improvements (namely NTCP2 and LS2).

I think that going forward you'll realistically get more done working together with us at loki using lokinet, lots of i2pd people feel really burned by the previous interactions with monero.

@majestrate is it possible to use Loki Network without being bound to the cryptocurrency part?

[kayront]

@anonimal continues to propagate this unsubstantiated claim:

Besides; this entire issue has already been deprecated by Sekreta. Single-system solutions are a thing of the past.

Once again, because he failed to reply on reddit, and I quote my post in its entirety:

Repeated frequently in your recent posts is the assumption that a single overlay network is now "deprecated" and "not sound".

Please provide evidence supporting this assertion, something other than "I have begun working on something even more complex than the project that has not materialized, and THAT is the solution to all of our problems.

I would like to see comments backed by security professionals, tor and i2p developers, where they clearly agree with your assertion.

Do you have any such material to share? I will naturally be glad to review my opinion if presented with irrefutable evidence (this message is not adversarial, just straight to the point and I would be happy to learn more if the state of affairs in anonymizing technology truly has changed that much), to the best of my present knowledge no such consensus exists, the first time I heard about Tor or I2P being deprecated when single-handedly relied upon is from your claims, you will surely understand my healthy scepticism on the matter when continued funding depends on the acceptance of the premise that a single overlay network is no longer adequate.

I must also reiterate that @anonimal continues to exhibit - as clearly seen in this github thread - unwarranted, rude, and aggressive behavior, and continues to speak down to other contributors in a manner that any civilized and reasonable person ought to consider unacceptable.

No one else is distributing insults and belittlements the way @anonimal is doing. This sort of behaviour is hardly acceptable.

[fluffypony]

@x1ddos good question! We largely ignore ipv6 as it is not resistant to isolation attacks, which is especially relevant in light of the recent ETC attack (which some suspect was an isolation attack and not a 51% attack). This is because ipv4 addresses are scarce, and thus more expensive. What I’d personally like to see on clearner is some sort of baseline approach where we do like 8 outbound connections on ipv4 for isolation attack resistance, and then anything inbound can be ipv4 or ipv6.

[JustFranz]

@anonimal continues to propagate this unsubstantiated claim:

Besides; this entire issue has already been deprecated by Sekreta. Single-system solutions are a thing of the past.

Once again, because he failed to reply on reddit, and I quote my post in its entirety:

Repeated frequently in your recent posts is the assumption that a single overlay network is now "deprecated" and "not sound".

I've had some time to think about sekreta. The readme concentrates on non issues like message confidentiality and integrity which are guaranteed through encryption already.

What tor/i2p are supposed to do is hide you and your activity. Blasting i2p/tor/loki network traffic at the same time is going to reveal you (at the beginning with few users and apps).

Sekreta can not detect a compromised network and route around a spy.

Sekreta will join the different anonymity networks into one for sekreta users and apps. The underlying flaws of each different network remain.

If you use 10 different networks at the same time and 9 of them are perfect while the 10th is flawed and that 10% of usage deanomizes you, you are done. It just does not make sense to use multiple networks simultaneously. You want to use a robust network and blend into the other users of the network.

Perfect network A and perfect network B with 50K concurrent users for both. For each there are 15K sekreta dual networkers for a total of 15K sekreta users. Those sekreta users are revealing themselves at the ISP level, they are in a pool of 15K instead of the 35K of the remainder of each respective network (+ 15K/2 if the sekreta users divided themselves). Both networks will be monitored and who knows what you can find out about the dual users if you can identify their traffic on both networks.

An API for easy integration with any of the networks currently out there, commendable. Extra encryption safeguards, why not. IMO network switching is bad and simultaneous usage is double-triple bad.

Sekreta might improve security by making the usage and implementation of if easier but it will not enhance any of the networks or synergize multiple for a positive effect for the user.

Sekreta warrants more discussion, thought and planning.

[x1ddos]

This his a bit of a weak argument against ipv6 imho. I personally wouldn't consider resource scarcity being an obstacle to mount such an attack in ipv4 space given the interested party has sufficient funds.

ISPs and hosting providers become more and more desperate due to the same issue of ipv4 scarcity and everyone's switching to ipv6 even though much slower than expected. I know some ISPs deliver new networks to users exclusively over ipv6 stack these days and ipv4 is an exception. To me the lack of ipv6-only support is kind of delaying the inevitable. Relying on ipv4 as some kind of a security measure might as well backfire with slower adoption of monero.

But this is out of scope here. I see there's already #147 although it's closed for some unspecified reason.

[fluffypony]

@x1ddos the cost of mounting an attack on ipv6 is like $0, the cost of doing so on ipv4 is not cheap given Monero's node distribution and the usage of anchor connections, class limitations, etc. Some good reading is:

• This paper describing Monero's p2p system in detail

• This paper describing eclipse attacks, and countermeasures against them, some of which Monero has implemented

[orignal]

I don't know what happened, and I don't really want to know, but wow there is a lot of bad blood between Monero and i2pd.

Since they're separate teams, I hope this bad blood doesn't extend to the I2P-Java team.

Great. Just leave i2pd alone. Especially about "slimmed down i2pd". Go write your own code.

[lessless]

@orignal I thought that we all are here to advance privacy in the Internet. What's the problem with using i2pd code?

[orignal]

@orignal I thought that we all are here to advance privacy in the Internet. What's the problem with using i2pd code?

The is no problem with using i2pd code at all. And we are happy when people use it and help everybody, but kovri, due the theft initiated by Spagni, that affects entire Monero. And since @knaccc 's position is pretty clear, there is no more room for discussions.

[lessless]

Politics will obviously drive this a bit further away from the productive discussion, and I guess all of us have to express gratitude to @knaccc in the first place for bearing with so many loosely related to the original issue content.

@orignal won't you please mind explaining your concerns to community at /r/Monero, so we will at least be informed about the situation at hand. There are a lot of people out there who are involved in Monero with their hearts, souls and pockets and who will appreciate clearly delivered information. Thanks.

[majestrate]

the aforementioned SAM patches for i2pd are on a branch that needs to be (non trivially) rebased atop the recent protocol improvements (namely NTCP2 and LS2). I think that going forward you'll realistically get more done working together with us at loki using lokinet, lots of i2pd people feel really burned by the previous interactions with monero.

@majestrate is it possible to use Loki Network without being bound to the cryptocurrency part?

yes lokinet can be used without being tied to the loki coin, but it may require a network fork depending on what parts you want to utilize. either way it's totally something we can figure out.

[knaccc]

@orignal

And since @knaccc 's position is pretty clear, there is no more room for discussions.

Not sure what you mean by this. I'm just someone that pointed out that I2P-Java looks like a great project and that it would be easy to bundle it with Monero. It's not my decision, and my enthusiasm for this approach is subject to a healthy debate about the future.

[orignal]

@lessless if you, guys, were not away what fluffypony and anonimal did, that's too bad for you.

But based on this statement

The only reason I suggested Java-I2P in the meanwhile is because that dream scenario seems to be at least 1-2 years away.

The built-in i2pd worked in the Anoncoin network as early as end of 2015. And Spagni knew about it (I can provide a log if necessary). Instead they preferred to shit on i2pd everywhere and kept doing until recent time. Later on we have decided to not use this approach for gostcoin, but bundle i2pd and gostcoin and communicate though the SAM using libsam as suggested in this topic. We have to make some changes to SAM implementation in i2pd and we also changed libsam to support EdDSA signatures and ECIES crypto. Such approach works successfully almost for two year now.

My impression is that Monero remembers about i2pd only when somebody fails. This scenario was with i2pcpp, now kovri, that's not a way we are interested in.

@coneiric mentioned LS2 and ECEIS. LS2 goes lives next week. ECIES proposal comes from i2pd. We use ECIES-P256 a lot for a long time, because it's much faster than ElGamal. Everybody can check their netdb for LeaseSets with crypto type 1.

[fluffypony]

@orignal Dude, stop. You're embarrassing yourself. Please stop. You literally disappeared and, as far as anyone could tell, abandoned i2pd. After AN ENTIRE MONTH a few people decided to fork the project. I offered them a home at the Monero project. It doesn't matter if it was working with Anoncoin or not, the project was forked and it was up to the new maintainer (@anonimal) to figure out what to do. The fact that you came back later is tangential, because you came back and were immediately hostile to everyone. This fact is evidenced by the terms you use today like "theft" instead of "forked my abandoned code".

I get that there's a language barrier, but even the IRC logs you posted on Reddit last year make you look like you misinterpreted the situation, not like @anonimal and I are evil, conniving tricksters who stole your livelihood. It's better if you just walk away from this with your dignity intact.

[orignal]

@fluffypony you didn't fork, you decided to hijack entire i2pd. Without authorization from anybody. Proof. https://github.com/PurpleI2P/i2pd/tree/cryptopp "Remove orignal certificate." Stop lying like you do all the time. I NEVER ABANDONED or planned to do it. Nobody from your tried to contact me while others was able to contact me without any problem. You was just waiting for an opportunity to hijack i2pd because you failed to pay. Who has assigned anonimal as "new maintainer"? You did, didn't you? You abused the trust granted to you and so was able to get an access to the repository.

Have you shared info about anci2pd project among other Monero people? I doubt. There is no "language barrier" as you like to repeat this word. There is only your permanent lie, that looks the same in any language.

[fluffypony]

@orignal Forking is not hijacking, stop being ridiculous. Also, that commit was EinMByte, who was/is a prominent i2p contributor. I have no control over what he did on a repo that I don't have collaborator privileges on.

Failed to pay whom or for what? I literally have no idea what you're talking about.

What repository did I not have access to? The i2pd repo was open, was it not? I don't recall being given special privileges to access anything.

Again, the fact that you came back and were working on i2pd was no secret. anonimal chose to continue with Kovri regardless of whatever i2pd and Anoncoin were doing, and that was his call. There is no conspiracy here, nobody was hiding information that was public in any event. The excess paranoia is not helpful.

This argument isn't pushing the conversation further. I'm going to add you to my ignore list, feel free to continue with your paranoid rants as you wish.

[lessless]

@orignal are you the guy who erased git history https://github.com/monero-project/kovri-docs/blob/master/i18n/en/faq.md#what-were-the-turning-points-that-lead-to-forking-from-i2pd-and-why-are-there-two-i2pd-repositories-one-on-bitbucket-and-one-on-github, moved project to https://bitbucket.org/orignal/i2pd/src/master/ and then came back?

[orignal]

@orignal Forking is not hijacking, stop being ridiculous. Also, that commit was EinMByte, who was/is a prominent i2p contributor.

He has never been an i2pd contributor before. Furthermore he has been declined by me explicitly.

Failed to pay whom or for what? I literally have no idea what you're talking about.

Let me refresh your memory. When i2pcpp guy has stopped the project, you start buzzing me and promised to pay on behalf of the Monero. Or you didn't and just wanted to say "hi"? And I have worked on the code for two years and then suddenly decided to abandon it just for you. Don't make people idiots.

I have no control over what he did on a repo that I don't have collaborator privileges on.

Blaming 1M this time? That's how you "had no privelleges". https://github.com/PurpleI2P/i2pd/commit/85b1505e511c3ba9da0cf6e8ab140a1a6a9b46b6

anonimal chose to continue with Kovri regardless of whatever i2pd and Anoncoin were doing, and that was his call.

Answer yes or no if you have shared this info among Monero people. Or I want to ask others if they have ever heard about anci2pd before.

[orignal]

@orignal are you the guy who erased git history https://github.com/monero-project/kovri-docs/blob/master/i18n/en/faq.md#what-were-the-turning-points-that-lead-to-forking-from-i2pd-and-why-are-there-two-i2pd-repositories-one-on-bitbucket-and-one-on-github, moved project to https://bitbucket.org/orignal/i2pd/src/master/ and then came back?

They have erased the history not me. See https://github.com/PurpleI2P/i2pd/tree/cryptopp By moving all files to not show the history before like these files was started from scratch.

I continued on the bitbucket (and I keep maintaining that mirror now) because I was not able to fight with this gang by that time due personal circumstances.

When i2pd got back to github I continued from the original tree to retain the history and moved their stuff to the branch "cryptopp" as evidence of the theft.

[zlatinb]

In a probably futile attempt to get this thread back on topic I'd like to point out that it is a good idea to as a lawyer or Oracle themselves whether the BCL applies to the bundles produced by jlink.

The BCL says the full JRE is subject to export restrictions (Iran, North Korea, etc) but says nothing about jlink.

[knaccc]

Here's a starting point for figuring out license concepts:

Oracle open sourced the JDK under GPLv2 with Classpath Exception. See https://openjdk.java.net/legal/gplv2+ce.html

The classpath exception means that any code that runs inside an OpenJDK JVM is not subject to the GPLv2 and is free to be licensed in any way.

I think the BCL (Binary Code License) that zlatinb is referring to is related to the OracleJDK and not the OpenJDK, as far as I can see.

The OpenJDK is available as packages in most major Linux distributions, so I wonder whether they've already looked into possible export restrictions.

[zlatinb]

@knaccc I think it's simpler than that. How did you find the download links for the different JDKs? Did you have to click "agree" to any license, or was there text that says something along the lines of "By downloading this software you agree to blah blah"? If yes, then whatever license that is (most likely BCL) is what applies.

[knaccc]

@zlatinb If you download the OracleJDK, you have to agree to license conditions before downloading, because that's the Oracle version.

The OpenJDK however does not require agreement before downloading. The links are here: https://jdk.java.net/11/

You can even build the OpenJDK from source, using instructions here: http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html

[zlatinb]

@knaccc fantastic! No export restrictions then. I would have hated to have to configure our download servers to block the people who need i2p most.

[KeeJef]

@x1ddos The PR for IPv6 support is here, will soon be merged once a few things are fixed https://github.com/monero-project/monero/pull/4851

[mikalv]

Meeh here.

After reading this thread, I can't hold back a comment; omfg so much fucking stupid I've read (aggressive posts, claims, etc). But ok, I'll jump over that and keep the topic.

We decided earlier today I'm gonna maintain the I2P-Java's libsam3 from now on. aka libsam3 helpdesk. So this shouldn't be a problem.

[orignal]

@mikalv correct me if I'm wrong. You use new libsam3 in Anoncoin-gost already

[mikalv]

@orignal yes I think you're right

[knaccc]

I've got some updated information about the export restrictions on strong crypto in the JDK. I've been told that If things are hosted in the US, then web sites like https://openjdk.java.net/ will cover themselves legally by asking people not to export downloaded content to certain countries. There is actually a ToU on the US hosted OpenJDK site for example https://openjdk.java.net/legal/tou/terms

For this reason, I've been told about an IBM sponsored JDK binary download site here: https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot

GNU have a FAQ item about this: https://www.gnu.org/licenses/gpl-faq.en.html#ExportWarranties

The bottom line seems to be that since it's GPLv2 software, what counts is that the country you're downloading it from does not enforce export rules. So no US hosting.

[zlatinb]

@knaccc are you sure these export restrictions do not apply only to the unlimited strength JCE? That is a separate download.

Also, it is not clear how much of the crypto gets jlink-ed into the final bundle.

[knaccc]

@knaccc are you sure these export restrictions do not apply only to the unlimited strength JCE? That is a separate download.

In the old days, the unlimited strength crypto policy jar was a separate download. They changed this and unlimited strength is now the default. Either way, it's all GPLv2 now.

[zlatinb]

@knaccc two small things:

• 0.9.38 is done and tagged
• if you set LG2=en before invoking ant, it will skip the translations and build much faster

[knaccc]

@zlatinb thanks, done and pushed

[knaccc]

@jtgrassie Has discovered https://jdk.java.net/jpackage/ https://openjdk.java.net/jeps/343 which will build self-contained msi/exe/deb/rpm/dmg/app files. This is currently scheduled to be available in OpenJDK 13, due for release in September 2019.

[knaccc]

I2P-zero GUI just released. Screenshots at the top of the README here:

https://github.com/knaccc/i2p-zero/blob/master/README.md

[lessless]

Fantastic job!

[zlatinb]

@knaccc I did some experimenting with different compression schemes and managed to get all of I2P + a windows JRE (with full I2P dependencies, not just those used by zero) down to 32MB. To get there, I disabled compression in jlink and in all I2P jars, then compressed the final bundle with lzma.

[moneromooo-monero]

Is this still relevant ? I think the GUI uses i2p0 now ?

[selsta]

I think the GUI uses i2p0 now ?

GUI is working on I2P-zero support. I think this can be closed.

[moneromooo-monero]

Alright, please reopen if this gets new life as an alternative.

+invalid