I already updated Abe yesterday. Will give it a try though. Edit: No dice, seems this commit might have something to do with it since it errors on this column. indeed. I removed the call to new_id() because it was creating a new id. however, the request might not work on all databases. (I use postgresql) |
|
|
|
Updated my server but go this while starting it back up.
...
Edited out the addresses but other then that it is as is. It also looks like my client might be stuck synchronizing.
Should I worry about this?
Edit: I get the errors each time I want to connect to the server with my client.
I guess this is a schema change in abe try to run the abe update script: python -m Abe.abe --config your_abe_config_file |
|
|
|
|
I made some changes to the server code this week:
- The server shuts itself down if it loses connection with the bitcoin daemon. This will prevent servers lagging in the past
- The server announces its version to clients. The current server version is tagged 0.1.
This version number will be used by future versions of the client; for example, the client will filter out servers that have not been upgraded after a critical bug has been fixed.
|
|
|
|
this is not possible. the time a tx was first received depends on the server.
the correct way to sort transactions is to look at their inputs and outputs.
I think that's OK - in practice, transactions are spread fast enough that it won't differ by more than a few seconds, whereas blocks are often over 30 minutes apart. no, there is no guarantee that different servers will configure their clock with the same time. in addition, get_history will be extended, and it should be completely deterministic; a hash of the history will be used to avoid the server resending the whole history everytime it changes. I'm not sure if I understand how inputs/outputs can be used to sort transactions... could you expound?
when transactions are in the same block, they are logically ordered; you cannot spend coins before you receive them |
|
|
|
In the server response to "blockchain.address.get_history" commands, a transaction's timestamp is set to the time it was included in a block (or 0 while it's in the mempool). This makes it impossible for a client to correctly sort transactions which occurred while the it wasn't connected to the server, and adds a lot of complexity to correctly sorting those which occur when it's connected.
Could the server be updated to report the time a transaction was first received, either instead of the current timestamp value (as the blockchain.info API does) or in another field?
I can provide a patch if you let me know which of these is preferred, ThomasV.
this is not possible. the time a tx was first received depends on the server. the correct way to sort transactions is to look at their inputs and outputs. |
|
|
|
ThomasV,
I've just updated Electrum/Translation wiki, add cn , mind merge that ?
finway
that's very nice, thanks! note that I still have to update that page; some new messages are missing. |
|
|
|
When I connect to electrum.novit.ro, I seem to get all of my transactions (up to today's).
When I connect to ecdsa.org, I get transactions up to two days ago (Jun 16th), although I didn't make any yesterday, so it might just be today's that are missing.
When I connect to uncle-enzo.info, I get transactions up to four days ago (Jun 14th).
When I connect to btcback.com, I get transactions up to ~two weeks ago (Jun 3rd).
This does not inspire confidence in the status of the Electrum servers... what could be causing the issues?
I agree. The server is now my top priority. |
|
|
|
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.
my server (ecdsa.org) runs on a vps hosted by cinfu.com, with 1GB of RAM I had crashes in the last few days because I was working on the server code; the traffic increase caused by SatoshiDice forced me to make my bitcoind patch more efficient.. I believe this is fixed. bitcoind has been running for 24h and does not crash anymore. However, its memory usage slowly increases; there might be a memory leak. The total memory usage right now is 630M. This is bitcoind + the electrum server in python. (note that the electrum server never removes elements from its cache, so in principle this is another leak that should be fixed. in practice, however, bitcoind eats much more) |
|
|
|
I'm trying to send a transaction from an offline wallet following the instructions in https://en.bitcoin.it/wiki/ElectrumBut I'm getting an error at the point when I'm making the transaction with the command 'electrum -w offlinewallet mktx toaddress 0.1': Traceback (most recent call last):
File "/usr/local/bin/electrum", line 456, in <module>
fee = options.tx_fee, change_addr = change_addr, from_addr = from_addr )
TypeError: mktx() got an unexpected keyword argument 'change_addr'I'm thinking of adding the optional flags -s and -c on my next try, but I got sidetracked by another problem. I reproduced the same error by making a transaction from my online wallet. But this time my balance got deducted. Shouldn't the balance remain the same if there's an error in making a transaction? Using both version 0.59 (offline) and 0.59a. Really sorry about that. I have been focusing mostly on server issues yesterday, and I did not take enough time to test this release. Here is 0.59b that fixes this problem. edit: the good news is that server issues seem to be solved now  |
|
|
|
I've unchecked "Use Change Addresses" and yet on three separate transactions it's still using them.  sorry, I made a mistake. it's fixed now, see 0.59a |
|
|
|
IMHO it's the smartest thing you can do with any fiat currency this moment...
I totally agree! I just started stacking Bitcoins about 2 months ago after stacking silver and gold for a couple of years now. we need a better expression for that, "chaining bitcoins"? I think "hoarding" is the commonly used verb :-) |
|
|
|
I released version 0.59
novelties:
- russian translation
- help buttons in send tab
- use_change is now a preference stored in the wallet
- new script: get_history
- minor fixes
On Windows I get: python-ecdsa does not seem to be installed. Try 'sudo pip install ecdsa' Any tips? sorry, the zip file was incomplete. try again now. |
|
|
|
I'm having a bit of trouble figuring out offline transactions. When I tried it with electrum -w wallet mktx <recipient> <amount> I got an error that says I don't have enough funds. Indeed, if I use -o balance, it says my wallet has 0 balance. How can I get Electrum to recognize my true wallet balance when it is offline? The wallet I'm using does contain all the transaction history so it should know its most recent balance...
you have to follow the steps explained here: https://en.bitcoin.it/wiki/Electrum#Offline_wallet |
|
|
|
|
I released version 0.59
novelties:
- russian translation
- help buttons in send tab
- use_change is now a preference stored in the wallet
- new script: get_history
- minor fixes
|
|
|
|
Adding preference dialogs for font and color customization can be
done by Thomas but I don't think it's a big priority for him at the moment.
For the moment my priority is to stabilize the servers. the increase of traffic caused by Satoshi Dice has revealed some inefficiencies in the server code. |
|
|
|
The change you made for seedless wallets wasn't strictly necessary, as my fix had already taken that into account (even though that wasn't easily apparent, I admit).
does that mean that a single call to setCurrentIndex would have been sufficient? please explain things; do not assume others have information you do not share. No, a single call doesn't fix it, but switching to the contacts tab (index 3 for seeded wallets) then back to history does. And then I added the setCurrentIndex(2) to account for the seedless mode. that means that a single call to setCurrentIndex() is sufficient. No, I've tested that, it's 2 calls, in each case. (setCurrentIndex(0) is always needed at the end to make the fix transparent to the user) this is what I meant: https://gitorious.org/electrum/electrum/commit/3d9eb32b50bf55b54d74e52dd86bd106325a802e |
|
|
|
The change you made for seedless wallets wasn't strictly necessary, as my fix had already taken that into account (even though that wasn't easily apparent, I admit).
does that mean that a single call to setCurrentIndex would have been sufficient? please explain things; do not assume others have information you do not share. No, a single call doesn't fix it, but switching to the contacts tab (index 3 for seeded wallets) then back to history does. And then I added the setCurrentIndex(2) to account for the seedless mode. that means that a single call to setCurrentIndex() is sufficient. |
|
|
|
I have received 109 transactions on one specific address and about ~120 in total. And now I get the error all the time. What should I do in order to be able to access the coins connected to that address? And what happens if more transactions are sent to that address now when I have reached the limit?
Which server are you using? I recently raised the limit to 500 on ecdsa.org, and I did not see any request rejection since then. The limit on sql requests is an experimental feature; please understand that this is not its final form. Future versions of the client will handle this limit more gracefully; the server will send its policy to the client, and the client will be able to detect that it needs to use another server. My goal is to make a distinction between users who do not use a lot of resources, and heavy users, who will be redirected to other (possibly commercial) servers. The electrum service will remain free at ecdsa.org, and that server will keep running on donations; however, this free service will come with limitations on the request that your client can do. Other server operators will be free to decide what their sql limit policy is, and whether they want to run on donations or to charge a small fee. I expect this to have a load-balancing effect, and to create an incentive to run more servers. It is not possible at the moment to tell you how high the final limit will be at ecdsa.org. There are various software and protocol improvements that we need to investigate, and that are likely to offset that limit. |
|
|
|
|
Show Posts
