We accept payment in Bitcoin: Part five, there are nuances

I've already covered most of what you'll need to implement a gateway to accept bitcoin payments. But, as always, in real life there are nuances...

It so happens that many cryptocurrencies have Bitcoin as their ancestors. With varying degrees of differences and varying levels of independence, however, much is inherited from the parent code. This includes litecoin, and DASH, and of course, Bitcoin Cash (the latter are generally almost an exact copy). Even something as exotic as Zcash carries a lot of bitcoin source code. 

As a side effect, we have an almost complete copy of the JSON-RPC implementation. And as a result, once you have implemented everything necessary for bitcoind, you have a fairly complete foundation for accepting payments in at least the listed cryptocurrencies. Of course, as the title says, there are nuances. Some commands may be different or give different results. For example, DASH does not know what multisig addresses are, and litecoind in some versions requires additional effort to generate an address in segwit format. But in general, everything is very similar, and adapting the finished code will not be difficult. 

But not everything in our lives is so rosy. Let's return to how we implemented accepting payments in bitcoin. The way we implemented this is good if you have several dozen payments per day. After all, it’s not that difficult to check even a hundred addresses for an incoming transaction. What if you were asked to write a gateway that accepts payments, for example, for ebay or amazon?

When in a week or two your database of issued addresses grows to several tens of thousands, the evening will cease to be languid. Bitcoind's response speed will begin to rapidly fall, and the flow of requests to it will rapidly grow. And checking the entire database will no longer take seconds or tens of minutes, but then hours. I think few people will want to wait a day for their payment to be processed. 

It’s good that the bitcoin developers took care of this, and their successors received ready-made functionality. Luckily for us, bitcoind can send a notification that an incoming transaction has been received. This was good news. Now - not very good. More precisely, several.

Firstly, bitcoind can report the fact that a new transaction has been received, but it won’t tell us a word about what address it was received at, but it will send us its tx-id, such a scary long string, something like:

ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

We’ve already seen it somewhere.. And we even know that you can ask:

bitcoin-cli gettransaction ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

and get complete information about it. This is good because, firstly, in the transaction information we will find which address it came to. And secondly, there can be many recipient addresses in a transaction, and theoretically there could be several of ours in it. 

Now about the nuances. Our bitcoind only sends notification 2 times. The first is when the transaction goes through the network, even before it is confirmed. The second is when the transaction is included in a block. That is, at the first confirmation. But if you want to recognize the payment as having taken place on the 6th confirmation, these notifications will not help you much. 

And one more unpleasant nuance. The fact is that bitcoind does not send a notification in the usual ways, such as the same RPC request. It can only execute a command within the operating system in which it operates. And pass the data as a parameter.

In the next article I will tell you how to live with this, and most importantly, how to set it all up.