Принимаем оплату в Bitcoin: Часть пятая, есть нюансы

Принимаем оплату в Bitcoin: Часть пятая, есть нюансы

Я уже рассказал большую часть того, что вам понадобится для реализации шлюза для приема оплаты в bitcoin. Но, как всегда, в реальной жизни есть нюансы…


Так сложилось, что многие криптовалюты имеют в предках именно bitcoin. С разной степенью отличий и разным уровнем самостоятельности, тем не менее, многое унаследовано от родительского кода. Это и litecoin, и DASH, и уж конечно, Bitcoin Cash (последние являются вообще практически точной копией). Даже такая экзотика, как Zcash несет много исходного кода bitcoin. 

Как побочный эффект, мы имеем почти полную копию реализации JSON-RPC. И как следствие, реализовав однажды все необходимое для bitcoind, вы имеете достаточно полный фундамент для приема платежей как минимум в перечисленных криптовалютах. Конечно, как и говорится в названии, есть нюансы. Некоторые команды могут отличатся или давать другой результат. Например, DASH не знает что такое multisig адреса, а litecoind в некоторых версиях требует дополнительных усилий для формирования адреса в формате segwit. Но в общем и целом, все очень похоже, и выполнить адаптацию готового кода не составит большого труда. 

Но не все в нашей жизни так радужно. Вернемся к тому, как мы реализовывали прием платежей именно в bitcoin. То, как мы это реализовывали - хорошо, если у вас проходит несколько десятков платежей в сутки. Ведь не так и сложно проверить даже сотню адресов на предмет входящей транзакции. А если вас попросили написать шлюз, который принимает платежи, например, для ebay или amazon?

Когда через неделю-другую ваша база выданных адресов разрастется до нескольких десятков тысяч, вечер перестанет быть томным. Скорость ответа bitcoind начнет стремительно падать, а поток запросов к нему - стремительно расти. И проверка всей базы начнет занимать уже не секунды и десятки минут, а потом и часы. Я думаю, мало кто захочет ждать сутки, пока его платеж будет обработан. 

Хорошо, что разработчики bitcoin об этом позаботились, да и их наследники получили готовый функционал. К нашему счастью, bitcoind умеет отсылать уведомление о факте получения входящей транзакции. Это была хорошая новость. Теперь - не очень хорошая. Точнее, несколько.

Во-первых, bitcoind умеет сообщить факт получения новой транзакции, но ни слова не скажет нам о том, на какой адрес она поступила, но зато пришлет нам ее tx-id, такая страшная длинная строка, что-то вроде:

ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

Где-то мы её уже видали. И даже знаем, что можно спросить:

bitcoin-cli gettransaction ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

и получить о ней полную информацию. Это хорошо, потому что, во-первых, в информации о транзакции мы найдем, на какой адрес она пришла. А во-вторых - в транзакции может быть много адресов получателей и теоретически наших в ней может оказаться несколько. 

Теперь о нюансах. Наш bitcoind отправляет уведомление только 2 раза. Первый - когда транзакция проходит по сети, еще до ее подтверждения. Второй - когда транзакция включена в блок. То есть, при первом подтверждении. А вот если вы хотите признать оплату состоявшейся на 6 подтверждении, эти уведомления вам мало помогут. 

И еще один малоприятный нюанс. Дело в том, что bitcoind не присылает уведомление привычными способами, вроде того же RPC-запроса. Он умеет только выполнить команду в пределах операционной системы, в которой сам работает. И передать данные в качестве параметра.

В следующей статье я расскажу как с этим жить, и самое главное - как это все настроить.


440

Свежие новости

Выбор редакции

Аналитика