transaction received time

[mav]

I have some questions about the time that transactions are received as recorded by the official satoshi client.

1) Why is the time recorded for a received transaction only stored to an accuracy of one second instead of a greater accuracy such as one millisecond or microsecond? It would seem that for automated services which need to know the order in which transactions have arrived, this would not provide enough accuracy.

I ran a quick test using the following script to send alternating amounts rapidly in a row, which produced the following sent and received transaction list from calling listtransactions (see end of post, trimmed for clarity)

It may be expected that transactions announced in the order 0.1, 0.2, 0.3, 0.4 etc should arrive in the order 0.1, 0.2, 0.3, 0.4 etc however if the time between announcing them is small enough, they do not.

I have justified this discrepancy by telling myself 'the network is complex and transaction propagation is complex', however my second question is

2) If two received transactions have the same timestamp (accurate to one second), how can I be certain which transaction was received first? Is it fair to assume that the transaction list from calling bitcoind listtransactions is in the same order as the client received them? It seems like a fair assumption, but I just want to be sure. From the transaction list I have on the 'send' client it seems this is not the case, and the order for transactions with the same timestamp is arbitrary. For example, when querying a normal sql database for several rows without any 'order by' clause, there should be no expectation about the order of those rows - does this also apply here?

Also

3)  What sort of error should I expect on this? For example, how much time between transactions should I leave to be 99% certain that they will appear in the receive client in the correct order? Can this question even be reasonably answered or does it depend too much on unknown factors?

4) Does the bash script below definitely send the coins in the order described or am I experiencing some kind of threading complexity which means that the transactions are actually being sent in a different order to what I would expect? (Just a sanity check here)

Code:

#!/bin/bash
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002

SENDER listtransactions

Code:

[
    {
        "amount" : -0.00100000,
        "txid" : "124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8",
        "time" : 1345863327
    },
    {
        "amount" : -0.00200000,
        "txid" : "26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb",
        "time" : 1345863327
    },
    {
        "amount" : -0.00100000,
        "txid" : "d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e",
        "time" : 1345863327
    },
    {
        "amount" : -0.00100000,
        "txid" : "1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b",
        "time" : 1345863328
    },
    {
        "amount" : -0.00100000,
        "txid" : "26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095",
        "time" : 1345863328
    }
]

RECEIVED listtransactions

Code:

[
    {
        "amount" : 0.00100000,
        "txid" : "1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b",
        "time" : 1345863331
    },
    {
        "amount" : 0.00100000,
        "txid" : "26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387",
        "time" : 1345863331
    },
    {
        "amount" : 0.00200000,
        "txid" : "26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb",
        "time" : 1345863331
    },
    {
        "amount" : 0.00100000,
        "txid" : "d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e",
        "time" : 1345863331
    },
    {
        "amount" : 0.00200000,
        "txid" : "5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168",
        "time" : 1345863332
    },
    {
        "amount" : 0.00200000,
        "txid" : "c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c",
        "time" : 1345863332
    },
    {
        "amount" : 0.00100000,
        "txid" : "124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8",
        "time" : 1345863333
    },
    {
        "amount" : 0.00200000,
        "txid" : "d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095",
        "time" : 1345863333
    }
]

edit:

and this is the output from the bash script

Code:

124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8
26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb
d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e
5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168
26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387
d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095
1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b
c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c

[DeathAndTaxes]

Why?

Why would you need to know the order tx arrived?

The order received is no guarantee that is the order sent.  You are dealing with a peer to peer network where independent nodes can arbitrarily join, leave, fail to forward, run alternate versions or codebases, have unpatched bugs, etc.  

I mean even in streaming video a client doesn't assume that the order packets are received is the order they are sent.  The packets are given a sequence number so the player can re-arrange the stream and even with buffering occasionally sufficient number of packets arrive far enough out of order that playback is affected.   Now that is dealing with dedicated internet switches.  Replace that with a volentary loose association of nodes and you have even less assurance (none) that txs will be received in order.

3)  What sort of error should I expect on this? For example, how much time between transactions should I leave to be 99% certain that they will appear in the receive client in the correct order? Can this question even be reasonably answered or does it depend too much on unknown factors?

It can't be answered.  The best thing you can do is perform some modeling/testing but even that has the limitation that your source nodes will traverse differing parts of the network and the network is continually changing so the results from the simulation would only be applicable to the network from that source to that destination for that specific period in time.  You may be able to draw some rough guidelines but they would be rough.

[mav]

Why?

Why would you need to know the order tx arrived?

Say I run a site like 'catch of the day' where users deposit bitcoins to a specific address which relates to a specific item. I have 100 of those items. Everyone wants one. As soon as the address is announced, I get 500 people deposit, all received within 1s of each other and thus with the same timestamp. I have to refund 400 of those and send products to 100 of them. Which deposits do I send the product to and which ones do I return? There are many instances where the order of receiving money matters. And many instances where the automation of sending money is possible resulting in floods of transactions. Even without providing a 'real world' example, the question of 'why was the arbitrary accuracy of X microseconds chosen for transaction receive time' is still valid (in this case X is 1e6).

I suspect you will say 'applications like that aren't suited to bitcoin' - but that doesn't answer the question of why the accuracy is low when it could be high, and thus possibly facilitate these styles of applications.

3)  What sort of error should I expect on this? For example, how much time between transactions should I leave to be 99% certain that they will appear in the receive client in the correct order? Can this question even be reasonably answered or does it depend too much on unknown factors?

It can't be answered.  The best thing you can do is perform some modeling/testing but even that has the limitation that your source nodes will traverse differing parts of the network and the network is continually changing so the results from the simulation would only be applicable to the network from that source to that destination for that specific period in time.  You may be able to draw some rough guidelines but they would be rough.

Yes I thought this would be the case. Thanks for clarifying.

[error]

You can't even be sure the timestamps are accurate to less than a couple of hours (IIRC). It's in the paper.

As for your "catch of the day" site, you have to give everyone a unique receiving address anyway, so just give out 100 of them.

[mav]

You can't even be sure the timestamps are accurate to less than a couple of hours (IIRC). It's in the paper.

As for your "catch of the day" site, you have to give everyone a unique receiving address anyway, so just give out 100 of them.

I was thinking for the cotd style site that one address would be published which would be associated with an item, and whoever deposited to the address first would be the winner and get the item, the rest of the payments would be returned. To have everyone get an address and then deposit to it doubles the 'race' for competitors. To prove the comp wasn't rigged I would upload the wallet so the order in which transactions was received could be verified. However, I see that there is no way even with uploading the wallet file to prove that the wallet file wasn't tampered with to make the order specific. For ordered transactions, it's best to use some means other than the wallet tx timestamp to verify it.

Thanks d&t and error, you have helped me realise that bitcoin tx timestamp being more accurate isn't actually a solution to the problem I am trying to solve.