Какие варианты у меня есть, чтобы избежать лимита пропусков API? Я использую ключи xpub

Я создаю приложение, и дизайн таков, что «страница приветствия» имеет код qr, позволяющий пользователю приобрести одноразовое использование приложения.

Blockchain.info удобно позволяет вам использовать xpub для генерации адресов, однако в их документах упоминается bip 44 и «лимит промежутка». на самом деле, 30 пользователей заходят в приложение меньше, чем время, которое требуется одному пользователю для покупки), 20 будут представлены биткойн-адреса для покупки, 10 не будут из-за ошибок API, выбрасывающих пробел.

Какие варианты у меня есть, чтобы обойти это?

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

ОБНОВИТЬ

Есть ли способ каждый раз повторно использовать один и тот же адрес, но прикрепить к нему guid, чтобы, когда я вижу транслируемый txn, я мог связать его с сеансом данного пользователя? Это действительно все, что мне нужно. Мне не нужен xpub. Мне просто нужен способ определить, что пользователь A и пользователь B просматривают страницу приветствия, пользователь A не платит, пользователь B платит, пользователю B автоматически предоставляется доступ, пользователь A не .

@pebwindkraft, к сожалению, этот пост не предлагает никакого решения или предложения.
Используйте github.com/bitcoin/bips/blob/master/… ? Вам нужна реализация?

Ответы (2)

Проблемы, связанные с ограничением пропусков, кратко изложены в этой записи блога . В основном у вас есть несколько вариантов

  • Используйте кошельки, такие как Электрум, чтобы увеличить настройку лимита гэпа.
  • Автоматически отправляйте небольшую сумму средств на 20-й незарегистрированный адрес, чтобы поддерживать работу. Этим занимаются такие сервисы, как блокономика
  • Продолжайте генерировать новый адрес, не беспокоясь об ограничении пропусков. Позже вы можете сгенерировать все закрытые ключи с помощью xprv и вывести средства со всех закрытых ключей.
может дать мне больше информации о 3-м варианте?

Вот мое решение.

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

Например, если цена вашего продукта составляет 0,001 BTC, сгенерируйте сумму, например 0,00100001 для пользователя A, 0,00100002 для пользователя B, используя один и тот же адрес при достижении разрыва.

Теперь для пользователя A вы используете API получения Blockchain.info. В базе данных вы записываете пользователя А, цену и адрес.

Теперь в случае пользователя B вы используете API обновления баланса. В базе данных вы также записываете пользователя B, цену и адрес.

Поэтому, когда вы получаете уведомление, вы можете проверить, какой пользователь сделал платеж, проверив уплаченную сумму.

Это не решение. Это может привести к катастрофе. не стоит давать адрес двум пользователям одновременно и ждать, если один из них отправит сумму. Как насчет времени, когда двое из них отправили сумму?! Это не маленький залог. Это очень большой недостаток этого метода.
Первый пользователь отправляет деньги, и вы возвращаетесь *ok*для обратного звонка. Второй пользователь отправляет деньги, а кошелек не выполняет обратный вызов, потому что вы возвращались *ok*по этому адресу ранее. так что больше не мониторит. значит можно даже не знать второй платный пользователь!
Еще одно лучшее решение для этого, вы можете использовать уведомление «Обновление баланса».
Ожидание большего количества обратных вызовов после оплаты одного — это плохо. Возможно, вы получите первый обратный вызов с подтверждением для 2-го пользователя за 48 часов. Обновление баланса не является решением для ограничения разрыва. Кажется, HD-кошельки не для торговцев. У них есть большой недостаток для интернет-магазинов, и они не могут работать с большими или даже маленькими интернет-магазинами.
Маленький или большой залог не имеет значения. оба они равны неисправной системе.