Bitcoin Forum
December 02, 2016, 08:11:21 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: [PATCH] implement 'xlisttransactions'  (Read 11418 times)
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 12:34:53 AM
 #1

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'


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
1480709481
Hero Member
*
Offline Offline

Posts: 1480709481

View Profile Personal Message (Offline)

Ignore
1480709481
Reply with quote  #2

1480709481
Report to moderator
1480709481
Hero Member
*
Offline Offline

Posts: 1480709481

View Profile Personal Message (Offline)

Ignore
1480709481
Reply with quote  #2

1480709481
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480709481
Hero Member
*
Offline Offline

Posts: 1480709481

View Profile Personal Message (Offline)

Ignore
1480709481
Reply with quote  #2

1480709481
Report to moderator
1480709481
Hero Member
*
Offline Offline

Posts: 1480709481

View Profile Personal Message (Offline)

Ignore
1480709481
Reply with quote  #2

1480709481
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 12:48:34 AM
 #2


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

Raw patch:  http://pastebin.ca/raw/1910564


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 03:00:24 AM
 #3


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
    }
]

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 09:22:06 PM
 #4


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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 29, 2010, 10:38:49 PM
 #5

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("$", "\r")' | patch
That'll make the line endings on the removed parts match the Windows line endings in the code files.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 10:45:26 PM
 #6

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 29, 2010, 10:53:00 PM
 #7

Could you make count=0 return all transactions?

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 29, 2010, 11:02:49 PM
 #8

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 30, 2010, 12:51:03 AM
 #9

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.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 30, 2010, 05:44:23 AM
 #10


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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 30, 2010, 01:18:06 PM
 #11

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

How often do you get the chance to work on a potentially world-changing project?
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 30, 2010, 06:30:40 PM
 #12

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.

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 30, 2010, 06:43:37 PM
 #13


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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 30, 2010, 07:40:54 PM
 #14

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
*
qt
Offline Offline

Activity: 1470


View Profile
July 30, 2010, 07:45:21 PM
 #15

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 30, 2010, 07:48:33 PM
 #16

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.

How often do you get the chance to work on a potentially world-changing project?
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
July 31, 2010, 03:24:10 AM
 #17


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

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
July 31, 2010, 01:36:59 PM
 #18

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

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.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 31, 2010, 01:58:09 PM
 #19

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.

How often do you get the chance to work on a potentially world-changing project?
throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 05, 2010, 09:12:06 AM
 #20

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.
Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!