Posted on Leave a comment

Hodl Trading Bitcoin

Hodl Bitcoin

Although it could be, HODL is not the acronym for “Hold On for Dear Life”, the term has its origin in December 18, 2013 in the Bitcoin Talk forum when the user GameKyuubi writes an entry titled “I AM HODLING”doubting his nature as a trader and stating his admiration for those who say they are capable of predicting movements in the price of bitcoin. That typographical error in the word HODLING where the letters D and L dance quickly became viral and the term hodl perpetuated. 

A trader is the person who trades short taking advantage of what he believes are the best times to buy and sell stocks or cryptocurrencies and thus make profits and mitigate losses. In contrast we would have the hodler who is the one who chooses to invest in a digital asset buying regularly over time and storing it waiting for it to revalue.

Like GameKyuubi I do not believe that in bitcoin trading, it is a good way to lose BTCs and where the 90-90-90 rule applies, 90% of new participants lose 90% of the money in their account in a maximum of 90 days. 

Trading in bitcoins for neophytes does not work, it is enough to compare the recommendations of the supposed experts with the subsequent behavior of the market, they are wrong, neither do the most used indicators of technical analysis such as moving averages, RSI (Relative Strength Index), retracement. Fibonacci bands, Bollinger Bands … Whales carry a lot of weight in the Bitcoin market, they are knowledgeable about the typical technical analyzes that traders follow and it is very easy for them to provoke trends in the short term. Everyone will value but the risk of loss when trading in this market is high.

On the other hand, the Hodl strategy is simple and if it works, to date the trend in the price of bitcoin has been upward, there is high volatility in the short term but its trajectory in the medium and long term is clearly upward.


Buying small amounts on a regular basis in an asset like bitcoin that is highly volatile has the advantage of ending up averaging the purchase price. Sometimes luck will be with you and you will have to acquire the BTCs when the price is low and others on the contrary you will buy in the ascending period, in the long run some will be compensated with the others and you will end up having an average purchase price of your BTCs. This way of operating is called DCA (Dollar Cost Averaging Into Bitcoin) and just as it is highly recommended to accumulate BTCs, I do not consider it as interesting to do with the Dollar or with the Euro since its value decreases over time.

When, on the contrary, you buy very few times but a large amount of bitcoins you do not have that averaging factor and you will be exposed to price volatility.

Bitcoin P2P platforms

A common way to hodle is to buy a reasonable amount weekly according to your income and do it in a place where you are not required to identify yourself, that is, without KYC (Know Your Client) to favor your privacy and do not have custody of your bitcoins , the sale is made between individuals. There are several sites where it operates as well as bisqhodlhodl… 

Exchange Bitcoin

There are those who prefer to automate the purchase and use an exchange for the purchase and the possibility that they offer to launch periodic purchase orders. In these cases, it is advisable from the point of view of security and privacy is once purchased to send them to a new address of a wallet that has the option of making CoinJoin such as Samourai wallet  and then send them to an address generated in your hardware wallet.

Hodl Trading Bitcoin

Finally and the most profitable from the economic point of view is to make the purchase through a trading order, taking advantage of the fact that historically the trajectory of the price of bitcoin has been upward. Reviewing the percentage of days in the history of Bitcoin in which buying BTCs has been profitable for investors at the current price, it is 96.2%. 

Instead of buying directly, a purchase order is registered for a lower price, for example at 95% of its current price, if in the period until the next purchase the price of BTC falls below that threshold the order is executed by making the purchase at a lower price than we would have bought directly if, on the contrary, it was not executed, we make the purchase at the market price and place the next purchase order. In addition to the advantage of having bought at a lower price, we have that purchase orders on traders’ sites have no commission and immediate purchase at market price does.

To clarify the operation, let’s take an example, let’s imagine that we buy BTC every Monday.

BTC Price: $ 10,000

Limit Price: $ 9500 (95% of BTC Price)

Amount: 0.002 (20 / BTC Price)

In the Trader

If the following Monday the purchase order has not been executed we have to make the manual purchase of the BTCs with the $ 20 and we will also place the next purchase order. 

The benefit of the Hodl Trading technique comes when the order is executed since in that case we have bought at 5% cheaper than we would have done if we had made the purchase directly.

