His point was that BBR would benefit from a QoS (or "network I/O scheduling" to be more precise) too. I don't really think it is a particularly interesting point since it applies every coin.

Which of course includes Monero. It does't have a QoS now, and is up and running.

You are welcome to participate in this thread at any time as long as it is focused on topics directly relevant to Monero. (You are also welcome to not participate, if that is your choice, of course.)

That includes the proof-of-work. If you can identify a specific vulnerability, post a proof of concept (even pseudo code). Voluminous abstract philosophical discussions of proof-of-work design are not directly relevant to Monero.

If you want to call that censorship, so be it. I'd rather be accused of censorship than have the thread filled with pages and pages of discussion not of interest to most of the Monero user community.

And for one last time, I never said that ASICs aren't a threat. I said that the approach of "1000 copies" of a straightforward implementation of the algorithm on a chip will not work. The Cryptonote people claim that the algorithm is ASIC-resistant generally. They may be right or they may be wrong, but I certainly will never mislead anyone that this is just a claim from some anonymous source. I don't know what background work they have done (if any) to support the ASIC-resistant claim, so I can't meaningfully evaluate it.

Some degree of GPU-resistance has been demonstrated however, so one of their claims has now been weakly validated.

In fact he said "longer to validate" not "longer to propagate." That is good because the former is not a Monero-specific issue at all so it doesn't belong on this thread.

BTW, if you "don't know if ... Monero  has implemented" something, please don't bring it up here (except, perhaps, once to ask if Monero has implemented it, if you are unable to determine that yourself by consulting the source code). This is not a thread for general discussion of coin design topics that apply to virtually every coin.

Let's exclude coins that have virtually no usage. They essentially exist only on exchanges as speculative pump-and-dump vehicles.

When it comes to the small subset of coins that actually have users, they do run into this. I think we can agree that not having any users/usage is not a good way to address the problem.

