listtransactions output is not in order #2853

According to API docs this command is expected to return transactions in chronological order. It does not do that. Please check out details here: https://bitcointalk.org/index.php?topic=205647.0

"Chronological order" is a bit ambiguous when it comes to Bitcoin transactions, which don't have timestamps! Where is this documentation? listtransactions should stick to the order transactions were seen in, and try to guess a reasonable time partially based on that.

I completely understand that, but it does not sort them even by received timestamp. I've already figured outworkaround: listtransactions "*" 1000 0 instead of listtransactions "" 1000 0 does what expected. But i've spent several hours googling and experimenting, so i suggest fixing default behavior.

I think this is working as intended. I cannot find any mention of "chronological order" in the RPC help.

Here is a quote: "Returns up to [count] most recent transactions" https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

Doesn't "most recent" mean chronological?

And as i already mentioned, it's not clear that you need to put "*" to make it work right. Please fix either code or documentation.

The code won't be changed: if the sorting is changed then other people will complain, this is one of those things that can never suit everyone. You can update the documentation yourself in the wiki.

0.10.0, this still doesn't work, even in the most basic fashion. Why did you close it?

~$ ./bitcoin-cli listtransactions "someuser" 100 | grep time "time" : 1362497078, "time" : 1362497078, "time" : 1362511807, "time" : 1362512629, "time" : 1362512629, "time" : 1362533147, "time" : 1362533148, "time" : 1362600301, "time" : 1362774870, "time" : 1362777300, "time" : 1362787505, "time" : 1362795145, "time" : 1362795145, "time" : 1362810319, "time" : 1362810320, "time" : 1362816319, "blocktime" : 1362892319, "time" : 1362891827, "timereceived" : 1362891827 "time" : 1362900226, "time" : 1362900226, "time" : 1362903509, "time" : 1362903902, "time" : 1363046425, "time" : 1358656002, "time" : 1358706907, "time" : 1358706927, "time" : 1358804344, "time" : 1358804996, "time" : 1358859744, "time" : 1358859745, "time" : 1358899370, "time" : 1358899370, "time" : 1358899372, "time" : 1358899372, "time" : 1358904719, "time" : 1358904719, "time" : 1358988793, "time" : 1358988794, "time" : 1359088721, "time" : 1359088721, "time" : 1359093098, "time" : 1359093099, "time" : 1359187505, "time" : 1359187513, "time" : 1359402161, "time" : 1359402161, "time" : 1359417604, "blocktime" : 1359451646, "time" : 1359451080, "timereceived" : 1359451080 "time" : 1359454691, "time" : 1359454692, "time" : 1359608999, "time" : 1359609303, "time" : 1359609324, "time" : 1359623896, "time" : 1359623896, "time" : 1359778649, "time" : 1359778649, "time" : 1359833102, "time" : 1359920106, "time" : 1359921919, "blocktime" : 1359939536, "time" : 1359939449, "timereceived" : 1359939449 "time" : 1359943341, "time" : 1359943341, "time" : 1359943343, "time" : 1359943344, "time" : 1360022405, "time" : 1360054005, "blocktime" : 1360122677, "time" : 1360122176, "timereceived" : 1360122176 "time" : 1360123276, "time" : 1360123276, "time" : 1360123278, "time" : 1360123278, "time" : 1360147690, "time" : 1360147690, "time" : 1360366744, "time" : 1360366744, "time" : 1360368306, "time" : 1360480803, "time" : 1360481339, "time" : 1360483174, "time" : 1360486819, "time" : 1360747325, "time" : 1360747325, "time" : 1361084414, "time" : 1361084710, "time" : 1361093570, "time" : 1361093570, "time" : 1361110493, "time" : 1361232016, "time" : 1361429756, "time" : 1361430012, "time" : 1361431112, "time" : 1361652605, "time" : 1361658617, "time" : 1361836830, "time" : 1362116442, "time" : 1362116703, "time" : 1362118131, "time" : 1362118132, "time" : 1362118133, "time" : 1362118133,

The docs all lead users to believe it will return the most recent transactions sorted in chronological order. It also just so happens that that is going to be the most common use case. Why wouldn't you want to fix that?

Tried "-zapwallettxes=1".

No change.

Note that this wallet is over 560M and has around 170,000 transactions in it.

No change, please fix it.

@laanwj There does appear to be some kind of bug in @burnside 's case, seeing as his new transactions are getting added before his older ones. So maybe it's appropriate to reopen this issue. @burnside @DmRomantsov I'm not sure I will be able to actually fix the issue without a wallet demonstrating the problem. Is this something you can somehow reproduce in a testnet wallet without sensitive keys?

On these sreens you can see that old transactions are on the list before the new.

@DmRomantsov That's expected behaviour in the first place... In any case, output is not useful for debugging this.

@luke-jr The same response format is obtained by working through RPC. Each time I have to turn over the list. This is not a critical issue, but most likely it fixes by couple lines of code. So I would appreciate it if you correct it.