Estoy creando una aplicación y el diseño es que la "página de bienvenida" tiene un código qr que permite al usuario comprar una aplicación de un solo uso.
Blockchain.info convenientemente le permite usar xpub para generar direcciones, sin embargo, sus documentos mencionan bip 44 y el "límite de brecha"... Esto es instantáneamente un problema como puedo imaginar, digamos 30 usuarios que van simultáneamente a la aplicación (más De manera realista, 30 usuarios que van a la aplicación por debajo de la cantidad de tiempo que le toma a un solo usuario comprar), a 20 se les presentarán direcciones de bitcoin para comprar, 10 no lo harán debido a los errores de límite de brecha de lanzamiento de API.
¿Qué opciones tengo para sortear esto?
Otros me han sugerido que solo genere manualmente un montón de claves privadas y no use xpub, pero tener que consolidar manualmente todas esas transacciones individuales por dirección suena como una pesadilla absoluta que me gustaría evitar.
ACTUALIZAR
¿Hay alguna forma de reutilizar la misma dirección cada vez, pero adjuntarle un guid para que cuando vea el txn transmitido, pueda vincularlo con la sesión de un usuario determinado? Esto es realmente todo lo que necesito. No necesito xpub. Solo necesito una forma de identificar que el usuario A y el usuario B están viendo la página de bienvenida, el usuario A no paga, el usuario B sí, el usuario B tiene acceso automáticamente, el usuario A no. .
Problemas relacionados con el límite de brecha como se resumen en esta publicación de blog . Básicamente tienes pocas opciones.
Aquí está mi solución.
Cuando se alcance el límite de brecha, agregue una cantidad de satoshi aleatoria y única a la cantidad total de bitcoin y asóciela con el usuario.
Por ejemplo, si el precio de su producto es BTC 0.001, genere una cantidad como 0.00100001 para el usuario A, 0.00100002 para el usuario B, ambos usando la misma dirección cuando se alcance la brecha.
Ahora, para el usuario A, utiliza la API de recepción de Blockchain.info. En la base de datos, registra el usuario A, el precio y la dirección.
Ahora, en el caso del usuario B, utiliza la API de actualización de saldo. En la base de datos, también registra el usuario B, el precio y la dirección.
Entonces, cuando reciba la notificación, puede verificar qué usuario realizó el pago al verificar el monto pagado.
*ok*para que le devuelvan la llamada. El segundo usuario envía dinero y la billetera no devuelve la llamada porque regresó *ok*a esa dirección antes. así que ya no monitorea. ¡Significa que ni siquiera puedes saber que el segundo usuario pagó!
pebwindkraft
Patricio
MCCCS