I see the bizarre newbie shill accounts are trying this "Monero is the best!" thing again. No clue why.

Once we've tightened the nuts and bolts on the interface (a few more weeks, donations dependent) we'll push the interface up to a project of its own on github so we can better manage all the translation efforts. Tangentially and simultaneously, the integration with Monero will start. Given the complexity of all of this, we may find that the interface is ready, the translations are ready, and the integration drags a little, but since the integration efforts there will be an ongoing and continuous it will be able to be tested by everyone. Eventually when things are more broadly tested, all features are done, and it is ready for prime time, we will have an official launch (totally with a launch party;)

Good stuff - I'll bounce this around and a bit with the UI designers. If for whatever reason we forget about it, then wait till the interface code is up on github and you'll be able to open an issue for this. The text is also very much "up for grabs" at this stage, we've been design focused and haven't touched the wording on anything besides the wallet -> account thing (which has a wider impact).

It will have complete granularity in integer steps up to a realistic top-end (no clue what, let's call it a mixin of 100 for argument's sake). If for any reason someone needs to use a mixin level beyond that top end they would have to create a manual tx or use the CLI / RPC tools. We want to provide a reasonable scope, but we also can't cater for edge cases. If it so happens in future that large block sizes are common, large tx sizes are common, blah blah, then increasing this top end is a trivial exercise that a power user can do in the source and compile on their own without even waiting for us to make the change:)

That's in the works - we've just been debating it peripherally (for 2 weeks) so we get how it displays correct. For the most part, even a power user may not care about the actual value after a while, so we don't want the numerical amount to be too obtrusive (or too hidden;)

There will be a flag you set when going through the first-start wizard that will allow you to suppress non-P2P connections. There are consequences to this (eg. DNS seed nodes cannot be used because DNS traffic != P2P traffic, the blockchain bootstrap can't be auto-downloaded, the Twitter and news feeds can't update, the tutorial videos are not available, and so on), but this is a "paranoid mode" that some may choose to turn on.

One of the things we've spent an inordinate amount of time is abstracting stuff away from simplewallet. This has resulted in us being able to build rpcwallet, which takes the rpc guts out of simplewallet and gives it a much more robust frame for automated environments.

The GUI will use the same libraries the daemon does, so it will provide the same underlying functionality without the need for a second instance of the daemon to run. This is NOT the right solution for mobile devices or even very low power devices. That said, the fundamentals that we're abstracting and working on now will allow a rich variety of interfaces to exist, all inheriting and using the same functionality without worrying about underlying application logic changes.

It's the MiniWindow - I showed it off in the Fireside Chat. There's an icon at the top left when the window-bar slides down that lets you switch between the regular interface and the MiniWindow.

You can just create a random one yourself - it's 64 hex characters:)

That's true, although my idea was a little half-baked and not entirely thought through;) It still doesn't solve the problem of masternode operators being willing to attack each other to boost their own profits, though, and it doesn't give you any insight as to whether a masternode has been hacked and is being maliciously controlled. If they're hell-bent on using externally observable transaction mixing / coinjoin-style mixing, then the real solution is for every node to be involved in mixing (as with i2p or BitMessage, for instance), and for there to be no financial incentive to mix and no ability to disable it. That's the only way you avoid Sybil attacks and remove the risk of masternodes destroying each other. Then you'd need to add stealth addresses where output destinations are computed with random data, and hard fork so that any tx that has non-stealth outputs is rejected.

My suggestion is as follows:

1. Take any machine you have lying around, even your normal workstation. You may find it easier to use an older computer that has no wifi or bluetooth if you're particularly paranoid.
2. Create a Linux or Windows bootable disk, and make sure you have the Monero binaries on the same disk or on a second disk (for Linux make sure you have also downloaded copies of the dependencies you will need, libboost1.55 and miniupnpc for instance).
3. Disconnect the network and/or Internet cables from your machine, physically remove the wifi card or switch the wifi/bluetooth off on a laptop if possible.
4. Boot into your bootable OS, install the dependencies if necessary.
5. Copy the Monero binaries to to a RAM disk (/dev/shm in Linux, Windows bootable ISOs normally have a Z: drive or something)
6. Don't run the Monero daemon. Instead, using the command line, use simplewallet to create a new wallet.
7. When prompted for a name, give it any name, it doesn't really matter.
8. When prompted for a password, type in like 50 - 100 random characters. Don't worry that you don't know the password, just make it LONG.
9. Write down (on paper) your 24 word mnemonic seed.
10. Write down (on your phone, on paper, on another computer, wherever you want) your address and view key.
11. Switch off the computer, remove the battery if there is one, and leave it physically off for a few hours.

