[PATCH] implement 'xlisttransactions' - page 3.

knightmb

sr. member

Activity: 308

Merit: 256

Quote from: jgarzik on August 05, 2010, 03:02:03 PM

Quote from: knightmb on August 05, 2010, 02:12:42 PM

Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail.

It should present a list very similar to the GUI-presented display.

Ah ok, good to know. When I read over this topic, I saw some "example" outputs that didn't look that much different than what I was use to seeing, but now I see how useful feature really is, so it certainly has my vote.

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: knightmb on August 05, 2010, 02:12:42 PM

Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail.

It should present a list very similar to the GUI-presented display.

knightmb

sr. member

Activity: 308

Merit: 256

Quote from: lachesis on August 05, 2010, 11:00:21 AM

Quote from: knightmb on August 05, 2010, 06:32:04 AM

I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better?

It lists transactions while the getreceivedby* functions return the sum of all transactions to that label or address. There's no reliable way to see individual transactions using the getreceivedby* functions.

Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail.

lachesis

full member

Activity: 210

Merit: 104

Quote from: knightmb on August 05, 2010, 06:32:04 AM

I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better?

It lists transactions while the getreceivedby* functions return the sum of all transactions to that label or address. There's no reliable way to see individual transactions using the getreceivedby* functions.

knightmb

sr. member

Activity: 308

Merit: 256

Quote from: satoshi on July 30, 2010, 03:40:54 PM

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.

I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better?

My only beef with *all* those function calls is that direct IP to IP payments are never shown. As it is right now, if I send a payment via IP to IP, I can't find it with those commands. I can see the balance is right, but I'm not sure where it came from because neither command will show me any info about the transaction.

If listtransactions (or getreceivedbyaddress & getreceivedbylabel) could list IP to IP transactions, that would be useful.

[edit] I see it will show generated coin, so that is useful actually. Also, the current getreceivedbyaddress & getreceivedbylabel seem to be buggy in which transactions they show to begin with.

throughput

full member

Activity: 158

Merit: 100

Quote from: satoshi on July 30, 2010, 03:40:54 PM

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.

It seems, that you certainly prefer GUI in favor of CLI interfaces.
GUI is really awful type of interface, when you have, say 5 nodes with SSH access to them and
want to periodically collect some state in a loop like this:

Code:

#!/bin/bash
while read host;
do
ssh "$host" "hostname; bitcoind listtransactions"
echo =============
done > report.txt < hostlist

Then, report.txt may be emailed to a human.
I hope, that is a valid usecase for you.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: jgarzik on July 30, 2010, 11:24:10 PM

Updated to version 8 of listtransactions:
http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

Cool! Hope you don't mind, I added it to my github network as a 'feature' branch.

lachesis

full member

Activity: 210

Merit: 104

Quote from: satoshi on July 30, 2010, 03:40:54 PM

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.

Why is it unreliable? It provides the same information that the GUI provides, and that works fine for watching for payments...

Quote from: satoshi on July 30, 2010, 03:40:54 PM

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.

We really shouldn't adopt a policy of protecting users from themselves. If we do, there should at least be a "devmode" switch or config line to turn it off.

jgarzik

legendary

Activity: 1596

Merit: 1091

Updated to version 8 of listtransactions:
http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

Includes gavin's suggestion, renaming 'class' to 'category'.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: jgarzik on July 30, 2010, 02:30:40 PM

Quote from: Gavin Andresen on July 30, 2010, 09:18:06 AM

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.

It's pretty common to turn maps into objects, so you can use syntax like:
foo.tx_id
... instead of foo['tx_id']. Especially if you're doing something like passing the data into a templating system (which may ONLY understand the object.field syntax).

And foo.class just doesn't work out nicely.

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: satoshi on July 30, 2010, 03:40:54 PM

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.

Can you be more specific about "no reliable way"?

The existing facility getreceivedby* is provably unreliable. It combines transactions into summarized totals. When you go to the bank ATM and perform two deposits, the second immediately following the first, you do not see "ATM deposit $80" on your bank statement, you see two transactions with different transaction IDs for "ATM deposit $40".

I am missing something here? listtransaction seems more reliable than getreceivedby* summaries.

satoshi

founder

Activity: 364

Merit: 6472

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.

jgarzik

legendary

Activity: 1596

Merit: 1091

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

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: Gavin Andresen on July 30, 2010, 09:18:06 AM

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: Gavin Andresen on July 30, 2010, 09:18:06 AM

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

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));

jgarzik

legendary

Activity: 1596

Merit: 1091

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.

lachesis

full member

Activity: 210

Merit: 104

Quote from: jgarzik on July 29, 2010, 07:02:49 PM

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.

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: lachesis on July 29, 2010, 06:53:00 PM

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.

lachesis

full member

Activity: 210

Merit: 104

Could you make count=0 return all transactions?

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: lachesis on July 29, 2010, 06:38:49 PM

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

Topic: [PATCH] implement 'xlisttransactions' - page 3. (Read 21687 times)