Help me test new electrum server implementation

[fireduck]

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

[fireduck]

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.

[fireduck]

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

[ThomasV]

congratulations! looking forward to see it live

[fireduck]

congratulations! looking forward to see it live

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)

[Pontius]

Code:

./electrum -1 -s h.1209k.com:50002:s
wrong certificate h.1209k.com

(using plain TCP works though)

[...] I hope to release the code later this week. [...]

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.

So, any news on this?

[EagleTM]

Nice work!

Regarding sync speed: Bear in mind the python server implementation has a per address throtteling in place to avoid DoS. One of the shortcomings of the current python implementation is that one client with lots of addresses can hog server ressources to a point where all other clients are hanging in "sync" until the large request with lots of addresses is served. To avoid ressource hogging by one client throtteling per address was implemented and works rather well as a workaround.

[Edit: spelling]

[fireduck]

Code:

./electrum -1 -s h.1209k.com:50002:s
wrong certificate h.1209k.com

(using plain TCP works though)

[...] I hope to release the code later this week. [...]

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.

So, any news on this?

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