What is the status of trezor with electrum?

Can someone give me an overview?

After a fresh DB sync, I have a server up at b.1209k.com 50002 ssl.

If it doesn't connect, try deleting your cert for b.1209k.com.  I ran an electrum server with a different cert there before.

With some recent improvements I've simplified the locking model for multi-threaded database updates and made it a bit faster.

I think we are looking at about a ~2-3 day sync for the entire blockchain, assuming SSD and a few CPU cores.

https://github.com/fireduck64/jelectrum

I have created a fresh electrum server that uses java and bitcoinj.  It replicates all features of the standard python electrum server (that I know about).

If anyone tried it in the last week, I just changed some things around in the database.  You'll have to nuke your mongodb DB and sync fresh.

If you want notifications in general and are willing to expose your master public key I have a thing:

http://1209k.com/bitcoin-eye/

You can have those SNS notifications go to whatever you like.  I'm not sure this helps for whatever you have in mind.

Just released today:
https://github.com/fireduck64/jelectrum

Thanks.  I've moved it to my main port so it is at h.1209k.com:50002:s

I am loading the database on GCE instance but the load isn't as fast as I would like on non-SSD.

I am also working with some people on building business solutions around the electrum protocol.  I think it is at the right level of abstraction for people to build business transaction processing units that don't worry about the blockchain, they just talk to an electrum server just like other electrum clients.

In that environment, business will likely want to run their own servers (maybe making them public as well)

I think so.  I use a bunch of different electrum wallets for different things and clearing one out is a fairly common use case for me.

Also, if you think your key data may have been compromised and you are trying to send your funds elsewhere you will likely be stressed and maybe near panic and doing math to subtract a fee from your total is not what yo want to be doing.

With more, you can add in some error detection and even error correction.  That could be nice.

However, in using words a good bit of human brain error correction is already being leveraged.

In case anyone had tried, I had a firewall rule issue so no one could connect from outside.  That is corrected now.

Oh yeah, things that don't work:

- IRC server announcement
- Most input checking on requests, requests that are wrong will most likely cause the server to break the connection with no error message to the client.
- Transactions to broadcast are handed directly to a bitcoind for validation and the response from bitcoind isn't checked so errors are not relayed back as they should be.

I think I have my electrum server implementation feature complete.  More testing is needed.

You can help me by trying it out:

h.1209k.com:50001:t
h.1209k.com:50002:s

It is about 4k lines of java.  It syncs faster than the python reference server using multiple threads to import the transactions for a block.  It also works on the transactions for multiple blocks at once.  It uses a local mongodb instance for data storage, but it could use pretty much any fast key-value store.  It syncs the entire blockchain from scratch in about 3 days (faster on fast hardware+ssd).

In my testing, it seems to be faster to sync a large wallet (300+ addresses) about twice as fast but I haven't done rigorous testing there yet.

I hope to release the code later this week.

If you encounter problems and want to help track them down please reproduce them on:
h.1209k.com:50015:t

This port records all TCP traffic in and out for debugging purposes.  Then let me know the time you did it as exactly as you can and I'll be able to pull the logs.

FYI, if you want to connect to a single server and no other the command line looks like this:
electrum -1 -s h.1209k.com:50006:s

In case anyone cares and finds this (as per http://xkcd.com/979/) I'll include what I have found.

The order of the transactions does not seem to matter.  However, you need agreement between what you send for blockchain.address.get_history and the order used for making the hash in blockchain.address.subscribe or the client will reject it.

The client is taking the list from the history message (in the order that they appear) and doing the hash and making sure that matches with the hash given by the address subscription.

In both the history and the hash, an unconfirmed transaction should be listed with a height of 0.  This was getting me because I happened to be using the string 'null' instread of zero for the hash and then the client was rejecting my address history.

So I am ordering by transaction ID and that seems to work well.

This of course means there is a race condition between when you report a new hash and when the client asks for the history.  If there is more action on that address between those two, the client will reject the history and not try again.  I think it stayed in state synchronizing which would probably work.  The new address hash should come in and then the client should ask for the new history and get it again, hopefully matching this time.  So this is actually probably a self-correcting problem assuming your server isn't pants-on-head.

Ok, I'll ignore it for now.

So in the electrum protocol there is a "utxo_root" with the block headers.

What is that about?  The only thing I've been able to find is this discussion:
https://bitcointalk.org/index.php?topic=101734.0
This discussion is more focuses on adding it to the bitcoin blockchain.

Can anyone offer and guidance on how electrum is implementing this or how the clients will use it?

I am in the process of building an alternative electrum server and am trying to make it feature compatible.

Well, my theory of the order was wrong.

It appears the order is something I can't figure out.  I'm going to assume it is probably based on native order of some python hash implementation and didn't need to be consistent across servers.

I am in the process of writing an alternative electrum server.  Without derailing into why I am doing that I have a few questions.

When a client calls blockchain.address.subscribe the response seems to be a hash of the transaction IDs and block heights known to that server in a particular form.
- descending order by block height
- For each transaction: "txid:height:"

All this sha256ed and then returned.

Does this checksum need to be the same between electrum servers?  (Do I need to do the same exact things to be compatible?)

If so, what do I put for height if a transaction is unconfirmed?
How do I order them if they are at the same height?

If there is a doc somewhere that has this spelled out, I would love that.

Tired of wasting every waking moment checking the Bitcoin price but still want to know if things are getting feisty?

http://1209k.com/bitcoin-price-notify/

Get a simple email notification if the price changes by a set percentage.  If you want to not miss any big moves, all you need to do is check your email.

This is a simple service using Amazon Simple Notification Service for email delivery (a great service, I helped write it during my time at Amazon).

Reddit discussion is here:

http://www.reddit.com/r/Bitcoin/comments/237zpi/i_just_made_a_bitcoin_price_notifier_to_avoid/

One issue I have had with Electrum is the server.  It seems to take forever to sync.  I'm running a database rebuild now and it is going at the incredibly slow speed of 30 seconds per block.  This is partially solved by having recent databases downloadable (http://foundry.electrum.org/leveldb-dump/?C=M;O=D).  However, assuming in some future these were unavailable, it would take quite some time to sync up a fresh server.

This is the biggest downside that I can see.  However, electrum is still far better than any alternative that I have seen.  I would strongly recommend to anyone searching for a bitcoin client to use it.

When I have time, I plan on making a protocol compatible alternative electrum server.  I *think* I can make it faster but maybe not.

I think mine meets those requirements.  b.1209k.com with the normal ports.

bitcoind getinfo
{
    "version" : 99900,
    "protocolversion" : 70002,