Monero is such a "dark blockchain". Without an esoteric attack to compromise your keys your balance and transactions is unknown and unknowable. You can't formulate a "rich list", because you can't see the balances of any single address.

If you delete the wallet.bin (NOT the .bin.keys file) and re-open the wallet it'll re-scan the blockchain and rebuild the cache, and that failed transfer will be available again. Incidentally, it didn't fail because of not including the payment ID - are you sure you're using a current version of Monero, downloaded from the links in the OP of this thread? Transfers can fail to be mined by the network if, for instance, the incorrect fee is attached to it (which would happen with a very old or incorrect version of the wallet software).

The adaptive parameters are discussed in the CryptoNote whitepaper - a good starting point is our annotated version of the whitepaper (the annotations are raw, so just ignore the occasional piece of snark;) that you can grab here: http://monero.cc/downloads/whitepaper_annotated.pdf - a lot of it is around hard-coded constraints in Bitcoin and Bitcoin clones that are adaptive or flexible in Monero.

One of the key features that makes privacy inherent in Monero is, as you pointed out, stealth addresses. You only have one "address", which is not an address in the Bitcoin sense of the term, and when funds are sent to it the address is unpacked and the resulting key combined with random data to compute the destination for a particular output. This means that it's impossible to inspect the blockchain and find someone's balance, and if your address is leaked there's ostensibly no way for blockchain analysis to confirm whether or not you received funds to that address.

Of course, there are esoteric attacks that could reveal information about a sender or recipient, which is why ring signatures provide an additional layer of ambiguity. Basically, with ring signatures a transaction output is signed by you and by a group of random signatories (garnered from the utxoset, and the number of signatures is specified by you). Only one of these signatures is "true" (and that can be determined by the recipient), but to an outside observer they cannot determine which of the N signatures on an output is true, as they all appear to be valid.

Additional edge cases can and do exist that may "deanonymise" a group of signatures, but they are such extreme edge cases that they are not going to be a concern except where a sufficiently advanced and powerful attacker exists (and in that case they'd probably just beat you with a pipe wrench till they get your privkey and can access everything anyway). There have been suggestions such as enforcing a minimum mixin, and there's an interesting discussion on the pitfalls of such a system on the CryptoNote forum if you're interested. Ultimately there are many, many things outside of Monero's control that are more likely to unmask someone, such as them being caught physically receiving a marked package at the post office, but for the purposes of most transactions Monero provides a 100% working system in which transactions are cryptographically unlinkable and untraceable.

Spot on. The design is not and has never been an issue, and everyone who has offered assistance has wanted to offer design assistance. That is the (relatively) trivial part. The thing that is taking time is getting the content right. I cannot begin to tell you the amount of time spent slaving over a turn of phrase and its implications. Nothing is perfect, and everything will change and iterate, but we want to things to be good from the outset and not have to spend inordinate amounts of time redoing it later. It's bad enough that we have to refactor a metric ton of CryptoNote reference code as we go;)

I haven't dug into the Trezor internals, but I'd guess that it would need a Trezor of its own to work. I'm unsure as to whether or not the hardware is general purpose enough to handle the ring signature stuff. It's definitely something to consider, but then again once there is demand and utility you may find a completely different crowd up and beats Trezor at their own game, you know how these things go:)

It's well known that Monero (the largest CryptoNote-based coin) provides cryptographically unlinkable and untraceable transactions, a trait it shares with all of the CryptoNote-based coins.

One of the points that is often not mentioned with the Bitcoin-forked altcoins that claim anonymous transactions is that you have to give out your recipient address to receive coins. The process in-between may protect the sender, but if the receiver's address is found (eg. mentioned on a forum or on IRC once) the receiver is at-risk, since it can be seen that they received a transaction of a certain amount.

I fully agree with you - the Getting Started thing was a stop-gap that David threw together when we moved from the old Wordpress site to a static HTML dump because the site was getting hammered. We've been chasing our tails to deal with stuff like that whilst get everything else done in parallel, but we are getting there:)

We've rejected the notion of bounties for two reasons:

1. The amount contributed is rarely - if ever - close to a level of compensation a REALLY competent developer (or even a development team) expects. Very occasionally this is mitigated by someone who is willing to take a huge hit based on the potential future value of the bounty.

