Electrum: the blockchain is the cloud

[ThomasV]

The new Electrum Bitcoin client uses a deterministic wallet. This allows users to recover their complete list of addresses and transaction history from a secret seed.  (except for labels, which are not stored in the blockchain)

For the moment this feature allows users to restore their wallet in case of loss, or to easily transport their wallet on another machine. However, it does not automatically synchronize a wallet that is being used on two different machines. I would like to add this functionality. This would very much ressemble "cloud" services.

The idea, of course, is to use the blockchain as the only source of information; we do not want users to be tied to a third-party storage.

In order to achieve this, the client needs to watch the next addresses that are going to be used in its deterministic sequence. The Electrum wallet actually uses two distinct sequences: one for receiving addresses, one for change addresses. The sequence of receiving addresses might contain gaps (unused addresses), and the maximal size of these gaps is a parameter set by the user. The sequence of change addresses does not have gaps.

The problem of synchronization between two wallets is the following: If bitcoins are received at one of the addresses that are at the end of the current sequence, then the client needs to extend that sequence, in order to know whether the next addresses have been involved in transactions. For this, the client needs to generate new private keys, and therefore it needs the user's password.

So, we are left with the following dilemma: should the client pre-generate the next 100 addresses of its sequence and store them, or should it occasionally ask the user for his password when the wallet receives some bitcoins? both solutions seem awkward to me. Is there a third solution?

UPDATE: this question has been answered below. Version 0.34 of Electrum implements a "type 2" wallet and multiple instances of the same wallets are synchronized automatically.

[jim618]

What exactly is a sequence ?
Is it something like a process that can make a new address A(n+1) from A(n) that is valid for a fixed, maximum number of n ?

If it is, is there any mileage of having a "sequence sequence" / a "synchronisation sequence" so that one client can effectively say:

"I have run out of addresses I can create from my current sequence, can we move onto the next one please?"
and then any other client can see the switch to a new sequence and move in step.

If there is a finite length you can safely create in a sequence you will, of course, run to the end of a "synchronisation sequence" but that will be O(n^2) and hence not too frequent.

[Maged]

The problem of synchronization between two wallets is the following: If bitcoins are received at one of the addresses that are at the end of the current sequence, then the client needs to extend that sequence, in order to know whether the next addresses have been involved in transactions. For this, the client needs to generate new private keys, and therefore it needs the user's password.

So, we are left with the following dilemma: should the client pre-generate the next 100 addresses of its sequence and store them, or should it occasionally ask the user for his password when the wallet receives some bitcoins? both solutions seem awkward to me. Is there a third solution?

Yes: Use a different type of deterministic wallet - one that takes advantage of the properties of ECC keys:
https://bitcointalk.org/index.php?topic=19137.0

In a nutshell: that allows you to determine a large number of future public keys by just using a master public key that is based off the master
private key. Yes, reading that made my head explode.

Also....

WARNING: This Bitcoin client does not check that an address is valid before sending to it. Use copy and paste ONLY until this is resolved.

For more info:
https://bitcointalk.org/index.php?topic=52035.msg621172#msg621172

[finway]

I think deterministic wallet is a bad idea.

Think about online bank, do they use your passphrase to generate keys? of course not, that's stupid.

Keys are keys, and passphrase are passphrase,  your keys are stored in USB-keys, and protected by passphrase and the thrid-party ---BANK.

[ThomasV]

Use copy and paste ONLY until this is resolved.

well, this was resolved before your post...

[ThomasV]

Yes: Use a different type of deterministic wallet - one that takes advantage of the properties of ECC keys:
https://bitcointalk.org/index.php?topic=19137.0

In a nutshell: that allows you to determine a large number of future public keys by just using a master public key that is based off the master
private key. Yes, reading that made my head explode.

nice. thanks for that link

[MoonShadow]

I see a potential problem with any phase based deterministic wallet.  It reduces the namespace of an attacker trying to force an address collision by searching for English phrases in the same way that a dictionary attack works against common passwords.  It's more than conceivable to have an accidental collision as well, if two fans of classical lit both choose "Call me Ishmael" or more than one Tolkien fan chooses the same quote from TLOTR.  Hell, an attacker who was just using the King James version of the Bible would get quite a few hits from Christians using their favorite verses.  It would be better to do it in reverse, by having the client generate a random number sequence and translating that into a set of English words that can be printed, saved as an encrypted file to be stored elsewhere, or memorized.

[ThomasV]

I see a potential problem with any phase based deterministic wallet.  It reduces the namespace of an attacker trying to force an address collision by searching for English phrases in the same way that a dictionary attack works against common passwords.  It's more than conceivable to have an accidental collision as well, if two fans of classical lit both choose "Call me Ishmael" or more than one Tolkien fan chooses the same quote from TLOTR.  Hell, an attacker who was just using the King James version of the Bible would get quite a few hits from Christians using their favorite verses.  It would be better to do it in reverse, by having the client generate a random number sequence and translating that into a set of English words that can be printed, saved as an encrypted file to be stored elsewhere, or memorized.

