Hasta donde yo sé ( y como se explica aquí ), las billeteras deterministas jerárquicas mantienen un par de claves maestras (privadas y públicas). Al usarlos, la clave pública se genera nuevamente en cada transacción. Comprendí que las claves secundarias se generan mediante la multiplicación elíptica de las claves principales. Se afirma que los beneficios asociados con las billeteras HD son:
Si bien entiendo más o menos el concepto teórico, lucho con la implementación práctica del proceso y, en particular, con la forma en que el sistema asocia el saldo de varias transacciones (asignadas a diferentes claves públicas derivadas) a la misma "cuenta" de bitcoin. o clave pública maestra?
¿Alguien puede hacer una aclaración "para tontos"?
¿Cómo asocia el sistema el saldo de varias transacciones (asignadas a diferentes claves públicas derivadas) a la misma "cuenta" de bitcoin o clave pública maestra?
El sistema debe conocer el XPUB (a menudo la clave pública maestra) para que pueda generar todas las direcciones para 'observar'.
Si bien estamos en el tema de las claves públicas maestras y la privacidad, hay muchas cosas que puede hacer mal. Compartir su clave pública maestra (XPUB) es una mala idea, ya que la otra parte podrá ver todas sus direcciones. He visto muchos proyectos haciendo esto, básicamente destruyendo tu privacidad.
BIP47, todavía un borrador y no implementado, tiene como objetivo resolver este problema de privacidad y aún ofrece el beneficio de direcciones infinitas de las billeteras HD.
Pero lo que describe, el acto de compartir una clave pública maestra y permitir que el CLIENTE obtenga las direcciones es malo y no es el caso en la mayoría de los sistemas. Es mucho más probable que el SERVIDOR obtenga las direcciones y mantenga en secreto la clave pública maestra.
Entonces, supongamos lo siguiente:
Tenemos la clave pública a través de la cual se pueden derivar todas las demás claves públicas nuevas (y, por lo tanto, nuevas direcciones).
Hemos recibido una transacción en la dirección 15.
Estamos arrancando un nuevo nodo y haciendo una descarga de bloque inicial y, por lo tanto, hemos procesado 0 bloques.
Perdimos nuestro archivo wallet.dat anterior, por lo que no tenemos ni idea de en qué direcciones hemos recibido dinero. Recuperamos nuestra billetera a través de la clave pública como se describe en 1.
En este momento, la billetera HD realmente no sabe en qué direcciones ha recibido dinero, pero para verificar si las transacciones nos pertenecen, ha vuelto a generar un "LOOKAHEAD" de las primeras 20 direcciones. Esas 20 direcciones potencialmente utilizadas se agregan al conjunto de claves, todas las transacciones nuevas a estas direcciones nos pertenecen.
Un bloque se procesa con una transacción para la dirección 15, esto cae dentro de nuestra anticipación de 20, por lo que podemos recogerlo. Regeneramos más direcciones anticipadas una vez que encontramos una transacción en una de nuestras direcciones .
Esta búsqueda anticipada es importante, supongamos que realizamos una búsqueda anticipada de 10, no estaríamos observando la dirección 15, solo hasta la dirección 10. No veríamos nuestra transacción. (nota: esto solo se aplica si perdió su wallet.dat y se recuperó de la semilla)
BIP44 especifica que el "límite de brecha de dirección" sea 20.
El límite de la brecha de direcciones está establecido actualmente en 20. Si el software llega a 20 direcciones no utilizadas seguidas, espera que no haya direcciones utilizadas más allá de este punto y deja de buscar en la cadena de direcciones.