8 hours approximately. Besides, I guess we should thank ArticMine for that, he donated ~12k. Big props!

The more funding XMR devs request, the faster their requests are fulfilled.

I like this trend!   

Go Mustangs!

I'm honestly not sure.

There are criticisms about the chain being larger than Bitcoin. That's one thing, maybe an issue in practice, maybe not, but not really the same question as "computationally efficient".

There have also been criticisms of the PoW being too slow. This was a bigger concern before it got optimized and verifying a PoW took a second or something. But now at 20 ms, I don't really see this as disastrous. Even if it is, it could easily be replaced, and doesn't constitute a scaling issue (PoW cost doesn't go up as usage increases, in fact it decreases per-tx).

I'm not really sure where a criticism of the protocol itself being too computationally inefficient would come from. The signature verification is based on DJB's elliptic curve methods that are designed to be very efficient. We can verify something like 1400 signatures/sec on CPUs that are a couple of generations out of date. And that isn't even fully optimized.

So who knows. Sometimes memes based on a tiny bit of information, possibly taken out of context or misinterpreted, just get out there and take on a life of their own, making them very hard to ever fully kill off.

This is now funded.

I assume you meant transactions instead of signatures.

For example this recent tx "06246f5c78aefac38b6c539ffc2ead5d48d452a38dbffe019cb63668aba657ed" has 15 inputs at mix 1, or 30 signatures. It took 3ms to verify on my machine (i7-4770). That would imply 10k sigs verified per second (not sure if this is multithreaded or not, and I'm not sure how much overhead there is on verifying beyond sig checking).

First bold - yeah, the refreshing of the wallet is a thorn in my side as well. I know fluffypony mentioned on IRC one time that some serious effort needs to be put into making that fast, so its on the radar. And there may or may not have been an option at some point to refresh from a certain height, so you don't have to scan the entire blockchain if you you just created your wallet yesterday.

second bold - this is an artifact of "sparse file format" https://en.wikipedia.org/wiki/Sparse_file . And the argument has been made that a larger database on disk is better than a smaller database in ram.

Third bold - its the fundamentals. This coin, its developers and the community have continuously pushed for the fundamentals over user experience. I don't expect this to change anytime soon, and I'm glad.

Fourth bold - that could be interesting, though if a "refresh from block X" is ever integrated, this will be moot.

If you create a new wallet, this is already done. The issue is that there is no creation date as part of seed words, so when you restore using seed words it has to scan the entire chain, starting from the genesis block. Probably at some point in the future when seed words are improved (especially with better error detection and correction) some sort of date indicator can be added.

As for performance and efficiency (including storage space) overall, it is important to recognize that the database right now is close to the first implementation and the main goal was to get it to work (not quite the first since NoodleDoodle did optimize some of it). Further optimizations and improvements are good goals for the future.

I would like to hear more feedback about the subject of this thread:
https://forum.getmonero.org/6/ideas/2392/privately-donate-to-privacy-oriented-services

With 0.9 coming soon it is time we give more attention to getting more privacy oriented services involved with Monero.

As menetioned above in the thread,
and

So as you can see, Fluffypony has encountered severe fundamental problems with developing v. 0.9, and because exactly this reason he can not release v. 0.9 officially. I am afraid he never can. Fluffypony, refute me please, I wanna be wrong.