Blockchain para Superdummies


Blockchain? Si, claro. Eso es lo de las Bitcoins, no? mmmm pues bueno. Si.
Pero además es un estupendo buzzword del que muchos hablamos, incorporamos a nuestro discurso (he estado en reuniones donde se planteaba la creación de comisiones de Blockchain ) y pretendo explicarlo un poco en este post pos veraniego de forma cero técnica. Es más, casi consigo que mi madre, una señora de edad indeterminada (la que ella quiera), entienda el concepto básico (eso, o la inmensa paciencia de una madre con el friki de su hijo)

Al final del post comento igualmente donde reside el interés de Microsoft en la plataforma Blockchain y Azure en el mundo de la empresa.Blockchain Info Logo

Y lo mejor es recurrir en la medida de lo posible a ejemplos cotidianos.
Ya que acabamos de terminar el verano, supongamos, y es un suponer, que mi hija mayor se hubiera ido alegremente de vacaciones con sus amigos, y debido a algunos contratiempos (aunque a mi me parecieran más que previsibles: gasolina, comida.. vamos… llamadme vidente ) se ha quedado sin dinero antes de lo previsto, y si quiero tenerla de vuelta en algún momento, tendré que transferirle dinero para el viaje de regreso. Tras valorar los pros y contras de tenerla de vuelta 😉 (pobrecita, ella sabe que es broma), decidimos hacerle esa transferencia de 20€.

Es mi hija, hay confianza, hay voluntad de hacer esa transferencia, y por parte de ella, sin duda, de recibirla. Pero aun así, yo estoy en Madrid, mi hija en Cádiz, y necesitamos de un tercero que “bendiga” esa transacción. La Bendición consiste en comprobar que yo soy yo, que tengo más de 20€ en mi cuenta, que tengo la voluntad de dárselos a mi hija, que mi hija los acepta (lo garantizo si más ciencia de por medio), que se suman en su cuenta y que desaparecen de la mía.

Ese tercero, mi banco en este caso, en el que apenas pongo un pie por cierto (todo lo hago on line), y que bien podría cambiar de un día para otro a golpe de click, habrá creado en algún momento un apunte donde quede registrado que:

El 5 de Agosto del 2017, Héctor transfirió 20€ a Marina.

Esto solo lo sabemos Yo, el Banco y por supuesto Marina.
Nadie ha tocado un billete (ni mi hija, que lo utilizó para echar gasolina y pago desde su tarjeta de debito). Es decir, lo único que realmente ha ocurrido es la creación de un apunte en un registro creado por un tercero, el banco, en el que todos hemos acordado confiar.

Es decir, que para establecer una relación de confianza entre mi hija Marina y yo hemos dependido de un tercero. Sin valorar la confianza o no que podamos tener en ese tercero, todo comienza con la pregunta… ¿Por qué? ¿No hay alguna otra forma en la que podamos crear y mantener ese registro, que al final parece ser lo más importante, sin que un único tercero en concreto tenga que hacerlo por nosotros?

Adicionalmente, alguien podría pensar que la ubicuidad física del banco, existencia de cajeros, etc, es un valor importante. Bien. Es cierto, aunque en este caso concreto, no hiciera ninguna falta. Y es que es evidente que la posibilidad de transmisión de información, cualquier tipo de información, de un punto a otro en plena era Internet NO solo está al alcance de una entidad financiera.

Pues como podemos ir adivinando, la respuesta a esta situación que hemos planteado respecto a la “vida” de ese registro, se basa en Blockchain.
Volvamos a Marina y a su Padre, que soy yo.Bitcoin

