Как решить проблему ограничения адресов Blockchain 20?

В настоящее время мы предлагаем вывод и депозит биткойнов на нашем веб-сайте. Blockchain API используется для обработки всех операций.

Единственная проблема заключается в ограничении 20 адресов Blockchain Receive API, как указано здесь: http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/

Теперь у нас есть много любопытных пользователей, которые нажимают кнопку депозита в биткойнах и фиксируют его, фактически не отправляя никаких транзакций, которые легко увеличиваются до 20 адресов. Какие есть способы снять это ограничение? У меня есть несколько идей, но они довольно громоздкие, а некоторые требуют полного переписывания кода и замены Blockchain API. Можете ли вы, ребята, предложить какое-либо понимание и / или совет? Как можно решить эту проблему элегантным и эффективным способом?

Я не думаю, что полностью понимаю вашу проблему, но не могли бы вы просто показывать один и тот же адрес пользователю, который хочет внести депозит, пока он действительно не внесет что-то на этот адрес? Конечно, это потребует больше вызовов API для проверки любых транзакций, которые платят на этот адрес.
Вы также должны иметь возможность запросить больше адресов после того, как вы используете начальные 20, верно?

Ответы (2)

Да, это проблема с кошельком HD. Блокчейн сделал запись в блоге о работе с этой проблемой. См. здесь: https://blog.blockchain.com/2016/06/15/receive-payments-api-update-address-gap-limits/#more-9024 .

Допустим, вам платят на первый адрес, адрес 1 — кошелек будет просматривать адреса 2-21 вперед, чтобы увидеть, есть ли какие-либо дополнительные средства или история транзакций по этим адресам. Если он ничего не найдет, он перестанет искать. Таким образом, если вам платят на адрес 22, программное обеспечение кошелька не увидит средства, потому что оно остановилось на 21. Однако, если вам платят на адрес 2, программное обеспечение кошелька будет просматривать адреса 3-22 вперед, видеть средства, которые были отправлены на адрес 22, а затем смотреть еще 20 вперед (адреса 23 – 43).

Начиная с 1 августа 2016 года мы будем отвечать на запросы API, в результате которых вы превысите ограничение в 20 адресов, с ошибкой HTTP, и мы не будем генерировать новые адреса для вашего xpub, пока не обнаружим платеж, который закроет этот пробел. ниже этого предела. Это гарантирует, что у вас никогда не будет недоступных средств при использовании Receive Payments API V2, но может привести к тому, что адреса не будут генерироваться, когда ваши пользователи запрашивают их.

Вы можете вызвать checkgap API через следующую конечную точку:

https://api.blockchain.info/v2/receive/checkgap?xpub= {xpub}&key={apikey}

Вы получите ответ JSON, который выглядит так:

{ "gap": 1 }

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

каков статус этого сейчас в мае 2019? есть ли способ уменьшить разрыв, аннулирующий неоплаченные адреса? может срок годности какой-то?
Я заметил, что в этой компании blockchain.info большинство их старых URL-адресов не работают. Как тот, который вы разместили в этом сообщении в блоге. (И это тоже не в машине обратного пути.)

До того, как появились новые ограничения API, правильный способ обработки биткойн-платежей был

  • Запросить отдельный адрес (открытый/закрытый ключ) для каждого пользователя
  • Сохраните новый адрес в учетной записи пользователя и отобразите общедоступную часть для транзакции
  • Слушайте обратный вызов от Blockchain.info
  • При поступлении обратного вызова проверьте, с какого адреса был произведен платеж, сколько было оплачено, проведите бизнес-логику и запросите новый адрес для этого пользователя.

После того, как новый API ввел ограничения на общее количество запрашиваемых адресов, с моей точки зрения, он стал бесполезен. По крайней мере, я не вижу, насколько "надежно" обрабатывать платежи с нескольких учетных записей пользователей одновременно.

-1, пожалуйста, сосредоточьтесь на ответе на вопрос, а не на представлении уже устаревшего решения и жалобах на его устаревание.