[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[grondilu]

There is something weird in the create_new_address function:

Code:

# strenghtening
for i in range(100000):
 
 
oldseed = seed
 
 
seed = hashlib.sha512(seed + oldseed).digest()

Is it me or this code is just the same as:

Code:

# strenghtening
for i in range(100000):
 
 
seed = hashlib.sha512(seed * 2).digest()

?

Also, I'm not sure I see what is the point of this :-|


PS.  I set up a github repo to work on my Perl client:
http://github.com/grondilu/Perlectrum

[1714206518]

1714206518

[1714206518]

1714206518

[1714206518]

1714206518

[ThomasV]

There is something weird in the create_new_address function:

Code:

# strenghtening
for i in range(100000):
 
 
oldseed = seed
 
 
seed = hashlib.sha512(seed + oldseed).digest()

Is it me or this code is just the same as:

Code:

# strenghtening
for i in range(100000):
 
 
seed = hashlib.sha512(seed * 2).digest()

?

Also, I'm not sure I see what is the point of this :-|


PS.  I set up a github repo to work on my Perl client:
http://github.com/grondilu/Perlectrum

oh you are right, the oldseed line should not be in the loop.
the point of this loop is to make brute force attacks more difficult.
I am afraid we need to fix this; it means that users will need to move their coins to new addresses.

[grondilu]

Well, I must say I feel quite enthusiast about this project, so I put an ad about it in my signature.

[ThomasV]

Well, I must say I feel quite enthusiast about this project, so I put an ad about it in my signature.

thanks for the ad. there are now multiple developers who contribute to Electrum, so you do not want to put my name on it :-)

I just released 0.31, that fixes the key stretching problem you spotted.
Unfortunately, this means that the new version is incompatible with existing wallets; if you have an old wallet, the software will display a message asking you to move your coins to a new wallet.
I am sorry about the inconvenience.

Please note that another incompatible change is planned in the future, when we switch to "type 2" wallets

[BTCurious]

Electrum 0.31 Build 1
MD5: a99cfe2461eb0af389df7fb07652340a

[ThomasV]

Electrum 0.31 Build 1
MD5: a99cfe2461eb0af389df7fb07652340a

thanks. perhaps you should start a new thread, and put the link in the first message of the thread;
that way, you can update the link on each release, and I can directly link to that thread.

[ThomasV]

I just released version 0.32
new features:
* compute transaction fees that depend on the size of the transaction
* fix precision issues caused by float

[molecular]

There is something weird in the create_new_address function:

Code:

# strenghtening
for i in range(100000):
 
 
oldseed = seed
 
 
seed = hashlib.sha512(seed + oldseed).digest()

Is it me or this code is just the same as:

Code:

# strenghtening
for i in range(100000):
 
 
seed = hashlib.sha512(seed * 2).digest()

?

Also, I'm not sure I see what is the point of this :-|


PS.  I set up a github repo to work on my Perl client:
http://github.com/grondilu/Perlectrum

oh you are right, the oldseed line should not be in the loop.
the point of this loop is to make brute force attacks more difficult.
I am afraid we need to fix this; it means that users will need to move their coins to new addresses.

huh? grondilu is right. oldseed = seed, therefore oldseed + seed = seed * 2. His proposed change doesn't change the semantics.

This code-snippet explains why generating a new address takes so long

[BTCurious]

huh? grondilu is right. oldseed = seed, therefore oldseed + seed = seed * 2. His proposed change doesn't change the semantics.

This code-snippet explains why generating a new address takes so long

True, I think ThomasV means it should be this:

Code:

# strenghtening

oldseed = seed
for i in range(100000):
 
 
seed = hashlib.sha512(seed + oldseed).digest()

Then it will still take long, but that's supposed to be the case. It makes bruteforce attacks very costly, even with weak passphrases.

[ThomasV]

True, I think ThomasV means it should be this:

Code:

oldseed = seed
for i in range(100000):
    seed = hashlib.sha512(seed + oldseed).digest()

