Un sitio de comercio electrónico está utilizando billeteras BIP32 para recibir pagos de pedidos de un árbol de claves secundarias donde cada nodo de hoja es único para una transacción de compra.
¿Es común que el sitio envíe inmediatamente las monedas recibidas a su superwallet (nodo maestro) tras X confirmaciones? Si es así, ¿cómo haría para enviar todas las monedas en todo el árbol de claves secundarias (que pueden ser toneladas de nodos dependiendo de la cantidad de transacciones) a la súper billetera?
¿Y cómo sabría cuando se envía un pago a una de las direcciones derivadas?
Supongamos el caso con una ruta de derivación de m/k'/0/i, donde mestá el nodo maestro, cada usuario tiene un knodo y ies su i-ésima transacción de compra.
¿Es común que el sitio envíe inmediatamente las monedas recibidas a su superwallet (nodo maestro) tras X confirmaciones?
No. En absoluto, y normalmente se consideraría una práctica muy mala, ya que en bitcoin no se gasta de las direcciones sino de las transacciones, por lo que "acumular" en una dirección realmente no funciona. El envío desde esa dirección nuevamente tendría que hacer referencia a todas las transacciones reenviadas. (Hay casos especiales como la dirección verde en su implementación original pero no, eso es cosa del pasado).
¿Y cómo sabría cuando se envía un pago a una de las direcciones derivadas?
¿Ves la red bitcoin? Ya sea a través de proxies o con un nodo completo. Consulte la API de insight.bitpay.com.
Supongamos el caso con una ruta de derivación de m/k'/0/i, donde m es el nodo maestro, cada usuario tiene un nodo k e i es su i-ésima transacción de compra.
Recomiendo encarecidamente mantener esa lógica solo en el servidor.
El comercio electrónico suena como un servidor central, por lo que realmente no hay una gran necesidad de expandirse demasiado en la estructura de la billetera HD. También debe buscar en BIP44 en el descubrimiento de transacciones.
Su lógica comercial debe realizar un seguimiento del propósito que tiene una dirección, pero si ese sitio web nunca tiene que enviar reembolsos, normalmente solo tendría una clave pública extendida. Ahora si recibe a
m / 44' / 0' / i' / 0 / j
cualquier billetera compatible con bip44 encontraría y podría gastar los fondos si le proporcionara al menos la clave xpriv para
m / 44' / 0' / i' / 0
pero típicamente
m / 44' / 0' / i'
Una cosa menor que debe tener en cuenta es la brecha entre las direcciones que no reciben un pago. Si su servidor observa una brecha de más de 20, tendría que ayudar a su billetera a encontrar esos fondos si es estrictamente bip44, que solo cubriría brechas de hasta 20. Si su última transacción es para indexar 1220 y no ve transacciones al 1255 y al 1257, podrías enviar un satoshi al 1239 y tu billetera encontraría el resto.
¿Es común que el sitio envíe inmediatamente las monedas recibidas a su superwallet (nodo maestro) tras X confirmaciones?
No es necesario agregar sus activos provenientes de toneladas de transacciones en una sola dirección, pero no es tan poco común. Puede ser práctico si el volumen de direcciones que contienen algunas monedas se vuelve inmanejable (el número exacto depende del software de su billetera, los recursos del sistema, etc.).
Si esto sucede, simplemente puede enviar esas monedas en una gran transacción con múltiples entradas (para ahorrar en las tarifas de tx) a una dirección administrada por su "nodo maestro" .
¿Y cómo sabría cuando se envía un pago a una de las direcciones derivadas?
De la misma manera que sabías antes. Puede seguir viendo la dirección después de haber transferido los fondos a su dirección maestra. Si es necesario, puede realizar otra transacción de agregación más tarde.