I see. After a lot of posts that debunked allegations in the orignal thread, they moved it to a place without comment.

Their campaign is very interesting to watch.

Obviously, the CSS has been changed to no longer reflect the original findings. There is no reason such a change would not be made.

Checking website contents or adding new website as proof for something, in such a way that it cannot be verified with archive.org, after the time of this reveal does not prove anything, because websites are easily created, modified and timestamps are trivial to falsify.

As we are all here for the purpose of reasonable discourse, I hope for your understanding and hope that no more of this type of unreliable evidence is posted.

The anonymity features of Monero work. You cannot just look up all transactions to and from an address.

But do BCN devs not also refer to the CN website? It would be strange for damaging material to be posted in that place.

Since some time has passed since the publication of the original analysis in this thread, the possibility of a "corrected" backdated whitepaper being posted on one or both of these sites should not be discounted.

This is very funny. Nobody is making racist claims. It is just that bad English is an easily identified trait that can be found in many of these specific shill posts.

Even more funny is that I have seen before those shill accounts making claims of racism when this property of their posts was pointed out in different places at similar times.

To make a point, my English is less than perfect, but I have not been accused of being a "FUDster troll" up until now.

It is fascinating to see all these puzzle pieces laid out so clearly. You did good detective work.

I have sent 2 XMR.

4cbda4a2a1323f41b8ffd8f6efe6b98c0c0b7e7ab200e8fb56c8624427f74ba2

So BCN devs could have mined Monero faster. But BCN devs do not appear to care for Monero. Do you have anything that strongly indicates BCN devs mined Monero back then?

If somebody who was not involved in the creation of the hash function optimized it, the fact that it was intentionally crippled instead of accidentally crippled does not matter for fairness.

You can build what is basically mesh network with fixed capacity connections upon which you run the mix network. Whenever you open a connection to another peer in the network, you keep open the connection and both sides keep sending packets at the agreed upon rate while tunneling their actual communication through this constant stream. Packets are routed through this network to the target peers chosen for the onion routing route for the given packet.

I see that this design is probably more than can be easily implemented on top of I2P if it was desirable at all.

It occurs to me that this discussion is probably off topic here.

My idea is that the cover traffic channels would be the outermost layer for communication between nodes participating in the mix network. You perform routing and onion routing through these channels.

Following the above, if an attacker controls all nodes to which you connect, the attacker can tell what part of the traffic is cover traffic.

If you find a way to switch around the order of layers, this can possibly be avoided. However, as you noted, doing cover traffic inside the onion routing network would be difficult.

I see this point.

If your threat model includes the attacker looking at clear traffic on both sides, you have lost anyway, because the attacker can already read the transactions senders send and know who the senders are. Otherwise, the attacker cannot tell the way the packet looked when the sender sent it, because from the side of the sender the attacker only sees say 100 packets per second of constant size sent to 16 different nodes each, which also behave this way.

Please understand that this proposal is intended to counteract opaque timing attacks only, not sybil attacks.

I entreat you to stop mentioning Tor. It is a different system than I2P, which is being implemented.

It is still a haystack, just of different size. It is still better than nothing at all. A hypothetical attacker with infinite budget cannot be defeated. We can model an attacker with specific capabilities and attempt to design system which defeats the attacker with a given probability. We do not actually disagree on this?

Can you please explain this in more detail? Neither are there exit nodes, nor are transactions sent directly to miners. Transactions are broadcast through the whole network. How do known miners make it easier to perform traffic analysis in a cover traffic scenario?

I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

Again: There are no exit nodes with I2P. This is also not possible with fixed bandwidth cover traffic channels.

Sybil attacks are very hard to defend against if your attacker can replace your internet connection with connection to NSA LAN instead. Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.

I believe Tor and I2P should not be conflated. Timing attacks are more difficult against I2P. With Tor, you have exit nodes which make it easy to see one of the endpoints for the purpose of correlation. It can still be done without visible exits, but this is a bit harder.

There has been some talk about introducing random delays to harden the mix network layer. Since that has various drawbacks, how about adding cover traffic instead? It is wasteful but should still allow low enough latencies while mitigating timing analysis. This is another thing that would not work well with an exit node based system.

That is better than nothing, but having only such a short part of the whole thing makes it hard to reason about with the bigger picture in mind. If there was the usual diff header, it would be a bit easier. Considering that it is also outdated already, I do not feel like investing time into figuring how it works. I hope you understand.


Please see: Kerckhoffs's principle

Cryptographic contests and bounties where the systems inner working are not published, are generally not accepted among cryptographers.

While Kerckhoffs's principle mainly applies to cryptographic systems, following Shannon's maxim, I believe it should be applied analogously to anonymity systems. If the way the system works is opaque, you cannot reason well about its security.


This is a very strange claim. CoinJoin was originally designed to be decentralized and trustless. To me, it sounds more like you have implemented CoinJoin the way it was originally supposed to be built.


Let us hope for their sake that nobody hex edits name and certain other things in the binary to launch a clone coin. :-)

I have tried looking at the source code (https://github.com/atcsecure/X11COIN.git) and could not see anything related to anon tech. There is also only a single commit, so maybe this is the wrong place. Do you know where I can find the current code?

If there is no code available, I propose:

3) No code available, so nobody with a mind will care about the coin and no analysis will be done.

To explain: Binary analysis is bothersome work to perform. I do not see a way of profiting by doing this work, so it is unlikely to be done. Without source, it is impossible to trust the coin or developer.

Good morning.

I have found this point impossible to ignore. You are misrepresenting the argument.

Sybil attacks can be used against IP anonymization layer such as I2P.

I assume you have made this mix-up, because these systems are called mix network. It sounds similar to the mixin parameter of Monero.

To compromise ring signatures with such an attack, an attacker needs to serve you a completely changed block chain that contains only their own signatures.

If an attacker can do this, you have lost and it does not matter what coin you are using.