does she offer price analysis as a paid newsletter?

have you evaluated how well an enhanced qr code would scan using a simple camera?

IMO, we are already pushing limits in usable qr code size, especially in weak lighting conditions

i think there are compelling reasons to have a strong EUR market. bitstamp seems to be stuck on dollars, because of liquidity concerns. but this creates unwanted fees for converting between dollar/euro with their bank.

this is a gap that kraken could fill.

ID verification does not seem to work. after submitting a number of times, making sure some of the technicalities are correct (btw filesize on a text-only pdf does not make much sense)
my documents never show up in the list.
also, the file picker seems bugged sometimes.

needs more UI testing i would suggest some more closed beta

I am very suspicious about this issue.
My assumptions:

Very large bodies of software are written badly. Even an absolute majority of software. this is not a conspiracy, it's a sad fact of life.
Errors are generally only fixed if someone complains about it. (QA or customers)
Various TLA are actively looking for flaws in crypto systems.
If they find one, they exploit it secretly and do not report it, so the flaw can stay there for a long time.
a semi-weak RNG is the best angle, short of a root backdoor, to total control, especially if you already sit on a big pipe, listening, because it makes all crypto futile.
a semi-weak RNG is better than completely broken, because powerful TLA's can break it, random hacker guy can't. so it is still perceived as secure.
it is a fact that TLA's employ vast amounts of mathematicans, which suggest they are a few years advantage than the unwashed masses.
-----------
my personal conclusions:
don't trust any hardware RNG exclusively.
DO audit the full stack of RNG and crypto libs, if you see something say something, even if you think it sounds stupid.
hardware "accellerators" for crypto, AES or RNG - provide a very obvious angle for attack, use software alternatives if possible.
don't assume "it is a NIST standard, so it must be OK"
---------
"Errors are generally only fixed if someone complains about it. (QA or customers)" - this is the part where it becomes interesting to look at bitcoin. people DO complain when their money gets stolen. the world can thank us later.

yes i completely agree. i made a usability study in the sahara. all bitcoiners there agreed that it does not improve scanning accuracy.

Yes. we already presented a merchant application at Bitcoin2013. There are some infos out there how this worked, our NEFT ladies used it to sell stuff for bitcoin.

But i will not spoil all the fun you are going to have once we release it, we are working on a number of changes. It is going to be a seperate app from the Mycelium Wallet.

exchange rates from mtgox are fixed for now, especiall EUR quotes should be more accurate (but still Mtgox)

https://bitcointalk.org/index.php?topic=286422.0

In the future, you will see much less reliance on Mtgox and very flexible display of exchange rates, stay tuned.

We have the best Bitcoin Economist in the world working on how to handle exchange rates in Mycelium Bitcoin Wallet

Yes, this was observed by me as well. there is a slight bug where the old view is not discarded. A fix is underway where initialization is moved to onResume. The next beta will contain a fix for that.

No. If you are rooted orbot can route any app through Tor. With this feature built-in also non-rooted users can enjoy orbot/mycelium together.

v0.7.4 pushed to the beta channel, should be online by now.

improved send dialog
support for socks proxies (for example orbot)
fading qr code for improved readability in low-light scenarios
freshly mined coins are now spendable according to standard rules (120 blocks)
manual address entry for desperate people.

please try out all the features and tell us how you like them.

as usual, to get the latest build, join this group https://plus.google.com/u/0/communities/102264813364583686576 and enable testing at https://play.google.com/apps/testing/com.mycelium.wallet

this time there is no direct download from mycelium.com, will follow for the main channel release

sha1: c547c29162d47b298ec5ef3c5c7f61ac97e63ef8

instead of toying around with XOR and |  you want to feed it in a cryptographic hash function such as sha256 to accumulate the entropy. "simply" feed every new genuine randomness to a MessageDigest
 and read the randomness from it. A proper application of this approach is the Fortuna PRNG. I will dedicate some resources into providing a library for Android + java from it, so we no longer have to trust /dev/urandom exclusively.

some cameras apparently have troubles switching between macro mode and normal mode. for qr code scanning you normally need normal mode. especially the Nexus 4. turning off this feature disables macro mode.
on the N4 we already detect this and set autofocus to false. if you provide us with the exact Build.MODEL and other constants we could put this on the "blacklist" too.

are you panning to have a lookahead limit that electrum tries to enforce, in order to make recovery easy?

i doubt you can do ecdsa signing/verification with this low amount of power in a reasonable amount of time.

Please note that the pin protects you from a kid grabbing your smartphone while on the toilet. it can not protect against a dedicated attacked with physical access to the phone, or root-level malware, any 6-digit pin would be cracked in minutes anyways. what could work is server side pin support with 2-of-3 multisig. that could in fact help against root level malware (but we are not there yet)

therefore, the pin does NOT encrypt your private keys it is just a UI measure.

If you did reveal your private key that way, your money should already be gone. if it is not gone its a pretty good indication that everything is fine

According to Jan, an update to bitcoinspinner was pushed to google play, will appear soon.

sure, this is the solution. but it means some more work for us both client and server side.

nobody knows. auditing this piece of code is very complex.

just think about why some TLAs were boasting about "phenomenal breakthroughs" in cryptanalysis.
http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1

a few months ago most of this speculation was conspiracy theory. now some of this is conspiracy fact.
seeing this kind of code audit failure/randomness failure makes me go shopping for tinfoil hats.

on my back-of the-spreadsheet envelope calculation i have estimated the "real" keyspace of SecureRandom to be very, very low.
definitely not 2^256.
edit: i don't even dare to write the number down - if the calculation is right this is too scary.

https://docs.google.com/spreadsheet/ccc?key=0Av2s7TgXTjFTdDNNZUlrb1ZPUG9EYmZGV0drZ1dWVlE#gid=0
this calculation is based on the fact that we have seen at least 1 collision of random values on android phones.
last time i did statistics was 10 years ago, so please point out any errors.

it also points out a discrepancy. if the entropy would be that low, we would see a massive amount of duplicate addresses. which are absent. i suspect the private key space is large enough - but the entropy provided at signing is too low.