[PATCH] implement 'xlisttransactions'

[knightmb]

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.

[1713483307]

1713483307

[1713483307]

1713483307

[lachesis]

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]

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.

[jgarzik]

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]

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]

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

Buggy, how?  Maybe they are just confusing, like they were to me, initially?

getreceivedby* are by-address or by-label totals, not individual transactions.

listtransactions was created while trying to implement web services for bitcoin.  The only alternative I can see for tracking transactions, outside of listtransactions, was watching individual bitcoin address totals.  getreceivedby* is not reliable, in that regard.

[knightmb]

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

Buggy, how?  Maybe they are just confusing, like they were to me, initially?

getreceivedby* are by-address or by-label totals, not individual transactions.

listtransactions was created while trying to implement web services for bitcoin.  The only alternative I can see for tracking transactions, outside of listtransactions, was watching individual bitcoin address totals.  getreceivedby* is not reliable, in that regard.

Confusing because I didn't know it was just "amounts" and not transactions. So in that regard it's still buggy because I have a system that I did a bunch of test transactions and yet none of the correct totals show up in the summary. If you run the GUI in server mode, you can throw server commands with it running at the same time to compare output and never match the GUI unless there is more detailed description about what output the function is suppose to give.

[throughput]

I have a question about listtransactions output.

Hi, I've patched 0.3.7 with listtransactions patch and with getblock patch.

listtransactions show me this output (full):

Code:

[   
    {   
        "address" : "1111111111111111111114oLvT2",
        "label" : "",
        "txn_id" : "c28a3addc59907c51292467dde331d5ab38e3a0b3b1724ff88475d124f2ad021",
        "category" : "mixed_debit",
        "amount" : 0.000000000000000,
        "confirmations" : 3
    },
    {   
        "address" : "1111111111111111111114oLvT2",
        "label" : "",
        "txn_id" : "8e1209c4d78ad77b8429a27613b7d2092be49b0ee6373f2e786374f19237d543",
        "category" : "mixed_debit",
        "amount" : 0.000000000000000,
        "confirmations" : 29
    }
]

It looks like generation, but 0.0BTC is generated and category is "mixed_debit".
So I was curious to list all blocks and check what was that txn_ids and have found that they
was exactly the generation transactions, the value is 50.0 and it is the first transaction in the block.

Code:

