JSON-RPC callback #20

1. 
   mikegogulski commented at 9:47 am on January 5, 2011: none

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

2. 
   gavinandresen commented at 7:40 pm on January 6, 2011: contributor

   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 to get the status of transactions that had fewer than $minconf confirmations.

3. 
   mikegogulski commented at 7:51 pm on January 6, 2011: none

   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.

4. 
   gavinandresen commented at 1:10 am on January 7, 2011: contributor

   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.

5. 
   mikegogulski commented at 1:29 am on January 7, 2011: none

   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:

   0$ bitcoind gettransaction 270d70635927aac5ec9b42fda27e539ae50a7a06bc3bb2fb98e086e11446a3e6
   1{
   2"amount" : -0.02000000,
   3"fee" : 0.00000000,
   4"confirmations" : 248,
   5"txid" : "270d70635927aac5ec9b42fda27e539ae50a7a06bc3bb2fb98e086e11446a3e6",
   6"message" : "comment",
   7"to" : "comment-to"
   8}
   

   How do I associate this with an account or address?

6. 
   gavinandresen commented at 2:38 am on January 8, 2011: contributor

   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.
7. laanwj referenced this in commit 3f0816e3d9 on Sep 18, 2011
8. gavinandresen closed this on Apr 4, 2012

   ---

9. namecoin-qt referenced this in commit f47518c328 on Jun 13, 2013
10. kac- referenced this in commit 6b78b89536 on Mar 25, 2014
11. justmoon referenced this in commit bfbe3b4441 on Apr 7, 2014
12. justmoon referenced this in commit eeaffa891d on Apr 7, 2014
13. rdponticelli referenced this in commit 3bc866b88f on Nov 26, 2014
14. rubensayshi referenced this in commit 7345bbe452 on Mar 16, 2015
15. braydonf referenced this in commit 645ae33bec on Jun 28, 2016
16. luke-jr referenced this in commit 3a051b88a7 on Jun 19, 2017
17. KrzysiekJ referenced this in commit 6ed383e932 on Mar 28, 2018
18. effectsToCause referenced this in commit b159b8be15 on Jun 22, 2018
19. Warchant referenced this in commit 7958da26e8 on Dec 31, 2019
20. KolbyML referenced this in commit 2a007e3ba5 on Aug 1, 2020
21. jonasschnelli referenced this in commit 9453fbf5a0 on Oct 22, 2020
22. laanwj referenced this in commit 924a4ff7eb on Oct 29, 2020
23. rajarshimaitra referenced this in commit 0a12889659 on Mar 23, 2021
24. MarcoFalke referenced this in commit bce09da122 on Apr 28, 2021
25. MarcoFalke referenced this in commit eb9a1fe037 on May 7, 2021
26. MarcoFalke referenced this in commit c857148636 on May 15, 2021
27. rajarshimaitra referenced this in commit 429ea51284 on Aug 5, 2021
28. MarcoFalke locked this on Sep 8, 2021

Contributors
mikegogulski gavinandresen

Labels
Feature