[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[molecular]

Code:

def mn_encode( number ):
    return [words[number],] if number < n else [words[number%n],] + mn_encode( number/n + number%n )

def mn_decode( wlist ):
    r = words.index(wlist[0])
    return r + n*(mn_decode(wlist[1:]) - r ) if len(wlist[1:])>0 else r

Error -1: Stack Overflow

Was that translated from lisp code or something? ^^

[1713580861]

1713580861

[1713580861]

1713580861

[ThomasV]

I think the mnemonic algorithm is kind of weird (using quartets of bytes??)
I suggest we use the full 2000 english words list with a complete base2000 encoding:

any reason for doing that?

Well, the good thing is that anyone can do his own recipe with his client, as
the server is not supposed to be aware of the particular encoding, right?

indeed, that's something the server does not see.

[ThomasV]

I just uploaded version 0.35 to the website.

Changelog:
* New 'import' command to add extra keypairs to your wallet. Example:

Code:

python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng

Note that you can export your keypairs in the same format using:

Code:

python electrum.py addresses -k

* random selection of the default server on wallet creation
* bug fix: previous version was not correctly synchronized after creating new addresses

[slush]

I'd like to enourage pythonist interested in Electrum client to review code implementing new network protocol (proposed in https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US - the last chapter is not finished yet). Repository of server is https://gitorious.org/electrum-server/electrum-server.

You can start server by typing

Code:

twistd -ny server.tac

and run some easy client side by

Code:

python client.py

. You'll need to install Twisted framework (easy_install twisted).

The goal of my project is to provide easy, extensible protocol and fast, flexible, service-based, multi-layer implementation. For now, TCP socket and HTTP(S) polling is implemented. Pubsub infrastructure described in google document (server which actively broadcast messages to clients) is in progress.

This is alpha implementation and there can be some weird bugs thanks to asynchronous server implementation, but so far I don't see any of them. Feel free to ask me to anything or comment the solution. Constructive criticism is welcome.

[marcus_of_augustus]

I just uploaded version 0.35 to the website.

Changelog:
* New 'import' command to add extra keypairs to your wallet. Example:

Code:

python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng

Note that you can export your keypairs in the same format using:

Code:

python electrum.py addresses -k

Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.

[terrytibbs]

I just uploaded version 0.35 to the website.

Changelog:
* New 'import' command to add extra keypairs to your wallet. Example:

Code:

python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng

Note that you can export your keypairs in the same format using:

Code:

python electrum.py addresses -k

Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.

That goes without saying, does it not?

[Ryland R. Taylor-Almanza]

How is electrum-qt coming along?

[Red Emerald]

I just uploaded version 0.35 to the website.

Changelog:
* New 'import' command to add extra keypairs to your wallet. Example:

Code:

python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng

Note that you can export your keypairs in the same format using:

Code:

python electrum.py addresses -k

Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.

That goes without saying, does it not?

Could it be made so that the deterministic addresses and the imported ones can be exported separately?  That way I could export just the non-deterministic keys for backup or whatever

[terrytibbs]

Could it be made so that the deterministic addresses and the imported ones can be exported separately?  That way I could export just the non-deterministic keys for backup or whatever

Thomas just posted how to export all keys above, just grab the one you imported manually and note it down.

[Red Emerald]

Could it be made so that the deterministic addresses and the imported ones can be exported separately?  That way I could export just the non-deterministic keys for backup or whatever

Thomas just posted how to export all keys above, just grab the one you imported manually and note it down.

I don't want to have to worry about splitting my exports manually.  That isn't feasible for scripted backups.  The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up.

[ThomasV]

Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.

that is correct. perhaps I should add a big fat warning during the import command?
in any case, I think that this command should not be available from the gui, in order to make sure that it is not used too easily.

[ThomasV]

Could it be made so that the deterministic addresses and the imported ones can be exported separately?  That way I could export just the non-deterministic keys for backup or whatever

Thomas just posted how to export all keys above, just grab the one you imported manually and note it down.

I don't want to have to worry about splitting my exports manually.  That isn't feasible for scripted backups.  The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up.

did you test the command? imported keys are marked as such. you can do :

Code:

python electrum.py addresses -k | grep imported

[BkkCoins]

Regarding the "green address" discussion a while back - wouldn't it be very simple and achieve similar goals to have an option that lets users say "below this value, confirmations aren't required"? So a user may decide when he receives say 1 BTC or less he's not going to enforce the 6 confirms needed to treat it as good. Thus paying for coffee or something isn't worth holding everything up for.

[HostFat]

Regarding the "green address" discussion a while back - wouldn't it be very simple and achieve similar goals to have an option that lets users say "below this value, confirmations aren't required"? So a user may decide when he receives say 1 BTC or less he's not going to enforce the 6 confirms needed to treat it as good. Thus paying for coffee or something isn't worth holding everything up for.

Good idea, I would like also to see an editable list of "green addresses".
So if I trust some addresses I can make the client always accepting bitcoins from them without confirmations and with every value.

Even better, some more options:
- All address: accepting bitcoin without confirmations if the value is lower than xxx

Green address list:
- Address A: accept bitcoin without confirmation at any value
- Address B: accept bitcoin without confirmation at value lower then xxx
- Address C: accept bitcoin with 2 confirmation at any value
- ...
- ...

[molecular]

I'd like to enourage pythonist interested in Electrum client to review code implementing new network protocol (proposed in https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US - the last chapter is not finished yet). Repository of server is https://gitorious.org/electrum-server/electrum-server.

You can start server by typing

Code:

twistd -ny server.tac

and run some easy client side by

Code:

python client.py

. You'll need to install Twisted framework (easy_install twisted).

The goal of my project is to provide easy, extensible protocol and fast, flexible, service-based, multi-layer implementation. For now, TCP socket and HTTP(S) polling is implemented. Pubsub infrastructure described in google document (server which actively broadcast messages to clients) is in progress.

This is alpha implementation and there can be some weird bugs thanks to asynchronous server implementation, but so far I don't see any of them. Feel free to ask me to anything or comment the solution. Constructive criticism is welcome.

Code:

nick@zero ~/bitcoin/electrum-protocol/python-twisted $ python client.py --help
Registered <class 'services.ServiceDiscovery'> for service 'discovery', vendor 'Electrum' (default: True)
nazdar
[u'node', u'firstbits', u'discovery']
[u'firstbits.com']
[u'resolve', u'create']
1MarekMKDKRb6PEeHeVuiCGayk9avyBGBB
1marekm

so, after a rough look, it seems you implemented "firstbits" lookup by falling back to firstbits.com api, right?

This seems to me it would be the time now to start implementing a "real" server?

What exactly are you asking us to do?

[grondilu]

I think the mnemonic algorithm is kind of weird (using quartets of bytes??)
I suggest we use the full 2000 english words list with a complete base2000 encoding:

any reason for doing that?

Well, 2000 is an easier number to remember and that's the number of words in the wikitionary page anyway.   Other wise you have to remember that 1626 is the lowest number n such as n**3 > 256**4 or something.  That's a bit odd.

But that doesn't change the final number of words in the mnemonic anyway, so I guess it does not matter much.

However, I recently thought about using /usr/share/dict/words, which is -at least in french-, about 136,000 words long.  This reduces the number of final words to height (for a 128 bit keys), which might be a significative improvment.

[BTCurious]

However, I recently thought about using /usr/share/dict/words, which is -at least in french-, about 136,000 words long.  This reduces the number of final words to height (for a 128 bit keys), which might be a significant improvement.

Is this dictionary constant? Can we rely on it being the same in 10 years? Because if not, then that's not an option.

[Red Emerald]

Could it be made so that the deterministic addresses and the imported ones can be exported separately?  That way I could export just the non-deterministic keys for backup or whatever

Thomas just posted how to export all keys above, just grab the one you imported manually and note it down.

I don't want to have to worry about splitting my exports manually.  That isn't feasible for scripted backups.  The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up.

did you test the command? imported keys are marked as such. you can do :

Code:

python electrum.py addresses -k | grep imported

Oh that will work just fine.  I didn't realize that they were marked with "imported".

[grondilu]

However, I recently thought about using /usr/share/dict/words, which is -at least in french-, about 136,000 words long.
This reduces the number of final words to height (for a 128 bit keys), which might be a significant improvement.

Is this dictionary constant? Can we rely on it being the same in 10 years? Because if not, then that's not an option.

Indeed.  I worry about that as well but I'm not sure we have more guaranties with the contemporary poetry.

[slush]

How is electrum-qt coming along?

For various reasons I decided to focus on networking layer before finishing Qt interface. It gives me also some time to think about GUI - it's definitely more complicated to design it properly than I originally thought.