fluffypony wrote:
Yes - I have several projects up my sleeve that I'm working on. Almost all of them are services for both Monero and Bitcoin, as I don't believe that Bitcoin must fail for Monero to succeed (quite the opposite). A few of these projects are finally nearing completion, so hopefully there will be a few more product launches in the next couple of months!

fluffypony wrote:

The issue wasn't if I2P in general was stable, the Java router is definitely stable enough. The issue was that we didn't want to add Java as a dependency for running Monero, so our focus has been on a C++ implementation of the I2P router. Expect a big announcement on this in the next couple of weeks 

fluffypony wrote:

Whilst not wanting to turn this into a this-currency-vs-that-currency debate, I will answer this, as I think it's important to understand the proverbial lay of the land.

Designing a cryptographically sound solution to a privacy problem is seriously difficult. As Greg Maxwell puts it, "information wants to be free", and the weakness will always be the human element. The more heavily reliant your scheme is on the opsec of participants, the more prone to leaks it will be. Coupled with this is the problem of "thinking adversarially", which is something that goes deeply against our human nature. To illustrate how flawed our human reasoning is when we try to think adversarially: if a Bitcoin node can only connect to 8 peers, how many of those have to be honest for the node to determine which ones are dishonest? As a human you might reason "well, if 4 are honest, and 4 are dishonest but telling the same lie, it can't tell which is honest, so the answer has to be 5". Or maybe you'd reason that dishonest peers will mostly be telling different lies, so if eat least 2 agree then they must be the honest ones...right? The actual answer is 1. It only needs 1 honest peer to be able to determine that the rest are dishonest. This is because it follows the "longest chain with valid PoW" rule, and can rule out all other nodes as offering dishonest chains. Now knowing that most of us are so incapable of designing such an elegant solution, and our minds resort to broken and hacky things like "voting", we should immediately be suspicious of any and all new systems and schemes. This is especially true where they are promising something as sensitive as privacy, and where there is money to be made (pretty much unique to altcoins, no new open-source reverse proxy or database or other project has the potential to make money for its creator).

Dash fails because, as djb describes in this excellent recent article, they have an "attacker economist" approach.

In other words, instead of purposely designing their systems to be cryptographically sound so that the "attacker will definitely fail" or the "attacker will probably fail", they instead (unwittingly?) design it so that "the attacker's expected cost of carrying out an attack exceeds the attacker's expected benefit from doing so." The unfortunate knock-on effect is that such an approach only works like that for a limited time...as the value of the cryptocurrency grows, so does the level of sophistication of the attackers that find it an interesting target. Trying to solve the privacy problems in a way that relies on the honesty and opsec of a small group of individuals is simply privacy theatre, no different from those that claim that Bitcoin is private as long as there's no address reuse.

On the other end of the scale is ZeroCoin, which is about as sophisticated as you can get, and in my opinion represents the future of cryptocurrency systems. In fact, it's sophistication is also its largest problem: the cryptography behind it needs a significant amount of peer review, and and implementation needs a significant amount of vetting, else you may end up with an exploitable bug where someone can double spend, or create a large number of coins, and nobody will be able to see it. In my mind I would need to give it 20-30 years before I could trust it with my livelihood.

The only trade-off is that it will be possible to tell the coins went through a mixer at one point in time. Works for me.
Monero can't compete with ETH, I'm not sure bitcoin can either.

New git updates since last time:

- blockchain_export can now create files compatible with NoodleDoodle's fast sync code
- speedup for the one-time database rescan to initialize hard fork into
- database dump utility, intended to detect differences between the several blockchain formats
- a new status command in the daemon, giving more user oriented information
- and random other fixes for DB potential issues, some RPC commands not working properly

Will there still be a minimum mixin number in the new release?

I like the idea of a minimum mixin but what impacts if any will this have on pools and or exchanges that must deal with dust transactions?