Quote from: ThomasV on June 22, 2012, 10:29:20 AM

no, there is no guarantee that different servers will configure their clock with the same time.

Why not just use UTC?

Quote from: ThomasV on June 22, 2012, 10:29:20 AM

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.

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?

Quote from: ThomasV on June 22, 2012, 10:29:20 AM

Quote from: ThomasV on June 22, 2012, 10:29:20 AM

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

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...