Many modern smartphones are 64-bit:) Also, the solution for smartphones (and most desktops, I would imagine) will be SPV-style thin clients, and not full nodes.

LOL - my wife thinks her top is awesome, I just smile and wave:)

If you used the binary / code from when we first released the mnemonic seed then it would be in the log, we updated it within a few days to fix Windows issues (stemming from VS2012 not supporting a specific C++ feature, so we had to switch to VS2013) and to use STDOUT instead of the normal log writer for the seed.

The entire OP is going to be overhauled, and that will include a bunch of FAQ answers (not that anyone will read it, they'll still ask the same questions in this thread;)

The 32-bit binaries are NOT obsolete - they work perfectly fine if PAE is enabled, and once we have the embedded database stuff working the 32-bit binaries won't even need PAE.

You're not just syncing downstream, you're receiving blocks from multiple peers to establish consensus and you're sending blocks to connected peers. The daemon has no understanding of "bandwidth", it works as fast as it can (which typically means maxing out your line). We are looking at adding a low-level QoS solution in the future, but in the interim you can use the bootstrap blockchain to get you going. As with anything, if you find it to be a major problem please do feel free to fix it and submit a pull request to the main github repo.

We are applying our mind to the blockchain size issue, but at its current growth rate of 40mb a week we've got plenty of time to figure out how to solve this in a way that doesn't compromise or reduce the anonymity set.

Every coin has botnets mining it, and it's a practical non-issue. To try and use a botnet to fudge consensus is extremely hard to the point of improbability, and given the hashing speed of the average crummy desktop (around 50h/s) you would need a botnet with more than 128 000 machines. The higher the hashrate the less of an issue this becomes:)

You don't - the mnemonic is a deterministic seed that is used to create your spend and view private keys, so it's unrelated to your wallet password (as it should be).

The seed isn't in the log, we removed that ages ago:)

It has been raised in #monero-dev a number of times, and we are considering options. It's not a priority, in sense of it needing to be done in the next two weeks, but we are cognisant of the need to change this and to change it soon.

Personally, I don't see how a rolling payment ID when coupled with a reasonable mixin reduces the anonymity set in any specific or measurable manner, but I understand that most merchant systems won't roll the payment ID over. In terms of threats to anonymity via a reduction in the anonymity set, this is actually quite far down the list. Identifying payments by the uniqueness in the amount is a considerably more realistic threat, and we are combating that by looking at fixed denominations (eg. 1, 2, 5, 10, 20, 50, 100 and so on).

I'd also hazard to say that as a dev team, our focus is on a combination of privacy, untraceability, and security, but we are also trying to figure out how to achieve usability and solve pressing technical concerns. Everything will evolve and improve over time, getting caught up on any single hurdle at this early juncture is just going to mean we're running pillar-to-post. We know academically where weaknesses lie (see the latest annotated whitepaper), and we are expanding that to implementation weaknesses in the code as well. The result of all of this will be a stronger cryptocurrency that can only improve on the reasonably high privacy Monero already provides:)

Still, it's had > 100 BTC daily trade volume on Poloniex most days (and has gone over 1000 BTC daily trade volume just on Poloniex on more than one occasion), so its in a reasonable position (generally in the top 10 cryptocurrencies by trade volume).

Ok so to conclude the Monero GUI bounty, we've spent a GREAT deal of time discussing this and trying to figure out what to do.

To give you some pretext to our decision: we were looking for a GUI wallet that had the following features:

- open source (as the title says)
- cross platform (as clarified by tacotime here)
- must work (I know this sounds funny, but you'd be surprised at the amount of non-working submissions bounties get)
- must support a minimum set of core functions (sending payments with a payment ID, for instance)

There has been a lot of really great work that has been done by a bunch of developers, and I think it's awesome that this is pretty much the first cryptocurrency I've seen that has multiple actively developed GUI clients. This is AWESOME, because it means that end users are the ones that benefit - they can pick and choose a client that is most suited to them. It also means that reference code will exist in multiple languages using multiple technologies, and this will vastly cut down on the effort required in the future by various projects. If you've developed a GUI client, please don't stop maintaining it:)