¿Tenemos alguna forma de no depender de un único tercero de confianza para crear y mantener ese maldito registro de los 20€? Pues si. La forma es depender de muchos.
Es decir, tiene que haber mucha más gente que no quiera depender de un solo tercero de confianza en sus transacciones, y que además estén dispuestos a mantener una transparencia insólita respecto a los movimientos de sus finanzas, en la misma medida que lo hago yo.
Es decir, no solo Marina y yo compartiremos la información de ese registro de los 20€ que le transferí, sino que esa información la compartimos además con toda esa comunidad que ha decidido, al igual que nosotros, confiar en este nuevo sistema de confianza en lugar de en una sola entidad (bancaria, en este caso).
Ahora todos los que participamos en este mecanismo sabemos que Héctor le hizo una transferencia de 20€ a Marina el 5 de Agosto del 2017 porque TODOS tenemos una copia idéntica de ese registro donde se van anotando las transacciones.
En esa hoja aparece que Héctor le hizo una transferencia a Marina de 20€, pero también que Pilar se la hizo a Andrés de 45€, que Juan recibió una transferencia de Manuel de 2500€ ….. etc… Y esa hoja, con TODOS los apuntes que vamos anotando, está en poder de TODOS.

Todos han podido ver mi intención de transferir 20€ a Marina, y ver que previamente tenía al menos esa cantidad en mi cuenta para poder hacerlo. Y todos han tomado nota en sus registros de esta transacción. En ese momento, la transacción ya está completa y es efectiva. Enhorabuena Marina. De vuelta a casa.

Creo que es bueno adelantar, llegados a este punto, y ante el más que probable susto que algún lector habrá sentido al leer cosas como “transparencia insólita de mis finanzas”, “todos sabemos lo de todos”, “ todos han podido ver mi transacción a Marina” etc.. que estoy utilizando identidades de personas para facilitar la compresión del mecanismo y solo con fines didácticos. En la realidad, las identidades de los usuarios de blockchain no están asociadas ni almacenan ninguna información sobre la identidad física y real de las personas. Son un pseudónimo. Una identidad en blockchain no será más que una clave pública (elemento fundamental en los sistemas de criptografía asimétrica pero que obviamente no es el objetivo de este post explicarlo aquí) sin asociación a ninguna identidad física. De hecho es común que una misma persona pueda utilizar diferentes identidades en Blockchain por motivos o propósitos diferentes.

Volvamos al ejemplo. Muchos pensareis que la cantidad de registros que tenemos que ir copiando todos es enorme. Y en efecto lo es. Por eso cada vez que completamos una hoja con un número determinado de registros, la cerramos, la almacenamos, y abrimos una nueva para seguir apuntando nuevas transacciones y registros.

El proceso de ir cerrando y almacenando esa pila de hojas de registros es muy importante. Ahí reside la memoria histórica de todo lo que ocurre en el sistema y por tanto de ello depende su futura consistencia y fiabilidad.

Por eso lo mejor es que esas hojas con los registros que vayamos completando, apilando y almacenando, los protejamos adecuadamente.

Para ello todos hemos decidido utilizar un mecanismo para proteger esa información según la vayamos almacenando. Pero… ¿Protegerla de qué?
¿Qué es lo peor que podría pasarle a esa información almacenada para que el sistema se viniera abajo?
¿Vulnerar la confidencialidad de esa información? Noooo. Hemos dicho que todos conocemos las transferencias que todos han hecho y recibido.
¿Qué alguien la robe? ¿Perdón? Tenemos millones de copias. Al menos cada persona tiene o ha tenido una copia ….
¿Qué alguien vulnere su integridad, es decir, que modifique algún registro? ¿Os imagináis que alguien pudiera generar nuevos registros falsos?¿O duplicarlos llevando el sistema a situaciones de “doble gasto” (en este caso los mismos 20€ utilizados no solo por Marina, sino también por.. ¿Nadia? desde la más árida estepa Siberiana?) Eso si sería un problema. Bueno, mas bien eso sería EL PROBLEMA.
Por tanto pensemos de que forma garantizamos entro todos la INTEGRIDAD de esos registros almacenados. Es decir, como nos aseguramos que esa información permanece inalterable bajo 7 llaves (de ello depende todas las garantías que sustentan el sistema).
Sin eso, todo se desmoronaría como un castillo de naipes. Si alguien consiguiera sustituir los 20€ de Marina por 20000€, el sistema ...y yo... nos resentiríamos de muerte. O si nuestra Nadia consiguiera gastarse los mismos 20€ de Marina, pero en polvorones “La Estepa” al otro lado del mundo, el sistema simplemente ya no nos serviría para nada.
Es por eso por lo que este mecanismo de protección de la integridad de los registros es sin duda la piedra angular de todo el mecanismo y donde reside parte de la sofisticación del sistema Blockchain.

