Estoy trabajando en un sitio web donde las personas deberían poder depositar BTC en los saldos de sus cuentas y luego hacer algo con estos saldos. Descubrí que necesito una billetera determinista y generar una dirección diferente para cada usuario (según la identificación del usuario) y tal vez para un depósito diferente (según el recuento total de depósitos del usuario; he leído que es la mejor práctica usar 1 dirección para 1 transacción) . Me gustaría poder notificar a los usuarios cuando veamos una transacción no confirmada y cuando se confirme (agregue el monto depositado al saldo de los usuarios).
Flujo de depósito :
1.1 al rawtxverificar si una de las direcciones de salida está en la base de datos ya que algunos usuarios depositan la dirección
1.2 si es la dirección de algunos usuarios, cree un nuevo depósito en DB con 0 confirmaciones y marque como pendiente
1.3 notificar al usuario que podemos ver su depósito pero aún no está confirmado y obtendrá BTC en su saldo una vez que esta transacción alcance 6 confirmaciones
1.4 en rawblockobtener todos los depósitos con menos de 6 confirmaciones y consulta blockchain.info para obtener el recuento de confirmaciones (ver problema c).
1.5 actualizar el recuento de confirmación y si es >= 6 asignar monedas al saldo + notificar al usuario sobre el cambio de saldo; a partir de ahora, su depósito se marcará como confirmado
Ahora problemas :
a) Si el servidor se desconecta por algún motivo (error de la aplicación/problemas de red/mantenimiento), es posible que el usuario aún pueda depositar monedas en la dirección previamente copiada y no detectaremos esa transacción, por lo que nunca pasará de 1.1 . En ZMQ, puedo detectar un problema de red al verificar el número de secuencia (¿y consultar RPC para obtener información faltante?). No puedo consultar todas las direcciones en el inicio de la aplicación para verificar si hubo depósitos mientras la aplicación estaba inactiva, por lo que debería conservar la última identificación del bloque (conocida por mi aplicación, actualizada después de 1.4) en la base de datos y al inicio simplemente verifique todos los bloques más nuevos para transacciones ya confirmadas (y realice 1.1 , 1.5 ) y verifique mempool para todas las transacciones no confirmadas y realice los pasos desde 1.1 -1.5 .
b) Mi otra idea para resolver a) el problema era realizar un seguimiento de las direcciones/usuarios sincronizados en la memoria/redis de las aplicaciones. Después de que el usuario se conecte (registros/inicios de sesión), verifique si dicho usuario ya estaba sincronizado en el tiempo de vida de esta aplicación (este inicio de aplicación - nodo index.js, matar, nodo inde.js serían 2 vidas - Espero que sepa a lo que me refiero) si el usuario está sincronizado, no haga nada y, si no, escanee todas las direcciones de usuario para todas las transacciones y verifique si ya se agregaron a la base de datos. Y marque al usuario como sincronizado. De ahora en adelante 1.4 , 1.5 debería encargarse del resto (?).
c) Preferiría no usar un servicio externo como blockchain.info y solo obtener información a través de RPC, pero todo el flujo de verificación de confirmación parece complicado debido a casos extremos como gastos dobles/reorganización de bloques. También tuve dificultades para usar el RPC de bitcoin-core (en parte porque primero sincronicé bitcoind y luego agregué índices y todavía los está sincronizando).
d) ¿ Meaby hay alguna otra forma más segura/más fácil/escalable de hacer esto?
De hecho, estos son problemas difíciles, pero afortunadamente ya están atendidos por BTCPay Server, con características adicionales como pagos relámpago: https://github.com/btcpayserver/btcpayserver .
Simplemente puede ejecutarlo a través de la receta de docker incluida ( https://github.com/btcpayserver/btcpayserver-docker ) y comunicarse con él a través de su API.
O si realmente desea volver a implementar las cosas esenciales usted mismo, mire su código o la documentación de la arquitectura.