2. More often than not, it becomes a race to the bottom. A competent developer will spend a lot of time discussing, architecting, scoping, and planning before writing a single line of code. A bounty encourages a writing-code-so-that-it-kinda-works style of development. In the end, we are left with poorly thought out code that we have to maintain.

This week's hasn't been released yet - we're busy working on it at the moment:)

Really? Your twelve year old niece could prepare guides for every platform on how to install and use Monero, replete with screenshots, in the midst of moving goalposts? Your twelve year old niece could prepare technical reference material for developers that want to use Monero in backend systems? Your twelve year old niece sounds incredible - please put her in touch with us and we will pay her for the couple of hours she has to spend putting this together.

I lol'd

We are working on a replacement site. Throwing a $20 template up is not a solution, as the visual aspect of the site is much less of a concern than getting the content right. There are so many things on the current site (from an information perspective) that is either downright outdated or needs serious reworking.

It's for ISO 4217 compliance: http://en.wikipedia.org/wiki/ISO_4217#X_currencies

Bitcoin is officially XBT for the same reason: http://www.xe.com/currency/xbt-bitcoin

This is just my opinion, but CoinDesk isn't a terribly credible source for any news. Their relationship with the Bitcoin Foundation and other businesses has been called into question on more than one occasion.

That having been said, I'm not sure if we want a ton of press coverage for Monero just yet. It's still in its infancy, and there is a lot of work to be done before we can provide utility and ease of use. The press coverage will come:)

A truly anonymous coin would reveal no address balances on the blockchain. Simple as that. If knowing your WhateverCoin address means I know your balance, that already reduces your privacy.

Also, anything that involves swapping makes it really easy to reduce the anonymity set. If I send 1.3145 WhateverCoins and within the space of a couple of minutes an address receives 1.3145 WhateverCoins, then it's a pretty reasonable assumption that those two are related. The only way you prevent this is by making it impossible to determine address balances from the blockchain alone.

I've personally transferred 40 000 XMR in a single transaction when escrowing a trade for someone. The dust payout issue hasn't happened for a while, not since zone117x fixed his pool software to stop paying dust. Consolidating dust is annoying, but doable, and there shouldn't be dust payouts to miners at all in the future. To try and ease the effort required to consolidate dust, the wallet will try and automatically large amount split transactions over as many as 30 transactions (this is not in the binaries, but has been in the main github repo for a month or so, and will be in the next tagged release).

This is the most bizarre string of newbie accounts and postings I've ever seen. Is someone trying to set Monero up for a shill accusation?

BCX is BitcoinExpress, not the Monero ticker symbol:) It's still XMR.

Whilst I appreciate the effort, hosting an XMR blockchain is not entirely necessary and may present a security risk. We do host the blockchain on our metal, and we superpeer with about 200 other nodes (including all the pools that have their daemon accessible) to ensure we're part of the general network consensus. Links are in the Monero OP and are always live to within a couple of hours.

• http://monero.cc/downloads/blockchain/win/blockchain.bin / Windows 64-bit blockchain (place it in %AppData%/bitmonero)
• http://monero.cc/downloads/blockchain/mac/blockchain.bin / OS X 64-bit blockchain (place it in ~/.bitmonero)
• http://monero.cc/downloads/blockchain/linux/blockchain.bin / Linux 64-bit blockchain (place it in ~/.bitmonero)

I think that we will definitely see the rise of a handful of cryptocurrencies fit for various purposes. Remember: even in the existence of a global economy, that wouldn't mean that in-game currencies such as those used in WoW or EVE are now redundant and every in-game currency is going to be Bitcoin (or whatever). Similarly, purely on a currency level, altcoins can be used for loyalty point systems. So I don't think we'll see the level of idiotic scammy altcoins we see today once the big shake out has happened in a few years, but that doesn't mean that altcoins will be completely non-existent:)

Same here - when I managed to get the blockchain downloaded and solo mining to work April 27th or so (10 days after launch) I told othe I mined 17 XMR in 9 hours on a Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz. At the time the daemon could do around 10h/s - 11h/s on that Xeon and about 33h/s on an Amazon c3.8xlarge slice, and net hash was around 7000h/s. To put that in real numbers, you'd have needed like 212 of those c3.8xlarge slices to control the entire network. If memory serves, you can fire 50 of them up with the standard EC2 account restrictions (5 in each zone). So I see no evidence of early botnet mining, and this was 10 days after launch.