(context post by Gavin Andresen)

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

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

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 Smiley

What are you needing to use listtransactions for?

The reason I didn’t implement listtransactions is I want to make sure web programmers don’t use it.  It would be very easy to latch onto that for watching for received payments.  There is no reliable way to do it that way and make sure nothing can slip through the cracks.  Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say “use this! use this! don’t use listtransactions!”, I don’t think we should implement listtransactions.

When we do implement listtransactions, maybe one way to fight that is to make it all text.  It should not break down the fields into e.g. comment, confirmations, credit, debit.  It could be one pretty formatted string like “0/unconfirmed   0:0:0 date   comment      debit 4  credit 0” or something so it’s hard for programmers to do the wrong thing and process it.  It’s only for viewing the status of your server.  I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.