Pages:
Author

Topic: [PATCH] implement 'xlisttransactions' (Read 21635 times)

legendary
Activity: 1596
Merit: 1022
February 23, 2011, 08:46:32 PM
#65
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.
legendary
Activity: 1596
Merit: 1022
December 17, 2010, 01:23:15 PM
#64
This patch is officially considered deprecated, as of mainline SVN r204.
legendary
Activity: 1596
Merit: 1022
December 02, 2010, 01:50:35 AM
#63
Patch updated for latest SVN.

RPC has been renamed to 'xlisttransactions', because mainline is now including an incompatible version.
legendary
Activity: 1596
Merit: 1022
November 27, 2010, 03:04:28 PM
#62
Patch updated to latest SVN.
legendary
Activity: 1596
Merit: 1022
November 22, 2010, 08:04:58 PM
#61
Updated to SVN r188 (accounts).
legendary
Activity: 1596
Merit: 1022
November 13, 2010, 03:20:58 PM
#60
Patch updated to latest SVN.  See top of thread for URL.
legendary
Activity: 1596
Merit: 1022
October 21, 2010, 03:36:24 PM
#59

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.
full member
Activity: 184
Merit: 101
October 20, 2010, 10:35:39 AM
#58
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.
legendary
Activity: 1372
Merit: 1002
1davout
October 18, 2010, 09:06:15 AM
#57
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 :/

legendary
Activity: 1596
Merit: 1022
September 29, 2010, 01:32:52 PM
#56
Patch updated to latest SVN, and for a change suggested by gavin:

  • sort by time, after sorting by number of confirmations
legendary
Activity: 1596
Merit: 1022
September 18, 2010, 03:44:33 PM
#55
Patch updated to latest SVN.
hero member
Activity: 574
Merit: 504
September 15, 2010, 04:39:10 PM
#54
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?
legendary
Activity: 1596
Merit: 1022
September 07, 2010, 03:21:30 AM
#53

Patch updated for SVN r147, which introduces trivial breakage w/ listtransactions.  (see start of thread for URL)
full member
Activity: 307
Merit: 101
September 01, 2010, 05:21:33 PM
#52
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.
legendary
Activity: 1596
Merit: 1022
September 01, 2010, 04:36:28 PM
#51
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.  Smiley  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?

hero member
Activity: 574
Merit: 504
September 01, 2010, 04:20:16 PM
#50
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:


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.
legendary
Activity: 1652
Merit: 1186
Chief Scientist
September 01, 2010, 03:35:27 PM
#49
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.
legendary
Activity: 1596
Merit: 1022
September 01, 2010, 02:40:17 PM
#48

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.
legendary
Activity: 1596
Merit: 1022
September 01, 2010, 02:35:40 PM
#47
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...

legendary
Activity: 1652
Merit: 1186
Chief Scientist
September 01, 2010, 02:33:54 PM
#46
  • 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).
Pages:
Jump to: