I am pledging 2 BTC from the Electrum donations wallet.

FYI, blockchain.info does not show all pending transactions.

Your project is welcome, and you can definitely use the name "Electrum"!

I would love to see an Android native version of Electrum, and I don't think that someone else is developing one at the moment;
a Kivy-based gui of Electrum is currently being developped by atweiden, but this is a python project, which is based on the Electrum codebase, so it requires less work than a complete rewrite.

Note that there are important changes planned in the architecture of the Electrum client/wallet (eg bip 32), so you better get in touch with me and other developers on IRC, in order to prevent incompatibilities.

(please note that I will not be highly available until July 1st)

well, if you could explain what exactly you misunderstood, or what caused you to do it wrong, then we might have a chance to impove things.

wich server are you using?
you have two incoming transactions with amounts lower than 0.00005430
they might be below the new threshold.

try changing server and report if you still see those transactions

what is the transaction ID ?

you probably made a mistake when writing or saving your seed.
check that all your 12 words are in the electrum dictionary, which is in lib/mnemonic.py

this bug has been reported a few times.
I cannot reproduce it on linux, though.

I guess what really matters if the amount of database operations.
if the hash of a node is stored at its parent, (and each node stores the hashes for all its children)
then updating the hash of a node requires only one database read and one write, instead of reading all children (see my previous post).

thanks, I fixed it in git. the repo is the same as for other guis

Electrum works like Bitcoin-qt with respect to this question: only your private keys (needed to spend money) are encrypted, not the entire wallet file.
I believe many design decisions used in Bitcoin-qt are good and should be followed.

Here are the reasons behind this choice:
- the user password is required only for signing transactions, so that private keys remain unencrypted in memory only for a few millisecond. This makes is very difficult for another program to read them.
- if the entire wallet file was encrypted with an additional password, some users would probably use the same password for the wallet and for the private keys, or (even worse) they would encrypt only the wallet, and not reencrypt the private keys. Thus, providing such an option would actually make the software less secure.

this is why you can use the same Electrum wallet on different devices.
Two Electrum wallets that have the same seed will use the same sequence of addresses, and remain synchronized on different machines, with no need to communicate.

I use a PATRICIA tree for addresses, and a simple list for UTXOs that belong to the same address.
I remember discussing this question on IRC, we were not sure if it was better to store UTXOs as database entries or to use addresses for the leaves of the tree (what I do)

note that if we use a patricia tree of UTXOs, we might end up doing more database queries for the hashes; what makes you think it would be less efficient?

can you provide a proper description of what you did and what happened?

I believe this proposal is of primary importance for Electrum.
I started to work on it a few weeks ago, in order to add it to Electrum servers. I finalized two preliminary implementations during this week-end.

I am pretty agnostic concerning the choice of keys; I guess hash160(rawscript) makes sense.

I would like to make the following point:
It is possible to compute node hashes much faster if you store the hash of a node at the key of its parent.
That way, it is not necessary to perform database requests to all children when only one child is updated.
In order to do that, it is necessary to keep a list of children pointers at each node; this list uses a bit more space (20 bytes/node).
Thus, each node stores a list of pointers (20 bytes), and a variable-length list of hash:sumvalue for its children

I made two separate implementations:
- a "plain vanilla" version without pointers, where a node's hash is stored at the node; this implementation was too slow to be practical.
- a faster version that stores node hashes at their parent, and keeps a list of pointers for each node.

both versions are available in on github, in the Electrum server code: https://github.com/spesmilo/electrum-server
(look for branches "hashtree" and "hashtree2")

both branches were tested with randomly generated blockchain reorgs, and they produced the same root hash.

I could run the "hashtree2" version for 184k blocks on my vps, and another user went over 200k using a faster machine, but it still took him more than 24h.
I am currently working on a third version, that will use write batches when computing the hashes; I hope to further accelerate it that way.

the Electrum client will not be a full node, but you can start your own Electrum server (public or private) if you want to use Electrum without relying on an external server.

I am currently working on the hash tree of addresses, aka "ultimate blockchain compression" proposed by etotheipi.
This will be added to the code of Electrum servers and provide an extra layer of security.

yes, I will do that.

if you know how to do, yes. but I guess official binaries should be available today.

version 1.8 is available (sources only)

changes:
* Menubar in classic gui
* Updated the QR Code plugin to enable offline/online wallets to transmit unsigned/signed transactions via QR code.
* Fixed bug where never-confirmed transactions prevented further spending

thanks. I will try to make a bugfix release soon.

Do not donate to me.
if you want to make a donation, better send it to one of the Electrum server operators; they have operating costs.