There you go - the wallet you've created was created in RAM, and the digital files are now lost forever. If some magical hacker manages to somehow get the data, they will lack the long password to open it. If you need to receive payments, you have the address, and you have the view key if needed. If you need access to it, you have your 24 word seed, and you can now write out several copies of it so that you have an offsite copy (eg. a bank deposit box). Due to the nature of the key you can write it as part of something else - eg. write a fake love letter to your wife so that the 24 words on the left hand side are your key or whatever. Then write a bunch of extra love letters. That way, if your deposit box is ever discovered, it'll be disregarded as unimportant love letters.

Absolutely - but the cost of doing this is extremely high. During a DDoS a datacenter is having their bandwidth saturated, and it's affecting other customers in the datacenter, so they will typically get their upstream bandwidth provider to null-route all traffic bound for that IP address. The upstream bandwidth provider's equipment is all muscle, no brain, on massive amounts of bandwidth, so it can't route things based on the type of data, only on the destination. Typically this means that DDoS mitigation is done, for example, by having round-robin DNS that spreads the load out to different data centers, and when under attack the DNS records can be updated faster than an attacker can reroute his DDoS. If the attack is sufficiently clever and sufficiently large there will be downtime, but it'll be measured in minutes and not in hours.

The only way to mitigate this is to scrub the data at line rate, which means you need your own very powerful, very clever, very expensive routers collocated at the DC. You're also going to need to rent at least 20gbps of the DC's bandwidth, even if you're only using a tiny tiny fraction of that, as a DDoS attack will fill that pipe and your routers will need to scrub it and only let clean data through. It's definitely doable, but it'll cost you tens of thousands of Dollars a month.

100% agreed, but the praise for the technical origins really should be given to the CryptoNote developers. After all, in all of the Bytecoin source code it says "Copyright (c) 2012-2013 The Cryptonote developers". That copyright notice seems to imply that there were no "Bytecoin developers" involved in the creation of the reference code.

Not even close. Even clever ways of "mixing" like CoinJoin or SharedCoin have been shown to be fundamentally broken.

I follow a lot of developments in cryptography, so I have of course been watching Darkcoin's progress. It definitely does add a lot more anonymity than Bitcoin provides, and that's certainly something that is to be applauded. Speaking purely from a cryptography perspective (and please do not take this as any sort of "FUD attack" or me being "anti-competitive" - I believe every cryptocurrency must carve out its own niche over time) there are two things that concern me:

1. Outputs can still be linked to addresses. If you send 20 DRK and it sends all these other outputs along with it to obfuscate, the 20 DRK still ends up in someone's address. That this can be observed on the blockchain means that analysis is easy, and we all know how often people leak addresses associated with their wallet (eg. posting it up for giveaways etc. etc.) This is an immutable problem in any Bitcoin-forked cryptocurrency that exists, as the solution (stealth addresses computed w/random data) has to be enforced for every transaction from the genesis block. If you enforce it halfway through you're stuck with old outputs that don't use stealth addresses, which makes it exceedingly complex to ensure the anonymityset is not at-risk.

2. Masternodes are an Achilles' heel. Let us say that there are 10 000 masternodes on the network. Their IP addresses and the port they operate on is, by necessity, known to the network. Let's assume that an attacker controls 5 masternodes of the 10 000. Let's also assume that each of the masternodes on the network is on a dedicated server (none of them use a VPS, because a VPS could be trivially owned by the host operating system) and each of these servers is on a 1gbps unmetered, dedicated port (clearly not the case right now, but I'm talking about a future time). How hard would it be for an attacker to knock the other 9995 masternodes off the network, leaving theirs as the only accessible masternodes (and thus not only earning them all the fees, but giving them perfect insight into transactions moving within their controlled group)? Well, NTP amplification attacks have let attackers launch 400Gbps attacks against a single machine from a sole 2mbps connection. SNMP has a theoretical 650x amplification factor. All an attacker needs to do is max out the unmetered port in an obvious attack, and the datacenter will have to react. Even straight up LOIC-style / botnet SYN floods to the port that the masternode has open will lead to the DC null-routing traffic to that box, typically for 6 hours whilst they wait for the attack to stop. Mitigating this is an extremely difficult and expensive operation for each masternode to individually undertake, and not all DCs will even be able to provide DDoS mitigation at this level. An unsophisticated attacker using extremely traditional tools can knock all of the masternodes off the network except those they control. This is a threat to anonymity.

