[PATCH] implement 'xlisttransactions' - page 2.

aceat64

full member

Activity: 307

Merit: 102

Quote from: mizerydearia on August 25, 2010, 09:20:46 PM

Is there a binary release (official or unofficial) that integrates this patch that I could use?

I'm now doing binary releases with my github repo: http://github.com/aceat64/bitcoin-patchwork

I've got the following patches included:

Jgarzik's listtransactions patch: http://bitcointalk.org/index.php?topic=611.20
Jgarzik's getblock patch: https://bitcointalksearch.org/topic/patch-getblockbycount-getblockbyhash-rpcs-724
The listgenerated method, lifted from Lachesis's now deprecated RPC Calls patch: http://www.alloscomp.com/bitcoin/

I've also made the following changes:

Slight change so that JSON-RPC returns 200 instead of a 500 error with invalid methods/params.
Slight change so that JSON-RPC binds to all/any IPs instead of just the loopback.
Changed MAX_OUTBOUND_CONNECTIONS from 8 to 32.

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: mizerydearia on August 25, 2010, 09:20:46 PM

I glanced at http://www.bitcoin.org/wiki/doku.php?id=list_of_patches and haven't noticed any updates for this. Is listtransactions established or useful/functional yet?

It has been functional since day one

Quote from: mizerydearia on August 25, 2010, 09:20:46 PM

Is there a binary release (official or unofficial) that integrates this patch that I could use?

Not AFAIK.

mizerydearia

hero member

Activity: 574

Merit: 507

I glanced at http://www.bitcoin.org/wiki/doku.php?id=list_of_patches and haven't noticed any updates for this. Is listtransactions established or useful/functional yet? Is there a binary release (official or unofficial) that integrates this patch that I could use? I would like to use the data extracted from using the listtransactions method to implement into my website if it is reliable to do so.

Specifically in a current use scenario I would like to be able to determine the last transaction that occurred for a particular address label and to extract related data such as amount and date/time.

aceat64

full member

Activity: 307

Merit: 102

Quoted with permission from me at least, so if need be mizerydearia can edit the post and make it a weird monologue.

ByteCoin

sr. member

Activity: 416

Merit: 277

I hope you have permission from the people in the converstation to post that. If not - bad form.
If you edit your post to included "quoted with permission" I will delete this post

ByteCoin

mizerydearia

hero member

Activity: 574

Merit: 507

ByteCoin

sr. member

Activity: 416

Merit: 277

Quote from: theymos on August 15, 2010, 02:29:49 AM

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

theymos

administrator

Activity: 5166

Merit: 12850

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

sr. member

Activity: 416

Merit: 277

Quote from: jgarzik on August 09, 2010, 12:51:06 PM

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.

Quote from: satoshi on November 22, 2009, 02:34:21 PM

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

jgarzik

legendary

Activity: 1596

Merit: 1091

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

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

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.

lachesis

full member

Activity: 210

Merit: 104

Quote from: jgarzik on August 13, 2010, 06:39:01 PM

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

Thank you

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: lachesis on August 13, 2010, 04:45:01 PM

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

full member

Activity: 210

Merit: 104

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

jgarzik

legendary

Activity: 1596

Merit: 1091

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

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

throughput

full member

Activity: 158

Merit: 100

Quote from: jgarzik on August 09, 2010, 12:51:06 PM

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

legendary

Activity: 1596

Merit: 1091

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

full member

Activity: 158

Merit: 100

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

knightmb

sr. member

Activity: 308

Merit: 256

Quote from: jgarzik on August 05, 2010, 04:19:41 PM

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

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

jgarzik

legendary

Activity: 1596

Merit: 1091

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

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

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