I should have been clear: this is a patch against the latest 'vanilla' svn.
Oh, well, thanks again
Boy, you're fast... 
Topic: [PATCH] monitoraddress/blocks - page 2. (Read 5484 times)
Oh, well, thanks again
Boy, you're fast... 
I should have been clear: this is a patch against the latest 'vanilla' svn.
Any chance of getting a patch against the vanilla svn? I have a heavily tweaked code base (cuda and a collection of patches).
I just updated the code/patch:
monitoraddress allwallet
... gets triggered for all transactions that go into your wallet. That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.
And I combined the getblockby methods into one. I know I would've never remembered "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".
monitoraddress allwallet
... gets triggered for all transactions that go into your wallet. That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.
And I combined the getblockby methods into one. I know I would've never remembered "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".
+3 all great stuff.
I strongly prefer this new 'getblock' arrangement of yours. My only question was whether satoshi might not like it.
I just updated the code/patch:
monitoraddress allwallet
... gets triggered for all transactions that go into your wallet. That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.
And I combined the getblockby methods into one. I know I would've never remembered "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".
monitoraddress allwallet
... gets triggered for all transactions that go into your wallet. That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.
And I combined the getblockby methods into one. I know I would've never remembered "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".
- getblockbyhash
Returns details of the block with(hexadecimal). - getblockbynumber
Returns details of blockin the longest block chain. - gettransaction
Returns details of transaction with(hexadecimal).
Your changes appear to come darned close to superceding my getblock and listtransaction patches. With a few minor changes, you can completely supercede my patches:
- add listtransactions or gettransactions, calling your txToJSON, for each wallet tx matching the given query parameters
- add the following fields to txToJSON from my patch: bitcoin address, label, category (credit, debit, generated, etc.), amount
- any reason why you didn't use 'getblockbycount' as elsewhere discussed? I named mine that based on your own logic
Come to think of it, maybe I should combine the getblockby* routines into one; there's no chance of mistaking a 64-character hex block hash for a 5-digit (or, in many years, a six or seven or ten digit) block number.
I thought about that before, too, but the rpc interface is internally typed. Sure, we can specify a string for the parameter, and interpret the string as either a block hash or a block number, but satoshi might grumble at the overloading of parameters? None of the existing RPC commands have multi-use parameters.
My preferred arrangement would be a 'monitorall' command...
Good Idea, and that aught to be easy.I'm thinking it should be:
monitoraddress allwallet
... instead of a separate monitor command.
Come to think of it, maybe I should combine the getblockby* routines into one; there's no chance of mistaking a 64-character hex block hash for a 5-digit (or, in many years, a six or seven or ten digit) block number.
My preferred arrangement would be a 'monitorall' command, which POSTs each incoming transaction to a URL, regardless of bitcoinaddress, as long as it's a wallet transaction.
Kudos to you!
I will have to find the time to merge this into my private version, but this opens a whole new world of possibilities to me, in terms of code organization mainly.
I will have to find the time to merge this into my private version, but this opens a whole new world of possibilities to me, in terms of code organization mainly.
This patch adds the following JSON-RPC commands to bitcoin/bitcoind:
If you use the monitor* functionality to POST information be sure to think through the security of your application. For example, if you use monitoraddress to get notified of customer payments you should think about whether or not a customer could fake a payment by POSTing bogus information to your web server.
Full source code is at: http://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
As always, bug reports, suggestions for improvement and feedback is welcome.
Updated monitoraddress/getblock commands as discussed below
- monitoraddress
[monitor=true]
When coins are sent toPOST JSON transaction info to .
Ifis 'allwallet' then monitor coins sent to all of your addresses.
Pass false as third param to stop monitoring. - monitorblocks
[monitor=true] [startblockcount=0]
POST block information toas blocks are added to the block chain.
[monitor] true will start monitoring, false will stop.
Pass [startblockcount] to start monitoring at/after block with given blockcount. - listmonitored
Returns list describing where blocks and transactions are being POSTed. - getblock
Returns details of the block with(hexadecimal) or . - gettransaction
Returns details of transaction with(hexadecimal).
If you use the monitor* functionality to POST information be sure to think through the security of your application. For example, if you use monitoraddress to get notified of customer payments you should think about whether or not a customer could fake a payment by POSTing bogus information to your web server.
Full source code is at: http://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
As always, bug reports, suggestions for improvement and feedback is welcome.
Updated monitoraddress/getblock commands as discussed below
Jump to: