They know if they are a party to one of the transactions. They can look at linkages between the transaction they know about and others. For example, if you run a business, your landlord or other vendors can look at the source of the funds you use to pay them. Likewise your customers can see where the coins they are sending you are going. They can also often (if not always) find other customer payments to you, since those payments will often be aggregated to make payments to vendors, salaries, etc., again establishing linkages.

Much has been written about blockchain analysis. It is not as trivial as you suggest.


Changing addresses does not help you because transactions are linked, publicly, on the block chain. If you want to break those links you need some kind of mixing, coin exchange, zero-knowledge proofs, etc. which brings us right back to the realm of "anonymous" technologies.

If it is a full client (and in practice many altcoins rely on full clients at least early on), then the difference is not so great because new users will need to download a block chain as well. That plus the software itself will rapidly eclipse 72 MB.

Now, maybe 1 GB is a lot (that might be years of blockchain on a lightly-used coin), but something more than 72 MB can certainly work.

Nope. Only your wallet can see it.

Neither the block explorer nor anyone else can see your transfers or balance given the address (public key).

There is something called a "View Key" (provided to you when you created your wallet) that can be used to view your incoming transfers but I don't think any of the block explorers have support for it yet.

I think he was talking about Bitmark. Is that an appcoin? As far as I can tell it was just trying to be a regular coin, but I couldn't be sure.

If you assume the ability to actually exhaust the key space (as in cosmological time scales), then sure, you (very) slightly improve your situation by creating a new key.

But if you are talking about someone taking shots in the dark at your key and hoping to get lucky (which is all that can be done in practice if the keys are drawn from the entire key space), moving it doesn't help you. It is just a likely that you move right into the path of the bullet than move out of the path.

If the threat is brute forcing a private key this is not correct. A "moving target" is exactly as easy to hit as a stationary one. You likely increase your exposure to other threats such as malware by moving the coins around. Keeping them untouched in cold storage is safer.

Not necessarily. The task of assembling them into an attack is still a significant investment. And once that is done you face the question of whether it is more profitable to mine or attack. Empirically it seems the incentives are usually to mine, with a few (so far) outlier exceptions (low-usage coins with large rapid drops in hash rate).

You mentioned Google or NSA, but both Google and NSA have those computers for a reason, so presumably they are already doing something. If you want to take those computers and use them to attack a coin, that has a significant opportunity cost. And even at that, Google still isn't that big. XMR is reasonably close (1-2 orders of magnitude) to exceeding Google's rumored entire 1m computer capacity (meaning you would have to shut down Google to pull off the attack -- good luck with that plan), and XMR is still a tiny coin.

I think you underestimate the task of building a large attack. By contrast, any subset of these computers can just go ahead and mine instead

I don't think you can trust the ASICs in the way you suggest. The ones already delivered and paid for in the hands of customers, perhaps. But chip production costs are usually quite low, especially for mature processes with high yield. Manufacturers constrain their production volume in order to achieve a high selling price (or if they are mining themselves, to maximize profitability by not driving up difficulty) and recoup NRE.

But consider the same economics from the point of view of a rogue ASIC-developer. He can run off 10x or 100x as many ASICs at only modestly increased cost, and then use them to attack the network instead of for mining.

The only real protection from this risk seems to be that it is usually more profitable to mine than attack.

That applies equally to ASICs, CPUs, and GPUs. We have seen enormous numbers of CPUs from AWS, etc. come online in a very short period of time on this coin and others. GPUs likewise move around constantly between different coins in order to mine them. This is easy to do when the mining profitability is there. But we rarely see actual attacks, and never on coins with a real level of success. It seems the incentives to attack are much smaller than the incentive to take that same resource and just mine with it. Otherwise, with how easy it already is to move CPUs and GPUs around, we would see attacks constantly.