The XMR blockchain size is not extraordinary as popular coins go, especially extrapolated forward. The DOGE blockchain, for example, is around 6 GB (I'm not sure if that is the on-disk size or the raw block size, but I suspect the latter, meaning the corresponding XMR size today would be about 800 MB). If you download that or more importantly upload it to other users who are downloading it, you will have major bandwidth issues.

It is a frequent issue for Bitcoin for that matter: http://www.google.com/#q=bitcoin+qos+site:bitcointalk.org

Another approach is for pools to limit the number (per time interval) of new addresses from which they will accept connections (and/or shares or blocks) at all. A DDOS as you described would lock out new users until countermeasures were deployed but existing users and the existing network would be unaffected.

I don't really know what vaporware means in the context of an open process where the coding work is transparent.

Certainly when a vendor claims something to be delivered "later" and the work is entirely opaque (meaning it is impossible to independently assess when if ever the delivery will occur) that can be described as vaporware.

It is not a delivered feature, on that much we agree.


No the QoS system is needed to deal with any size blockchain if people are using residential or other limited-bandwitch connections they don't want oversaturated, even temporarily.

I made several loans last year and earlier this year. I have also worked on other loan proposals, including some bigger ones, that didn't happen for various reasons but those reasons did not include the need for appropriate overcollateralization.

The fact is that legitimate uses for lending in a online nearly-trustless environment are very limited, but they do exist. Scams and attempted scams outnumber the legitimate loans, that is for sure.

Actually as far as I can tell, they delivered what you claim you were attempting to design. You have delivered no work product at all. No code. No white papers. Nothing. Except maybe delivered to yourself, which does not count. It is all hot air.

At this point I would ask that you take this discussion elsewhere. There may well be (theoretical, unidentified and undemonstrated) cryptographic or other issues with Cryptonight, but that is a tiny subset of topics of general interest to the user base and potential user base of Monero. Now we have the past several pages of this thread being taken over by the discussion, and the way the last few exchanges have gone, every appearance this back-and-forth will continue for several more pages. That is inappropriate. Please stop, or just go ahead and create your own thread focused on that particular subtopic.

Your post makes some good points and these issues are definitely being looked it. There is wide agreement that the one minute block time was a mistake absent other changes in the design of the block chain (such as GHOST or similar ideas).

One minor technical correction though:


As things stand today larger blocks don't take much longer to validate. The PoW hash is performed not directly on the entire block but on a much faster hash of the block, so it is essentially independent of the block size. The transactions within a block also need to be validated, but currently that is much faster than the PoW. That could change if database lookups are required. Note that if the dominant portion of block validation time is database lookups, then the speed of the PoW becomes unimportant to validation speed.

Reasonably good info here: http://security.stackexchange.com/questions/8048/why-aes-is-not-used-for-secure-hashing-instead-of-sha-x

Okay, I see we've found the "mindless slobbering." Thanks for your valuable contribution here.

Get real. People pump constantly in trollboxes. It is pretty much the only thing trollboxes have ever been used for.

The reason people pump XMR in the Poloniex troll box is simply that XMR is the most traded coin on Poloniex. It has nothing to do with the coin itself. When the most traded coin was DRK or something else, people pumped that. When the day comes that XMR is replaced as the most traded coin, the pumpers and trolls in the trollbox will move on to that coin as well.

"master" != "open source"

As I said it is ongoing open source work. The link to track has been posted on this forum.

This isn't meant to say that BBR changes are not worthwhile, but in reality if the size reduction is only 50% that is a small reduction.

Disk sizes are routinely measured in terabytes. Even SSDs are reaching the terabyte range now. Blockchain sizes for any of these coins are measured in the gigabytes or tens of gigabytes at most. On another thread someone estimated a CN blockchain with transaction volume comparable to bitcoin at around 60 GB in a few years. Obviously these estimates are highly innaccurate, but that isn't really the point. By the time this happens disk sizes will likely be measured in tens of terabytes. Whether the blockchain size turns out to be 30 GB (1/2) or 120 GB (2x) really makes very little difference.

I note in fairness that you did say at least 50%. If it turns out to be 90% or more, then perhaps you are on to something. But at 50% it is hard to see why anyone would care much.

Yes, I'm part of the XMR team so I have an an agenda here, as do you. However, others with no apparent agenda have made the same point, including I think dga who is now a visible BBR supporter.

It has been open source the whole time. The ongoing work can be tracked on github.

64 bit OS with 4 GB should be sufficient. The block chain is currently about 1.8 GB on disk and is growing at about 10 MB per day.

Obviously a faster CPU will allow you to sync up faster, load the wallet faster, etc. But anything with a 64 bit OS should work.

As for download, installation instructions, etc., be sure to use only resources linked from the original post on the official Monero thread. https://bitcointalk.org/index.php?topic=583449.0

If you are buying a second hand laptop, make sure it is completely wiped, has a clean install, and is well maintained with security patches, AV, firewall, etc. Malware is always a risk with wallets.

EDIT: added to OP

That all sounds very idealistic.

And, yet, you will be contributing to exactly this dynamic once you release your delayed open source.

Simple answer. The decision was not made by us.

Monero was launched as a clone of Bytecoin to address the massive premine/ninjamine. It was felt at the time that the best approach was to simply keep more or less everything from Bytecoin the same except the rate of mining and offering a clean pre-announced launch with no premine. This gave the community an easy choice between them, while making a whole bunch of other changes would have significantly muddied the waters.

Cryptonote, who claims to be the developers of the technology behind Bytecoin, has its own theories about how their algorithm is ASIC- and GPU-resistant, and how this leads to mining being what they call "egalitarian" and how in turn that is some sort of overall advantage (though they don't quite explain this).

Without commenting on their philosophy (in large part because I don't understand it), I will say that the PoW has proven to be a least somewhat GPU-resistant. Despite several GPU miners being developed, none has clearly demonstrated a major efficiency gain (in fact I'm not sure any of them have demonstrated any gain in hash/watt over CPU mining). People do mine with GPUs now, but people also still mine competitively with CPUs.

There is no reason for the community to support such a fork, as described. It is just an imitation with some obvious scammer behind it, while the brand value of the original developer will be vastly stronger. Such as fork will go nowhere, and as explained above will serve as a test, which once passed, will make the original stronger.

If there are other differences, then in that case, the community might just have a reason.