Parece que hay muchas formas de atravesar las direcciones de Bitcoin. Estoy buscando las mejores prácticas, y también estoy buscando la lógica documentada de cómo lo hacen las billeteras comunes para poder replicar su comportamiento.
Por ejemplo, Trezor crea la primera dirección en esta ubicación: m/49'/0'/0'/0/0, y luego la próxima dirección será m/49'/0'/0'/0/1, y pronto. Entonces, parece que sería fácil usar un iterador sobre el último dígito.
Pero, cuando gasta de m/49'/0'/0'/0/0, mueve el sobrante a m/49'/0'/0'/1/0 . Entonces, de repente, no solo tengo que iterar sobre el último dígito, también tengo que iterar sobre el penúltimo dígito. Podría haber dicho "penúltimo", pero dije penúltimo porque suena más inteligente.
¿Existe una práctica estándar para atravesar direcciones? Algo así como, ¿sigue recorriendo las direcciones hasta que llegue a una dirección sin transacciones? ¿O posiblemente decir tres direcciones seguidas sin transacciones? ¿O esto es realmente el salvaje oeste y hacemos lo que nos apetece?
La mayoría de las billeteras (pero no todas) seguirán lo que se especifica en los BIP 32 , 44 y 49 .
BIP 32 define qué rutas de derivación son y qué significan. Es el estándar para derivar todas las claves en una billetera HD.
Los BIP 44 y 49 especifican las rutas de derivación que deben usar las billeteras. BIP 44 define un formato de ruta de derivación estándar: m / purpose' / coin_type' / account' / change / address_index
. También define las purpose
claves de Bitcoin que no son segwit.
Cuando una billetera deriva las claves, la ruta para las claves externas, es decir, aquellas claves que obtiene al hacer clic en "Nueva dirección de recepción" (o similar) se m/44'/0'/0'/0/i
incrementa i
para las nuevas claves.
Para las claves internas, es decir, las claves para las direcciones de cambio, la ruta de derivación establecerá el change
campo en 1
, por lo que la ruta se m/44'/0'/0'/1/i
incrementará i
para cada nueva dirección de cambio que se necesite.
Dado que ese change
campo es esencialmente un booleano, no hay necesidad de iterar a través de ningún índice que no sea 0
y 1
.
BIP 49 especifica las purpose
claves for utilizadas para las direcciones segwit anidadas P2SH. Simplemente establece que el purpose
campo sea 49, por lo que las rutas de derivación serán m/49'/0'/0'/k/i
donde k
está el change
campo y i
es el address_index
. Los campos change
y address_index
siguen siendo los mismos que se definen en BIP 44.
Es importante tener en cuenta que no todas las billeteras siguen los BIP 32, 44 y 49. Por ejemplo, Armory usa su propio algoritmo de billetera HD que es anterior a BIP 32, aunque actualmente se está trabajando en la compatibilidad con BIP 32 para Armory. Otras billeteras, como Bitcoin Core y MultiBit HD, no siguen BIP 44. En su lugar, utilizan diferentes rutas de derivación. Para Bitcoin Core es m/k'/i'
donde k
está change
(misma definición que con BIP 44) y i
es address_index
(misma definición que con BIP 44).
colisionador de mallas
Christian Findlay
colisionador de mallas
Christian Findlay
Christian Findlay
Christian Findlay
Christian Findlay