Incidentally, the other problem with masternodes that nobody seems to have thought of is that the limited number of them will mean they're in direct competition with each other. It is in a masternode operator's financial interests to make life difficult for the rest of them - DDoS attacks, reporting the box to the datacenter, anything that can knock a single competitor off the masternode network means more fees for the remaining masternodes. This is different to PoW mining where, for instance, knocking the pools offline doesn't mean you'll get more transaction fees, as miners always have backup pools. I'm not sure how sustainable this is as a system if it unmistakably pitches operators against each other to fight for fees. Given the cost and capital required to own a masternode, it's appreciable that this will happen as a natural result of wanting to maximise masternode profits.

PGP/GPG has a WoT where you can sign someone's key with yours, indicating trust.

eg. mine is here: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7455C5E3C0CDCEB9

Peter Todd's is a more extreme example: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7FAB114267E4FA04

So that destroys many of the regular Sybil attack vectors. The bigger issue is that initialisation, where you and the person you're dealing with need to securely exchange keys. So a simple method may be to email your key fingerprint or your entire ASCII-armored public key, and then phone/Skype/IRC/whatever to confirm the fingerprint of the received key. A lot of key exchanges nowadays are done in real life, which then serves as a protection for all future communication between those two parties.


The NYSE only recently (2006) switched to annual licenses, a different model from the "trading seat" model they had previously. Because seats were forever (as with MPEX), there was a vigorous and small market where seats could be bought from brokerages that were getting out. In 2005, seats sold for $1 million - $5 million. The NYSE press release that details the shift to annual licenses is a good read if you want to learn about the history of it. I couldn't find an inflation adjustment calculator that could go back to the 1860s (when seats sold for $4 000), but in the early 1900s they were selling for $80 000, which is $2 million when adjusted for inflation. This makes the NYSE's seat cost at any point in its history 55x - 277x more expensive than MPEX.

Even now that the NYSE has switched to an annual license model, their fee is $40 000 per year (as confirmed on their trading license application form). This is still more than double MPEX's lifetime seat cost, and every year you'd have to renew it, widening that gap and making the NYSE's trading license more and more relatively expensive. I also think that this makes rational sense as it is, as MPEX doesn't have the historicity and caliber that the NYSE does, nor does it have listings that are anywhere close to the size of those listed on the NYSE. But this is perfectly fine - by the time Bitcoin is worth ~$33 300, MPEX's seat fee will be around $1 million, and we should expect that the listings will be somewhere around the caliber and size of listings the NYSE had in the early 1900s. In other words, the seat fee right now is commensurate with the size of the exchange, and that's perfectly fine.


It's hard to say - MPEX only appeals to startups involved in the Bitcoin space. Traditional startups have traditional VC funding routes, and larger companies have larger domestic exchanges they can use. A more likely scenario than a "legitimate" company listing on MPEX is that something like Van Ads or MiniGames is a rousing success, and that is a catalyst for other "legitimate" companies.


Well as demonstrated above that is provably incorrect, they have an incredibly low seat fee, one that is commensurate with their small size and volume.

LOL.

As if Meeh has le reddit army on speed dial.

Have you ever considered the possibility that a third party may be impersonating AnonCoin fanboys and doing this to cause dissent between you and AnonCoin?

The original CryptoNote whitepaper is here: https://cryptonote.org/whitepaper.pdf

The CN whitepaper had not been peer reviewed, so we took that job on ourselves.

Our mathematicians and cryptographers raw (and sometimes snarky;) annotations are here: http://monero.cc/downloads/whitepaper_annotated.pdf
The review of the CN whitepaper as presented by one of our mathematicians is here: http://monero.cc/downloads/whitepaper_review.pdf

(on the topic of CryptoNight, it was never called such in the whitepaper, but is called CryptoNight in the CN reference code)

Ah - this is a communication problem, you and I have fundamentally different ideas of "success". You're talking about success in terms of marketing and market price; I'm talking about success in terms of cryptographic soundness. Under this clearer definition you are correct - Bytecoin was wholly unsuccessful, in spite of its cryptographic soundness, and Darkcoin's market success definitely did spawn a string of idiotic imitators all trying to reinvent a broken wheel.

From a cryptographic perspective, Zerocoin has a great deal of potential, and Anoncoin is pushing ahead with their proposed implementation of it. As you may or may not know, Monero has a close working relationship with AnonCoin, to the point where we have formed an NGO together to tackle the low-latency mixnet work (i2pd) to benefit both Anoncoin and Monero, so Zerocoin is something we've discussed at length with them. Zerocoin is definitely a worthy approach to the problem, although it will suffer from similar "blockchain bloat" that Monero incurs if the proofs get posted back to the blockchain. It does nonetheless offer a sound approach to cryptographically unlinkable transactions, the only failure of which would be the "open" blockchain that still allows for some analysis (until ZC is coupled with hard-forked enforcement of stealth addresses, which would solve that from that point on).