2

I want to have a server running that will be processing payments and refunds. However, I also want to ensure that should my server die, that after a restart I will continue sending out any applicable refunds without sending a refund to someone I have already sent one too. I plan on using a WAL to achieve this, but I need to know what to store in the WAL. Is it possible to know your transaction ID before submitting the transaction?

That way I could just log the ID before submitting, and if I crash, I can just check the blockchain to see if that transaction already exists or not.

This seems like it would be a common problem for payment processors, but looking at the JSON-RPC documentation it appears that you only ever get the transaction ID after submitting the sendfrom/sendtoaddress.

  • I suspect this can be achieved by creating a raw tx, then storing that in the WAL before attempting to send the tx. Then, after a crash, I can verify which transactions are in the blockchain and which aren't, but I dont know if this is the best way or not. – senecaso Jun 13 '13 at 13:21
2

You can check blockchain for the latest transactions of the address you are using for refunds.

Get the latest transactions of the address from the blockchain and compare those to the refunds in your system to see which ones you were able to send and which ones you weren't before the crash.

  • 1
    But I need a way to uniquely identify a refund. Address+amount isn't necessarily unique, so I have no way of knowing which transactions from the blockchain match to which transactions in my outgoing queue. Am I missing something? – senecaso Jun 13 '13 at 13:20
  • No you're right. Note that this is a really extreme case. You need to have sent the coins and before you can save the transaction on your db the machine needs to crash. Checking the address works but you need to use a unique address for each refund. – Emre Kenci Jun 13 '13 at 13:37
  • 1
    Using a unique address is an interesting idea, however, how long do you wait after a crash to determine if a transaction ends up on the blockchain or not? You could very easily end up retransmitting due to a hiccup in the transactions processing (or my network connection). As I said above, I suspect the only safe way to do this is to store the signed raw tx in the WAL before sending and then replay it after a crash. That way the bitcoin network prevents the double spend for me. However, I'm not convinced there isnt an easier/cleaner way to do it. – senecaso Jun 13 '13 at 14:38
  • @senecaso The transaction id is always unique, you could use that. – Nick ODell Jun 13 '13 at 18:46
0

You could do this by chaining the refund and the transaction that you received. This way you could issue the refund as often as your system crashes without incurring the risk of returning more than you need. This is a bit tricky and you need to use the API from bitcoind but SatoshiDice has been using it successfully to return winnings. What you do is take the output that was sent to you and spend it in a transaction that refunds the sender. Since an output can be claimed at most once, the refund will be sent only once.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.