Posted on Leave a comment

Generar claves privadas en Bitcoin de forma segura y barata

private public keys

Había empezado a escribir este post cuando buceando por Internet me he topado con varias páginas de bitcoiners que ya habían escrito sobre la generación de claves utilizando la herramienta BIP39 de Ian Coleman más el sistema Tails, así que me voy a limitar a poner los enlaces y a especificar los pasos a grandes rasgos.



  1. Descargar Tails, verificar la firma y copiarlo en un USB

Verificar la imagen

Copiar la imagen

dd if=tails-amd64-4.7.img of=/dev/sda bs=16M oflag=direct status=progress
  1. Arrancar el ordenador desde el USB de Tails y configurar el acceso a Internet.
  1. Descargar el fichero bip39-standalone.html de

Para la versión 0.4.3 el comando sería este:

wget -O /home/amnesia/Tor\ Browser\bip39-standalone.html
  1. Eliminar la conexión a Internet de Tails.
  1. Ejecutar bip39-standalone.html desde Tor-browser. 
tor-browser /home/amnesia/Tor\ Browser\bip39-standalone.html
  1. En la página cargada en el navegador generar las 24 palabras. Se puede añadir entropía para tener una mayor seguridad.
  1. Generar la passphrase con 6 palabras aleatorias de la lista Long Diceware Wordlist 

Salvar en sitio seguro

  • La lista de las 24 palabras de la semilla → Mi recomendación es hacerlo en una o varias placas de metal. Referencias Metal Bitcoin Seed Storage Reviews también podría valer una simple chapa de acero inoxidable.
  • Las 6 palabras de la passphrase → Guardarlas en una o varias placas de metal, distintas de las anteriores queremos almacenar la semilla y la passphrase en sitios distintos.
  • Derived Addresses → Son nuestras direcciones públicas donde tendremos que ingresar los fondos.
  • BIP32 Derivation Path → Este valor puede ser útil en un futuro al querer recuperar las claves privadas en un wallet.
  • Account Extended Public Key → Clave a partir de la cual podemos extraer todas nuestras claves públicas.
  • BIP32 Extended Public Key (XPUB) → Clave en formato BIP32 para extraer todas nuestras claves públicas.

El artículo traducido al Inglés está en “Generate private keys in Bitcoin safely and cheaply

Posted on Leave a comment

Import verification of Coldcard seed and passphrase at Electrum and Wasabi

Wallet Bitcoin

Before providing funds to our hardware wallet Coldcard (CC) It is important to make sure that in the future whatever happens we will be able to recover them.

Over the years many situations can arise whereby we find ourselves in the position of having to recover these funds without having the hardware wallet (hww), such as losing it or it being damaged and not being manufactured anymore, either because that model does not exist or because the company has closed. To this day we do not know which companies will exist and which will not exist in 10 years, and although it was still alive, technology evolves very quickly and within a few years devices that are now in common use may not be available, such as microSD memory cards, microUSB connectors, internal battery… 

Therefore it is vitally important to verify that we are going to be able to access the private keys that our hww handles. In this post we will test to recover these private keys from the CC addresses in other wallets from the generated seed and the passphrase that we have put.

There is documentation on this on the Coldcard website on how to carry out this operation, but I think that this is well worth a practical exercise to verify that this is the case. There is also apage walletsrecovery. where they give very valuable information about the compatibility between the different wallets.

  • Turn on the Coldcard, for this we connect it to an external USB charger or an adapter connected to a socket, never charge it with the USB connector of the computer we must keep the Coldcard always offline.
  • Put the prepin and the pin, you have to write it down because the device will request it whenever you turn it on. Do not save them on any digital medium or on the Internet, you have to minimize the risks.
  • Updating the firmware is optional but recommended, we will not go into it.
  • Create the wallet

Option: New Wallet

  • Add the passphrase and write it down because it is not saved in the hww. Important, it must be entered every time the Coldcard is started and you want to operate with these addresses.

Option: Passphrase → Edit Phrase → APPLY → OK

When you start the HWW it will not warn you that you have to enter it and the menus they have do not help but if you forget to enter it you will end up operating with other different Bitcoin addresses.