the Electrum client generates a 128 bits random sequence and translates it into a set of English words...
see https://bitcointalk.org/index.php?topic=51397.0

[MoonShadow]

I see a potential problem with any phase based deterministic wallet.  It reduces the namespace of an attacker trying to force an address collision by searching for English phrases in the same way that a dictionary attack works against common passwords.  It's more than conceivable to have an accidental collision as well, if two fans of classical lit both choose "Call me Ishmael" or more than one Tolkien fan chooses the same quote from TLOTR.  Hell, an attacker who was just using the King James version of the Bible would get quite a few hits from Christians using their favorite verses.  It would be better to do it in reverse, by having the client generate a random number sequence and translating that into a set of English words that can be printed, saved as an encrypted file to be stored elsewhere, or memorized.

the Electrum client generates a 128 bits random sequence and translates it into a set of English words...
see https://bitcointalk.org/index.php?topic=51397.0

Oh, sorry.

[MoonShadow]

I see a potential problem with any phase based deterministic wallet.  It reduces the namespace of an attacker trying to force an address collision by searching for English phrases in the same way that a dictionary attack works against common passwords.  It's more than conceivable to have an accidental collision as well, if two fans of classical lit both choose "Call me Ishmael" or more than one Tolkien fan chooses the same quote from TLOTR.  Hell, an attacker who was just using the King James version of the Bible would get quite a few hits from Christians using their favorite verses.  It would be better to do it in reverse, by having the client generate a random number sequence and translating that into a set of English words that can be printed, saved as an encrypted file to be stored elsewhere, or memorized.

Electrum doesn't work that way it uses a predefined list of words based on a key but still even if the passphrase is freeform there are ways to overcome that.

The first is used of salt.  Including a non-secure semi-unique value in the key generation process like user's email address.  This doesn't need to be secure but it should be semi-unique.   This prevents using a pre-computation attack as each user's hash is unique even w/ same passphrase.

I was thinking more along these lines, and wondering if a passphrase plus a salt created by a standardized questionaire of usually secret personal info could be used, of the kind of questions that don't change.  For example, one such question could be "How old were you when you lost your virginity?" with multiple choice answers including each age from 12 to 24, and an option like "does not apply/refuse to answer" so that the multiple choice questionaire could take all such answers, as well as the numbers of the answers that users refuse to answer, and create a salt that could produce a unique.  The questions would have to be high in number, and of a standardized order so that a user could concievablely reproduce the wallet.dat while be unique enough that it won't produce wallets that could collide.  It would have a bias, as all such questionaires do, but it should a long enough of a questionaire that such a bias isn't predictable and of such personal info that users aren't going to answer such a questionaire outside of the context of the client.

[ALPHA.]

I am going to say it right here and right now: This is the future.

[Ean]

I don't seem to be able to make a second payment until the first is in the block chain ...

[netrin]

Deterministic wallets are much more elegant as far as backup regimes. Personally, I'd prefer to have a two part seed = (random + memorized). But the only real show stopper the Satoshi/C++ client presents me is regarding bandwidth. I'm often in situations where even one MB is prohibitively expensive for bitcoin to be practical. Can Electrum quickly and cheaply discover a wallet balance and send and verify a transaction from cold startup?

[netrin]

Thanks. I'm looking through the API to get an overview of the separation of concerns/tiers. It'd be nice to see a schema:

==============
Generic Servers:
blockchain instance
==============
Interface:
address balance check --> any server
signed transactions --> any server
==============
Client:
private seed,
cache of private keys
public address/transaction labels
==============

[grondilu]

On the main page I read:

Code:

sudo easy_install ecdsa
sudo easy_install pycrypto
git clone git://gitorious.org/electrum/electrum.git
python ./electrum/client/electrum.py

On debian I see a python-pycryptopp package that should do the job for pycrypto I guess.

But what is the equivalent of ecdsa on debian?

[ThomasV]

On the main page I read:

Code:

sudo easy_install ecdsa
sudo easy_install pycrypto
git clone git://gitorious.org/electrum/electrum.git
python ./electrum/client/electrum.py

On debian I see a python-pycryptopp package that should do the job for pycrypto I guess.

But what is the equivalent of ecdsa on debian?

pycrypto is no longer used.
see the announcement in the main thread: https://bitcointalk.org/index.php?topic=50936.msg635247#msg635247

[miscreanity]

Would it be possible to generate the seed from camera input, perhaps using facial recognition data?

[finway]

Would it be possible to generate the seed from camera input, perhaps using facial recognition data?

of course, but must make the original data solid, constant,

little difference will totally change the hash.

[slush]

Teoretically it's possible (OpenCV library provides face detection algorithms with python binding).

But I cannot imagine it will work in reality. I mean - to be secure enough to generate the same seed for the same face (aging, beard, face injuries, ...) and generate enough entropy for different faces.

[miscreanity]

Yes, that's what I thought. I've been looking for methods of collapsing the complexity after acquisition, but so far the only solutions result in a decrease of data quality/resolution.

Thinking out loud here: it would probably be more appropriate currently to offer facial recognition at the device or application level for unlocking access to a pre-generated seed.

Thanks to both for your input!