...
{   
    "hash" : "0000000000486e8b9c7092ae2b7f340143872e907db0140d745367aeca4f1372",
    "ver" : 1,
    "prev_block" : "00000000003f10014e3a0691e1896b1772eea506f03cf33edf9c4827eff1d6a8",
    "mrkl_root" : "8b6d8d7b13b91fd3d0b520c21e76e9ba38e37b8515735be42bc9ab3a3f385783",
    "time" : 1281348385,
    "bits" : 469809688,
    "nonce" : 3417957380,
    "n_tx" : 3,
    "tx" : [
        {   
            "hash" : "8e1209c4d78ad77b8429a27613b7d2092be49b0ee6373f2e786374f19237d543",
            "ver" : 1,
            "vin_sz" : 1,
            "vout_sz" : 1,
            "lock_time" : 0,
            "in" : [
                {   
                    "prev_out" : {
                        "hash" : "0000000000000000000000000000000000000000000000000000000000000000",
                        "n" : 4294967295
                    },
                    "coinbase" : "0418ba001c026605"
                }
            ],
            "out" : [
                {   
                    "value" : 50.00000000000000,
                    "scriptPubKey" : "0x41E4A7E22ACA8CFF9024B87F3722DA704B16265CA25F47E729691A41CDBC4DF4009F18B61A317D6DF67F9
3660E658204EF50BA28693B187D26CE33233264A63104 OP_CHECKSIG"
                }
            ]
        },
...

Does listtransactions mistakenly list two transactions as being my? Total balance is 0. Or WHAT?..

[jgarzik]

What you are seeing is normal.

Generated blocks show up as mixed_debit until they "mature", which is around 120 confirmations.  After maturity, you are credited the 50 BTC.  This is standard policy for all generated blocks in bitcoin.

If you were looking at the GUI, you would see a "matures in N blocks" messages for that block.

[throughput]

What you are seeing is normal.

Generated blocks show up as mixed_debit until they "mature", which is around 120 confirmations.  After maturity, you are credited the 50 BTC.  This is standard policy for all generated blocks in bitcoin.

If you were looking at the GUI, you would see a "matures in N blocks" messages for that block.

Great! And thanks for the patch!

[jgarzik]

Patch updated for current SVN, r130.  No change in implementation or operation.

Same patch URL:  http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

[lachesis]

Can you add the date and time associated with each transaction?

[jgarzik]

Can you add the date and time associated with each transaction?

Added, as the "tx_time" field in listtransactions version 10.

Same patch URL, as always:  http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

Sample output, with transactions from a local miner & test box:

Code:

[
    {
        "address" : "15SXfhMc82xC5pPx9qZhPA6bDrkbgBWBJy",
        "label" : "",
        "txn_id" : "716d636922c0fe4fa438914bfbccbdd3f440f68718438a5f14a62a954cd3ef49",
        "tx_time" : 1281424940,
        "category" : "credit",
        "amount" : 0.05000000,
        "confirmations" : 795
    },
    {
        "address" : "1GudGhcqpDCwrJktYvktPHYCnDe6MHtBSr",
        "label" : "",
        "txn_id" : "2900f86ade72c8a312cac92f759c7d1efcd30253f32a76323b63d6278ce6da97",
        "tx_time" : 1281139947,
        "category" : "debit",
        "amount" : 50.00000000,
        "confirmations" : 1387
    },
    {
        "address" : "1111111111111111111114oLvT2",
        "label" : "",
        "txn_id" : "d9aae437e71347dcfafd52a514a4b67db83044ae95384611fb127e805a51b9e7",
        "tx_time" : 1281068407,
        "category" : "generated",
        "amount" : 50.00000000,
        "confirmations" : 1507
    }
]

[lachesis]

Added, as the "tx_time" field in listtransactions version 10.

Thank you

[Gavin Andresen]

The naming is getting messy: 'txn_id' and 'tx_time' mismatch for no good reason.

tx as short for 'transaction' is fine (bitcoin source uses that abbreviation all over the place), but the rest of the JSON-RPC API doesn't use underscores, so they aught to be txid and txtime.

[jgarzik]

Posted version 11 of listtransactoins at a new URL,

http://yyz.us/bitcoin/patch.bitcoin-listtransactions

This update renames output fields to 'txid' and 'txtime'.

[ByteCoin]

Generated blocks show up as mixed_debit until they "mature", which is around 120 confirmations.  After maturity, you are credited the 50 BTC.  This is standard policy for all generated blocks in bitcoin.

I've never seen the point of this. Ostensibly it's to stop the coins being spent until they're definitely part of the block chain.

After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent.  Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours.  You don't have to be online during that time.

The thing is, if you allowed it to be spent immediately it could only be spent in a branch of the block chain that's includes it's own creation. If that branch is not the longest then both the transaction creating it and the transactions spending it will be rolled back anyway! There's no justification why they should be viewed any more skeptically than a normal transaction especially as they're so small. A 10000BTC transaction doesn't take any longer to mature than a 0.01BTC transaction.

ByteCoin

[theymos]

Most transactions are not "rolled back" when two chains recombine. Transactions in the shorter chain get put back into the transaction pool, and will eventually appear in a block. Generations would normally be the only transactions removed, which is why they are treated specially.

[ByteCoin]

Most transactions are not "rolled back" when two chains recombine. Transactions in the shorter chain get put back into the transaction pool, and will eventually appear in a block. Generations would normally be the only transactions removed, which is why they are treated specially.

Thank you for explaining that. It seems reasonable. The precaution makes more sense now

ByteCoin

[mizerydearia]

<topace> listtransactions still hasnt made it into svn has it ?
<aceat64> satoshi is somewhat hostile towards it
<Kiba> we need to gitify satoshi's project!
<kisom_dev> truth
<topace> huh why's that? against the method in which it was implemented? or against the concept of it?
<aceat64> topace: I'll find the thread
<aceat64> http://bitcointalk.org/index.php?topic=611.msg6706#msg6706
<bitbot> [PATCH] implement 'listtransactions' : 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 crack...
<topace> yea reading the thread now...
<topace> i still dont understand why he thinks its unreliable or not good idea for web applications? its perfect for web applications as far as i can see
<nanotube> yea i'm not getting it either... and he things making a plain text structured string will make it "more difficult" for web applications, as if he hasn't heard of string.split() or regexps.
<nanotube> thinks
<topace> lol yea
<topace> when i read that i just laughed
<topace> if it outputs it, it can be parsed
<necrodearia> topace: The more discussion about it in the thread, perhaps the more realization Satoshi will have to incorporate it maybe?

<aceat64> he's somewhat correct, listtransactions is bad way to determine if someone in particular has sent you bitcoins
<topace> why ?
<aceat64> the standard route of getnewaddress then monitor it with getreceivedbyaddress is really the best way
<aceat64> if you just look at transactions you can't see _who_ sent you money
<topace> sure you can, if you've labelled the address
<topace> or even if you ahvent, tied the address to an external account
<aceat64> ...
<aceat64> it doesn't work like that, when I sent you btc it could come from any number of my addresses
<aceat64> send*
<topace> yea but the address that shows in "listtransactions" shows the address it was sent TO
<topace> aka, the address that i've assigned to your account in my web application
<aceat64> oh, I see what you are saying, basically you're talking about the same idea of generating a unique address for each person but using listtransaction instead of getreceivedbyaddress to monitor it
<aceat64> Satoshi is talking about people using only listtransactions I think
<topace> yea.. you'd NEED to assign a unique address to each account in your web application
<topace> otherwise listtransactions would be just as useless as getreceivedbyaddress
<topace> i just don tsee the difference, once you have an address assigned to an account, you can get the TOTAL of all deposits using getreceivedbyaddress, or you can get each individual deposit using listtransactions
<aceat64> I personally run a client with the listtransactions patch in it
<aceat64> I think it should be in the vanilla client
aceat64> if someone is dumb enough to use just listtransactions and try to match up users with a transaction based on time and/or amount only, I say let them
<topace> yea that'd be impossible to do reliably
<topace> but also very stupid :p
<aceat64> I'm sure someone will do it
<topace> you create an account, you generate an address for it, and tell the account holder what the address is... it seems like a no-brainer to me
<aceat64> by not having listtransactions it makes it a lot harder to make an alternate GUI
<topace> a lot harder / impossible :p
<aceat64> well, you can make an alternate GUI, it'll just suck
<topace> yea, cuz it cant see any transactions :p
<topace> maybe thats the ulterior motive - to force people to use the vanilla client
<topace> _his_ client
<aceat64> I doubt it, I think he's just being a bit too over-protective