Option: Passphrase → A very long explanatory text but that is important because it indicates the problem of not entering it → Edit Phrase, It is not the best text for this option since what you have to do is enter your Passphrase and not edit it and then → APPLY → OK

When choosing the passphrase it is important that it is very difficult to discover on this page “Can BIP-39 passphrase be cracked?” they tell you how secure your password is.

  • Visualize your identity. 

Option: Advanced → View Identity to ensure that everything has been done correctly, we can check the fingerprint and that the text “BIP30 passphrase is in effect” appears to ensure that we are working with our passphrase.

  • Enter a microSD and export master public key (xpub) for the Electrum wallets and Wasabi which is where in the future we could import them.


microSD → Export Wallet → Electrum wallet -> Native Segwit

microSD → Export Wallet → Wasabi wallet

  • Saving addresses on the microSD card.

Option: Advanced -> Address Explorer -> 4 -> Select format (1b…) 1 

Generate a file addresses.txt in the microSD with 256 addresses.

  • Import the xpub in the Electrum wallet. 

It is recommended to run it within a Tails and not connect it to the Internet, it is not necessary for what we are going to do.

Take out the microSD card and connect it to the computer where we have installed the Electrum and Wasabi wallets.

  • Now we are going to create a wallet in Electrum with the same seed and passphrase that we have introduced in Coldcard.

Option: File → New / Restore

We choose the Standard Wallet option

We open the file addresses.txt exported from the CC to verify that the addresses shown by Electrum and those of Coldcard are the same.

Now we will perform the same check on the wasabi wallet.

  • We retrieve in Wasabi the wallet

It is not necessary and it is recommended for this exercise not to have the Wasabi connected to the Internet.

Option: Recover Wallet and introduce the seed and the passphrase

  • We load the Wallet

Option: Load Wallet

In the info of the wallet explorer we can verify that the Extended Master Fingerprint that shows wasabi matches the one that appears in Coldcard

  • Generate some addresses

Option : Recive 

When you restart wasabi it already shows the addresses

AND they actually match.

If initially only the Public Key appeared and not the address, we could perform the conversion to check that they are the same.

Address and Public Key at Electrum.

With this we have verified that from the Coldcard seed and passphrase we can recover the private keys in another wallet.

To summarize what we have to save to ensure recovery would be: 

  • The seed
  • The passphrase 
  • The type of address that we used in our case Native SegWit (bech32) which is the only one compatible with wasabi
  • The derivation paths “m / 84 ‘ / 0 ‘/ 0’ / 0 / XXXX ” 
  • It is recommended to also save an image of the Operating System together with the software used by Electrum and Wasabi. 

Another possible option for recovering private keys from seed and passphrase is to use the iancoleman bip39 web tool that has a downloadable version and works offline.

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.


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

Bitcoin Core update script to version 0.20.0

The Script executed BCubium the BGeometrics full node Bitcoin to update the Bitcoin Core software to the new version 0.20.0


PROCESS_DEP_BITCOIN="bitcoind lnd rtl btc-rpc-explorer"

if [ -n "$1" ]; then

systemctl stop $PROCESS_DEP_BITCOIN
su -c "wget" $USER_BITCOIN
su -c "bash" $USER_BITCOIN
su -c "$PATH_BITCOIN/bitcoin-core/bin/" $USER_BITCOIN
install -m 0755 -o root -g root -t $PATH_BITCOIN_INSTALL $PATH_BITCOIN/bitcoin-core/bin/bitcoin*
systemctl start $PROCESS_DEP_BITCOIN
rm -fr $PATH_BITCOIN/bitcoin-core/
rm -f
$PATH_BITCOIN_INSTALL/bitcoind --version | grep version

In Github:

Posted on Leave a comment

Are MicroSD cards worth to store the Blockchain of Bitcoin?

This is the question you have asked us the most, so we are going to answer it.

MicroSD cards have a bad reputation for long-term storage of information, this comes from old cards that had a low write limit and low-end cards that are very cheap but have high failure rates, there are only We do have to review the comments on the sales websites for these cards, but current and quality cards are valid for storing long-term information.

In the case of BCubium the card that comes is high-end, we only use two

