Topic: Electrum server discussion thread - page 19. (Read 61494 times)
So I notice there are currently 6 servers the Electrum client is aware of ... just wondering if the servers can be made aware of other servers in the same way that the client is?
I've set up an electrum server some time ago for me and my friends because we didn't want to download the blockchain. I've made it public now, it doesn't have a domain but the IP should show up in the server list: 176.9.206.164
Here's a note about running the electrum server on a 32-bit machine. The issue is that abe tries to mmap the blk000x.dat file, which may be too large to fit in 32-bit virtual memory. I use a patch for bitcoin that reduces the max size of each dat file to ~500MB:
The idea for this patch comes from this post by John Tobey. The "right" way to do this may be to fix abe to only mmap the file partially, but until then, this little hack works.
Code:
diff -ur bitcoin-0.6.2_orig/src/main.cpp bitcoin-0.6.2/src/main.cpp
--- bitcoin-0.6.2_orig/src/main.cpp 2012-07-07 23:18:28.365376724 -0700
+++ bitcoin-0.6.2/src/main.cpp 2012-06-19 18:40:45.842931405 -0700
@@ -1865,7 +1865,7 @@
if (fseek(file, 0, SEEK_END) != 0)
return NULL;
// FAT32 filesize max 4GB, fseek and ftell max 2GB, so we must stay under 2GB
- if (ftell(file) < 0x7F000000 - MAX_SIZE)
+ if (ftell(file) < 0x1F000000 - MAX_SIZE)
{
nFileRet = nCurrentBlockFile;
return file;
The idea for this patch comes from this post by John Tobey. The "right" way to do this may be to fix abe to only mmap the file partially, but until then, this little hack works.
vuce, i made an implementation of the server backend and created the server frontend so i can help you out. you should come to #electrum on Freenode.
Managed to figure it out, but I'll drop by if I have any more questions, thanks genjix!
vuce, i made an implementation of the server backend and created the server frontend so i can help you out. you should come to #electrum on Freenode.
Thomas, is there any specification for the server commands? I have trouble with some of the "methods" (namely "blockchain.address.subscribe"), but it might be due to me not understanding what it actually does. I've looked at the stratum protocol draft (I'm assuming electrum uses this or is at least based on it?) but it doesn't seem to have any real info either.
the specs are hosted on the bitcoinconsultancy wiki. that wiki is down atm. there is no ETA afaik
Thomas, is there any specification for the server commands? I have trouble with some of the "methods" (namely "blockchain.address.subscribe"), but it might be due to me not understanding what it actually does. I've looked at the stratum protocol draft (I'm assuming electrum uses this or is at least based on it?) but it doesn't seem to have any real info either.
Can I ask you what kind of resources a electrum server uses or rather what kind of resources I should dedicate to it to have it running stable.
post scriptum:
* make sure you use a 64-bit OS
* the first time you import the blockchain in abe, stop bitcoind during the import, it will go much faster.
* I do not currently use a SSD for ecdsa.org, but I would pick a VPS with SSD if I had to redo this
Is there a way of getting "blockchain.address.get_history" from a certain block hash onwards only? I'd imagine downloading full history of some addresses with a lot of traffic might be somewhat resource-consuming.
Maybe something like:
With the block hash from subscribe this could be very useful.
Maybe something like:
Code:
{
"id": 0,
"method": "blockchain.address.get_history",
"params": [
"17Su3J2RWnm2WLqf8pfpgj4hFUf6MFH9SZ",
"000000000000077b2195a0c9db6f4179cb98ef579f300943b3a69357ac9e2028"
]
}
With the block hash from subscribe this could be very useful.
yes, I am planning something like that.
get_status will be deprecated, and the client will send a hash of its current history
I'm now running a server as well to hopefully provide some redundancy for users.
I should have another server up again soon. I ran one for a little bit, but then Abe died and I haven't bothered since.
Is there a way of getting "blockchain.address.get_history" from a certain block hash onwards only? I'd imagine downloading full history of some addresses with a lot of traffic might be somewhat resource-consuming.
Maybe something like:
With the block hash from subscribe this could be very useful.
Maybe something like:
Code:
{
"id": 0,
"method": "blockchain.address.get_history",
"params": [
"17Su3J2RWnm2WLqf8pfpgj4hFUf6MFH9SZ",
"000000000000077b2195a0c9db6f4179cb98ef579f300943b3a69357ac9e2028"
]
}
With the block hash from subscribe this could be very useful.
I realize it's a bit of a hack, but do you see any practical drawbacks or issues in using tx_id fields for sorting transactions when their timestamp fields are equal? That seems to work well in addressing my UX concerns.
tx_id is not part of the protocol and should not be sent at all by the server.
it is a field that is only returned by abe-based servers, not servers using libbitcoin
D'oh! Story of my life.
It would really help if it were possible to recover those protocol docs (the link you posted on another thread is still down). What is libbitcoin? It seems like it might help to document the different kinds of servers, as well...
If I am running bitcoind daemon and an Electrum server, do both programs download the block chain separately?
bitcoind downloads the blockchain, then Electrum server (with the help of Abe) reads it and puts it in an SQL database to make it easier to query.
If I am running bitcoind daemon and an Electrum server, do both programs download the block chain separately?
Nevermind. After accidentally trashing my db for the 10th time, I'm declaring the current solution of bitcoind+abe+electrum server [edit]annoying[/edit]. I'll come back when it's not a full time job just to get it to run.
Edit:
Sorry, I was very frustrated. Now that I've calmed down, I'm going to try to help fix things instead of complaining
Edit:
Sorry, I was very frustrated. Now that I've calmed down, I'm going to try to help fix things instead of complaining
Code:
current_id = self.safe_sql("""SELECT max(id) FROM tx_seq""");
If the table is indexed properly, it should be just as fast, too. I'll try it on my node later and let you know how it works.
I tried that first but I got a tuple error of some kind. Let me know if you have more luck.
I can confirm that SELECT max(id) works for me on a MySQL server.
...
What you are proposing is that Electrum servers store information that is not in the bitcoin blockchain.
There are more obvious uses to it than just sorting transactions. For example servers could store transaction labels.
This is beyond scope, at least for now.
It would involve an extra layer and infrastructure, and it would be a bad idea to mix such requests with the stratum commands.
That makes sense. Thanks for the thorough explanations.
I realize it's a bit of a hack, but do you see any practical drawbacks or issues in using tx_id fields for sorting transactions when their timestamp fields are equal? That seems to work well in addressing my UX concerns.
tx_id is not part of the protocol and should not be sent at all by the server.
it is a field that is only returned by abe-based servers, not servers using libbitcoin
...
What you are proposing is that Electrum servers store information that is not in the bitcoin blockchain.
There are more obvious uses to it than just sorting transactions. For example servers could store transaction labels.
This is beyond scope, at least for now.
It would involve an extra layer and infrastructure, and it would be a bad idea to mix such requests with the stratum commands.
That makes sense. Thanks for the thorough explanations.
I realize it's a bit of a hack, but do you see any practical drawbacks or issues in using tx_id fields for sorting transactions when their timestamp fields are equal? That seems to work well in addressing my UX concerns.
...
What you are proposing is that Electrum servers store information that is not in the bitcoin blockchain.
There are more obvious uses to it than just sorting transactions. For example servers could store transaction labels.
This is beyond scope, at least for now.
It would involve an extra layer and infrastructure, and it would be a bad idea to mix such requests with the stratum commands.
Jump to: