[PATCH] implement 'xlisttransactions'

Here is a patch against SVN 117, implementing 'xlisttransactions' RPC: http://pastebin.ca/1910553 At present, the options are ignored, and it dumps all transactions it finds.
Raw patch: http://pastebin.ca/raw/1910553
Edit: Patch's current home is http://yyz.us/bitcoin/patch.bitcoin-listtransactions
Edit2: RPC command has been renamed to 'xlisttransactions'

Here's an updated version, that sorts by number of confirmations: http://pastebin.ca/1910564
Raw patch: http://pastebin.ca/raw/1910564

OK, here's version 4. Output now matches what you see in the UI, and gives you information on debits/credit/generated/etc. The 'count' and 'includegenerated' parameters are now honored.
Patch: http://pastebin.ca/1910623
Raw patch: http://pastebin.ca/raw/1910623
Here's sample output from my dev box:

Code:

$ /usr/local/src/bitcoin/bitcoind -datadir=/usr/local/bitcoin/data listtransactions
[
{
"address" : "15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5",
"label" : "",
"class" : "credit",
"amount" : 0.02000000000000000,
"confirmations" : 160
},
{
"address" : "15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5",
"label" : "",
"class" : "credit",
"amount" : 0.01000000000000000,
"confirmations" : 162
},
{
"address" : "1GKgKYtV79jYHR2mr1SSDp9EjXQuLTmUTw",
"label" : "",
"class" : "debit",
"amount" : 0.02000000000000000,
"confirmations" : 1525
},
{
"address" : "191ALqREPdXCGE6mhfS7HqRZCeQB2AHT6y",
"label" : "",
"class" : "credit",
"amount" : 0.02000000000000000,
"confirmations" : 1531
},
{
"address" : "1HVYQQ5K489fMx5Aqt48M5oTJPsmUhrpkx",
"label" : "",
"class" : "debit",
"amount" : 0.01000000000000000,
"confirmations" : 1572
},
{
"address" : "1KTpPjGWyhTBC5NNYFwNzkyjW6UDL9jKPG",
"label" : "Your Address",
"class" : "credit",
"amount" : 0.01000000000000000,
"confirmations" : 1587
}
]

Added a couple small cleanups, and verified it still works under 0.3.6 / SVN r119.
Version 5 of listtransactions: http://pastebin.ca/1911295
Raw patch: http://pastebin.ca/raw/1911295
FAQ:
Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?
A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly.

Very nice! Send Satoshi an email and ask him to add it to trunk.
By the way, anyone having trouble applying this on unix can use:

Code:

curl http://pastebin.ca/raw/1911295 | awk 'sub("$", "
")' | patch

That'll make the line endings on the removed parts match the Windows line endings in the code files.

Quote from: lachesis on July 29, 2010, 10:38:49 PM (https://bitcointalk.org/index.php?topic=611.msg6525#msg6525)

Very nice! Send Satoshi an email and ask him to add it to trunk.

He is welcome to pick it up now.
But I didn't want to push the patch to him until the two FIXME's are resolved. Those FIXMEs are for 0.01% cases, but still...

Could you make count=0 return all transactions?

Quote from: lachesis on July 29, 2010, 10:53:00 PM (https://bitcointalk.org/index.php?topic=611.msg6532#msg6532)

Could you make count=0 return all transactions?

Returning all transactions is pretty easy, sure.
I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your "count=0" the default.

Quote from: jgarzik on July 29, 2010, 11:02:49 PM (https://bitcointalk.org/index.php?topic=611.msg6537#msg6537)

I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your "count=0" the default.

Perhaps. In that case, you should switch the order of includegenerated and count. Perhaps even make includegenerated true? Generations are included by default in the UI, after all.

Version 6 of listtransactions: http://pastebin.ca/1911570
Raw patch: http://pastebin.ca/raw/1911570
listtransactions implementation should be complete at this point. The following command syntax is used:

Code:

listtransactions [count=10] [minconf=1] [includegenerated=true]

As lachesis suggested, count=0 will dump all transactions.
FAQ:
Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?
A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly.

Couple of quick suggestions:
Using the key name "class" will cause problems for, at least, JavaScript, and probably other languages where "class" is a reserved word. "type" or "variety" or some other synonym will cause fewer problems later.
Or, maybe better, get rid of that field and just report credits as positive numbers and debits as negative. And add a separate "generated" field (boolean true or false).
Since each entry refers to a transaction, I'd suggest adding a "tx_id" SHA256 hex-encoded transaction id. Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).
Code to get that would look something like:

Code:

uint256 tx_hash = transaction.GetHash();
string tx_id = tx_hash.GetHex();
mapJSONResponse.push_back(Pair("tx_id", tx_id));

Quote from: gavinandresen on July 30, 2010, 01:18:06 PM (https://bitcointalk.org/index.php?topic=611.msg6642#msg6642)

Couple of quick suggestions:
Using the key name "class" will cause problems for, at least, JavaScript, and probably other languages where "class" is a reserved word. "type" or "variety" or some other synonym will cause fewer problems later.

Can you be more specific? All mainstream programming language seem sensibly insensitive to abitrary string contents, JS included. String content can certainly include language-reserved keywords and parsing tokens.

Quote from: gavinandresen on July 30, 2010, 01:18:06 PM (https://bitcointalk.org/index.php?topic=611.msg6642#msg6642)

Since each entry refers to a transaction, I'd suggest adding a "tx_id" SHA256 hex-encoded transaction id. Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).
Code to get that would look something like:

Code:

uint256 tx_hash = transaction.GetHash();
string tx_id = tx_hash.GetHex();
mapJSONResponse.push_back(Pair("tx_id", tx_id));

Added, thanks for the suggestion.

Here is 'listtransaction' version 7:
http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions
This adds the suggested txn_id field -- very nice suggestion, gavin! I wanted a unique transaction id, and now I have one