Hasta aquí, tecnología cero.

Pero ahora si hace falta entender un sencillo concepto ampliamente conocido para cualquier ingeniero o matemático, pero probablemente desconocido para personas menos técnicas. Lo llamaremos algo así como “la prueba del 9” de que algo no ha sido modificado (la he llamado así para seguir manteniendo enganchado a cualquier lector no técnico, igual que la podría haber llamado la “función chivata” o cualquier otra cosa). En este caso, la garantía de que todas las hojas almacenadas permanecen integras y nadie ha modificado ningún dato. Esa “prueba del 9” de la integridad (o P9 que llamaré a partir de ahora), se llama función de Hash (Lo sé, es obvio para muchos, pero intento dejarme en el camino al menor número de personas).

Dejando de lado toda la criptografía asociada a esa función, recordemos que pretendemos ser cero técnicos, sepamos que esa función se caracteriza por devolver un resultado diferente y único a una entrada concreta. Es decir, si a nuestra función “Prueba del 9” le damos como dato de entrada el número 20, nos devuelve un resultado. Por ejemplo, y me lo invento, el resultado es este palabro: Xds21Wa.
Y SIEMPRE que presentemos el número 20 a la función, nos dará el mismo resultado: Xds21Wa. Y será único. Es decir, ningún otro número de entrada a la función dará el mismo resultado.
Por otro lado, no hay forma de aplicar esa función en sentido contrario. Es decir, si nos dan el palabro Xds21Wa, nunca podremos deducir que viene del número 20. Tan solo podremos confirmar una y otra vez que dando como entrada el número 20, SIEMPRE obtenemos Xds21Wa.

Por qué es útil esto? Porque si aplicamos esta función “prueba del 9” a la famosa hoja de registros almacenados cuya integridad queremos proteger a toda costa, obtendremos un resultado diferente para cada hoja. ¿Y si alguien modificara un registro de esa hoja? Pues nuestra función “prueba del 9” daría un valor diferente.
Es decir si aplicamos “Prueba del 9” a nuestra hoja número 324, nos dará el resultado único de R34t%6dg (me lo acabo de inventar de nuevo). Y cualquiera, en cualquier lugar del mundo que aplique la función “Prueba el 9” a la Hoja 324, obtendrá idéntico resultado (R34t%6dg).
Si alguien hábilmente modifica un registro de nuestra Hoja 324, al aplicar la función “Prueba del 9” dará un resultado distinto a R34t%6dg, dejando en evidencia ante todos, porque todos podemos efectuar esa operación, que algún registro ha sido modificado. Por tanto, no admitiremos esa modificación.

El Sudoku es un buen ejemplo para entender el concepto detrás de estas funciones: difícil de resolver, pero muuuyyy sencillo de comprobar por cualquiera.

Releyendo hasta aquí creo que no habré perdido a nadie por el camino. Pero vamos a complicarlo solo un poquito, de verdad, con tres operaciones nuevas:

Primera: Supongamos que nos inventamos una condición al resultado de aplicar la función “Prueba del 9”.
Por ejemplo ¿Cuántos números, A, me darán como resultado de aplicarles la función “prueba del 9”, un resultado que empiece, por ejemplo, por “1234”? Es decir, algo así:

P9(A)=1234...

