[PATCH] implement 'xlisttransactions'

[ByteCoin]

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

[1714911168]

1714911168

[1714911168]

1714911168

[1714911168]

1714911168

[1714911168]

1714911168

[1714911168]

1714911168

[aceat64]

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

[mizerydearia]

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.

[jgarzik]

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

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

Not AFAIK.

[aceat64]

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: http://bitcointalk.org/index.php?topic=724.0
• 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.

[Gavin Andresen]

• 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: JSON-RPC error / HTTP status codes:  I'm about to submit a patch to Satoshi so bitcoin better follows the JSON standards.  I'll create a new thread describing the changes.

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

[jgarzik]

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

[jgarzik]

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.

[Gavin Andresen]

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

I wouldn't bother-- HTTP Digest auth is vulnerable to man-in-the-middle attacks, it'd be a lot of work for a probably false sense of security.

[mizerydearia]

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: http://bitcointalk.org/index.php?topic=724.0
• 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.

[jgarzik]

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

I wouldn't bother-- HTTP Digest auth is vulnerable to man-in-the-middle attacks, it'd be a lot of work for a probably false sense of security.

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?

[aceat64]

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.

[jgarzik]

Patch updated for SVN r147, which introduces trivial breakage w/ listtransactions.  (see start of thread for URL)

[mizerydearia]

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?

[jgarzik]

Patch updated to latest SVN.

[jgarzik]

Patch updated to latest SVN, and for a change suggested by gavin:

• sort by time, after sorting by number of confirmations

[davout]

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 :/

[teppy]

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.

[jgarzik]

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]

Patch updated to latest SVN.  See top of thread for URL.