JSON-RPC callback #20

(from http://www.bitcoin.org/smf/index.php?topic=1872.0)

Allow extra parameters to be attached to an address/account at creation and modified later:

• $uri: JSON-RPC callback URI
• $total: Transaction total in BTC
• $timeout: Transaction expiration interval (sec)
• $minconf: Transaction minimum confirmations required
• $cert: PEM certificate for callback target server

Additional options passed in should also cover these use cases:

Fire $uri, including parameters for the current balance and the most recent payment received, when:

• Any payment is received to the address/account with $minconf confirmations.
• Balance on address/account >= $total with $minconf confirmations.
• $timeout expires without balance on address/account >= $total and without at least $minconf confirmations.

With this, bitcoind is ready to become a fully-fledged payment back-end for internet commerce.

I'm proposing a simpler api; see http://www.bitcoin.org/smf/index.php?topic=2647.0

I believe you can build what you want on top of the lower-level "tell me when there are new blocks and transactions".

For example, note the transaction ID when you get notified of a new transaction. Then when you get notified of new blocks, call gettransaction <txid> to get the status of transactions that had fewer than $minconf confirmations.

Hey Gavin,

I can see there would be applications for what you're doing with that API.

Seems like it would be painful to work with for e-commerce, though. Right now I can just poll an account/label linked to an open purchase order to check the balance and confirmations. Using this API would require (I think) responding to the JSON-RPC callback POST by sending a flurry of RPC calls to check on the each of the transactions in the new block. Given the complexity and traffic involved in that, I'd probably just continue to use periodic polling.

You could replace polling every N minutes with a monitorblocks callback that did what you are doing now-- because you know that transactions won't get more confirmations unless new blocks have been received. You should end up with more accurate results (you'll update as soon as bitcoind sees a new block) with less polling.

You would probably ignore the transactions in the block, unless you want to do something with 1-confirmation transactions.

I see how it could work, sure. But the sample JSON output you provided on the forum post showed the callback passing some general block info and then simply a list of transaction IDs.

For each transaction ID, I would have to determine if it's relevant to my open orders, then check each relevant transaction for the number of confirmations and the balance on the associated account/address in the wallet. Right now that would mean one RPC method call per transaction in the block.

Unless monitorblocks is going to cough up some per-transaction data correlating transactions with accounts/addresses, I can't see an advantage to using it over polling.

Actually, maybe I'm totally missing something. The current implementation of gettransaction returns something like:

$ bitcoind gettransaction 270d70635927aac5ec9b42fda27e539ae50a7a06bc3bb2fb98e086e11446a3e6
{
"amount" : -0.02000000,
"fee" : 0.00000000,
"confirmations" : 248,
"txid" : "270d70635927aac5ec9b42fda27e539ae50a7a06bc3bb2fb98e086e11446a3e6",
"message" : "comment",
"to" : "comment-to"
}

How do I associate this with an account or address?

I submitted a pull request today to add "details" to gettransaction output. You'll get one or more objects that give category (send or receive), account, and address.