Quoting for archival purposes. But wow, you catch on quick.
No kidding. When I saw this, freeloader247 became my favorite person.
I still haven't had a chance to read his programs in detail, but he's certainly on the right track.
Also what is a proper transaction flow? Currently I have things set up like this, but as it is advised to avoid both accounts and getbalance this is clearly wrong.
- Registration: getnewaddress for user setaccount to user ID.
- Transaction: getbalance of users account and confirm that is larger than purchase price.
When you create a new address to accept a payment, stash a copy in your local database, along with whatever identification you need. This could be as simple as {address,order number} or {address,userid}. Since the notification system is transaction based, you use something like gettransaction or getrawtransaction with the
verbose flag for processing.
If you pair this up with -blocknotify, you can really minimize the number of slow RPC calls you have to make.
Basically, you gettransaction each time -walletnotify triggers until it returns 1 confirmation. If you want 6 confirmations, you make a note to come back and check again after -blocknotify hits 5 more times. At that point, gettransaction
should read 6 confirmations. If it doesn't, then congratulations, your system was clever enough to not get fooled by a chain reorg, put it back in the queue to be checked again after X more blocks.