Samsung Memory MB-MC512GAEU cards – Micro SD 512 GB Evo plus  

Lexar High-Performance 512GB 633x microSDXC UHS-I

These cards that cost between 4 and 5 times more than the low-end ones and have very good references by consumers.

Both Samsung and Lexar give a 10-year warranty on these cards.

These microSD are normally used in video and still cameras where the writing volume is very high and they respond very well.

In our case, the operating system is in the eMMC memory of the NanoPI Neo Plus 2 motherboard and the MicroSD card is used to store the Blockchain and it is already preloaded from our laboratory, so the read and write ratios are due to the operation. derived from the writing of the blocks every 10 minutes (approx.), the indexing of the transactions and the communication between the different full nodes of the network. This functionality involves an average number of card reads and a very low number of writes, which means that the card suffers very little because what most affects microSD is the writing of information.

Choosing a day at random the average rate of io per second is 742 kB of reading and only 53 kB of writing.

We can also see it at the moment by running the dstat tool, obtaining similar values:

So, making the full node functionality of Bitcoin plus a Lightning Network Daemon as it is done in BCubium, we have an average ratio of reads and very low write range microSD cards alta are a fully valid device for safe storage in the short, medium and long term. Commenting that the personal information of the node is not stored in the microSD, only the Blockchain is stored, so if it were damaged, another card could be inserted and the history of Bitcoin could be resynchronized.

Posted on Leave a comment

¿Valen las tarjetas MicroSD para almacenar la Blockchain?

Esta es la pregunta que más nos habéis hecho con diferencia así que vamos a contestarla.

Las tarjetas MicroSD tienen mala fama para el almacenaje de la información a largo tiempo, esto viene debido a las tarjetas antiguas que tenían un límite bajo de escrituras y a las tarjetas de baja gama que son muy baratas pero que tienen índices de fallo alto, solo hay que revisar los comentarios en las webs de ventas de estas tarjetas, pero las tarjetas actuales y de calidad son válidas para almacenar información a largo plazo.

En el caso de BCubium la tarjeta que viene es de alta alta gama, sólo utilizamos dos tarjetas

Samsung Memory MB-MC512GAEU – Micro SD de 512 GB Evo plus  

Lexar High-Performance 512GB 633x microSDXC UHS-I

Estas tarjetas que cuestan entre 4 y 5 veces más que las de baja gama y tienen muy buenas referencias por parte de los consumidores.

Tanto Samsung como Lexar dan una garantía de 10 años para estas tarjetas.

Estas microSD normalmente se utilizan en cámaras de vídeo y de fotografía donde el volumen de escritura es muy alto y responden muy bien.

En nuestro caso el sistema operativo está en la memoria eMMC de la placa base NanoPI Neo Plus 2 y la tarjeta MicroSD se utiliza para almacenar la Blockchain y ya viene precargada desde nuestro laboratorio así que los ratios de lectura y escritura son los debidos a la operativa derivada de la escritura de los bloques cada 10 minutos (aprox.), el indexado de las transacciones y la comunicación entre los distintos full nodes de la red. Está funcionalidad conlleva un número medio de lecturas de la tarjeta y un número muy bajo de escrituras lo cual significa que la tarjeta sufre muy poco porque lo que más le afecta a las microSD es la escritura de información.

Escogiendo un día al azar el ratio medio de io por segundo es 742 kB de lectura y sólo 53 kB de escritura.

También podemos observarlo al momento ejecutando la herramienta dstat, obteniendo valores similares:

Así que realizando la funcionalidad de full node de Bitcoin más un Lightning Network Daemon como se hace en BCubium tenemos un ratio medio de lecturas y muy bajo de escrituras las tarjetas microSD de gama alta son un dispositivo totalmente válido para el almacenaje con seguridad a corto, medio y largo plazo. Comentar que en la microSD no se guarda la información personal del nodo sólo se almacena la Blockchain por lo que si se estropease se podría introducir otra tarjeta y resincronizar el histórico de Bitcoin.

La versión del artículo en inglés “Are MicroSD cards worth to store the Blockchain of Bitcoin?“.

Posted on 1 Comment

Why don’t we use Docker in BCubium full node

Docker is a virtualization technology that allows the packaging of an application along with all its dependencies and libraries in one container. This resulting software container can be run on machines other than where it was created with the sole premise that they have the Docker containerization system.

Containerization technology is more efficient than virtualization of the entire operating system because it does not need to replicate the entire system but only what is necessary for the execution of the container. Docker uses Linux cgroups technology to manage container resources and achieve isolation between them.

The main advantages that containerization offers us are the following:

It provides consistency, since it contains both the application code and the libraries it uses, whether they are its own or those of third parties, plus the complete execution environment, for example in a Java application we would have the developed code, plus all the libraries it uses, plus the complete application server. Much fewer points of failure when running the application.

We achieve standardization and productivity, by using the same image for all environments, development, integration, quality, pre-production, production or whatever it is, it is easier for us to manage it, label it, make backups, rollbacks … It 

helps in continuous integration and application of the DevOps philosophy because it facilitates the automated execution of tests on the software and the promotion among the different existing environments.

It improves security by having separate and isolated containers since if an intruder compromises the application that runs inside a container, its scope is limited to that container and not to the entire system.

It is multi cloud, since in all public and private clouds they have environments that allow the execution of Docker containers.

On the other hand, as the number of containers grows, a system that manages and automates operations with them begins to be needed, which is why platforms such as Kubernetes, Rancher, Openshift appeared …

With containers and the platform for their management, the Greater advantage provided by this technological system, which is dynamic autoscaling depending on the load, very useful for large websites with many visits and with an irregular load. I explain it with an example, if we have a web application of a company where the number of visits is different depending on the time of day, the day of the month or the month of the year, which is normal, with containerization technology we can configure that when the system load grows and exceeds a certain threshold, new containers are installed to absorb this increase in demand and when that load decreases, the created containers are eliminated, thereby using only the necessary resources at all times and thus reducing the cost hardware provisioning.

So far everything very nice but … what do we have in most of the Bitcoin full nodes?

A basic hardware to run a full node along with other applications to extend functionality and facilitate management, are usually basic boards with a processor with few resources, with little CPU and with little RAM. In the case of BCubium even more because our hardware is very limited because we want to have a small node and we are running bitcoin-core, LND, BTC-RPC-Explorer, RTL, the node administration website and some other tool, and We do not see any gain for running it with Docker because:

The applications that are run have been developed by third parties, they already give them fully functional, they install without problems without the need to containerize them.

When they are already installed, they automatically incorporate all the libraries they need and those they need from the Linux operating system with their package system, allowing them to self-install.

We are not going to make modifications to these applications, that is, they are not going to have a development made by us, so I do not have to run any continuous integration system, test batteries, or promotion between environments.

The fact of executing them containerized supposes an extra consumption of resources since each container comes with its own operating system plus the tools that the container management needs, plus the libraries necessary for its execution, causing it to have duplicate libraries and tools in the different containers and in the end forces us to have a system with more powerful hardware when what we want is just the opposite, a minimal system.

For our part, at BGeometrics we carry out a development that is the node administration website, which is a small website, so there is no great profit for developing it using containers and we also have a set of scripts that use many applications and utilities of the operating system and It does not matter that they run in an isolated container because it would mean having to install all these tools in the containers and some of them need to have access to the guest operating system.

Docker execution complicates management as we now have, in addition to having to perform the operation of the installed software, we must monitor the execution of each container and the communications between them, which among other things means that we have to have another network interface in the system. . 

In our case, our system runs on a motherboard and a processor, and we have no interest in running it on a public cloud, so we lose the ease that migration containers bring to the cloud.

There is no point in dynamic autoscaling which is the great advantage of containerization since you are not going to install a system like Kubernetes when we have a few containers, the load is very low and constant and access to applications like BTC-RPC-Explorer or RTL is done very occasionally and by a single person …

Summarizing Docker is a great technology that is already here and will continue with us for a long time, if we add to that the orchestrators like Kubernetes and on these Ranchers, Openshift … we have the complete kit to achieve a customized dimensioning, but in a case like ours where what we want is to run software on minimal hardware we do not need those advantages and we avoid adding complexity to the system and having a greater consumption of resources.

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