Ufff. Pues me parece que no nos va a quedar más remedio que comenzar a probar números y números a lo bruto para ver cuáles de ellos dan como resultado algo que empiece por “1234”. Y es que no hay una forma aritmética de deducirlos porque precisamente las funciones de Hash (nuestra función “Prueba del 9”) están diseñadas para que no sea posible deducir el número de entrada de una función, dado el resultado.
Por tanto creo que estaremos de acuerdo que solo podemos hacerlo por fuerza bruta. Es decir, comenzando a introducir números y números y números en nuestra función “prueba del 9” e ir quedándonos con aquellos cuyo resultado haya comenzado por 1234. Es importante entender en este punto que lógicamente esto requerirá un esfuerzo computacional, verdad?

Al final, de tanto probar y probar, habremos encontrado por ejemplo que nuestra Función “prueba del 9” aplicada al número, por ejemplo, 39874, nos ha dado el resultado 12349845.
Por tanto el número 39874 cumple la condición.
Y resulta que la función “prueba del 9” aplicada al número 3909001, también nos ha dado como resultado el numero 12349082375, cumpliendo igualmente la condición que habíamos definido.
Es decir, de todos los números que hemos ido probando hasta este momento, ya hemos encontrado dos, el 39874 y el 3909001, que cumplen la condición de dar como resultado un número que empiece por 1234. Pues bien, podemos seguir buscando.

Segunda: Vamos a añadir un pequeñísima dificultad en este proceso. No se trata más que de prestar un poco de atención a ese dato de entrada de nuestra función “Prueba del 9”. Vamos a cambiar ese dato de entrada por una suma de dos datos en lugar de un solo dato, ok? Es decir, en lugar de hablar de un número, al que se le aplica la función “Prueba del 9”, y que nos da un número que cumple la condición de comenzar por 1234, hablaremos de una suma de dos números a los que le aplicamos la función “prueba del 9”. Algo así como:

P9(A+B)=1234…..

Es decir, nuestra función “Prueba del 9”, que aplicada a la suma de A más B, cumpla la condición de dar un número que comience por 1234, ok?
Ya nos habremos dado cuenta de que el número de soluciones será infinito a no ser que fijemos el valor de uno de los dos números. Hagámoslo. Fijamos el valor de A=20, por ejemplo.
Ahora tengo que aplicar la función “prueba del 9” a la suma de 20, el valor de A, más un número B para que nos de un número que comience por 1234, ok?. Algo así:

P9(20+B)=1234….

Ahora tendríamos que probar en nuestra función “prueba del 9” un montón de valores de B para que, sumados a 20, nos de como resultado un número que cuando se le aplique la función P9, cumpla la condición de empezar por 1234, ok?
Bueno. No parece una complejidad muy grande respecto a lo anterior, verdad?. Pero en este caso es interesante ver que estamos encontrando una bonita relación casi romántica obsesiva entre un par de números, convirtiéndose uno en el “guardián” del otro. B guardará la integridad de A, y A guardará la integridad de B.
Es decir, podríamos decir que la integridad de A esta garantizada por B. Si alguien modificara A, al sumarse con B y aplicar a la suma nuestra función “prueba del 9”, daría un número que no comenzaría por 1234, dejando en evidencia la vulneración de la integridad de A. Y Viceversa.
Podríamos decir que B se convierte en el garante de la integridad de A.
Si volvemos por fin al ejemplo del registro de la olvidada transacción que hice a mi hija Marina por importe de 20€, podemos identificar esa transacción como la transacción A, y B será el guardian de que nadie modifique esa transacción. Si alguien modificara esa transacción A, al añadirle el valor de B (su guardian), veríamos que al aplicar la función “prueba del 9” a la suma, el resultado no cumpliría la condición de comenzar por 1234 (en un caso real la condición es diferente a esta simpleza que nos hemos inventado de que el resultado comience por 1234… , pero seguro que el ejemplo ha sido útil para entender todos estos conceptos básicos.  En la realidad, las condiciones tienen que ver con el numero de "ceros" con el que comience el resultado)

