Claves criptográficas, direcciones, billeteras
CONTROLANDO LA PROPIEDAD DE FONDOS
Stéphane Roche
02-06-2019
CREATIVE COMMONS
Atribución-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0)
SOBRE STEPHANE
2015 2017–2019
Trabaja en Ledger - empresa de monederos de hardware Encontré Bitcoin Studio
Enfócate en la educación sobre Bitcoin
Consultor en Chainsmiths
Trabajar en Ethereum
• Aprender y jugar
Co-fundar una organización sin fines de lucro Asseth
• Contribuir a los contratos inteligentes ERC20 de Consensys
• Dether.io
2016–2017
https://www.bitcoin-studio.com
@janakaSteph en Twitter
[email protected]
INTRODUCCIÓN
•« Carteras » en un sentido amplio
• Aplicaciones para controlar el acceso al dinero, gestionar llaves y direcciones, rastrear el saldo, crear
y firmar transacciones, etc.
•« Billeteras » en el sentido técnico estricto
•Estructura de datos utilizada para almacenar y gestionar las claves del usuario
Las billeteras nunca contienen monedas, sino claves para desbloquear las monedas.
Los usuarios firman la transacción con las llaves, demostrando así que son propietarios de las salidas de la transacción.
La generación y gestión segura de claves son de suma importancia para la seguridad de
tus fondos
•Para el usuario final: elección de la billetera de la aplicación
•Para el desarrollador de la billetera: dominando la criptografía y los estándares de Bitcoin
La criptografía se puede utilizar para
Cifrado
•Demostrar conocimiento de un secreto sin revelar ese secreto (digital
firma)
•Probar la autenticidad de los datos (huella digital)
•Utilizado extensamente en bitcoin para controlar la propiedad de fondos, en forma de
claves, direcciones y billeteras
•La encriptación no es una parte importante de bitcoin
•Los datos de comunicaciones y transacciones no están cifrados y no lo hacen.
necesitan ser encriptados para proteger los fondos
ESQUEMA
1 Criptografía de clave pública en Bitcoin
2 Mnemotécnico y semilla raíz
3 Derivación de claves de billetera HD
4 Estructura de billetera HD
Direcciones de Bitcoin (tipos, codificación)
5
6
1 CLAVE PÚBLICA
CRIPTOGRAFÍA
EN BITCOIN
Par de claves ECDSA para controlar el acceso a bitcoin
Clave pública utilizada para recibir fondos
•Clave privada utilizada para firmar digitalmente transacciones, con el fin de gastar los fondos
La firma se puede validar contra la clave pública sin revelar la clave privada.
Las claves son completamente independientes del protocolo de bitcoin
•Pueden ser generados y gestionados por el software de la billetera del usuario sin referencia
a la blockchain o acceso a internet
•PKC permite muchas de las propiedades interesantes de bitcoin
•Confianza y control descentralizados
•Atestación de propiedad
•Modelo de seguridad con prueba criptográfica
•Sistema abierto y sin permisos
Bitcoin utiliza un EC específico y un conjunto de constantes matemáticas conocidas como
secp256k1
•y2= x3+ ax + b donde a = 0 y b = 7
•Recomendado por los Estándares para la Criptografía Eficiente; no es una curva del NIST
A diferencia de las curvas NIST populares, las constantes de secp256k1 fueron seleccionadas de manera predecible.
manera, que reduce significativamente la posibilidad de una puerta trasera
Problema de maleabilidad de firma
•ECDSA no es fuertemente inquebrantable existencialmente contra mensajes elegidos adaptativos.
Ataque (SEUF-CMA)
•No forjabilidad existencial: difícil forjar una firma en un nuevo mensaje
•Corregido por una regla de política que requiere una codificación canónica « low-s » (Bitcoin PR #6769)
CLAVE PRIVADA
Una clave privada es simplemente un número entre 1 y 2256, elegido al azar
El rango de claves privadas válidas está regido por el estándar ECDSA secp256k1
•Necesitar una fuente segura de entropía (CSPRNG)
•1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
256 bits mostrados como 64 dígitos hexadecimales, cada 4 bits
Aproximadamente 1077en decimal
•Para comparación, se estima que el universo visible contiene 1080 átomos
CLAVE PÚBLICA
La clave pública se calcula a partir de la clave privada utilizando multiplicación EC
•K = k * G
La multiplicación de EC es irreversible (función unidireccional)
Una clave pública es un punto de coordenada (x,y) en una curva elíptica
•Con una curva P-256, la pubKey se representará como dos valores en el campo de 256 bits.
La simetría de la curva respecto a un eje horizontal hace posible la compresión
La representación de una curva definida sobre un campo finito produce dos puntos para cada valor de x
•Uno de estos puntos tendrá un valor y par, y el otro un valor y impar
COMPRESIÓN DE CLAVE PÚBLICA
• La SEC define formatos de serialización (sin comprimir y comprimidos)
La pubKey comprimida tiene 33 bytes en lugar de 65
FORMATO WIF
Formato de Importación de Billetera
Una forma de codificar una clave privada para facilitar su copia y exportación
•Two different pubKey formats (compressed and uncompressed) produces
dos direcciones de bitcoin válidas diferentes
•Por lo tanto, las carteras necesitan saber si la clave privada se ha utilizado para producir comprimido o
claves públicas sin comprimir
•Agregar un byte 0x01 => clave pública comprimida
•WIF / WIF-compressed
•BIP178 en discusión para integrar el tipo de salida en el WIF
Las claves privadas no se comprimen en sí mismas y no se pueden comprimir.
FORMATOS DE CLAVE PRIVADA
FORMATO DE CLAVE PRIVADA MINI
•Método de codificación de una clave privada de Bitcoin en tan solo 30 caracteres para el
el propósito de estar incrustado en un espacio pequeño
•El primero de los caracteres siempre es la letra mayúscula S
Los hologramas de la Serie 1 de Casascius utilizan un formato minikey de 22 caracteres,
en lugar de 30 caracteres
•Para determinar si la miniclave es válida
Agrega un signo de interrogación al final de la cadena de clave privada mini
•Toma el hash SHA256 de toda la cadena
Si el primer byte es 00, la cadena es un minikey bien formado
•Ejemplo: SzavMBLoXU6kDrqtUVmffv
BIP-38 - CLAVE PRIVADA PROTEGIDA POR FRASE SECRETA
•Propuesto por Mike Caldwell también conocido como Casascius en 2012
•Intendidas para su uso en billeteras de papel y Bitcoins físicos
•Cifrar una clave con una frase de contraseña
•Delegar la clave y la creación de direcciones a un par no confiable
•Cifrar una clave privada sin multiplicación EC
Ofrece la ventaja de que cualquier clave privada conocida puede ser encriptada.
La parte que realiza la encriptación debe conocer la frase de acceso
•Cifrado de una clave privada con multiplicación EC
•La idea es generar un código intermedio. Con este código intermedio, un tercero podrá
generate encrypted keys on the user behalf, without knowing password nor any clear private key
•Sólo la persona que conoce la frase de acceso original puede descifrar la clave privada
No ofrece la capacidad de encriptar una clave privada conocida.
•Utiliza salting y el KDF Scrypt para resistir ataques de fuerza bruta
2 MNEMOTÉCNICO Y
SEMILLA RAÍZ
BIP-39 – Código mnemotécnico para generar claves deterministas
•Describe cómo generar un código mnemotécnico
Describe cómo convertir el mnemónico en una semilla binaria
•Aleatoriedad generada por computadora
Fácil de respaldar y transportar
Los mnemotécnicos son más prácticos que las claves privadas
•No es necesario hacer copias de seguridad regularmente
Las frases creadas por el usuario (también conocidas como carteras cerebrales) son menos seguras
•WarpWallet brainwallet: PBKDF2(password/email)⊕ Scrypt(contraseña/correo electrónico)
Bastante bien si el usuario utiliza una contraseña única
•Pero sin derivación BIP32, solo un par de claves
•Nowallet en pre-alfa utiliza el mismo algoritmo, con soporte para BIP32/44
BIP39 WORDLISTS
• Disponible enhttps://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-
listas_de_palabras.md
2048 palabras en lenguaje natural
(2047)10(11111111111)211 bits
•Inglés, japonés, coreano, español, chino, francés e italiano
Basta con escribir las primeras cuatro letras para identificar la palabra de manera inequívoca
Se evitan palabras similares
Los caracteres nativos deben estar codificados en UTF-8 utilizando la Forma de Normalización.
Descomposición de compatibilidad (NFKD)
ESTIRAMIENTO DE CLAVE MNEMOTÉRICA BIP39
PBKDF2
•Aplica una función pseudorandom (HMAC-SHA512) a mnemotécnico + contraseña
Repite el proceso muchas veces para producir una semilla
•2048 rondas es débil
•Esto equivale a agregar 11 bits adicionales de seguridad a la semilla (2048 = 211)
•BIP39 fue creado para funcionar en monederos de hardware (propuesto por el equipo de Trezor)
•No hay problema mientras el mnemotécnico sea generado por un CSPRNG
•Contraseña (sal) opcionalmente añadida a la mnemotecnia
Reduce la capacidad de usar hashes precomputados (tablas arcoíris) para ataques
•Proporciona una negación plausible, porque cada contraseña genera una semilla válida
No sobreestimes tu capacidad para recordar esta contraseña
SISTEMA DE VERSIONES DE SEMILLA ELECTRUM
•Codificar con un número de versión, directamente en la semilla, cómo derivar las claves
•Pro: las billeteras no tienen que escanear diferentes llaveros. Tratar P2PKH, P2SH-P2WPKH,
Bech32 como cadenas de llaves separadas
•Desventaja: necesitas generar una nueva semilla cada vez que quieras usarla para
algo nuevo
La generación de semillas de Electrum no sigue BIP39
El método no está formalizado en un BIP
•Durante la generación de semillas, la frase mnemotécnica se hash hasta que el hash comienza con el correcto
prefijo del número de versión
•Logrado enumerando un nonce y rehaciendo el hash de la frase semilla hasta que se desee
se crea el número de versión
•El número de versión también se utiliza para verificar la integridad de la semilla; para ser correcto, una semilla
la frase debe producir un número de versión registrado
LISTA DE NÚMEROS RESERVADOS DE ELECTRUM
Número Escribe Descripción
0x01 Estándar Carteras P2PKH y Multisig P2SH
0x100 Segwit Segwit: monederos P2WPKH y P2WSH
0x101 2FA Carteras autenticadas en dos factores
3 BILLETERA HD
DERIVACIÓN DE CLAVE
BIP32 - CARTERAS DETERMINISTAS HIERÁRQUICAS
•BIP32 defines a framework for HD wallet (and suggests a structure)
Sistema para derivar un árbol de pares de claves a partir de una única semilla
•Tree-like structure => hierarchical
La estructura de árbol se puede usar para expresar un significado organizativo adicional
Todas las llaves se derivan de una única llave maestra, conocida como la semilla.
Las llaves están relacionadas entre sí
•Puede generarse de nuevo si se tiene la semilla original => determinista
•Prevenir copias de seguridad desactualizadas
•Las carteras se pueden compartir parcial o totalmente con diferentes sistemas, cada una con o
sin la capacidad de gastar monedas
CREANDO CLAVES MAESTRAS Y CÓDIGO DE CADENA A PARTIR DE UNA SEMILLA RAÍZ
FUNCIONES DE DERIVACIÓN DE CLAVES HIJAS BIP32
•Dado una clave extendida de padre y un índice i, es posible calcular el hijo correspondiente.
clave extendida
•Clave privada del padre → Clave privada del hijo
•CKDpriv((kpar, cpar), i)→(kyo, cYo)
•Calcula un XPRIV hijo a partir del XPRIV padre
•Verificar si i≥ 231(si el niño es una llave endurecida)
•Si es así HMAC-SHA512(código de cadena, k, i)
Si no HMAC-SHA512(código de cadena, punto(k), i)
Clave pública del padre → Clave pública del hijo
•CKDpub((Kpar, cpar), i)→(Kyo, cyo)
•Calcula un XPUB hijo a partir del XPUB padre
•Solo definido para claves de hijo no endurecidas (volver a fallar si i≥ 231)
•Clave privada del padre (neutra)→Clave pública del hijo
•N((k, c))→(K, c)
•Calcula el XPUB a partir del XPRIV correspondiente
El siguiente paso es encadenar varias construcciones CKD para construir un árbol.
•CKDpriv(CKDpriv(CKDpriv(m,3H),2),5) == m/3H/2/5
•CKDpub(CKDpub(CKDpub(M,3),2),5) == M/3/2/5
Cada nodo hoja en el árbol corresponde a una clave real, mientras que los nodos internos
corresponden a las colecciones de claves que descienden de ellas
Se ignoran los códigos de cadena de los nodos hoja, y solo se utiliza su privado incorporado.
o la clave pública es relevante
•Debido a esta construcción
Conocer un XPRIV permite la reconstrucción de todas las claves privadas descendientes y
claves públicas
Conocer un XPUB permite la reconstrucción de todos los descendientes no endurecidos.
claves públicas
DERIVACIÓN DE CLAVE PRIVADA DEL NIÑO
CKDpriv normal
CKDpriv endurecido
DERIVACIÓN DE CLAVE PRIVADA DE NIÑO NORMAL
DERIVACIÓN ENDURECIDA DE UNA CLAVE INFANTIL
LLAVES ENDURECIDAS
•Clave hijo no endurecida
•Hash(clave pública del padre + código de cadena + índice 0 a 2^31-1)
Un atacante que compromete una clave privada puede escalar la derivación
ruta combinándola con un código de cadena XPUB no endurecido
•Clave de niño endurecida
•Hash(clave privada del padre + código de cadena + índice 2^31 a 2^32-1)
El XPRIV endurecido crea un firewall
No pueden ocurrir compromisos en la derivación de claves multinivel (intergeneracionales)
•Pero la derivación pública de M ya no es posible
EXTENDED KEY
•Clave extendida = clave (256 bits) || código de cadena (256 bits)
•Formato de serialización: [magia][profundidad][huella digital del padre][índice de clave][código de cadena][clave]
El término también podría considerar como una "clave de extensión"
•Tal clave se puede utilizar para derivar hijos
Raíz de una rama en la estructura de árbol de la billetera HD
Compartir una clave extendida da acceso a toda la sucursal
•XPUB
•XPUB puede derivar claves públicas hijas no endurecidas (solamente)
•Puede crear una rama de claves públicas solamente
•Permite el uso de billeteras HD en un servidor inseguro o en una capacidad solo para recibir
•XPUB + clave privada principal puede derivar claves privadas no endurecidas de hijos
•XPRIV
•XPRIV puede derivar claves no endurecidas y endurecidas
DERIVACIÓN DE CLAVE PÚBLICA DE NIÑO DIRECTAMENTE DESDE XPUB
•Porque el xpub contiene el código de la cadena, si se filtra una clave privada hija,
it can be used with the chain code to derive all the other child private keys
•A single leaked child private key, together with a parent chain code, reveals all the private
llaves de todos los niños
Peor aún, la clave privada del niño junto con un código de cadena de padre se puede usar para deducir el
clave privada del padre
La derivación endurecida "rompe" la relación entre la clave pública padre
y código de cadena de hijos
•Creates a "firewall" in the parent/child sequence
El código de cadena no se puede utilizar para comprometer una clave privada de un padre o un hermano.
El "ramal" resultante de claves se puede usar para producir claves públicas extendidas que no son
vulnerable, porque el código de cadena que contienen no puede ser explotado para revelar ninguna información privada
llaves
•XPUB debe ser tratado con más cuidado que las claves públicas regulares
COMPROMISO INTERGENERACIONAL CLAVE
SLIP132 - BYTES DE VERSIÓN PARA CLAVES EXTENDIDAS BIP32
•Actualmente hay un intenso debate en la lista de correo bitcoin-dev y en los problemas de github
• Utilizado primero en la billetera Electrum, seguido de Trezor y otros
Con la activación de SegWit, el número de formas de codificar una dirección
la clave pública ha aumentado
•Utiliza los bytes de versión BIP32 para codificar también el tipo de scripts de salida de una billetera
debería derivar a lo largo del subárbol HD
El programa de billetera no tendría que adivinar el espacio de direcciones
•Dar una indicación al usuario sobre qué esquema de derivación está implementado
SLIP132 - VERSION HD REGISTRADA BYTES
Moneda Clave Pública Clave privada Codificación de Direcciones
Bitcoin 0x0488b21e - xpub 0x0488ade4 - xprv P2PKH o P2SH
Bitcoin 0x049d7cb2 - ypub 0x049d7878 - yprv P2WPKH en P2SH
Bitcoin 0x0295b43f - Ypub 0x0295b005 - Yprv P2WSH en P2SH
Bitcoin 0x04b24746 - zpub 0x04b2430c - zprv P2WPKH
Bitcoin 0x02aa7ed3 - Zpub 0x02aa7a99 - Zprv P2WSH
4 BILLETERA HD
ESTRUCTURA
ESTRUCTURA DE CARTERA HD
La estructura de la billetera HD está definida por una ruta BIP32
Cada nivel en ese camino tiene un significado especial
•Cada nivel divide el espacio de claves
BIP32 también sugiere una estructura de billetera (utilizada por Bitcoin Core)
BIP43 sugiere un campo de propósito para billeteras deterministas
•BIP44 es el estándar de Bitcoin
También se convirtió en el estándar de facto para muchas cadenas de bloques
BIP47 para códigos de pago reutilizables para billetera HD
•BIP49 para billeteras Segwit (P2SH-P2WPKH)
•BIP84 para monederos Segwit nativos (P2WPKH)
BIP43 - CAMPO DE PROPÓSITO PARA BOLSILLOS DETERMINISTAS
•BIP43 sugiere que el software de billetera intentará diversas derivaciones existentes
esquemas dentro del marco BIP32
•O el usuario necesita mover sus monedas (cf. BIP44 => BIP49)
Se basa en la suposición de que las billeteras futuras admitirán todas las anteriores.
métodos de derivación aceptados
•Teniendo que explorar las ramas del árbol BIP32 para determinar
el tipo de billetera vinculada a una semilla podría ser algo ineficiente
BIP44 - HIERARQUÍA MULTI-CUENTA PARA
BILLETERAS DETERMINISTAS
•Define una jerarquía lógica para billeteras deterministas
•Based on an algorithm described in BIP32
•Permite el manejo de múltiples monedas, múltiples cuentas, externas y
cadenas internas por cuenta
•m / purpose' / coin_type' / account' / change / address_index
•El apóstrofe indica que se utiliza la derivación endurecida BIP32
•Propósito
•Constante establecida en 44'
•Sigue la recomendación BIP43
•Indica que el subárbol de este nodo se utiliza de acuerdo con la especificación BIP44
Derivación endurecida
•Coin type
•Constante definida en SLIP44
•Bitcoin: 0, Ether: 60, Waves: 5741564, etc.
Crea un subárbol separado para cada criptomoneda
•Evita reutilizar direcciones entre criptomonedas, mejorando problemas de privacidad
Derivación endurecida
Cuenta
•Índice (utilizado como índice hijo en la derivación BIP32)
•Organizar los fondos para diferentes propósitos (donación, ahorros, gastos comunes, …)
Derivación endurecida
Cambiar
•Constante 0 para el llavero externo
Usado para generar nuevas direcciones públicas, para recibir pagos.
•Escanear durante el descubrimiento de cuentas, límite de brecha de 20 direcciones
•Constante 1 para el llavero interno
•Direcciones para el cambio de la cadena externa asociada
Las direcciones no se comunican
La derivación pública se utiliza a este nivel
•Índice
•Índice, utilizado como índice de hijo en la derivación BIP32
La derivación pública se utiliza en este nivel
EJEMPLOS DE RUTA BIP32
moneda cuenta cadena dirección path
Bitcoin primero externo primero m / 44' / 0' / 0' / 0 / 0
Bitcoin primero externo segundo m / 44' / 0' / 0' / 0 / 1
Bitcoin primero cambiar primero m / 44' / 0' / 0' / 1 / 0
Bitcoin primero cambiar segundo m / 44' / 0' / 0' / 1 / 1
Bitcoin segundo externo primero m / 44' / 0' / 1' / 0 / 0
Bitcoin segundo externo segundo m / 44' / 0' / 1' / 0 / 1
Bitcoin segundo cambiar primero m / 44' / 0' / 1' / 1 / 0
Bitcoin segundo cambio segundo m / 44' / 0' / 1' / 1 / 1
BIP47 - CÓDIGOS DE PAGO REUTILIZABLES PARA CARTERAS HD
El protocolo BIP47 extiende la billetera HD BIP44
•Sin embargo, las monedas que se recibieron en una dirección de Código de Pago solo se pueden acceder utilizando un BIP47
billetera compatible
Los códigos de pago añaden información de identidad a las transacciones
•Una clave pública extendida y los metadatos asociados que están relacionados con un particular
identidad/cuenta
•Se puede publicitar públicamente
•Proporciona los beneficios de privacidad de las Direcciones Ocultas al estilo de Darkwallet a los clientes SPV
•PayNym Bot: avatar visual generado de manera única a partir de un hash de tu BIP47 reutilizable
código de pago
•Ten cuidado, BIP sigue siendo controvertido, algunas personas dicen que no está lo suficientemente bien diseñado
•m / purpose' / coin_type' / identity' / 0
El 0º (no endurecido) hijo es la clave de notificación
•m / purpose' / coin_type' / identity' / 0 through 2147483647
•Estos pares de claves (no endurecidos) se utilizan para ECDH para generar depósitos
direcciones
•m / propósito' / tipo_de_moneda' / identidad' / 0' a 2147483647'
•Estos (endurecidos) pares de claves son códigos de pago efímeros
BIP49 - ESQUEMA DE DERIVACIÓN PARA P2WPKH NESTED EN P2SH
CUENTAS BASADAS
•P2SH-P2WPKH es el formato temporal para Segwit (utilizado para suavizar
transición, compatibilidad de billeteras
BIP49 define el esquema de derivación para billeteras HD que utilizan P2SH
Formato de serialización P2WPKH (BIP 141) para transacciones segwit
El usuario necesita crear una billetera segwit P2SH-P2WPKH dedicada.
•Asegura que solo las billeteras compatibles con BIP49 detecten las cuentas y las manejen.
apropriadamente
•m / purpose' / coin_type' / account' / change / address_index
• Mismo camino BIP44 excepto que el propósito es 49
BIP84 - ESQUEMA DE DERIVACIÓN PARA CUENTAS BASADAS EN P2WPKH
•P2WPKH es el formato nativo para Segwit
BIP84 define el esquema de derivación para billeteras HD utilizando P2WPKH
(BIP173) formato de serialización para transacciones segwit
El usuario necesita crear billeteras Segwit dedicadas
•Asegura que solo las billeteras compatibles con este BIP detecten las cuentas y
trátalos adecuadamente
•m / purpose' / coin_type' / account' / change / address_index
• Mismo camino BIP44 excepto que el propósito es 84
5 BITCOIN
DIRECCIONES
(TIPOS, CODIFICACIONES)
Nivel de usuario
Pero normalmente no lo ve.
Nivel de blockchain
Nivel de usuario
¿Qué se muestra en realidad?
BASE58CHECK
La mayoría de los datos presentados al usuario están codificados en Base58Check.
•Dirección de Bitcoin, clave privada, clave encriptada, hash de script, ...
•Ayudar a la legibilidad humana, evitar ambigüedades y proteger contra errores en la transcripción
Usa 58 caracteres (un sistema numérico Base58)
•Conjunto de letras minúsculas y mayúsculas y números sin 0, O, l, I
Código de verificación de errores incorporado (suma de comprobación)
•Representación compacta
Dirección Bitcoin Base58Check
•[versión de un byte 0x00][HASH160 pubKeyHash de 20 bytes][checksum de 4 bytes]
Dirección P2SH Base58Check
•[versión de un byte 0x05][HASH160 de 20 bytes redeemScriptHash][checksum de 4 bytes]
CODIFICACIÓN BECH32
• Nuevo formato de dirección Segwit especificado por BIP 173
• Al igual que Base58, es un azúcar para el usuario final, bech32 nunca está en la cadena de bloques
•Solo codifica scripts de testigos (P2WPKH y P2WSH). No compatible con P2PKH no segwit
o scripts P2SH
Una dirección segwit es una codificación Bech32 de
La parte legible por humanos "bc" para mainnet, y "tb" para testnet
•El separador « 1 »
•Los valores de data-part: script de testigo codificado con checksum
•Varios beneficios sobre Base58Check
El código QR es más pequeño
•Detección de cualquier error que afecte a un máximo de 4 caracteres (códigos BCH)
Corrección de errores
•Solo consiste en minúsculas, debería ser más fácil de escribir y leer en voz alta
•Excluye los caracteres "1", "b", "i" y "o"
Aumento de la seguridad
CONCLUSIÓN
El desarrollo de la billetera aún se encuentra en una fase exploratoria
Aún tenemos que diseñar el esquema mnemotécnico/semilla/derivación perfecto
•Los estándares se distribuyen entre BIPs, SLIPs y un estándar de facto que no está en un documento formal
Los estándares nunca son perfectos y están en constante evolución
•Los estándares no siempre se siguen, y está bien.
•Bytes de versión xkey de Electrum, aezeed de LND, ...
•Muchos de los estándares implementados aún están en estado de borrador
•Tenemos herramientas muy básicas para características avanzadas (bloqueos de tiempo, contratos personalizados,
elegir UTXOs, esquemas de privacidad, …)
Con Bitcoin eres tu propio banco
•Al final, no puedes confiar en nadie
Las billeteras no ofrecen ninguna garantía en cuanto a la calidad o fiabilidad de su producto.
Lo que significa que en algún momento necesitas aprender todo eso.
Es útil saber qué esquema de derivación utiliza tu billetera (BIP44, BIP49,
personalizado...)
Elige tu billetera con cuidado
•El más famoso, utilizado, renombrado
La versión oficial
•No más que dinero de bolsillo en la versión beta
•Verificar qué BIPs son compatibles
•Verificar la suma de verificación MD5, compilación de Gitian
• Usa múltiples billeteras en caso de que una tenga un problema
Necesita una correcta gestión de claves
Filtrar una mnemotecnia/clave privada significa pérdida de monedas
Filtrar una clave pública significa perder privacidad
Se debe tener más cuidado con las llaves extendidas (todo el árbol de llaves)
•Compartición Secreta de Shamir tu mnemónico
•Sé organizado (Excel, revisión regular del acceso a fondos, …)
BIBLIOGRAFÍA
Interfaz gráfica avanzada para la derivación de claves de billetera HD
• https://iancoleman.io/bip39/
Guía del Desarrollador de Bitcoin
• https://bitcoin.org/es/guia-del-desarrollador#billeteras
Dominar Bitcoin, Andreas Antonopoulos
• https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc
• https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc
•BIPs de billetera HD
• https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki