This patch is now un-deprecated. People continue to find value in a 'listtransactions' display that uses [almost] the same logic as the GUI's wallet display.
The patch has been updated to latest git. See top of thread for URL.
Topic: [PATCH] implement 'xlisttransactions' (Read 21687 times)
This patch is officially considered deprecated, as of mainline SVN r204.
Patch updated for latest SVN.
RPC has been renamed to 'xlisttransactions', because mainline is now including an incompatible version.
RPC has been renamed to 'xlisttransactions', because mainline is now including an incompatible version.
Patch updated to latest SVN.
Updated to SVN r188 (accounts).
Patch updated to latest SVN. See top of thread for URL.
Patch updated to latest SVN (v0.3.14).
Could you have listtransactions also include the comment field associated with a transaction? Here's the problem I'm running into:
Yeah, I think this is doable. Will look into it.
jgarzik,
Could you have listtransactions also include the comment field associated with a transaction? Here's the problem I'm running into:
Dragon's Tale MMO does periodic (every 3 minutes) checkpoints. If someone has withdrawn BTC since the last checkpoint and the server crashes, then when it comes back up (restoring the most recent checkpoint), they could withdraw the same BTC again!
I deal with the opposite case cleanly: When someone requests an address to use to deposit BTC, I label that address and use getreceivedbylabel when computing their balance: My server and bitcoind are always in agreement WRT how many BTC the person has deposited. But unless I can query bitcoind about how many BTC were sent out on behalf of a player, I just have to trust the value stored in the last checkpoint file - very dangerous!
My solution is to record a comment consisting of the player's name, in each outbound transaction, and then when doing a restore, read in the last N transactions to correct for unrecorded outbound transactions in the game's database.
FWIW, this is almost exactly the same technique we use to sync the game database and our credit card merchant's database in A Tale in the Desert.
Could you have listtransactions also include the comment field associated with a transaction? Here's the problem I'm running into:
Dragon's Tale MMO does periodic (every 3 minutes) checkpoints. If someone has withdrawn BTC since the last checkpoint and the server crashes, then when it comes back up (restoring the most recent checkpoint), they could withdraw the same BTC again!
I deal with the opposite case cleanly: When someone requests an address to use to deposit BTC, I label that address and use getreceivedbylabel when computing their balance: My server and bitcoind are always in agreement WRT how many BTC the person has deposited. But unless I can query bitcoind about how many BTC were sent out on behalf of a player, I just have to trust the value stored in the last checkpoint file - very dangerous!
My solution is to record a comment consisting of the player's name, in each outbound transaction, and then when doing a restore, read in the last N transactions to correct for unrecorded outbound transactions in the game's database.
FWIW, this is almost exactly the same technique we use to sync the game database and our credit card merchant's database in A Tale in the Desert.
Hello all !
Is this patch ever going to hit the main official vanilla client ?
I don't really get how it could be the 'wrong way' to track transfers for a web application as long as each user has a distinct address which really seems like an obvious pre-requisite for any kind of app that is going to support multiple users.
Without that patch it's not really possible for an user to have a single entry point for transfers to his account without doing some dangerous guesswork. And since, AFAIK, nothing prevents re-using by mistake a payment address that has already been used there is the possibility that some transferred funds will end up in some no man's land :/
Is this patch ever going to hit the main official vanilla client ?
I don't really get how it could be the 'wrong way' to track transfers for a web application as long as each user has a distinct address which really seems like an obvious pre-requisite for any kind of app that is going to support multiple users.
Without that patch it's not really possible for an user to have a single entry point for transfers to his account without doing some dangerous guesswork. And since, AFAIK, nothing prevents re-using by mistake a payment address that has already been used there is the possibility that some transferred funds will end up in some no man's land :/
Patch updated to latest SVN, and for a change suggested by gavin:
- sort by time, after sorting by number of confirmations
Patch updated to latest SVN.
I've also made the following changes:
- Slight change so that JSON-RPC binds to all/any IPs instead of just the loopback.
This patch doesn't seem to be compatible with this patch. Can these patches be combined or is one better than the other?
Patch updated for SVN r147, which introduces trivial breakage w/ listtransactions. (see start of thread for URL)
Can you provide link to patches for listgenerated method and the following three changes at the end? I'd like to incorporate them into my Gentoo Linux ebuild.
In the repo I have a folder called "patches" where I keep a copy of all the patches I apply.
RE: binding to any/all IPs: DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet! Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
I was thinking about adding support for Digest auth...For Some Value Of vulnerable.
The password cannot be obtained, at least. MiTM can (a) tell the client to use another auth, and (b) impersonate a server. (a) can be mitigated by requiring RFC 2617, (b) by SSL.But, use of HTTP-Basic is just a crime, because it is so trivial to obtain the shared secret. If HTTP-Basic is to be kept, at least require SSL connections?
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.
Can you provide link to patches for listgenerated method and the following three changes at the end? I'd like to incorporate them into my Gentoo Linux ebuild.
RE: binding to any/all IPs: DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet! Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
I was thinking about adding support for Digest auth...Patch updated for current SVN, r146, aka the "break patches with a CR/LF policy change" revision.
Same patch URL (see top of this thread), no change in implementation or operation.
RE: binding to any/all IPs: DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet! Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
I was thinking about adding support for Digest auth...
- 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.
RE: binding to any/all IPs: DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet! Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
Jump to: