Bitcoin: registros de transacciones

En su núcleo, bitcoin es, básicamente, una cadena de firmas electrónicas que realmente reflejan el camino recorrido por las monedas a través del ecosistema bitcoin. Y, ¿sabes qué? Pienso que, de hecho, es conceptualmente más sencillo pensar en los bitcoins como entradas colectivas en un libro (mayor de contabilidad) que en monedas físicas. Por que, si piensas en ello, en un libro (de contabilidad), tienes un registro de la historia de transacciones que refleja lo que ha pasado en bitcoin, mientras que una moneda física, no tiene memoria asociada. No hay historia en una moneda física de que es lo que ha pasado con esa moneda en el pasado. En este contexto, puedes pensar en una transacción como si fuera una declaración firmada electrónicamente por una parte de su intención de transferir algunos bitcoins que posee a otro grupo de partes (participantes). Y cuando digo que una parte posee un cierto número de bitcoins, realmente lo que quiero decir es que hay una transacción previa registrada en la que todo el mundo está de acuerdo en que una parte, ahora transfiriendo bitcoins, fue en su momento receptora de una transferencia previa de esos bitcoins, ¿de acuerdo? Me doy cuenta de que es un poco complicado así que, para ayudar a entender la mecánica de una transacción puedo poner un ejemplo de que pasaría en el contexto de una transacción bitcoin. Digamos que tenemos una parte, a la que llamaremos Alice que es un nombre utilizado frecuentemente en los esquemas criptográficos, y, digamos, que ella quiere transferir algunos bitcoins a Bob, vamos a decir que ella tiene la intención de transferir 50 bitcoins a Bob. Ahora, recordemos que cualquiera que interactúa en el ecosistema bitcoin, de hecho no lo está haciendo usando un nombre real, sino que, más bien, lo hace por medio de una identidad muy específica, un seudónimo dentro del ecosistema bitcoin, y que esa identidad, ese seudónimo, corresponde, de hecho, a una clave de verificación pública de un esquema de firma electrónica (digital). Así, en este caso, digamos que la identidad de Alice en el sistema es, realmente, una clave de verificación pública, que denominaremos VK (Verification Key) de A. Esto es, la clave de verificación de Alice. Y, en lo que hace referencia a Bob, diremos que su clave de verificación pública es VKsubB. Así, estas claves son usadas dentro de esquemas de firma electrónica y, en consecuencia, podemos asumir que Alice ha generado su clave en algún momento, y que la ha hecho pública, y que Bob ha hecho lo mismo, de forma que ambos tienen identidades dentro del sistema, y esas identidades son secuencias de números que corresponden a claves públicas de verificación en el contexto de la firma electrónica criptográfica. ¿De acuerdo? Ahora, recordemos, que estos valores también corresponden a valores privados, de forma que cada persona que tiene una clave pública tendrá su correspondiente clave privada, asociada con esa clave pública, a la que, en este caso, llamaremos clave privada, o clave secreta, que es, de hecho, una clave de firma (Signing Key) en este contexto, SK de Alice, y diremos que la clave de firma de Bob es SKsubB. ¿OK? Y ellos se encargarán de mantener esas claves en privado (secretas). Ahora, digamos que Alice había recibido, ella misma, en el pasado, tres transacciones de bitcoins de otras partes. Digamos que recibió 25 bitcoins de Carol, y utilizaremos VKsubC para asociar a Carol con su clave (de verificación), digamos que ella (Alice) recibió 20 bitcoins de David, y, digamos, obtuvo 20 bitcoins más de Ted. ¿De acuerdo? Así tenemos estos bitcoins correspondientes a diferentes personas que proporcionaron a Alice bitcoins en el pasado, y, así, como puedes ver, Alice tiene ahora un suma total de 65, que son 20 mas 20 mas 25 bitcoins, y, como resultado, ella tiene disponible un número suficiente para poder transferir 50 de esos (65) bitcoins a Bob, ¿OK? Así, para empezar, una transacción de Alice a Bob de 50 bitcoins contendrá información sobre esas (tres) transacciones previas, así cada una de esas tres transacciones previas donde Alice recibió algunos bitcoins han sido registradas en el ecosistema bitcoin, y han sido hecho públicas, al igual que todas las demás transacciones de forma que lo que Alice puede hacer es tomar alguna representación de esas transacciones e incluirlas como parte de una nueva transaccióna a Bob, básicamente, como si fuera un punto de anclaje para decir: "He recibido previamente estos bitcoins, y ahora voy a transferir una parte de esos bitcoins a Bob." ¿De acuerdo? Así, en este contexto, de hecho ella no necesita incluir los detalles completos en el registro de la transacción actual a Bob. Lo que ella puede hacer en su lugar es tomar los detalles de la transacción y aplicarles una función hash criptográfica para obtener una serie de resúmenes de cada transacción. Así, en este caso, digamos que ella tiene un resumen que correspode a la transacción de Carol, ella tiene un resumen que correspode a la transacción de David y ella tiene un resumen que corresponde a la transacción de Ted, ¿de acuerdo? Y ella, básicamente, incluye cada uno de estos tres resúmenes en el registro de transacción, y así estas trazas te permiten, en realidad, permiten a cualquiera interesado, verificar la cadena de propiedad de esos bitcoins, porque vale con tomar los registros de las transacciones previas, que, recordemos de nuevo, son públicos. Se pueden aplicar las funciones hash criptográficas a estos registros de transacciones y verificar que estos "hashes" criptográficos cuando se aplican de nuevo a estos registros de transacciones te permiten obtner de vuelta los valores DsubC, DsubD y DsubT, y así, te proporciona un tipo de garantía criptográfica porque como estamos usando funciones hash criptográficas, tenemos la garantía de que Alice fue la última depositaria de esas transacciones provenientes de esas (tres) diferentes partes. tenemos esa "bonita" historia que podemos registrar, y que nos permite hacer las averiguaciones de esta forma. ¿De acuerdo? Como estamos utilizando funciones hash criptográficas, podemos tener cierta seguridad de que Alice no podría engañar fácilmente al sistema. ¿De acuerdo? Así, en este momento de la transacción, quizás dibujaré una línea de forma que puedas ver dónde se registran los detalles de la transacción. En este momento de la transacción, tenemos detalles sobre la propiedad de Alice de estos 65 bitcoins, y ella tiene información suficiente en esa transacción para que cualquiera pueda verificar que ella posee esos bitcoins. Puedes pensar en esta parte de la transacción como si, de hecho, estuviera representando la entrada de la transacción. Ahora, además de la porción correspondiente a la entrada de la transacción, hay también una porción correspondiente a la salida. Voy a poner la parte correspondiente a la salida en este lado, pero antes voy a etiquetarla, y así para arrancar, en la parte de la salida, ella tiene que incluir, o Alice tiene que incluir, una lista de receptores para sus bitcoins, y dado que Alice quiere, digámoslo así, transferir estos bitcoins a Bob, ella debe especificar la identidad de Bob en el sistema, que, de hecho, como hemos dicho anteriormente, era la clave pública de Bob, de forma que diremos que ella mencionará VKsubB, y ella también tiene que decir, en este momento, cuantos bitcoins quiere transferir a Bob y, como hemos dicho antes, vamos a asumir que Alice quiere transferir exactamente 50 de sus bitcoins a Bob, ¿de acuerdo? De forma que ella va a especificar el número de 50. De hecho, ella especificará otro número, pero va a representar 50 bitcoins para Bob, ¿de acuerdo? Ahora, para que Alice recupere el cambio porque ella está proporcionando 65 bitcoins de entrada y únicamente está dando 50 a Bob, lo que ella debería hacer es decidir que ella va a especificar que 14 de esos bitcoins le sean devueltos en forma de cambio, así 14 de esos bitcoins van a ser reasignados de nuevo a la clave pública de Alice, ¿de acuerdo? Y lo que Alice hará a continuación es tomar todos estos datos, estos datos de la transacción, esta entrada y esta salida, y ella va a firmar electrónicamente estos datos y para ello va a utilizar su clave de firma (SK) para firmar electrónicamente todos estos datos con una firma electrónica, y ella va a adjuntar esta firma a los contenidos del registro de la transacción y esto enlazará efectivamente la identidad de Alice con el registro mismo de la transacción. Y la razón para enlazarlo es que estamos usando un esquema de firma electrónica de forma que cualquiera que posea la clave pública de Alice que, recordemos, ha sido hecha pública, puede comprobar que únicamente Alice podría haber creado el bloque, porque sólo Alice, teóricamente, puede acudir con la firma que correspode a su clave pública, porque ella es la única persona que, en teoría, debería poseer la clave privada de firma correspondiente a su clave pública, ¿de acuerdo? Así, todos estos datos serán retransmitidos, de forma que estos datos de la transacción serán emitidos a todos los diferentes participantes y nodos en la red bitcoin. Cualquiera en la red bitcoin podrá saber ahora que VKsubA está intentando enviar 50 bitcoins a VKsubB. Ahora, en este punto, puedes haber notado una ligera discrepancia aquí: que Alice empezó con 65 bitcoins, en el lado de la entrada, pero que, en el lado de la salida, ella tiene solo 50 mas 14, o sea 64 bitcoins, contabilizados. Así que hay un problema, ¿qué pasa con este bitcoin, el último restante? Hay una especie de bitcoin escondido, "revoloteando", que no ha sido contabilizado, y lo que vamos a hacer con ese bitcoin es que va a ser utilizado, de hecho, como una cuota (tasa) de transacción. Lo que, básicamente, está diciendo Alice es que ese bitcoin restante debería ser considerado una cuota (pago) de la transacción a quién es conocido como un minero de bitcoins. Un minero de bitcoins, como mencioné en un vídeo previo, es un tipo de entidad en el ecosistema bitcoin. de hecho, culquiera puede ser un minero de bitcoins, que es un nodo en la red bitcoin ocupado, realmente, en el esfuerzo de colaborar con el esfuerzo general de validar esta transacción. ¿A qué me refiero con validación general? Bien, si piensas en ello, hasta este punto hemos usado el hashing criptográfico y la firma electrónica para validar que Alice poseía en un momento dado los bitcoins necesarios en el sistema y que ella no sólo anunciaba públicamente su intención de transferir parte de esos bitcoins a Bob sino que, además, firmaba electrónicamente ese pronunciamiento público, Como consecuencia de lo cual, su clave pública de verificación, que representa su identidad en el sistema bitcoin, está ahora asociada a la transacción. Pero lo que Bob no sabe todavía, a pesar de que sabe todas estas cosas y de que puede validarlas, lo que Bob no sabe todavía es si, digamos, Alice intentó previamente firmar la transferencia de esos mismos bitcoins a algún otro. Quizás hay otra parte. Digamos que Alice tiene una amiga llamada Eve. Quizás Alice decidió que iba a enviar estos bitcoins no únicamente a Bob, sino que también ella iba a intentar enviar estos mismos bitcoins a Eve, y Bob en este punto puede no estar seguro de que Alice no ha tratado de engatusarle con este tipo de engaños, ¿de acuerdo? Y la parte difícil aquí es que aunque todas las transacciones de las que hemos hablado aquí han sido hechas públicas porque bitcoin requiere que todas las transacciones sean hechas públicas, todavía necesitamos un mecanismo, y tiene que ser un mecanismo descentralizado que no requiera, per se, una tercera parte de confianza. Necesitamos un mecanismo dscentralizado para lograr acuerdos, respecto al orden real en que las transacciones han tenido lugar, de forma que podamos resolver cualquier disputa respecto alguien que intente gastar dos veces sus bitcoins. Es este requsito, este sellado de tiempo, este sellado de tiempo descentralizado en el que los mineros de bitcoins juegan un papel fundamental en el ecosistema bitcoin, y hablaré sobre cómo funciona y sobre cómo trabajamos con el sellado temporal de transacciones en vídeos subsiguientes.