Posted on Leave a comment

Verificación de la importación de la semilla y passphrase de Coldcard en Electrum y Wasabi

Wallet Bitcoin

Antes de proveer fondos a nuestro hardware wallet Coldcard (CC) es importante asegurarnos que en un futuro pase lo que pase vamos a poder recuperarlos.

Con el paso de los años se pueden dar muchas situaciones por las cuales nos encontremos en la tesitura de tener que recuperar estos fondos sin contar con el hardware wallet (hww), como puede ser perderlo o que se estropeé y que ya no lo fabriquen, ya sea porque ese modelo no existe o porque la empresa ha cerrado. A día de hoy no sabemos que empresas existirán y cuáles no dentro de 10 años, y aunque siguiese viva la tecnología evoluciona muy rápido y dentro de unos años dispositivos que ahora son de uso común podrían no estar disponibles, como las tarjetas de memoria microSD, los conectores microUSB, la batería interna… 

Por lo cual es de vital importancia verificar que vamos a ser capaces de acceder a las claves privadas que maneja nuestro hww. En este post haremos la prueba de recuperar estas claves privadas de las direcciones de CC en otros wallets a partir de la semilla generada y de la passphrase que hemos puesto.

Existe documentación al respecto en la web de Coldcard sobre cómo realizar esta operativa pero creo que esto bien merece un ejercicio práctico para verificar que es así, además existe una página walletsrecovery donde dan información muy valiosa sobre las compatibilidades entre los distintos wallets.

  • Encender la Coldcard, para ello la conectamos a un cargador externo de usb o a un adaptador conectado a un enchufe, nunca cargarla con el conector USB del ordenador debemos mantener la Coldcard siempre offline.
  • Poner el prepin y el pin, hay que apuntarlo porque el dispositivo te lo solicitará siempre que lo enciendas. No guardarlos en ningún medio digital, ni en Internet, hay que minimizar los riesgos.
  • Actualizar el firmware, es opcional pero recomendable, no vamos a entramos en ello.
  • Crear el wallet

Opción:  New Wallet

  • Añadir la passphrase y apuntarla porque no se guarda en el hww. Importante, hay introducirla cada vez que se arranca la Coldcard y se quiera operar con estas las direcciones.

Opción: Passphrase → Edit Phrase → APPLY → OK

Cuando inicies la HWW no te va avisar que tienes que introducirla y los menús que tienen no ayudan pero si se te olvida meterla acabarás operando con otras direcciones diferentes de Bitcoin.

Opción: Passphrase → Un texto explicativo muy largo pero que es importante porque te indica el problema de no introducirla  → Edit Phrase, No es el mejor texto para esta opción ya que lo que tienes hacer es meter tu Passphrase y no editarla y luego → APPLY → OK

A la hora de elegir la passphrase es importante que sea muy difícil de descubrir en esta página “Can BIP-39 passphrase be cracked?” te indican cuanto de segura es tu clave.

  • Visualizar tu identidad. 

Opción: Advanced → View Identity para asegurarnos que todo se ha realizado correctamente, podemos comprobar la fingerprint y que aparece el texto “BIP30 passphrase is in effect” para asegurar que se está trabajando con nuestra passphrase.

Opción:

microSD → Export Wallet → Electrum wallet -> Native Segwit

microSD → Export Wallet → Wasabi wallet

  • Guardado de las direcciones en la tarjeta microSD.

Opción: Advanced -> Address Explorer -> 4 -> Select formato (1b…) 1 

Genera un fichero addresses.txt en la microSD con 256 direcciones

  • Importar la xpub en el wallet de Electrum. 

Se recomienda ejecutarlo dentro de un Tails y no conectarlo a Internet, no es necesario para lo que vamos a realizar.

Sacar la tarjeta microSD y la conectamos en el ordenador donde tenemos instalados los wallets Electrum y Wasabi.

  • Ahora vamos a crear un wallet en Electrum con la misma semilla y passphrase que hemos introducido en Coldcard.

Opción: File → New/Restore

Elegimos la opción Standard Wallet