Es decir, en el sistema de Blockchain, todos los participantes pueden comprobar de forma autónoma que B es el guardián de A, y que si se modifica cualquiera de ellos, el otro evidenciará esa vulneración de la integridad. Parece que la información de mi transacción a Marina está a salvo y hay mucha gente que está de acuerdo. Muchísima gente que está de acuerdo. La inmensa mayoría está de acuerdo.

Tercera. Si hemos llegado hasta aquí sin perdernos, esto ya está hecho. Pero nos falta un pequeño detalle. La transacción que hice a Marina, la transacción A, ya está hecha, guardada, almacenada, bendecida con su clave B que impide que nadie pueda modificarla. Pero ¿Y si alguien estuviera muy interesado en modificar ese registro A, que podría hacer? Pues se me ocurre que podría realizar la modificación deseada en A, y volver a calcular un nuevo número B que sumado a A cumpliera de nuevo la condición de arrojar un resultado que comenzara por 1234. Hago la sustitución de A y B por sus nuevos valores, y ya está. El sistema vulnerado ☹. Pues vaya… ¿Para este corto viaje tantas alforjas? (realmente no es tan sencillo vulnerar así el sistema, dado que una gran mayoría tendría una copia de ese registro original y podría detectar ese intento de trampa. Pero supongamos, a efectos didácticos, que si fuera sencillo, para dar contexto a lo que sigue en esta explicación)
¿Cuál ha sido el problema y como podríamos resolverlo? Básicamente, no podemos tratar las transacciones como hechos aislados, sin ningún tipo de conexión entre si. Todo el mecanismo que hemos descrito nos ha servido para garantizar la integridad de cualquier registro en particular de forma autosostenida, y que todos los demás puedan verlo, pero independientemente de la existencia del registro vecino. De esa forma, se podría manipular y vulnerar un registro aunque no sin cierta dificultad.
Llegados a este punto, estaría muy bien que pudiéramos introducir un nuevo elemento que nos relacione mi transacción A, no solo con esa especie de sello o guardian que hemos llamado B hasta ahora, sino que también lo hiciera con otra transacción vecina, que a su vez también estaría relacionada con otra, y esta con otra… y si… aquí aparece por primera vez el por que de la palabra “cadena”, chain, en esta tecnología.

En este escenario, modificar un registro significaría modificar tooooda la cadena de registros vecinos….. y eso ya tiene muy pocas probabilidades de poder realizarse, verdad ?.
Es decir, ese nuevo elemento que nos relacione un registro con el registro vecino lo vamos a llamar C, ok? Y que mejor que representar a ese registro vecino que con el resultado de su “prueba del 9”?
De esta forma la integridad de cada registro A estará custodiada no solo por ese guardian B, sino que también por ese otro valor de C que depende del registro vecino. Es decir, que el registro A que recoge la información de la transferencia de 20€ que le hice a Marina está custodiada por ese clave B que definíamos anteriormente, pero que a su vez depende de otro elemento C que nos trae información sobre el registro vecino, en este caso el de la transferencia que Juan le hizo a Mónica por valor de 1500€…. por ejemplo.
Es decir, antes teníamos que P9(A+B)= 1234….. donde A es el registro a proteger, y B tenía que ser calculado para cumplir la condición de dar un número que comenzara por 1234. Ahora tenemos que:

P9(A+B+C)=1234…..

donde A es de nuevo el registro a proteger, B tendrá que ser de nuevo calculado y C es el resultado de aplicar P9 al registro anterior. Es decir, también un número que comenzaría por 1234…. en nuestro ejemplo.

De esta forma, la protección de cada registro depende de parámetros del registro anterior. Si alguien quisiera modificar el registro A utilizando ese truquillo descrito al principio de este punto, tendría que modificar el contenido de A, calcular la clave de protección B de todos los registros siguientes para mantener la consistencia del sistema. Y además conseguir repetir esa operación fraudulenta en todas las copias de los bloques, o en los de una inmensa mayoría, que no olvidemos están distribuidas entre todos los participantes en el sistema. Y todo eso me parece a mi que ya es bastante más que improbable que suceda (aunque un ejercicio teórico en el que todos los participantes del sistema blockchain, ¿millones? nos volviéramos malos malísimos, y diéramos por buena esa cadena inconsistente, se podría llevar teóricamente el sistema al traste).

 