Satoshi said something along these lines in his paper. It likely assumes some level of actual success by the coin (so the mined coins are worth enough, otherwise you will get nuisence attacks, even if they aren't economically motivated), and it assumes a rational mining emissions. If there are no (or nearly no) mining rewards, you might as well attack.

Lock maybe. Delete no. The event happened. It is puzzling and not fully explained, but it shouldn't covered up in any case.

Yes, I'm well aware.

My point is, launch it in a coin and have the coin not get attacked, suffer from extreme instamine-type issues with optimized miners, get built into ASICs, etc. If if you don't want to launch an actual coin, raise a substantial bounty for a successful attack on the algorithm directly (and then have the bounty go unclaimed for some significant period of time). There was a thread a while back where dga talked specifically about cuckoo and explained some of the issues in broad terms.

Those same issues applied equally to Cryptonight when it surfaced, although now at least we have some (limited) track record with it.

I disagree.

At worst (if no one ever claims), you have a typical non-premined launch where the outstanding coins start at zero and all the coins come from mining. There will still be a large number coins created quickly in mining, which will be available for use on the network. If there is a shortage of coins, the value will increase, likely spurring more claims.

Mining inflation, as with any coin without a huge premine, is self correcting. At the very start it is enormous (the second block has 100% inflation per-block!), but as the number of coins outstanding increases, the inflation rate naturally falls rapidly.

In reality, the spun off coins already exist at genesis. Whether people claim them or not doesn't matter. People who don't claim are just keeping their coins in cold storage. So the correct base to use in measuring inflation includes the spun-off coins.

TLDR: It is fine to use the same mining rewards. In fact if you don't then the experiment fails to demonstrate anything because you have changed something else besides the initial distribution.

Not true, you have revealed to Alice where your coins came from. If Alice gets coins from multiple customers that share some common history she can link the sources of those coins. In fact a third party can also start to make those links, though individual identities won't be known. However, if some identities are discovered later, that information can then be used to make links with other transactions.

If you are assuming that Alice can't tell where the coins come from without mixing because they are pre-anonymized (mixed), then you haven't really accomplished anything. You still need a mix in between each change of ownership.

Also, once you send the coins to Alice, you can trace what Alice does with them, unless there is mixing. Again, you need a mixing on every change of ownership.

The way real progress happens is someone goes and demonstrates this.

I don't have real numbers of course but I'm guessing that both are a tiny fraction of the CPU cycles available to end users. At one point a number of one million computers was circulated for google. The PC installed base is around a billion.

This is not true for ASICs. Big farms have routinely had double digit percentages of the total SHA hash rate.

There is no official "promise" from the development team on this, but personally I expect the on disk storage to eventually end up a lot closer to what is reported by monerochain.info, which means less than half of these numbers. Currently a lot of data is being stored multiple times on disk. Being smarter about how to do that should help a lot.

But first we need to get the database interface completed and a reference database integrated (see latest Missives for status). Then people can optimize.

I do not believe an official position has been stated on that issue specifically.

Early on there was a statement that we would not change the algorithm and would let the chips fall where they may, but I believe the context of that was GPUs (and at the time the reasonable expectation was that this would turn out to be like most other claimed "GPU-resistant" algorithms and would quickly turn out not to be). Since that time we have seen the Cryptonote claims of GPU-resistance (perhaps surprisingly) hold up reasonably well. When it comes to ASICs I don't know what will happen either way.

The algorithm has little value as a general purpose hashing tool. It is purpose built for proof-of-work.  

The design is heavily influenced by the desire to resist attempts to massively accelerate it on GPUs or ASICs, or to put it another way, to ensure that similar-cost devices will perform similarly, at least for some period of time.

So far this objective has been largely achieved with GPUs. GPU miners don't outperform CPUs that much on a hash/$ metric and don't outperform them at all on a hash/W metric. It remains to be seen how well it does with ASICs.

Your point about testing and rigor is valid. It is possible to surmise that with some level of obvious competence having gone into the design, there may have been significant testing, analysis, and scrutiny. Or there may not. Since it is all shrouded in secrecy, we just don't know.

The context was various areas of development that are being done via an open process with progress visible in github. How that turned into a discussion of which coins have or need QoS I have no idea.

BTW, here is an open issue for Bitcoin from 2011. This is not a new issue at all. In practice most people end up working around the missing feature by programming it into their router or OS network layer.

https://github.com/bitcoin/bitcoin/issues/273

That was a bit meandering but I'm wondering what is your specific objection to crediting the source of patches you use.

There has been no collection done for this bounty. Everything so far has been done by pledges on the honor system, with payments directly to the eventual winner.