Indeed, this is the change I made in 0.31.
Perhaps I should emphasize that this bug caused a vulnerability, and that the new version is a security update.
I strongly advise you to update your client if you have not done so.
You will need to move your coins to a new address (see my comment above and the release notes)

[ThomasV]

Note:
I noticed that someone created a direct link from facebook to the tar.gz of version 0.22.
In order to prevent users from downloading older versions, I removed the old tarballs from the website.

If you want to link to Electrum, please link to the page http://ecdsa.org/electrum, so that users will download the most recent version.

[Red Emerald]

Note:
I noticed that someone created a direct link from facebook to the tar.gz of version 0.22.
In order to prevent users from downloading older versions, I removed the old tarballs from the website.

If you want to link to Electrum, please link to the page http://ecdsa.org/electrum, so that users will download the most recent version.

Or perhaps provide a tarball that always links to the current stable?

[ThomasV]

molecular reported a bug that occurs when several transactions are unconfirmed at the same time.
If the unconfirmed transactions use the same inputs, it will confuse the client; it will display incorrect
history and balance, and it might create transactions that will be rejected by the network (double spends).

I cannot fix this right now, I hope that I will have time this week-end
In the mean time, if you encounter this problem, the workaround is to wait until your unconfirmed transactions are confirmed.

[ThomasV]

molecular reported a bug that occurs when several transactions are unconfirmed at the same time.
If the unconfirmed transactions use the same inputs, it will confuse the client; it will display incorrect
history and balance, and it might create transactions that will be rejected by the network (double spends).

I cannot fix this right now, I hope that I will have time this week-end
In the mean time, if you encounter this problem, the workaround is to wait until your unconfirmed transactions are confirmed.

ok, this was easier to fix than expected, so I released version 0.33 that fixes it.
the distributed version contains only the client code now; the server code should be retrieved via git.

[BTCurious]

Actually, you didn't include the client code either…

[ThomasV]

Actually, you didn't include the client code either…

oh sorry. it is there now.

[BTCurious]

Nice
This may be a stupid question but… where are the release notes? Don't know if you are keeping an official changelog somewhere or something…

[ThomasV]

Nice
This may be a stupid question but… where are the release notes? Don't know if you are keeping an official changelog somewhere or something…

No, there's no real changelog at this point, except this thread.

There is a file named RELEASE-NOTES, but it is intended to explain how to upgrade your wallet when changes are made that break backward compatibility (as was the case with 0.31). For the moment I still consider that this software is in an alpha stage, because there are other changes that need to be made and that will similarly break backward compatibility. Whenever such a change is made, it will be explained in the RELEASE-NOTES.

[grondilu]

Damn, developping a client in Perl is much more difficult than I thought, but I really want to do it as I am not comfortable with python code.

I had made a mistake creating the repo (I wrote Perlelectrum for the name instead of Perlectrum).

It's now corrected (I guess):      http://github.com/grondilu/Perlectrum

Any other Perl adepts here?  If so, please help.

[grondilu]

The more I think about it, the more I think this stuff is really good.  For at least two reasons:

1.  It separates the client code from the server code, making two clearly distinct applications.  What is good about this is that it gives much less possibility for a troyan to be harmful in the server code.

2.  This idea of generating keys deterministically from a seed that can be memorized is just a great idea.  The official bitcoin client should propose something like this as an option.

I'd like to nominate ThomasV for a Satoshi award or something


Anyway, I have a question.

I don't quite understand this random number generation algorithm (the "randrange_from_seed_trytryagain").  It seems overly complicated to me.

If I must pick a random number from 0 to n, where n < 2**256, I would just do this:

x = randrange(0, 256)
for i in range(32 + 4):
     x = 256*x + rand(0, 256)
return x % n

Maybe there is something I miss mathematically here, but basically why can't I pick a number from 0 to p where p is fairly larger than 2**256 (say, 256**4 times), and then take the remainder modulo n?