Y ya para terminar, incorporemos otro concepto fundamental. Hemos hablado con bastante ligereza de aplicar funciones (nuestra manida “prueba el 9”), calcular números que cumplan condiciones etc.. Y además estos cálculos son imprescindibles para ir “sellando” los registros con esas claves B que hemos ido comentando. El sistema necesita esas claves.

Pues bien, el esfuerzo computacional para realizar estos cálculos no es menor. Es muy intenso. Probar millones de entradas con nuestras función de hash (Prueba del 9) para ver cuales nos devuelven un resultado que cumpla una determinada condición (empezar por 1234), requiere mucha capacidad de proceso …. y algo de suerte 😉.
En un sistema descentralizado como este nos podemos preguntar, ¿Quién lo hace? ¿Y por que lo va a hacer?
La respuesta a la primera pregunta es clara: cualquiera de los participantes en el sistema de Blockchain lo puede hacer (siempre y cuando cuente con alguna capacidad de proceso). Pero siendo un proceso que requiere unos cálculos intensos, que acarrean gastos importantes en tiempo y energía, proceso, por que alguien querría hacerlo? ¿Altruismo? ¿experimentación? Pues la respuesta a ello es una recompensa tan poco original, como genial en este caso….: dinero.
Si, dinero, pero como no podría ser de otra forma, en forma de Bitcoins.

De hecho, el Bitcoin, como cualquier otra moneda, circula, se transfiere, se gasta, se compra, se invierte, se cambia, se regala, se roba, se ….. todo. Pero ¿Cómo se crea? O utilizando términos apropiados ¿Cómo se acuña? No existe un Banco Central que “fabrique moneda”, no. La única forma de crear Bitcoin de la nada e inyectarlos en el sistema es trabajando para el sistema ¿Cómo? Aportando potencia de cálculo para obtener esas claves B que nos vayan cerrando y guardando los registros, y que como hemos visto, son imprescindibles para la seguridad e integridad de todo el mecanismo. Si habíais oído el término “minar Bitcoins”, ya sabéis a que se refiere, por qué se hace y que se obtiene a cambio. Este esfuerzo computacional es a lo que se le denomina una prueba de trabajo, concepto fundamental en el mundo Bitcoin/Blockchain.

En el proceso de minar Bitcoins, se da el dicho de “the First takes it all”. El primero que consigue una clave B válida, es decir que cumple la condición de P9(A+B+C)=1234…, cerrará ese bloque. Informará a todos de su descubrimiento, todos podrán comprobar inmediatamente que en efecto ha descubierto una clave B válida (es decir, una clave B que cumple la condición de, sumada a A y a C, dar un número que comienza por 1234...), y se llevará por ello toda la recompensa. Premio. A seguir trabajando sobre el resto de bloques. Recuerdo en este punto de nuevo el ejemplo del Sudoku: difícil de resolver, pero muy sencillo de comprobar por todos que se ha resuelto correctamente.
El sistema autoregula de forma automática el factor de dificultad de la condición a cumplir para sellar un bloque (cálculo de B). Si la condición “número que comienza por 1234” comienza a ser demasiado sencilla, pongo por caso, y se tarde menos de 10 minutos de media en el cálculo de B, se incrementa automáticamente la dificultad de la condición a cumplir, por ejemplo, cambiándola por “comenzar por 12345” (recordar que es un ejemplo didáctico. En la realidad hablaremos de añadir "ceros" a la condición)