As it stands right now, we won't be integrating any of these GUI clients into the main codebase just yet, as there is still a great deal of underlying work that must be done before we can ship a GUI wallet that just about anyone can run (unless we want to make the minimum memory requirement 8gb and the minimum Internet connection requirement 20mbps;) That having been said, we will continue to recommend the actively developed GUI wallets to anyone who prefers to use a GUI wallet, and that is the main purpose behind closing and awarding this bounty now: to have a short-list of recommended GUI wallets.

Our rationale behind how we awarded the bounty is as follows (from smallest to greatest portion) -

jwinterm - 5%, for using python and kivy, both great alternatives to Qt and providing awesome reference code
BitKoot - 5%, for having the first working wallet out the gate, and for adding to it where possible
Jojatekok - 20%, for ticking many of the boxes, and for his ongoing and active development
neozaru - 70%, for having the most tightly-integrated, cross-platform GUI. He has also contributed a bunch of code upstream to the Monero core, much of which is useful not only to his project but to other GUIs.

Good job, everyone! Please PM smooth your XMR and BCN addresses, and he will sort payment out as soon as he gets a moment.

Rerig? Mooi, boet, en dankie - nou sal al die 'expats' Monero gebruik;)

That would immediately turn Monero into an instamined scamcoin, so no, not happening. Getting a large portion of coins out and into the hands of people is a good thing.

Well, instead of that what we're doing is taking each of the common "error" messages, investigating why they occur, and then figuring out whether we need to handle it or whether it's a pseudo-error and can be discarded without notifying at all. Some of them are, for instance, occurring because Monero doesn't obey OS resource constraints, and we need to make it more resource-aware. That having been said, that specific error doesn't cause any problems per se; Monero just asks the OS for an extra network connection or whatever, and the OS says "no", and then Monero tries again a few minutes later because it's not a very clever panda bear at the moment.

Please stop posting this in this thread. There's a Monero Mining thread if you want to spam it. If you post this again I will report it to the moderators as spam.

I will write up a restore guide when I get a moment. The electrum-style seed is in master and is part of the current standard binaries (0.8..

Die.

If anyone is comfortable compiling Monero, there are three things that could do with some testing:

Transaction auto-splitting

Splits transactions with lots of inputs into multiple transactions. Prompts before doing so. There is a new RPC API call for this, but it is not ready for testing (needs payment ID support). Github branch linked in the title.

Properly daemonised bitmonerod

Linux only at this stage. Properly forks to the background, and allows the execution of all daemon commands from the command line (as a command-line argument). This is a substantial piece of work, and each RPC command needs to be tested. Github branch linked in the title.

rpcwallet

Simplewallet will remain as the interactive CLI wallet client, but for automation and merchant systems all the RPC stuff has been taken out of simplewallet and put into rpcwallet (new binary). The RPC functionality that was available to simplewallet is fully available, of course, and it should be a lot more robust - if it loses its connection to the daemon it will try to regain the connection and not just conveniently shut down. Github branch linked in the title.

If you have any feedback on these three branches, please do hop on to #monero-dev on Freenode and let us know.

We're already working on it:)

Boost is a set of libraries used in Monero, they aren't really replaceable:)

Even when we've moved to an embedded database, it will grow linearly as the blockchain grows. However, it will vastly reduce the memory footprint required by the running daemon, as we will only need to keep a small number of blocks in RAM, and just maintain the current utxoset.

No, they're not lost forever.

Make sure you are using the LATEST version! Then delete your poolstate.bin from ~/.bitmonero/ or APPDATA/bitmonero, and delete your wallet.bin file (NOT the wallet.bin.keys file). Then you can start the daemon up again, and run simplewallet --wallet-file wallet.bin and wait for it to rebuild the wallet cache.