Does it not focus? If so, try to disable the checkbox "Continous Autofocus" in the settings.

Some background:
The general idea in embedding a QR code scanner within Bitcoin wallets is: security. If you rely on a third-party barcode scanner app which may not be open-source (so that you can check it does not something malicious) someone could trick you into installing a malware barcode scanner which does not behave honestly.

For example: I could easily write a barcode scanner app, which works perfectly for weeks as expected (so that you won't suspect anything), but only if you scan a payment request which is - let's say greater than 5 BTC - my malicious barcode scanner returns one of my address instead of the real one you just scanned. If you would't look carefully enough you might end up sending your funds directly to the attacker.

@jan:
Just noticed last weekend on a friend's phone that on international Galaxy S2 (Samsung GT-I9100, sorry have no further build details) the autofocus also only works, when "Continous Autofocus" is disabled.

Yes, with "dd" you should get a low-level bit-wise copy of the underlying blockdevice. Also if you already found other matching files this indicates that you got the correct device (where /data partition was stored on).

If you cannot find the data inside the dump, it may have been already overwritten or fragmented by the filesystem. I'm not an expert but in this case it may be very unlikely (or even impossible) to recover your keys.

If the data partition just has been wiped (formatted), you *may* find data in the raw dump of the data partition. How did you do the "raw copy" of the internal storage?


However if you already have a bit-level dump of the partition you could try to grep for your bitcoin addresses (the addresses are also stored in the data file). The data file where the keys are stored in begins with:


so you may look for these strings too.


Good look! And print your backup next time, it's really easy with Mycelium. 

Yes, you can perfectly use a single address only for login at local trader (this is the one which is associated with your username) and never have any Bitcoins on it.  You can send and receive from other addresses in your wallet.

For others who are interested in understanding consensus: I found this unorganized article helpful: https://ripple.com/wiki/Unedited_Notes

To make it clear: I'm not a promoter for Ripple, I'm just interested in the different concepts used by different cryptocurrencies. And as this is so different to Bitcoin it's interesting, so I want to learn to understand it from a technical perspective.

JoelKatz, thank you for your fast response. This makes it clearer for me now!

hI!

Thanks to JoelKatz for his patience with us and his detailled  explanations. But I still have one open question about the process of "consensus". Please correct me if I got something wrong:


As I understood, new transaction are broadcasted to every server in the network (or read it out load in the room analogy). Each server receives this new transaction and decides for itself if it is valid and if so adds it to its "candidate list" of transactions which could be applied to the last closed ledger (LCL) to form a new LCL. Also each server receives proposals from other servers on its UNL and compares them with its own candidate list.

After the current timer expires (according to the youtube consensus video) the server checks which transactions in the candidate set have passed the approval rate threshold (eg. >50% of server on UNL agree with it) and forms its own new proposal containing these transactions which then will be sent out to other servers on the network. And the next iteration round may begin.

Is this correct until here?


If so, I still do not understand one single point:

My Question:
How can a new transaction in the beginning ever get an approval rate over 50% if each server first needs to see the transaction approved by some other servers in his UNL?

Wouldn't this be a chicken-or-egg problem?
A server only includes a transaction in his own proposals, if he sees the transactions in other server's proposals. But if nobody starts inlcuding it in his porposals, it never will get a 50% approval rate.

What am I missing here?
Can someone point me in the right direction? (documentation, wiki, source code, another posting,...) Any help understanding the consensus concept would be highly appreciated.

Nice!

For completeness: That's what I did on my raspberry:
https://bitcointalk.org/index.php?topic=223573.msg2376165#msg2376165

I also can confirm one Jalapeno in real-life shipped to an average user in Austria (who brought it to our last Bitcoin-Austria community meeting and allowed me to test it for an hour or so on my laptop ). We also received our USB Block Erupter group buy package on this meeting.

You can see the pictures here: https://www.dropbox.com/sc/4q1p29fbp9bawu6/T8tkDUvOJ0
Very funny and exciting evening! 

Or maybe you could plot directly into into the graph the average of the last 10/50/100/whatever values in different color. Would make it easier to see how luck is going. People loooove statistics and fancy graphs! 

And for the record: Great work! Highly appreciated!

You are welcome!

here are some more pictures from yesterday (Austrian group buy device distribution.. )
https://www.dropbox.com/sc/4q1p29fbp9bawu6/T8tkDUvOJ0#/

Just for the record:

Raspberry working fine with 3 eruptors using cgminer 3.1.1 and this hub:
http://www.digitus.info/en/products/accessories/usb-hubs/usb-20-7-port-hub-da-70222/

This hub is a 7-port hub, but only 5 eruptors will fit in (I actually tested the hub on my laptop with 5 eruptors for about 2 hours). Now it's running stable with 3 Eruptors on my raspberry (as only 3 of the 5 eruptors were my own).

To compile cgminer 3.1.1 on a current raspbian system I just did the following:

Check that user pi is part of the group "dialout" so it can access the device files /dev/ttyUSBx:

For starting cgminer 3.1.1 with 3 eruptors I use this commandline on the raspberry:

And the config file cgminer.conf looks like this:


hashing away just fine now!

[edit]
corrected wget command to correct link for cgminer 3.1.1
[/edit]

That's this one here:
http://www.digitus.info/produkte/zubehoer/usb-hubs/usb-20-7-port-hub-da-70222/

It's a 7-port hub, but I've only tested it with 5 eruptors (and 7 Eruptors won't fit as the ports on the side are to near to each other).
I got it here in Vienna in a local computer store for 15 Euros.

(see also: http://geizhals.at/digitus-7-port-usb-2-0-hub-da-70222-a852140.html )

[edit]
Works also on my raspberry pi! (running stable for about 12 hours now)
[/edit]

pic from yesterday: 5 of them hashing happily together with a Jalapeno  
(unfortunately not mine):

https://photos-1.dropbox.com/t/0/AABxruyM8Jn6VsF961EEK10axZ8BSzIzxhZJ2uyzoUyo6g/12/16898473/jpeg/32x32/3/1370419200/0/2/IMG_20130604_211328.jpg/YQjSx9wBVQFWnrdhvNHVnEk0As3tDNfMUYiL7QpdLV8?size=1024x768

[edit]
and here another one:
https://photos-4.dropbox.com/t/0/AABewHEh2Thd7ivSFkdbmrg2u3F5NhnZI3_FHiPkXwX3Pw/12/16898473/jpeg/32x32/3/1370419200/0/2/IMG_20130604_211719.jpg/JuEC4GQnFRCHMyIpyfKz1JyHpSe8jt6IY92ds0BHJYM?size=1024x768

Pictures taken yesterday in Hackerspace Metalab in Vienna (as Austrian group buy package arrived)

The command you are looking for is "gettxoutsetinfo" (you can enter it also in the debug console of bitcoin-qt).


AFAIK:
This had nothing to do with LevelDB. As gmaxwell said, due to an error of miners it happened 2 times that a new transaction was created having the same transaction hash as existing transactions before (which in fact means that the previous transaction got overwritten). While it's normally not easy or practically impossible to produce 2 transactions with the same hash value this is not true for coinbase transactions (which can be more easily duplicated - as one can freely enter anything into the coinbase field thus influencing the resulting transaction hash value).

To avoid that this can happen again, a new check was introduced which checks, if the transaction hash exists already in the chain (and has unspent outputs IIRC). But as already 2 transactions existed which broke this rule, these 2 cases are specially handled in code now (you can see this in line 1622 here: https://github.com/bitcoin/bitcoin/blob/v0.8.2/src/main.cpp#L1622 ).

So nothing bad here, one check was missing and got fixed (already some time ago).

Please correct me, if I got something wrong.

John

Maybe this 2-of-3 example is helpful:
https://gist.github.com/gavinandresen/3966071

john

I think it is: 80mm x 40mm x 18mm
as posted here by friedcat: https://bitcointalk.org/index.php?topic=217104.msg2282898#msg2282898

[edit:]
ah ok, maybe these are the dimensions of the package, I don't know.

Can someone confirm or correct me, if I understood correctly what would happen with all the "normal" transactions (i.e. no double-spend) in this hypothetical case:

As far as I understood it:

After the netorks merge again, the longer blockchain will be considered as the valid one, all clients which used the shorter one, will do a internal reorganisation (and validate and adopt the longer block-chain) and all non-conflicting (not double spend) transactions from the now orphaned shorter blockchain will be floating again and will be included in the next blocks of the longer chain.

Is this correct?

Btw, kann jemand einen preiswerten und gleichzeitig verlässlichen powered USB-Hub empfehlen?
Wenn man die Amazon Bewertungen diverser Geräte liest, bekommt man schnell den Eindruck, dass da im low-price Segment sehr viel Schrott verkauft wird. Trotzdem würde ich gerne das Budget etwas schonen.

Ich hätte momentan diesen hier ins Auge gefasst:
http://www.digitus.info/produkte/zubehoer/usb-hubs/usb-20-7-port-hub-da-70222/

Laut Angaben  mit 3,5 A Netzteil für 7 Ports und gibts schon ab knapp über 15,- Euro in Wien.
Kennt den jemand aus Erfahrung?