En relación a su implementación tecnológica, es interesante igualmente exponer que todo el código fuente de Bitcoin es software libre (bajo una licencia libre permisiva no-copyleft), que es un proyecto de código abierto tras el que no hay nadie detrás, que cualquiera con las skills adecuadas puede participar, que nadie lo controla, sino que se gestiona en github y listas de correo públicas como cualquier otro proyecto de software libre.

Y en relación a su utilización, es obvio que no hay que conocer NADA de lo que he descrito en este post para ser un feliz usuario de Bitcoins, blockchain o de cualquier otro proyecto basado en esta tecnología.

Se habla mucho del uso de la tecnología de Blockchain en el ámbito empresarial, si bien algunas de sus caractaerísticas diseñadas originalmente para funcionar en un ámbito absolútamente público, descentralizado y sin gobierno, como característica fundamental de su disño, necesitan de alguna modificacón en términos de goberbnanza, confidencialidad o rendimiento,  para que se uso pueda ser ampliamente aceptado en el mundo de la empresa.Resultado de imagen para ethereum

Lo escenarios de la empresa que miran a Blockchain como una solución importante a muchos retos, tienen que ver no solo con las criptomonedas o sector bancario. Hablamos de ámbitos de transferencias, registros, seguros (caso Microsoft & Maersk) votaciones, seguimiento de productos y servicios, internet de las cosas, contratos inteligentes, previsiones, musica on line, compartición de vehículos, compra de acciones y un etcetera tan largo como queramos.

En este sentido, Microsoft se ha convertido en el proveedor de servicios en cloud con más atención a esta tecnologia y no en vano se acaba de anunciar por parte del CTO de la compañía, Mark Russinovich, la existencia del denominado Coco Framework sobre Microsoft Azure. Unas plataforma Open Source que habilita un Blockchain con características pensadas para su uso en el mundo de la empresa en términos de escalabilidad, gobernanza, confidencialidad. Algunos de los primeros proyectos sobre la plataforma Coco está siendo la integación de Ethereum.

Y creo que lo voy a dejar aquí, pero no sin antes agradecer a mi amigo Miguel Vidal, que hace ya unos años me descubrió la existencia de este mundo, con una cerveza de por medio, y que desde entonces no he dejado de aprender de él en especial desde sus artículos, opiniones y comentarios en diferentes redes sociales, siendo en mi opinión uno de los mayores expertos en el tema. Solo con su Visto Bueno, y habiendo incorporado lo que él humildemente ha llamado “recomendaciones” ( aunque las recomendaciones de un experto son órdenes para mí 😊), me he atrevido a publicar este post.


Comments (4)

  1. Leer este artículo es montar sobre hombros de dos gigantes, M. Vidal y tu mismo Héctor. Muy claro el recorrido, el protagonismo de Marina es bastante elocuente, se lo pasaré a mi padre nonagenario para que se ilustre, que a él le gustan estas cosas. Un abrazo y mil gracias 🙂

    1. Estupendo artículo!! Y también un placer encontrar aquí a Javier Viñuales (aunque sea en los comentarios… x’DDD).
      ¡¡Un abrazo Javi!!

  2. César Ocampo dice:

    Tremendo artículo. Mis felicitaciones y agradecimientos por él. Saludos desde Colombia

  3. Daniel Torralba dice:

    Me ha parecido muy interesante, nunca había entendido cual era el papel de la minería de BitCoins en todo esto y en el, artículo queda muy claro, enhorabuena.
    Me surgen muchas dudas nuevas, aunque advierto que no estoy nada familiarizado con estos temas y soy de un mundo muy distinto, pero tengo curiosidad. Si hay transacciones constantes, cada vez hay más registros y el trabajo computacional es mayor, esto implica que se deberían repartir mas Bitcoins, pero tengo entendido que hay un límite teórico cerrado de Bitcoins. ¿Cuando ya esté todo repartido, como se podrán hacer nuevas transacciones si ya no hay recompensa y además el trabajo computacional de todas esas operaciones será tan grande (entiendo que cada vez mayor)?

Skip to main content