Why not just use UTC?


Then just remove the received time before hashing? Or just use the hash of the last block a client knows of to identify how much history is missing?


That's a very sparse ordering. Say I receive transactions from three different accounts 5 minutes apart. As of now, it's quite possible for me to see the oldest transaction at the top of my transaction list, with the newer transactions below it. If I'm expecting them and keeping an eye on the list as I'm receiving them, that's a really obvious and confusing bug, and a horrible UX.

Or say you need to send out several transactions in a row, there are a ton of use cases where seeing them in the same order you sent them might be important. Again, the current situation can lead to bad UX.

The blockchain.info API seems to provide the received time for transactions without much issue, why can't Electrum?

Edit: sorting by tx_id when transactions belong to the same block seems to partially mitigate the issue. It doesn't fix transactions which take time to be confirmed, however...

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.

I'm not sure if I understand how inputs/outputs can be used to sort transactions... could you expound?

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.

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?

Figured it out! It's the scriptPubKey, but with the OPs in their hex form.

When reporting unspent outputs on an address, blockchain.info and the Electrum servers have a field called "script" and "raw_output_script", which are 200 bytes, but the wiki [1] documents scriptSigs which are much longer. How is the former generated?

1. https://en.bitcoin.it/wiki/Transactions

ThomasV: could you implement import/export via JSON in the next version of the Electrum client? As you say, it shouldn't be too hard...

To anyone working on this, I cleaned up the address generation code to be a bit easier to understand. You can get it here: https://gist.github.com/2933373

For the last couple of hours, the servers at ecdsa.org, btcback.com, and electrum.novit.ro have been responding to:

--> {"params": [], "id": 2, "method": "blockchain.numblocks.subscribe"}

with:

<-- {"id": 2, "result": 0}

Which seems... unlikely. Any idea of what could be causing it?

Just re-tested it, and it looks like it's working on ecdsa.org. Thanks for the quick response!

Hm, Google and archive.org don't seem to have that page archived... when do you expect it to be up?

Was this a problem on the client? From what I see in the traffic, the client is polling the server just fine - it's just not getting back the transaction notification.

No, this was on Ubuntu.


Thanks, ThomasV!

I just tried it on electrum.novit.ro and btcback.com with the same results: when the client is connected over TCP, an incoming transaction generates the appropriate server->client message in 5-10 seconds, whereas if the client is connected over HTTP, nothing happens (I waited ~2 minutes before restarting the client, at which point the transaction shows up).

So I realize this isn't enforced in any way, but is there a standard system by which addresses in a Bitcoin wallet are to be used?

I just started playing around with the client, and it's pretty neat!

However, after a bit of testing, there seems to be a bug in the JSON-RPC over HTTP service at ecdsa.org:8081 (and no bug over TCP on 50001). Over TCP, transactions to an account the client is subscribed to yield a nearly instantaneous message from the server of the form:

<-- {"params": ["<account>", "mempool:<len(h)>"], "method": "blockchain.address.subscribe"}

Whereas the HTTP version doesn't seem to report anything to the polling requests.

Could someone verify that this isn't me making some trivial mistake? I used "sudo ngrep -q -Wbyline '' dst host 78.47.154.42 or src host 78.47.154.42" to watch the traffic.

Could you explain the reasoning behind this? Will you be editing or accessing the wallet file directly on the filesystem? Browser extensions usually don't write to the filesystem, and actually can't in any browser but Firefox, where it gets a bit hairy since paths are platform-dependent. Would it be acceptable to write the file to localStorage (which is saved on the filesystem)?

I was going to just put them in localStorage, optionally encrypting them with a passphrase. I'm up for critique/suggestions, though!

Thanks, Maged! Appreciate the help, browsing for 4 hours is quite the challenge... :-P

That would be awesome, thanks Blazr! I had a few questions for ThomasV, the original poster:

1) Is the "jsonrpc communication with Electrum servers" you refer to documented anywhere? If not, does anyone know where in the Electrum source I could look to figure it out?

2) The requirements state that the extension should "read/write the wallet on disk, using the same file format [as the Electrum client]". Could you explain the reasoning behind this (i.e. will you be editing/accessing the wallet file directly on the filesystem?)? Browser extensions usually don't write to the filesystem (and actually can't on any browser but Firefox).

Thanks again!