Abrimos el fichero addresses.txt exportado de la CC para verificar que las direcciones que muestra Electrum y las de Coldcard son iguales.

Ahora realizaremos la misma comprobación en el wallet wasabi.

  • Recuperamos en Wasabi el wallet

No es necesario y es recomendable para este ejercicio no tener el Wasabi conectado a Internet.

Opción: Recover Wallet e introducimos la semilla y la passphrase

  • Cargamos el Wallet

Opción: Load Wallet

En la info del wallet explorer podemos comprobar que la Extended Master Fingerprint que muestra wasabi coincide con la que aparece en Coldcard

  • Generar unas direcciones

Opción: Recive 

Al volver a iniciar wasabi ya muestra las direcciones

Y efectivamente coinciden.

Si inicialmente sólo nos apareciese la Public Key y no la dirección podríamos realizar la conversión para comprobar que son iguales.

Dirección y Public Key en Electrum.

Con esto hemos verificado que a partir de la semilla y la passphrase de Coldcard podemos recuperar las claves privadas en otro wallet.

A modo de resumen lo que tenemos que guardar para asegurarnos la recuperación sería: 

  • La semilla
  • La passphrase 
  • El tipo de dirección que hemos utilizado en nuestro caso Native SegWit (bech32) que es la única compatible con wasabi
  • Los paths de derivación “m/84’/0’/0’/0/XXXX” 
  • Es recomendable guardar también una imagen del Sistema Operativo junto con el software utilizado de Electrum y Wasabi.

Otra posible opción para la recuperación de las claves privadas a partir de la semilla y la passphrase es utilizar la herramienta web bip39 de iancoleman que tiene una versión descargable y que funciona off-line.

Enlace al artículo en Inglés “Import verification of Coldcard seed and passphrase at Electrum and Wasabi

Posted on Leave a comment

Por qué no utilizamos Docker en BCubium full node

Docker es una tecnología de virtualización que permite el empaquetado de una aplicación junto con todas sus dependencias y librerías en un contenedor. Este contenedor de software resultante puede ejecutarse en otras máquinas distintas a donde se creó con la única premisa que tengan el sistema de contenerización de Docker.

La tecnología de contenerización es más eficiente que la de virtualización del sistema operativo completo porque no necesita replicar todo el sistema sino únicamente lo necesario para la ejecución del contenedor. Docker utiliza la tecnología cgroups de Linux para gestionar los recursos de los contenedores y conseguir el aislamiento entre ellos.

Las principales ventajas que nos ofrece la contenerización son las siguientes:

Aporta consistencia, al contener tanto el código de la aplicación como las librerías que utiliza, ya sean propias o de terceros, más el entorno completo de ejecución por ejemplo en una aplicación Java tendríamos el código desarrollado, más todas las librerías que utiliza, más el servidor de aplicaciones completo. Muchos menos puntos de fallo a la hora de ejecutar la aplicación.

Conseguimos estandarización y productividad, al utilizar la misma imagen para todos los entornos, desarrollo, integración, calidad, preproducción, producción o los que haya nos es más sencillo gestionarla, etiquetarla, hacer backups, rollbacks… 

Ayuda en la Integración continua y la aplicación de la filosofía DevOps porque facilita la ejecución automatizada de pruebas sobre el software y la promoción entre los distintos entornos existentes.

Mejora la seguridad al tener contenedores independientes y aislados ya que si un intruso compromete la aplicación que se ejecuta dentro de un contenedor su ámbito de acción se limita a ese contenedor y no a todo el sistema.

Es multi cloud, ya que en todos los clouds públicos y privados tienen entornos que permiten la ejecución de contenedores Docker.

Por contra a medida que el número de contenedores crece se empieza a necesitar un sistema que gestione y automatice las operación con estos y por ello aparecieron plataformas como Kubernetes, Rancher, Openshift…

Con los contenedores más la plataforma para su gestión se consigue la mayor ventaja que nos aporta este sistema tecnológico que es el autoescalado dinámico en función de la carga, muy útil para websites grandes con muchísimas visitas y con una carga irregular. Lo explico con un ejemplo, si tenemos una aplicación web de una empresa donde el número de visitas sea distinto en función de la hora del día, del día del mes o del mes del año, que es lo normal, con la tecnología de contenerización podemos configurar que cuando la carga del sistema crezca y supere un determinado umbral se instancien nuevos contenedores para absorber ese aumento de la demanda y cuando esa carga decrezca se eliminen los contenedores creados consiguiendo con ello utilizar sólo los recursos necesarios en cada momento y así reducir el coste del aprovisionamiento de hardware.

Hasta ahora todo muy bonito pero… ¿qué tenemos en la mayor parte de los Bitcoin full nodes?

Un hardware básico para ejecutar un full node junto con otras aplicaciones para ampliar funcionalidad y facilitar la gestión, normalmente son placas básicas con un procesador con pocos recursos, con poca CPU y con poca RAM. En el caso de BCubium todavía más porque nuestro hardware es muy limitado porque queremos tener un nodo pequeño y en él estamos ejecutando bitcoin-core, LND, BTC-RPC-Explorer, RTL, la web de administración del nodo y alguna herramienta más, y no vemos ninguna ganancia por ejecutarlo con Docker por:

Las aplicaciones que se ejecutan han sido desarrolladas por terceros, ya nos las dan totalmente funcionales, se instalan sin problemas sin necesidad de contenerizarlas.

Cuando se instalan ya auto incorporan todas las librerías que necesitan y las que necesitan del sistema operativo Linux con su sistema de paquetes permite que se autoinstalen.

No vamos a hacer modificaciones sobre estas aplicaciones es decir no van a tener un desarrollo hecho por nosotros por lo que no tengo que ejecutar ningún sistema de integración continua, ni baterías de pruebas, ni promoción entre entornos.

El hecho de ejecutarlas contenerizadas supone un consumo extra de recursos ya que cada contenedor viene con su propio sistema operativo más las herramientas que necesita la gestión de los contenedores, más las librerías necesarias para su ejecución, lo provoca que tenga librerías y herramientas duplicadas en los distintos contenedores y al final nos obliga a tener un sistema con un hardware más potente cuando lo que queremos es justo lo contrario, un sistema mínimo.

Por nuestra parte desde BGeometrics realizamos un desarrollo que es la web de administración del nodo que es un website pequeño por lo que no hay una gran ganancia por desarrollarlo utilizando contenedores y también tenemos un conjunto de scripts que utilizan muchas aplicaciones y utilidades del sistema operativo y que no interesa que se ejecuten en un contenedor aislado porque supondría tener que instalar todas estas herramientas en los contenedores y algunas de ellas necesitan tener acceso al sistema operativo huésped.

La ejecución de Docker complica la gestión ya que tenemos ahora además de tener que realizar la operación del software instalado hay que vigilar la ejecución de cada contenedor y las comunicaciones entre ellos que entre otras cosas significa que tenemos que tener otro interfaz de red en el sistema. 

En nuestro caso nuestro sistema se ejecuta en una placa base y en un procesador y no tenemos ningún interés en ejecutarlo en una cloud pública por lo cual perdemos la facilidad que nos aportan los contenedores de migrado al cloud.

No tiene sentido el autoescalado dinámico que es la gran ventaja de la contenerización ya que no vas a instalar un sistema como Kubernetes cuando tenemos unos pocos contenedores, la carga es muy baja y constante y el acceso a las aplicaciones como BTC-RPC-Explorer o RTL se realiza muy de vez en cuando y por una una única persona…

Resumiendo Docker es una gran tecnología que ya está aquí y va a continuar con nosotros durante un buen tiempo, si a eso le sumamos los orquestadores como Kubernetes y sobre estos Rancher, Openshift… tenemos el kit completo para conseguir un dimensionamiento a medida, pero en un caso como el nuestro donde lo que queremos es ejecutar un software en un hardware mínimo no necesitamos esas ventajas y nos evitamos añadir complejidad al sistema y tener un mayor consumo de recursos.

La versión del artículo en inglés Why don’t we use Docker in BCubium full node