name: Privacidad en Bitcoin goal: Comprender y dominar los principios de protección de la privacidad al utilizar Bitcoin objectives:

Definir los conceptos teóricos necesarios para comprender las cuestiones de privacidad
Identificar y mitigar los riesgos asociados a la pérdida de confidencialidad para los usuarios de Bitcoin
Uso de métodos y herramientas para proteger su privacidad en Bitcoin
Comprender los métodos de análisis de la cadena y desarrollar estrategias de defensa

Proteja su privacidad en Bitcoin

En un mundo en el que la confidencialidad de las transacciones financieras se está convirtiendo poco a poco en un lujo, comprender y dominar los principios de protección de la privacidad cuando se utiliza Bitcoin es esencial. Este curso de formación le da todas las claves, tanto teóricas como prácticas, para conseguirlo de forma autónoma.

Hoy en día, en Bitcoin, hay empresas especializadas en el análisis de blockchain. Su actividad principal consiste precisamente en inmiscuirse en su esfera privada, con el fin de comprometer la confidencialidad de sus transacciones. En realidad, en Bitcoin no existe el "derecho a la privacidad". Así que es usted, el usuario, quien debe hacer valer sus derechos naturales y proteger la confidencialidad de sus transacciones, porque nadie lo va a hacer por usted.

El curso está diseñado para ser exhaustivo y general. Cada concepto técnico se trata con detalle y se apoya en diagramas explicativos. El objetivo es que los conocimientos sean accesibles para todos. Por ello, BTC204 es asequible para principiantes y usuarios intermedios. El curso también ofrece un valor añadido para los bitcoiners más experimentados, ya que profundizamos en ciertos conceptos técnicos que a menudo se malinterpretan.

Únase a nosotros para transformar su uso de Bitcoin y convertirse en un usuario informado, capaz de comprender las cuestiones relacionadas con la confidencialidad y proteger su privacidad.

Introducción

Descripción del curso

¡Bienvenido al curso BTC204!

Bitcoin no es sólo "subir números" y preservar el valor de los ahorros. Con sus características únicas y su historia, es ante todo la herramienta de la contraeconomía. Gracias a este formidable invento, usted puede disponer libremente de su dinero, gastarlo y acumularlo, sin que nadie pueda impedírselo.

Bitcoin le ofrece una escapatoria pacífica del yugo del Estado, permitiéndole disfrutar plenamente de sus derechos naturales, que no pueden ser cuestionados por las leyes establecidas. Gracias al invento de Satoshi Nakamoto, usted tiene el poder de hacer respetar su propiedad privada y recuperar la libertad de contratar.

Sin embargo, Bitcoin no es anónimo por defecto, lo que puede representar un riesgo para las personas que se dedican a la contraeconomía, sobre todo en regiones bajo un régimen despótico. Pero éste no es el único peligro. Dado que el bitcoin es un activo valioso e incensurable, puede ser un objetivo para los ladrones. Por eso, proteger tu privacidad se convierte también en una cuestión de seguridad: puede ayudarte a evitar el pirateo y las agresiones físicas.

Como veremos, aunque el protocolo ofrece ciertas protecciones de confidencialidad por sí mismo, es crucial utilizar herramientas adicionales para optimizar y defender esta confidencialidad.

Este curso de formación está diseñado para ofrecer una visión general y exhaustiva de las cuestiones relacionadas con la confidencialidad de Bitcoin. Cada concepto técnico se trata en detalle, con el apoyo de diagramas explicativos. El objetivo es hacer estos conocimientos accesibles a todo el mundo, incluso a principiantes y usuarios intermedios. Para los Bitcoiners más experimentados, también cubrimos conceptos altamente técnicos y a veces poco conocidos a lo largo del curso, para profundizar en la comprensión de cada tema.

El objetivo de este curso de formación no es que usted sea totalmente anónimo en el uso de Bitcoin, sino proporcionarle las herramientas esenciales para saber cómo proteger su confidencialidad en función de sus objetivos personales. Tendrá la libertad de elegir entre los conceptos y herramientas presentados para desarrollar sus propias estrategias, adaptadas a sus objetivos y necesidades específicas.

Sección 1: Definiciones y conceptos clave

Para empezar, vamos a repasar los principios fundamentales que rigen el funcionamiento de Bitcoin, para luego poder abordar con calma las nociones relativas a la confidencialidad. Es esencial dominar algunos conceptos básicos, como UTXO, la recepción de direcciones y el scripting, antes de poder entender completamente los conceptos que trataremos en las siguientes secciones. También presentaremos el modelo general de confidencialidad de Bitcoin, tal y como lo imaginó Satoshi Nakamoto, lo que nos permitirá comprender las apuestas y los riesgos asociados.

Sección 2: Comprender el análisis de la cadena y protegerse contra él

En la segunda sección, examinamos las técnicas utilizadas por las empresas de análisis de blockchain para rastrear su actividad en Bitcoin. Comprender estos métodos es crucial para reforzar la protección de su privacidad. El objetivo de esta sección es examinar las estrategias de los atacantes para comprender mejor los riesgos y preparar el terreno para las técnicas que estudiaremos en las siguientes secciones. Analizaremos patrones de transacciones, heurísticas internas y externas, e interpretaciones probables de estos patrones. Además de la teoría, aprenderemos a utilizar un explorador de bloques para el análisis de cadenas, mediante ejemplos prácticos y ejercicios.

Sección 3: Dominar las mejores prácticas para proteger su privacidad

En la tercera sección de nuestro curso de formación, vamos al grano: ¡la práctica! El objetivo es dominar todas las buenas prácticas esenciales que deberían convertirse en reflejos naturales para cualquier usuario de Bitcoin. Vamos a cubrir el uso de direcciones en blanco, etiquetado, consolidación, el uso de nodos completos, así como KYC y métodos de adquisición. El objetivo es proporcionarle una visión global de las trampas que debe evitar para establecer una base sólida en nuestra búsqueda de la protección de la privacidad. Para algunas de estas prácticas, se le guiará a un tutorial específico sobre cómo ponerlas en práctica.

Sección 4: Entender las transacciones coinjoin

¿Cómo podemos hablar de privacidad en Bitcoin sin mencionar los coinjoins? En la sección 4, descubrirá todo lo que necesita saber sobre este método de mezcla. Aprenderá qué son los coinjoins, su historia y objetivos, así como los diferentes tipos de coinjoin que existen. Por último, para los usuarios más experimentados, veremos qué son los anonsets y la entropía, y cómo calcularlos.

Sección 5: Comprender los retos de otras técnicas avanzadas de confidencialidad

En la quinta sección, echaremos un vistazo a todas las demás técnicas disponibles para proteger su privacidad en Bitcoin, aparte de coinjoin. A lo largo de los años, los desarrolladores han mostrado una notable creatividad en el diseño de herramientas dedicadas a la privacidad. Veremos todos estos métodos, como payjoin, transacciones colaborativas, Coin Swap y Atomic Swap, detallando cómo funcionan, sus objetivos y sus puntos débiles.

También estudiaremos la privacidad a nivel de la red de nodos y la difusión de transacciones. También discutiremos los diversos protocolos que se han propuesto a lo largo de los años para mejorar la privacidad del usuario en Bitcoin, incluyendo los protocolos de direcciones estáticas.

BTC204 ¿Listo para explorar los entresijos de la privacidad en Bitcoin? ¡Vamos allá!

Definiciones y conceptos clave

El modelo UTXO de Bitcoin

Bitcoin es ante todo una moneda, pero ¿sabe realmente cómo se representan los BTC en el protocolo?

UTXOs en Bitcoin: ¿qué son?

El protocolo Bitcoin se basa en el modelo UTXO, que significa "Unspent Transaction Output" (salida de transacciones no gastadas).

Este modelo difiere profundamente de los sistemas bancarios tradicionales, que se basan en un mecanismo de cuentas y saldos para seguir los flujos financieros. De hecho, en el sistema bancario, los saldos individuales se mantienen en cuentas vinculadas a una identidad. Por ejemplo, cuando usted compra una baguette a un panadero, su banco simplemente carga el importe de la compra en su cuenta, reduciendo su saldo, mientras que la cuenta del panadero se abona con la misma cantidad, aumentando su saldo. En este sistema, no existe ningún vínculo entre el dinero que entra en tu cuenta y el que sale de ella, aparte de los registros de transacciones.

Bitcoin funciona de forma diferente. El concepto de cuenta no existe, y las unidades monetarias no se gestionan mediante saldos, sino a través de UTXOs. Un UTXO representa una cantidad específica de bitcoins que aún no se ha gastado, formando así una "pieza de bitcoin", que puede ser grande o pequeña. Por ejemplo, un UTXO puede valer 500 BTC o simplemente 700 SATS.

**> El satoshi, a menudo abreviado como sat, es la unidad más pequeña de Bitcoin, comparable al céntimo de las monedas fiduciarias.

1 BTC = 100 000 000 SATS

Teóricamente, un UTXO puede representar cualquier valor en bitcoins, desde un sat hasta un máximo teórico de unos 21 millones de BTC. Sin embargo, es lógicamente imposible poseer los 21 millones de bitcoins, y existe un umbral económico inferior denominado "polvo", por debajo del cual se considera económicamente poco rentable gastar un UTXO.

**> El mayor UTXO jamás creado en Bitcoin tenía un valor de 500.000 BTC. Fue creado por la plataforma MtGox durante una operación de consolidación en noviembre de 2011: 29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf

UTXOs y condiciones de gasto

Los UTXOs son los instrumentos de intercambio en Bitcoin. Cada transacción da lugar al consumo de UTXOs como entradas y a la creación de nuevos UTXOs como salidas. Cuando se completa una transacción, los UTXOs utilizados como entradas se consideran "gastados", y se generan nuevos UTXOs que se asignan a los destinatarios indicados en las salidas de la transacción. Así, un UTXO representa simplemente una salida de transacción no gastada y, por tanto, una cantidad de bitcoins pertenecientes a un usuario en un momento dado.

Todos los UTXOs están asegurados por scripts que definen las condiciones en las que se pueden gastar. Para consumir un UTXO, un usuario debe demostrar a la red que cumple las condiciones estipuladas por el script que asegura ese UTXO. Normalmente, los UTXO están protegidos por una clave pública (o una dirección receptora que representa esta clave pública). Para gastar un UTXO asociado a esta clave pública, el usuario debe demostrar que posee la clave privada correspondiente, proporcionando una firma digital realizada con esta clave. Por eso decimos que tu monedero Bitcoin no contiene bitcoins en realidad, sino que almacena tus claves privadas, que a su vez te dan acceso a tus UTXOs y, por extensión, a los bitcoins que representan.

Dado que en Bitcoin no existe el concepto de cuenta, el saldo de un monedero es simplemente la suma de los valores de todos los UTXOs que puede gastar. Por ejemplo, si su monedero Bitcoin puede gastar los siguientes 4 UTXOs:

- 2 BTC
- 8 BTC
- 5 BTC
- 2 BTC

El saldo total de su cartera sería de 17 BTC.

La estructura de las transacciones Bitcoin

Entradas y salidas de transacciones

Una transacción Bitcoin es una operación registrada en la blockchain que transfiere la propiedad de bitcoins de una persona a otra. Más concretamente, dado que estamos en un modelo UTXO y no hay cuentas, la transacción satisface las condiciones de gasto que aseguraron uno o más UTXOs, los consume y, equivalentemente, crea nuevos UTXOs con nuevas condiciones de gasto. En resumen, una transacción mueve bitcoins de un script satisfecho a un nuevo script diseñado para asegurarlos.

Por lo tanto, cada transacción Bitcoin consiste en una o más entradas y una o más salidas. Las entradas son UTXOs consumidos por la transacción para generar salidas. Las salidas son nuevos UTXOs que pueden ser utilizados como entradas para futuras transacciones.

**> Teóricamente, una transacción bitcoin podría tener un número infinito de entradas y salidas. El único límite es el tamaño máximo del bloque.

Cada entrada en una transacción Bitcoin hace referencia a un UTXO previo no gastado. Para utilizar un UTXO como entrada, su titular debe demostrar que es el propietario legítimo validando la escritura asociada, es decir, satisfaciendo la condición de gasto impuesta. En términos generales, esto significa proporcionar una firma digital producida con la clave privada correspondiente a la clave pública que garantizó inicialmente este UTXO. El script consiste por tanto en verificar que la firma corresponde a la clave pública utilizada cuando se recibieron los fondos.

Cada salida, a su vez, especifica la cantidad de bitcoins a transferir, así como el destinatario. Este último se define mediante un nuevo script, que suele bloquear el UTXO recién creado con una dirección receptora o una nueva clave pública.

Para que una transacción se considere válida según las reglas de consenso, el total de salidas debe ser menor o igual que el total de entradas. En otras palabras, la suma de nuevos UTXOs generados por la transacción no debe superar la suma de UTXOs consumidos como entradas. Este principio es lógico: si sólo tienes 500.000 SATS, no puedes hacer una compra de 700.000 SATS.

Intercambio y fusión en una transacción Bitcoin

La acción de una transacción Bitcoin sobre UTXO puede compararse así a la refundición de una moneda de oro. En efecto, un UTXO no es divisible, sino sólo fundible. Esto significa que un usuario no puede simplemente dividir un UTXO que representa una cierta cantidad en bitcoins en varios UTXO más pequeños. Debe consumirlo íntegramente en una transacción para crear uno o varios UTXO nuevos de valores arbitrarios en salidas, que deben ser inferiores o iguales al valor inicial.

Este mecanismo es similar al de una moneda de oro. Supongamos que usted posee una moneda de 2 onzas y quiere hacer un pago de 1 onza, suponiendo que el vendedor no pueda darle cambio. Tendría que fundir su moneda y acuñar 2 nuevas de 1 onza cada una.

Bitcoin funciona de forma similar. Imaginemos que Alice tiene un UTXO de 10.000 SATS y desea comprar una baguette de 4.000 SATS. Alice realizará una transacción con 1 UTXO de 10.000 SATScomo entrada, que consumirá en su totalidad, y 2 UTXOs de 4.000 SATS y 6.000 SATScomo salida. El UTXO de4.000 SATSse enviará al panadero como pago por la baguette, mientras que el UTXO de6.000 SATS` volverá a Alice en forma de cambio. Este UTXO, que vuelve al emisor original de la transacción, se conoce como "cambio" en la jerga de Bitcoin.

Ahora imaginemos que Alice no tiene un único UTXO de 10.000 SATS, sino dos UTXOs de 3.000 SATS cada uno. En esta situación, ninguno de los UTXOs por separado es suficiente para ajustar los 4.000 SATS de la varita. Por lo tanto, Alice debe utilizar simultáneamente los 2 UTXOs de 3.000 SATS como entradas para su transacción. De esta forma, la cantidad total de inputs alcanzará los 6.000 SATS, permitiéndole satisfacer el pago de 4.000 SATS al panadero. Este método, en el que se agrupan varios UTXO como insumos de una transacción, suele denominarse "fusión".

Comisiones de transacción

Intuitivamente, se podría pensar que los costes de transacción también representan el producto de una transacción. Pero en realidad no es así. Los costes de transacción representan la diferencia entre el total de insumos y el total de productos. Esto significa que, después de utilizar parte del valor de los insumos para cubrir los productos deseados en una transacción, una cierta suma de los insumos queda sin utilizar. Esta suma residual constituye los costes de transacción.

Frais = total inputs - total outputs

Tomemos el ejemplo de Alicia, que tiene un UTXO de 10.000 SATS y quiere comprar una baguette a 4.000 SATS. Alice crea una transacción con su UTXO de 10.000 SATS como entrada. A continuación, genera una salida de 4.000 SATS para que el panadero pague la baguette. Para animar a los mineros a integrar su transacción en un bloque, Alice asigna 200 SATS en concepto de comisiones. A continuación, crea un segundo resultado, el intercambio, que le será devuelto y que asciende a 5.800 SATS.

Aplicando la fórmula de las tasas, vemos que efectivamente quedan 200 SATS para los menores:

Frais = total inputs - total outputs
Frais = 10 000 - (4 000 + 5 800)
Frais = 10 000 - 9 800
Frais = 200

Cuando un minero consigue validar un bloque, está autorizado a cobrar estas tasas por todas las transacciones incluidas en su bloque, a través de la llamada transacción "coinbase".

Creación de UTXOs en Bitcoin

Si ha seguido atentamente los párrafos anteriores, ahora sabrá que los UTXOs sólo pueden crearse consumiendo otros UTXOs existentes. De este modo, las monedas Bitcoin forman una cadena continua. Sin embargo, puede que se esté preguntando cómo surgieron los primeros UTXOs de esta cadena. Esto plantea un problema similar al del huevo y la gallina: ¿de dónde salieron estos UTXOs originales?

La respuesta está en la transacción coinbase.

La coinbase es un tipo específico de transacción de Bitcoin, que es única para cada bloque y siempre es la primera de éstas. Permite al minero que ha encontrado una prueba de trabajo válida recibir su recompensa de bloque. Esta recompensa se compone de dos elementos: block grant y transaction fee, comentados en el apartado anterior.

La transacción de coinbase es única en el sentido de que es la única capaz de crear bitcoins ex nihilo, sin necesidad de consumir inputs para generar outputs. Estos bitcoins de nueva creación son lo que podríamos llamar "UTXOs originales".

Los bitcoins subvencionados por bloques son nuevos BTC creados desde cero, según un calendario de emisión preestablecido en las reglas de consenso. La subvención por bloque se reduce a la mitad cada 210.000 bloques, es decir, aproximadamente cada cuatro años, en un proceso conocido como "halving". Originalmente, se creaban 50 bitcoins con cada subvención, pero esta cantidad ha ido disminuyendo gradualmente; actualmente, es de 3,125 bitcoins por bloque.

En cuanto a las comisiones por transacción, aunque también representan BTC de nueva creación, no deben superar la diferencia entre el total de entradas y salidas de todas las transacciones de un bloque. Hemos visto antes que estas comisiones representan la parte de las entradas que no se utiliza en las salidas de las transacciones. Esta parte se "pierde" técnicamente durante la transacción, y el minero tiene derecho a recrear este valor en forma de uno o más nuevos UTXOs. Se trata de una transferencia de valor entre el emisor de la transacción y el minero que la añade a la blockchain.

**> Los bitcoins generados por una transacción coinbase están sujetos a un periodo de maduración de 100 bloques, durante el cual no pueden ser gastados por el minero. Esta norma está pensada para evitar complicaciones vinculadas al uso de bitcoins recién creados en una cadena que más tarde podría quedar obsoleta.

Implicaciones del modelo UTXO

En primer lugar, el modelo UTXO influye directamente en las tasas de transacción de Bitcoin. Dado que la capacidad de cada bloque es limitada, los mineros favorecen las transacciones que ofrecen las mejores tarifas en relación con el espacio que ocuparán en el bloque. De hecho, cuantos más UTXOs incluya una transacción en sus entradas y salidas, más pesada será, y por tanto requerirá tarifas más altas. Esta es una de las razones por las que a menudo intentamos reducir el número de UTXOs en nuestra cartera, lo que también puede afectar a la confidencialidad, un tema que abordaremos en detalle en la tercera parte de este curso.

En segundo lugar, como se ha mencionado en las secciones anteriores, las monedas Bitcoin son esencialmente una cadena de UTXOs. Así, cada transacción crea un vínculo entre un UTXO pasado y un UTXO futuro. Por tanto, los UTXO permiten seguir explícitamente la trayectoria de los Bitcoins desde su creación hasta su gasto actual. Esta transparencia puede considerarse positiva, ya que permite a cada usuario cerciorarse de la autenticidad de los bitcoins recibidos. Sin embargo, es también en este principio de trazabilidad y auditabilidad en el que se basa el análisis de blockchain, una práctica destinada a comprometer su confidencialidad. Analizaremos en profundidad esta práctica en la segunda parte del curso.

El modelo de privacidad de Bitcoin

Dinero: autenticidad, integridad y doble gasto

Una de las funciones del dinero es resolver el problema de la doble coincidencia de necesidades. En un sistema basado en el trueque, la realización de un intercambio requiere no sólo encontrar a un individuo que ceda un bien correspondiente a mi necesidad, sino también proporcionarle un bien de valor equivalente que satisfaga su propia necesidad. Lograr este equilibrio es una cuestión compleja.

Por eso utilizamos el dinero para mover valor tanto en el espacio como en el tiempo.

Para que la moneda solucione este problema, es esencial que la parte que proporciona un bien o servicio esté convencida de su capacidad para gastar esa suma en una fecha posterior. Así, cualquier individuo racional que desee aceptar una moneda, ya sea digital o física, se asegurará de que cumple dos criterios fundamentales:

La pieza debe tener integridad y autenticidad ;**
y no debe gastarse dos veces.**

Si se utiliza moneda física, la primera característica es la más compleja de afirmar. En distintos periodos de la historia, la integridad de las monedas metálicas se ha visto a menudo afectada por prácticas como el recorte o la perforación. En la antigua Roma, por ejemplo, era práctica habitual que los ciudadanos rasparan los bordes de las monedas de oro para recoger un poco del metal precioso y guardarlas para futuras transacciones. De este modo se reducía el valor intrínseco de la moneda, pero su valor nominal seguía siendo el mismo. Esta es una de las razones por las que posteriormente se estrió el canto de la moneda.

La autenticidad es también una característica difícil de verificar en un soporte monetario físico. Las técnicas actuales para combatir la falsificación de moneda son cada vez más complejas, lo que obliga a los minoristas a invertir en costosos sistemas de verificación.

Por otra parte, debido a su naturaleza, el doble gasto no es un problema para las monedas físicas. Si te doy un billete de 10 euros, sale irrevocablemente de mi posesión y entra en la tuya, lo que naturalmente excluye cualquier posibilidad de gasto múltiple de las unidades monetarias que encarna. En resumen, no podré volver a gastar este billete de 10 euros.

En el caso de la moneda digital, la dificultad es diferente. Garantizar la autenticidad y la integridad de una moneda suele ser más sencillo. Como vimos en la sección anterior, el modelo UTXO de Bitcoin permite rastrear una moneda hasta su origen, y verificar así que fue efectivamente creada por un minero de acuerdo con las reglas de consenso.

Por otra parte, garantizar que no haya doble gasto es más complejo, ya que todos los bienes digitales son en esencia información. A diferencia de los bienes físicos, la información no se divide cuando se intercambia, sino que se propaga multiplicándose. Por ejemplo, si le envío un documento por correo electrónico, se duplicará. No puedes estar seguro de que haya borrado el documento original.

Evitar el doble gasto en Bitcoin

La única forma de evitar esta duplicación de un activo digital es estar al tanto de todos los intercambios del sistema. De este modo, podemos saber quién posee qué y actualizar las tenencias de cada persona en función de las transacciones realizadas. Es lo que ocurre, por ejemplo, con el dinero escritural en el sistema bancario. Cuando pagas 10 euros a un comerciante con tarjeta de crédito, el banco registra el intercambio y actualiza el libro de cuentas.

En Bitcoin, el doble gasto se evita de la misma manera. Tratamos de confirmar la ausencia de una transacción que ya haya gastado las monedas en cuestión. Si las monedas nunca se han utilizado, entonces podemos estar seguros de que no se producirá un doble gasto. Este principio fue descrito por Satoshi Nakamoto en el Libro Blanco con la famosa frase:

**La única forma de confirmar la ausencia de una transacción es estar al tanto de todas las transacciones

Pero a diferencia del modelo bancario, en Bitcoin no queremos tener que confiar en una entidad central. Así que todos los usuarios necesitan poder confirmar esta ausencia de doble gasto, sin depender de un tercero. Así que todo el mundo necesita estar al tanto de todas las transacciones de Bitcoin. Esta es la razón por la que las transacciones de Bitcoin se difunden públicamente en todos los nodos de la red y se registran en texto claro en la blockchain.

Es precisamente esta difusión pública de la información lo que complica la protección de la privacidad en Bitcoin. En el sistema bancario tradicional, en teoría, sólo la entidad financiera tiene conocimiento de las transacciones realizadas. Con Bitcoin, en cambio, todos los usuarios están informados de todas las transacciones, a través de sus respectivos nodos.

El modelo de confidencialidad: sistema bancario frente a Bitcoin

En el sistema tradicional, tu cuenta bancaria está vinculada a tu identidad. El banquero puede saber qué cuenta bancaria pertenece a qué cliente y qué transacciones están asociadas a ella. Sin embargo, este flujo de información está cortado entre el banco y el dominio público. En otras palabras, es imposible conocer el saldo y las transacciones de una cuenta bancaria perteneciente a otro individuo. Sólo el banco tiene acceso a esta información.

Por ejemplo, su banquero sabe que usted compra su baguette cada mañana al panadero local, pero su vecino no tiene conocimiento de esta transacción. De este modo, el flujo de información es accesible para las partes implicadas, en particular el banco, pero permanece inaccesible para los extraños.

Debido a la restricción de la difusión pública de las transacciones que vimos en la sección anterior, el modelo de confidencialidad de Bitcoin no puede seguir el modelo del sistema bancario. En el caso de Bitcoin, dado que el flujo de información no puede interrumpirse entre las transacciones y el dominio público, el modelo de confidencialidad se basa en la separación entre la identidad del usuario y las propias transacciones.

Por ejemplo, si compras una baguette al panadero, pagando en BTC, tu vecino, que tiene su propio nodo completo, puede ver cómo se realiza tu transacción, igual que puede ver todas las demás transacciones del sistema. Sin embargo, si se respetan los principios de confidencialidad, no debería poder vincular esta transacción concreta a tu identidad.

Pero como las transacciones de Bitcoin se hacen públicas, sigue siendo posible establecer vínculos entre ellas para deducir información sobre las partes implicadas. Esta actividad constituye incluso una especialidad por derecho propio, conocida como "análisis de blockchain". En la siguiente parte del curso, le invito a explorar los fundamentos del análisis de blockchain, para que pueda entender cómo se rastrean sus bitcoins y defenderse mejor de ellos.

Comprender el análisis de la cadena y protegerse contra él

¿Qué es el análisis de la cadena Bitcoin?

Definición y funcionamiento

El análisis de la cadena de bloques es la práctica de rastrear el flujo de bitcoins en la cadena de bloques. En términos generales, el análisis de la cadena se basa en la observación de características en muestras de transacciones anteriores. Consiste entonces en identificar estas mismas características en una transacción que deseamos analizar, y deducir interpretaciones plausibles a partir de ellas. Este método de resolución de problemas, basado en un enfoque práctico para encontrar una solución suficientemente buena, se conoce como "heurística".

En términos sencillos, el análisis de la cadena consta de tres etapas principales:

Observando la blockchain ;
La identificación de rasgos conocidos ;
**La deducción de supuestos **

El análisis de la blockchain puede realizarlo cualquiera. Basta con acceder a la información pública de la blockchain a través de un nodo completo para observar los movimientos de las transacciones y formular hipótesis. También existen herramientas gratuitas que facilitan este análisis, como OXT.me, que exploraremos en detalle en los dos últimos capítulos de esta sección. Sin embargo, el principal riesgo para la confidencialidad procede de las empresas especializadas en el análisis de cadenas. Estas empresas han llevado el análisis de blockchain a una escala industrial y venden sus servicios a instituciones financieras y gobiernos. Entre estas empresas, Chainalysis es seguramente la más conocida.

Objetivos del análisis de la cadena

Uno de los objetivos del análisis de blockchain es agrupar diversas actividades en Bitcoin para determinar la unicidad del usuario que las llevó a cabo. Posteriormente, será posible intentar vincular este conjunto de actividades a una identidad real.

Recuerde el capítulo anterior. He explicado por qué el modelo de privacidad de Bitcoin se basaba originalmente en la separación de la identidad del usuario de las transacciones. Por tanto, sería tentador pensar que el análisis de blockchain es inútil, ya que aunque consigamos agregar actividades onchain, no podemos asociarlas a una identidad real.

Teóricamente, esta afirmación es correcta. En la primera parte de este curso, vimos que los pares de claves criptográficas se utilizan para establecer condiciones sobre UTXO. En esencia, estos pares de claves no divulgan ninguna información sobre la identidad de sus titulares. Por lo tanto, aunque consigamos agrupar las actividades asociadas a diferentes pares de claves, esto no nos dice nada sobre la entidad que está detrás de estas actividades.

Sin embargo, la realidad práctica es mucho más compleja. Hay multitud de comportamientos que pueden vincular una identidad real a la actividad onchain. En análisis, esto se denomina punto de entrada, y existen multitud de ellos.

La más común es KYC (Know Your Customer). Si retira sus Bitcoins de una plataforma regulada a una de sus direcciones receptoras personales, algunas personas pueden vincular su identidad a esa dirección. Más ampliamente, un punto de entrada puede ser cualquier forma de interacción entre su vida real y una transacción Bitcoin. Por ejemplo, si publica una dirección de recepción en sus redes sociales, esto podría ser un punto de entrada para el análisis. Si realiza un pago en Bitcoins a su panadero, éste podrá asociar su cara (parte de su identidad) con una dirección Bitcoin.

Estos puntos de entrada son prácticamente inevitables cuando se utiliza Bitcoin. Aunque intentemos restringir su alcance, siempre estarán presentes. Por eso es crucial combinar métodos destinados a preservar su privacidad. Aunque mantener una separación entre su identidad real y sus transacciones es un enfoque interesante, hoy en día sigue siendo insuficiente. En efecto, si todas tus actividades en la cadena pueden agruparse, es probable que hasta el más mínimo punto de entrada comprometa la única capa de confidencialidad que has establecido.

Defenderse del análisis en cadena

Así que también tenemos que ser capaces de hacer frente al análisis de blockchain en nuestro uso de Bitcoin. Al hacerlo, podemos minimizar la agregación de nuestras actividades y limitar el impacto de un punto de entrada en nuestra privacidad.

¿Qué mejor manera de contrarrestar el análisis de blockchain que conocer los métodos utilizados en él? Si quieres saber cómo mejorar tu privacidad en Bitcoin, necesitas entender estos métodos. Esto te dará una mejor comprensión de técnicas como coinjoin o payjoin (técnicas que veremos en las partes finales del curso), y reducirá los errores que puedas cometer.

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/payjoin-848b6a23-deb2-4c5f-a27e-93e2f842140f

En esto, podemos establecer una analogía con la criptografía y el criptoanálisis. Un buen criptógrafo es ante todo un buen criptoanalista. Para idear un nuevo algoritmo de cifrado, necesita saber a qué ataques se enfrentará y también estudiar por qué se han roto algoritmos anteriores. El mismo principio se aplica a la privacidad de Bitcoin. Comprender los métodos de análisis de blockchain es la clave para protegerse contra ellos. Por eso he incluido toda una sección sobre análisis de cadenas en este curso de formación.

Métodos de análisis en cadena

Es importante entender que el análisis de cuerdas no es una ciencia exacta. Se basa en heurísticas derivadas de observaciones previas o interpretaciones lógicas. Estas reglas nos permiten obtener resultados bastante fiables, pero nunca con una precisión absoluta. En otras palabras, el análisis de cadenas siempre implica una dimensión de probabilidad en las conclusiones a las que se llega. Por ejemplo, puede ser posible estimar con diversos grados de certeza que dos direcciones pertenecen a la misma entidad, pero la certeza total siempre estará fuera de nuestro alcance.

Todo el sentido del análisis en cadena reside precisamente en la agregación de diversas heurísticas para minimizar el riesgo de error. En cierto modo, es una acumulación de pruebas que nos acerca a la realidad.

Estas famosas heurísticas pueden agruparse en diferentes categorías, que describiremos en detalle a continuación:

Patrones de transacción ;**
Heurística interna de la transacción ;**
Heurística externa a la transacción.**

Satoshi Nakamoto y el análisis de la cadena

Las dos primeras heurísticas de análisis de cadenas fueron descubiertas por el propio Satoshi Nakamoto. Habla de ellas en la Parte 10 del Libro Blanco de Bitcoin. Son :

cIOH (Heurística de propiedad de entrada común);
y reutilización de direcciones.

Fuente: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Veremos cuáles son en los capítulos siguientes, pero ya es interesante observar que estas dos heurísticas siguen manteniendo hoy una preeminencia en el análisis de cadenas.

Modalidades de transacción

Un patrón de transacción es simplemente un modelo o estructura general de una transacción típica, que puede encontrarse en la blockchain, y cuya interpretación probable es conocida. Al estudiar los patrones, nos centramos en una única transacción y la analizamos a alto nivel.

En otras palabras, sólo vamos a observar el número de UTXO en las entradas y el número de UTXO en las salidas, sin detenernos en los detalles más específicos o el entorno de la transacción. Basándonos en el patrón observado, podemos interpretar la naturaleza de la transacción. A continuación, buscaremos las características de su estructura y deduciremos una interpretación.

En esta sección, veremos juntos los principales modelos de transacción que se encuentran en el análisis de cadenas, y para cada modelo, le daré la interpretación probable de esta estructura, así como un ejemplo concreto.

Envío único (o pago único)

Empecemos por un modelo muy común, ya que es el que aparece en la mayoría de los pagos con bitcoin. El modelo de pago simple se caracteriza por el consumo de uno o más UTXOs como entradas y la producción de 2 UTXOs como salidas. Por lo tanto, este modelo tiene el siguiente aspecto:

Cuando detectamos esta estructura de transacción en la blockchain, ya podemos extraer una interpretación. Como su nombre indica, este modelo indica que estamos ante una transacción de envío o pago. El usuario ha consumido su propio UTXO en entradas para satisfacer en salidas un UTXO de pago y un UTXO de intercambio (dinero devuelto al mismo usuario).

Por lo tanto, sabemos que el usuario observado probablemente ya no está en posesión de uno de los dos UTXO de salida (el UTXO de pago), pero sigue en posesión del otro UTXO (el UTXO de intercambio).

Por el momento, no podemos especificar qué salida representa a qué UTXO, ya que no es el objetivo del estudio de patrones. Llegaremos a ello apoyándonos en la heurística que estudiaremos en las secciones siguientes. Por el momento, nuestro objetivo se limita a identificar la naturaleza de la transacción en cuestión, que en este caso es un simple envío.

Por ejemplo, he aquí una transacción Bitcoin que adopta el patrón de envío simple:

b6cc79f45fd2d7669ff94db5cb14c45f1f879ea0ba4c6e3d16ad53a18c34b769

Source : Mempool.space

Después de este primer ejemplo, debería comprender mejor lo que significa estudiar un "modelo de transacción". Examinamos una transacción centrándonos únicamente en su estructura, sin tener en cuenta su entorno ni los detalles específicos de la transacción. En este primer paso, sólo nos fijamos en el panorama general.

Ahora que ya sabe lo que es un patrón, pasemos a los demás modelos existentes.

Barriendo

Este segundo modelo se caracteriza por el consumo de un único UTXO como entrada y la producción de un único UTXO como salida.

La interpretación de este modelo es que estamos en presencia de una autotransferencia. El usuario se ha transferido sus bitcoins a sí mismo, a otra dirección que le pertenece. Dado que no hay intercambio en la transacción, es muy poco probable que estemos en presencia de un pago. En efecto, cuando se efectúa un pago, es casi imposible que el pagador disponga de un UTXO correspondiente exactamente a la cantidad requerida por el vendedor, más la comisión de transacción. Por lo tanto, en general, el pagador está obligado a producir una salida de cambio.

Entonces sabemos que el usuario observado probablemente sigue en posesión de este UTXO. En el contexto de un análisis en cadena, si sabemos que el UTXO utilizado como entrada en la transacción pertenece a Alice, podemos suponer que el UTXO utilizado como salida también le pertenece. Lo que será interesante más adelante es encontrar heurísticas internas a la transacción que puedan reforzar esta suposición (veremos estas heurísticas en el capítulo 3.3).

Por ejemplo, he aquí una transacción Bitcoin que adopta el patrón de barrido:

35f1072a0fda5ae106efb4fda871ab40e1f8023c6c47f396441ad4b995ea693d

Source : Mempool.space

Cuidado, sin embargo, que este tipo de patrón también puede revelar una autotransferencia a la cuenta de una plataforma de intercambio de criptodivisas. Será el estudio de las direcciones conocidas y el contexto de la transacción lo que nos dirá si se trata de una transferencia a un monedero de autocustodia o de una retirada a una plataforma. De hecho, las direcciones de las plataformas de intercambio suelen ser fácilmente identificables.

Tomemos de nuevo el ejemplo de Alice: si el escaneo conduce a una dirección conocida por una plataforma (como Binance, por ejemplo), esto puede significar que los bitcoins han sido transferidos fuera de la posesión directa de Alice, probablemente con la intención de venderlos o almacenarlos en esta plataforma. Por otro lado, si la dirección de destino es desconocida, es razonable suponer que se trata simplemente de otro monedero que aún pertenece a Alice. Pero este tipo de estudio pertenece más a la categoría de la heurística que a la de los patrones.

Consolidación

Este modelo se caracteriza por el consumo de varios UTXO en la entrada y la producción de un único UTXO en la salida.

La interpretación de este patrón es que estamos en presencia de una consolidación. Se trata de una práctica habitual entre los usuarios de Bitcoin, cuyo objetivo es fusionar varios UTXOs en previsión de un posible aumento de las comisiones por transacción. Realizando esta operación durante un periodo en el que las comisiones son bajas, es posible ahorrar en comisiones futuras. Hablaremos más sobre esta práctica en el capítulo 4.3.

Podemos deducir que el usuario detrás de este modelo de transacción probablemente estaba en posesión de todos los UTXOs en entrada y todavía está en posesión del UTXO en salida. Así que probablemente se trate de una auto-transferencia.

Al igual que el barrido, este tipo de patrón también puede revelar una autotransferencia a la cuenta de una plataforma de intercambio. Será el estudio de las direcciones conocidas y el contexto de la transacción lo que nos diga si se trata de una consolidación a una cartera de autocustodia o de una retirada a una plataforma.

Por ejemplo, he aquí una transacción de Bitcoin que adopta el patrón de consolidación:

77c16914211e237a9bd51a7ce0b1a7368631caed515fe51b081d220590589e94

Source : Mempool.space

En un análisis de cadena, este modelo puede revelar mucha información. Por ejemplo, si sabemos que una de las entradas pertenece a Alicia, podemos suponer que todas las demás entradas y la salida de esta transacción también le pertenecen. Esta suposición permitiría remontar la cadena de transacciones anteriores para descubrir y analizar otras transacciones susceptibles de estar asociadas a Alicia.

Gastos agrupados

Este modelo se caracteriza por el consumo de unos pocos UTXO como insumos (a menudo sólo uno) y la producción de muchos UTXO como productos.

La interpretación de este modelo es que estamos en presencia de un gasto agrupado. Es una práctica que probablemente revela una actividad económica muy grande, como una plataforma de intercambio. El gasto agrupado permite a estas entidades ahorrar costes combinando sus gastos en una única transacción.

Podemos deducir de este modelo que los UTXO de entrada proceden de una empresa con un alto nivel de actividad económica, y que los UTXO de salida se dispersarán. Muchos pertenecerán a los clientes de la empresa que hayan retirado bitcoins de la plataforma. Otros irán a parar a empresas asociadas. Por último, habrá sin duda uno o varios intercambios que volverán a la empresa emisora.

Por ejemplo, aquí hay una transacción Bitcoin que adopta el patrón de gastos agrupados (presumiblemente, es una transacción emitida por la plataforma Bybit):

8a7288758b6e5d550897beedd13c70bcbaba8709af01a7dbcc1f574b89176b43

Source : Mempool.space

Transacciones específicas del protocolo

Entre los patrones de transacción, también podemos identificar aquellos que revelan el uso de un protocolo específico. Por ejemplo, los coinjoins de Whirlpool (analizados en la parte 5) tendrán una estructura fácilmente identificable que los diferenciará de otras transacciones más convencionales.

El análisis de este patrón sugiere que es probable que estemos en presencia de una transacción colaborativa. También es posible observar una coinjoin. Si esta última hipótesis resulta ser correcta, el número de salidas podría proporcionarnos una estimación aproximada del número de participantes en la coinjoin.

Por ejemplo, aquí hay una transacción Bitcoin que adopta el patrón de transacción colaborativa coinjoin:

00601af905bede31086d9b1b79ee8399bd60c97e9c5bba197bdebeee028b9bea

Source : Mempool.space

Existen muchos otros protocolos con sus propias estructuras específicas. Por ejemplo, existen las transacciones Wabisabi, las transacciones Stamps y las transacciones Runes.

Gracias a estos patrones de transacción, ya podemos interpretar cierta información sobre una transacción determinada. Pero la estructura de la transacción no es la única fuente de información para el análisis. También podemos estudiar sus detalles. Estos detalles internos son lo que me gusta llamar "heurística interna", y los estudiaremos en el próximo capítulo.

Heurística interna

Una heurística interna es una característica específica que identificamos dentro de la propia transacción, sin necesidad de examinar su entorno, y que nos permite hacer deducciones. A diferencia de los patrones, que se centran en la estructura general de la transacción a alto nivel, las heurísticas internas se basan en el conjunto de datos extraíbles. Esto incluye:

Los importes de las distintas UTXO de entrada y salida;
Todo lo relacionado con los scripts: direcciones de recepción, versionado, tiempos de bloqueo..

En general, este tipo de heurística nos permitirá identificar el intercambio en una transacción específica. De este modo, podremos perpetuar el rastreo de una entidad a lo largo de varias transacciones diferentes. En efecto, si identificamos un UTXO perteneciente a un usuario que deseamos rastrear, es crucial determinar, cuando realiza una transacción, qué salida ha sido transferida a otro usuario y qué salida representa el intercambio, que permanece así en su poder.

Una vez más, permítanme recordarles que estas heurísticas no son absolutamente precisas. Tomados individualmente, sólo nos permiten identificar escenarios probables. Es la acumulación de varias heurísticas lo que ayuda a reducir la incertidumbre, sin poder eliminarla nunca por completo.

Similitudes internas

Esta heurística consiste en estudiar las similitudes entre las entradas y las salidas de una misma transacción. Si se observa la misma característica en las entradas y en una sola de las salidas de la transacción, es probable que esta salida constituya el intercambio.

La característica más obvia es la reutilización de una dirección receptora en la misma transacción.

Esta heurística deja poco lugar a dudas. A menos que le hayan pirateado su clave privada, la misma dirección de recepción revela necesariamente la actividad de un único usuario. La interpretación resultante es que el intercambio de transacciones es la salida con la misma dirección que la entrada. A partir de este intercambio, podemos seguir el rastro del individuo.

Por ejemplo, he aquí una transacción en la que probablemente pueda aplicarse esta heurística:

54364146665bfc453a55eae4bfb8fdf7c721d02cb96aadc480c8b16bdeb8d6d0

Source : Mempool.space

Estas similitudes entre entradas y salidas no se limitan a la reutilización de direcciones. Cualquier similitud en el uso de guiones puede servir para aplicar una heurística. Por ejemplo, a veces podemos observar el mismo versionado entre la entrada y una de las salidas de la transacción.

En este diagrama, podemos ver que la entrada n° 0 desbloquea un script P2WPKH (SegWit V0 empezando por bc1q). La salida n° 0 utiliza el mismo tipo de script. La salida n° 1, en cambio, utiliza un script P2TR (SegWit V1 que comienza por bc1p). La interpretación de esta característica es que es probable que la dirección con el mismo versionado que la entrada sea la dirección de intercambio. Por lo tanto, pertenecería siempre al mismo usuario.

He aquí una transacción en la que probablemente pueda aplicarse esta heurística:

db07516288771ce5d0a06b275962ec4af1b74500739f168e5800cbcb0e9dd578

Source : Mempool.space

En este último, podemos ver que la entrada nº 0 y la salida nº 1 utilizan scripts P2WPKH (SegWit V0), mientras que la salida nº 0 utiliza un script P2PKH diferente (Legacy).

A principios de 2010, esta heurística basada en el versionado de scripts era relativamente poco útil debido a los limitados tipos de scripts disponibles. Sin embargo, con el tiempo y las sucesivas actualizaciones de Bitcoin, se ha introducido una creciente diversidad de tipos de scripts. Por lo tanto, esta heurística es cada vez más relevante, ya que con una gama más amplia de tipos de script, los usuarios se dividen en grupos más pequeños, aumentando así las posibilidades de aplicar esta heurística de reutilización de versionado interno. Por esta razón, sólo desde el punto de vista de la confidencialidad, es aconsejable optar por el tipo de script más común. Por ejemplo, mientras escribo estas líneas, los scripts Taproot (bc1p) se utilizan con menos frecuencia que los scripts SegWit V0 (bc1q). Aunque los primeros ofrecen ventajas económicas y de confidencialidad en determinados contextos específicos, para usos más tradicionales de firma única, puede tener sentido seguir con un estándar más antiguo por razones de confidencialidad, hasta que el nuevo estándar se adopte más ampliamente.

Pagos con números redondos

Otra heurística interna que puede ayudarnos a identificar el intercambio es la heurística del número redondo. En términos generales, ante un patrón de pago simple (1 entrada y 2 salidas), si una de las salidas gasta una cantidad redonda, entonces esto representa el pago.

Por eliminación, si una salida representa el pago, la otra representa el intercambio. Por lo tanto, puede interpretarse como probable que el usuario de la entrada siempre esté en posesión de la salida identificada como el intercambio.

Hay que subrayar que esta heurística no siempre es aplicable, ya que la mayoría de los pagos se siguen efectuando en unidades de cuenta fiduciarias. De hecho, cuando un minorista en Francia acepta bitcoin, generalmente no mostrará precios estables en sats. En su lugar, optará por una conversión entre el precio en euros y el importe en bitcoins a pagar. Por tanto, no debería haber números redondos al final de la transacción.

No obstante, un analista podría intentar realizar esta conversión teniendo en cuenta el tipo de cambio vigente en el momento de la emisión de la transacción en la red. Tomemos el ejemplo de una transacción con una entrada de "97.552 sats" y dos salidas, una de "31.085 sats" y otra de "64.152 sats". A primera vista, esta transacción no parece implicar importes redondos. Sin embargo, aplicando el tipo de cambio de 64.339 euros en el momento de la transacción, obtenemos una conversión en euros como sigue:

Una aportación de 62,76 euros;
Un rendimiento de 20 euros;
Un rendimiento de 41,27 euros.

Una vez convertida en moneda fiduciaria, esta transacción puede utilizarse para aplicar la heurística de pago de importe redondeado. El producto de 20 euros probablemente fue a parar a un comerciante, o al menos cambió de propietario. Por deducción, es probable que el producto de 41,27 euros haya permanecido en posesión del usuario original.

Si algún día el bitcoin se convierte en la unidad de cuenta preferida en nuestros intercambios, esta heurística podría resultar aún más útil para el análisis.

Por ejemplo, he aquí una transacción en la que probablemente pueda aplicarse esta heurística:

2bcb42fab7fba17ac1b176060e7d7d7730a7b807d470815f5034d52e96d2828a

Source : Mempool.space

La mayor producción

Cuando identificamos una brecha suficientemente grande entre 2 salidas de transacción en un modelo de pago simple, podemos estimar que la mayor salida es probablemente la de divisas.

Esta heurística del mayor rendimiento es seguramente la más imprecisa de todas. Por sí sola, es bastante débil. Sin embargo, esta característica puede combinarse con otras heurísticas para reducir la incertidumbre de nuestra interpretación.

Por ejemplo, si estamos ante una transacción con un pago redondo y un pago mayor, la aplicación conjunta de la heurística del pago redondo y la heurística del pago mayor reduce nuestro nivel de incertidumbre.

Por ejemplo, he aquí una transacción en la que probablemente pueda aplicarse esta heurística:

b79d8f8e4756d34bbb26c659ab88314c220834c7a8b781c047a3916b56d14dcf

Source : Mempool.space

Heurística externa

El estudio de la heurística externa supone analizar las similitudes, pautas y características de determinados elementos que no son propios de la transacción en sí. En otras palabras, mientras que antes nos limitábamos a explotar elementos intrínsecos a la transacción con la heurística interna, ahora ampliamos nuestro campo de análisis para incluir el entorno de la transacción, gracias a la heurística externa.

Reutilización de direcciones

Esta es una de las heurísticas más conocidas de los bitcoiners. La reutilización de direcciones permite establecer un vínculo entre diferentes transacciones y diferentes UTXOs. Se produce cuando una dirección receptora de Bitcoin se utiliza varias veces.

Así, es posible explotar la reutilización de direcciones dentro de la misma transacción como una heurística interna para identificar el intercambio (como vimos en el capítulo anterior). Pero la reutilización de direcciones también puede utilizarse como heurística externa para reconocer la unicidad de una entidad detrás de varias transacciones.

La interpretación de la reutilización de una dirección es que todos los UTXO bloqueados en esa dirección pertenecen (o han pertenecido) a la misma entidad. Esta heurística deja poco margen a la incertidumbre. Una vez identificada, es probable que la interpretación resultante se corresponda con la realidad. Por tanto, permite agrupar diferentes actividades en la cadena.

Como se explica en la introducción de la Parte 3, esta heurística fue descubierta por el propio Satoshi Nakamoto. En el Libro Blanco, menciona una solución para ayudar a los usuarios a evitar generarla, que consiste simplemente en utilizar una dirección en blanco para cada nueva transacción:

"Como cortafuegos adicional, se podría utilizar un nuevo par de claves para cada transacción para mantenerlas desvinculadas de un propietario común."

Fuente: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Por ejemplo, he aquí una dirección que se reutiliza en varias transacciones:

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fuente : Mempool.space

Similitud de guiones e impresiones de carteras

Además de la reutilización de direcciones, existen muchas otras heurísticas que permiten vincular acciones a una misma cartera o grupo de direcciones.

En primer lugar, un analista puede buscar similitudes en el uso de scripts. Por ejemplo, ciertos scripts minoritarios como multisig pueden ser más fáciles de detectar que los scripts SegWit V0. Cuanto mayor sea el grupo en el que nos escondemos, más difícil será descubrirnos. Esta es una de las razones por las que, en los buenos protocolos Coinjoin, todos los participantes utilizan exactamente el mismo tipo de script.

En términos más generales, un analista también puede centrarse en las huellas dactilares características de una cartera. Se trata de procesos específicos del uso que pueden identificarse con vistas a explotarlos como heurística de rastreo. En otras palabras, si observamos una acumulación de las mismas características internas en las transacciones atribuidas a la entidad rastreada, podemos intentar identificar estas mismas características en otras transacciones.

Por ejemplo, podremos identificar que el usuario rastreado envía sistemáticamente su cambio a direcciones P2TR (bc1p...). Si este proceso se repite, podemos utilizarlo como heurística para el resto de nuestro análisis. También podemos utilizar otras huellas, como el orden de UTXOs, el lugar del cambio en las salidas, la señalización RBF (Replace-by-Fee), o el número de versión, el campo nSequence y el campo nLockTime.

Como señala @LaurentMT en Space Kek #19 (un podcast en francés), la utilidad de las huellas de cartera en el análisis de cadenas aumenta considerablemente con el tiempo. En efecto, el número creciente de tipos de escrituras y el despliegue cada vez más progresivo de estas nuevas funcionalidades por parte de los programas informáticos de carteras acentúan las diferencias. En algunos casos, incluso es posible identificar el software exacto utilizado por la entidad rastreada. Por lo tanto, es importante comprender que el estudio de las huellas de cartera es especialmente pertinente para las transacciones recientes, y no para las iniciadas a principios de la década de 2010.

En resumen, una huella puede ser cualquier práctica específica, realizada automáticamente por el monedero o manualmente por el usuario, que podemos encontrar en otras transacciones para ayudarnos en nuestro análisis.

La heurística de la propiedad común de insumos (CIOH)

La heurística de la propiedad común de los insumos (CIOH) es una heurística que establece que cuando una transacción tiene múltiples insumos, es probable que todos ellos procedan de una única entidad. En consecuencia, su propiedad es común.

Para aplicar la CIOH, primero observamos una transacción con varias entradas. Pueden ser 2 o 30 entradas. Una vez identificada esta característica, comprobamos si la transacción se ajusta a un modelo de transacción conocido. Por ejemplo, si hay 5 entradas con aproximadamente el mismo importe y 5 salidas con exactamente el mismo importe, sabremos que se trata de la estructura de una coinjoin. No podremos aplicar el CIOH.

Por otro lado, si la transacción no encaja en ningún modelo de transacción colaborativa conocido, entonces podemos interpretar que es probable que todas las entradas procedan de la misma entidad. Esto puede ser muy útil para ampliar una agrupación ya conocida o continuar un rastreo.

CIOH fue descubierto por Satoshi Nakamoto. Habla de ello en la parte 10 del Libro Blanco:

"[...] la vinculación es inevitable con las transacciones de entradas múltiples, que necesariamente revelan que sus entradas pertenecían al mismo propietario. El riesgo es que si se revela el propietario de una clave, los enlaces pueden revelar otras transacciones que pertenecieron al mismo propietario."

Es especialmente fascinante observar que Satoshi Nakamoto, incluso antes del lanzamiento oficial de Bitcoin, ya había identificado las dos principales vulnerabilidades de privacidad para los usuarios, a saber, CIOH y la reutilización de direcciones. Tal previsión es bastante notable, ya que estas dos heurísticas siguen siendo, incluso hoy en día, las más útiles en el análisis de blockchain.

Por poner un ejemplo, he aquí una operación en la que probablemente podamos aplicar la CIOH:

20618e63b6eed056263fa52a2282c8897ab2ee71604c7faccfe748e1a202d712

Source : Mempool.space

Datos fuera de la cadena

Por supuesto, el análisis de cadenas no se limita exclusivamente a los datos de la cadena. Cualquier dato de un análisis anterior o disponible en Internet también puede servir para afinar un análisis.

Por ejemplo, si observamos que las transacciones rastreadas se emiten sistemáticamente desde el mismo nodo Bitcoin, y conseguimos identificar su dirección IP, podremos identificar otras transacciones de la misma entidad, así como determinar parte de la identidad del emisor. Aunque esta práctica no es fácilmente realizable, ya que requiere el funcionamiento de numerosos nodos, puede ser empleada por algunas empresas especializadas en el análisis de blockchain.

El analista también tiene la opción de basarse en análisis realizados previamente en código abierto, o en sus propios análisis anteriores. Tal vez podamos encontrar un resultado que apunte a un grupo de direcciones que ya hayamos identificado. A veces, también es posible basarse en resultados que apunten a una plataforma de intercambio, ya que las direcciones de estas empresas son generalmente conocidas.

Del mismo modo, se puede realizar un análisis por eliminación. Por ejemplo, si al analizar una transacción con dos salidas, una de ellas se refiere a un clúster de direcciones ya conocido, pero distinto de la entidad que estamos rastreando, entonces podemos interpretar que la otra salida probablemente representa el intercambio.

El análisis de canales también incluye un componente OSINT (Open Source Intelligence) algo más general, que implica búsquedas en Internet. Por este motivo, desaconsejamos publicar direcciones directamente en las redes sociales o en un sitio web, ya sea con seudónimo o sin él.

Modelos temporales

Pensamos menos en ello, pero ciertos comportamientos humanos son reconocibles en cadena. Quizá el más útil en un análisis sea tu patrón de sueño Sí, cuando duermes, no emites transacciones Bitcoin. Pero generalmente duermes más o menos a la misma hora. Por eso es una práctica común utilizar el análisis temporal en el análisis de blockchain. En pocas palabras, se trata de un censo de las horas a las que las transacciones de una entidad determinada se emiten a la red Bitcoin. Analizando estos patrones temporales, podemos deducir una gran cantidad de información.

En primer lugar, un análisis temporal permite a veces identificar la naturaleza de la entidad rastreada. Si observamos que las transacciones se emiten de forma constante a lo largo de 24 horas, esto delatará un alto nivel de actividad económica. Es probable que la entidad detrás de estas transacciones sea una empresa, potencialmente internacional y tal vez con procedimientos internos automatizados.

Por ejemplo, reconocí este patrón hace unos meses al analizar la transacción que había asignado por error 19 bitcoins en comisiones. Un simple análisis temporal me permitió plantear la hipótesis de que se trataba de un servicio automatizado y, por tanto, probablemente de una gran entidad como una plataforma de intercambio.

Efectivamente, unos días después se descubrió que los fondos pertenecían a PayPal, a través de la plataforma de intercambio Paxos.

Por el contrario, si vemos que el patrón temporal está más bien repartido en 16 horas concretas, podemos estimar que se trata de un usuario individual, o quizá de una empresa local en función de los volúmenes intercambiados.

Más allá de la naturaleza de la entidad observada, el patrón temporal también puede indicarnos aproximadamente dónde se encuentra el usuario, gracias a las zonas horarias. De este modo, podemos cotejar otras transacciones y utilizar sus marcas temporales como una heurística adicional que puede añadirse a nuestro análisis.

Por ejemplo, en la dirección multiusuario que he mencionado antes, podemos ver que las transacciones, tanto entrantes como salientes, se concentran en un intervalo de 13 horas.

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fuente : OXT.me

Esta franja corresponde probablemente a Europa, África u Oriente Medio. Por lo tanto, podemos suponer que el usuario que está detrás de estas transacciones vive en estas zonas.

En otro orden de cosas, un análisis temporal de este tipo también condujo a la hipótesis de que Satoshi Nakamoto no operaba desde Japón, sino desde EE.UU.: The Time Zones of Satoshi Nakamoto

Ponerlo en práctica con un explorador de bloques

En este capítulo final, vamos a poner en práctica los conceptos que hemos estudiado hasta ahora. Te voy a mostrar ejemplos de transacciones reales de Bitcoin, y tendrás que extraer la información que te pido.

Lo ideal para realizar estos ejercicios sería utilizar una herramienta profesional de análisis de cadenas. Sin embargo, desde la detención de los creadores de Samourai Wallet, la única herramienta de análisis gratuita OXT.me ya no está disponible. Por lo tanto, optaremos por un explorador de bloques clásico para estos ejercicios. Recomiendo el uso de Mempool.space por sus numerosas funciones y su gama de herramientas de análisis de cadenas, pero también puedes optar por otro explorador como Bitcoin Explorer.

Para empezar, te presentaré los ejercicios. Utiliza tu explorador de bloques para completarlos y anota tus respuestas en una hoja de papel. Al final del capítulo te daré las respuestas para que puedas comprobar y corregir tus resultados.

Las operaciones seleccionadas para estos ejercicios se han elegido puramente por sus características de forma un tanto aleatoria. Este capítulo está destinado únicamente a fines educativos e informativos. Me gustaría dejar claro que ni apoyo ni animo al uso de estas herramientas con fines maliciosos. El objetivo es enseñarte a protegerte contra el análisis de cadenas, no a realizar análisis para exponer información privada de otras personas.

Ejercicio 1

Identificador de la transacción a analizar :

3769d3b124e47ef4ffb5b52d11df64b0a3f0b82bb10fd6b98c0fd5111789bef7

¿Cómo se llama el modelo de esta transacción y qué interpretaciones plausibles pueden extraerse examinando únicamente su modelo, es decir, la estructura de la transacción?

Ejercicio 2

Identificador de la transacción a analizar :

baa228f6859ca63e6b8eea24ffad7e871713749d693ebd85343859173b8d5c20

¿Cómo se llama el modelo de esta transacción y qué interpretaciones plausibles pueden extraerse examinando únicamente su modelo, es decir, la estructura de la transacción?

Ejercicio 3

Identificador de la transacción a analizar :

3a9eb9ccc3517cc25d1860924c66109262a4b68f4ed2d847f079b084da0cd32b

¿Cuál es el modelo de esta transacción?

Una vez identificado su modelo, utilizando la heurística interna de la operación, ¿qué resultado es probable que represente el intercambio?

Ejercicio 4

Identificador de la transacción a analizar :

35f0b31c05503ebfdf7311df47f68a048e992e5cf4c97ec34aa2833cc0122a12

¿Cuál es el modelo de esta transacción?

Una vez identificado su modelo, utilizando la heurística interna de la operación, ¿qué resultado es probable que represente el intercambio?

Ejercicio 5

Imaginemos que Loïc ha publicado una de sus direcciones de recepción de Bitcoin en la red social Twitter :

bc1qja0hycrv7g9ww00jcqanhfpqmzx7luqalum3vu

Basándose en esta información y utilizando sólo la heurística de reutilización de direcciones, ¿qué transacciones de Bitcoin pueden vincularse a la identidad de Loïc?

Obviamente, no soy el verdadero propietario de esta dirección de recepción y no la he publicado en las redes sociales. Es una dirección que tomé al azar de la blockchain

Ejercicio 6

Siguiendo el ejercicio 5, gracias a la heurística de reutilización de direcciones, has podido identificar varias transacciones de Bitcoin en las que parece estar implicado Loïc. Normalmente, entre las transacciones identificadas, deberías haber visto esta:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace

Esta transacción es la primera que envía fondos a la dirección de Loïc. ¿De dónde crees que proceden los bitcoins recibidos por Loïc a través de esta transacción?

Ejercicio 7

Siguiendo el ejercicio 5, gracias a la heurística de reutilización de direcciones, has podido identificar varias transacciones de Bitcoin en las que Loïc parece estar involucrado. Ahora quieres averiguar de dónde procede Loïc. Basándote en las transacciones encontradas, realiza un análisis horario para encontrar la zona horaria más probablemente utilizada por Loïc. A partir de esta zona horaria, determina la ubicación en la que parece vivir Loïc (país, estado/región, ciudad...).

Ejercicio 8

He aquí la transacción Bitcoin a estudiar:

bb346dae645d09d32ed6eca1391d2ee97c57e11b4c31ae4325bcffdec40afd4f

Si nos fijamos únicamente en esta transacción, ¿qué información podemos interpretar?

Soluciones de ejercicio

Ejercicio 1:

El modelo para esta transacción es el modelo de pago simple. Si estudiamos sólo su estructura, podemos interpretar que una salida representa el intercambio y la otra salida representa un pago real. Por lo tanto, sabemos que el usuario observado probablemente ya no está en posesión de uno de los dos UTXO de salida (el del pago), pero sigue estando en posesión del otro UTXO (el del intercambio).

Ejercicio 2:

El modelo de esta transacción es el del gasto agrupado. Este modelo revela probablemente una actividad económica a gran escala, como una plataforma de intercambio. Podemos deducir que el UTXO de entrada procede de una empresa con un alto nivel de actividad económica, y que los UTXO de salida estarán dispersos. Algunos pertenecerán a clientes de la empresa que han retirado sus bitcoins a monederos de autocustodia. Otros irán a parar a empresas asociadas. Por último, habrá sin duda algún intercambio que volverá a la empresa emisora.

Ejercicio 3:

El modelo de esta transacción es el pago simple. Por lo tanto, podemos aplicar la heurística interna a la transacción para tratar de identificar el intercambio.

Personalmente he identificado al menos dos heurísticas internas que apoyan la misma hipótesis:

La reutilización del mismo tipo de escritura ;
La mayor producción.

La heurística más evidente es la de reutilizar el mismo tipo de script. En efecto, la salida 0 es un P2SH, reconocible por su dirección de recepción que empieza por 3 :

3Lcdauq6eqCWwQ3UzgNb4cu9bs88sz3mKD

Mientras que la salida 1 es un P2WPKH, identificable por su dirección que empieza por bc1q :

bc1qya6sw6sta0mfr698n9jpd3j3nrkltdtwvelywa

El UTXO utilizado como entrada para esta operación también utiliza un script P2WPKH:

bc1qyfuytw8pcvg5vx37kkgwjspg73rpt56l5mx89k

Así, podemos suponer que la salida 0 corresponde a un pago y la salida 1 es el intercambio de la transacción, lo que significaría que el usuario de entrada siempre posee la salida 1.

Para apoyar o refutar esta hipótesis, podemos buscar otros heurísticos que confirmen nuestro pensamiento o disminuyan la probabilidad de que nuestra hipótesis sea correcta.

He identificado al menos otra heurística. Es la heurística de salida más grande. La salida 0 mide 123.689 saturaciones, mientras que la salida 1 mide 505.839 saturaciones. Por lo tanto, hay una diferencia significativa entre estas dos salidas. La heurística de la mayor producción sugiere que la mayor producción es probablemente la de divisas. Esta heurística refuerza aún más nuestra hipótesis inicial.

Por lo tanto, parece probable que el usuario que suministró el UTXO como entrada siga teniendo la salida "1", que parece encarnar el intercambio de la transacción.

Ejercicio 4:

El modelo de esta transacción es el pago simple. Por lo tanto, podemos aplicar la heurística interna a la transacción para tratar de identificar el intercambio.

Personalmente he identificado al menos dos heurísticas internas que apoyan la misma hipótesis:

La reutilización del mismo tipo de escritura ;
La salida del poste redondo.

La heurística más evidente es la de reutilizar el mismo tipo de script. En efecto, la salida 0 es un P2SH, reconocible por su dirección de recepción que empieza por 3 :

3FSH5Mnq6S5FyQoKR9Yjakk3X4KCGxeaD4

Mientras que la salida 1 es un P2WPKH, identificable por su dirección que empieza por bc1q :

bc1qvdywdcfsyavt4v8uxmmrdt6meu4vgeg439n7sg

El UTXO utilizado como entrada para esta operación también utiliza un script P2WPKH:

bc1qku3f2y294h3ks5eusv63dslcua2xnlzxx0k6kp

Así, podemos suponer que la salida 0 corresponde a un pago y la salida 1 es el intercambio de la transacción, lo que significaría que el usuario de entrada siempre posee la salida 1.

Para apoyar o refutar esta hipótesis, podemos buscar otros heurísticos que confirmen nuestro pensamiento o disminuyan la probabilidad de que nuestra hipótesis sea correcta.

He identificado al menos otra heurística. Es la salida de cantidad redonda. La salida 0 mide 70.000 sats, mientras que la salida 1 mide 22.962 sats. Por tanto, tenemos una salida perfectamente redonda en la unidad de cuenta BTC. La heurística de la salida redonda sugiere que la UTXO con una cantidad redonda es muy probablemente la de pago, y que por eliminación, la otra representa el intercambio. Esta heurística refuerza aún más nuestra hipótesis inicial.

Sin embargo, en este ejemplo, otra heurística podría cuestionar nuestra hipótesis inicial. En efecto, la salida "0" es mayor que la salida "1". Basándonos en la heurística de que la salida mayor suele ser de divisas, podríamos deducir que la salida 0 es de divisas. Sin embargo, esta contrahipótesis parece poco plausible, ya que las otras dos heurísticas parecen sustancialmente más convincentes que la heurística de la mayor salida. En consecuencia, parece razonable mantener nuestra hipótesis inicial a pesar de esta aparente contradicción.

Por lo tanto, parece probable que el usuario que suministró el UTXO como entrada siga teniendo la salida "1", que parece encarnar el intercambio de la transacción.

Ejercicio 5:

Podemos ver que 8 transacciones pueden asociarse a la identidad de Loïc. De ellas, 4 implican la recepción de bitcoins:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace
8b70bd322e6118b8a002dbdb731d16b59c4a729c2379af376ae230cf8cdde0dd
d5864ea93e7a8db9d3fb113651d2131567e284e868021e114a67c3f5fb616ac4
bc4dcf2200c88ac1f976b8c9018ce70f9007e949435841fc5681fd33308dd762

Los otros 4 se refieren a envíos de bitcoin:

8b52fe3c2cf8bef60828399d1c776c0e9e99e7aaeeff721fff70f4b68145d540
c12499e9a865b9e920012e39b4b9867ea821e44c047d022ebb5c9113f2910ed6
a6dbebebca119af3d05c0196b76f80fdbf78f20368ebef1b7fd3476d0814517d
3aeb7ce02c35eaecccc0a97a771d92c3e65e86bedff42a8185edd12ce89d89cc

Ejercicio 6:

Si observamos el modelo de esta transacción, queda claro que se trata de un gasto agrupado. En efecto, la transacción tiene un único input y 51 outputs, lo que indica un alto nivel de actividad económica. Por tanto, podemos plantear la hipótesis de que Loïc ha retirado bitcoins de una plataforma de intercambio.

Varios factores refuerzan esta hipótesis. En primer lugar, el tipo de script utilizado para asegurar la entrada UTXO es un script multisig P2SH 2/3, lo que indica un nivel avanzado de seguridad típico de las plataformas de intercambio:

OP_PUSHNUM_2
OP_PUSHBYTES_33 03eae02975918af86577e1d8a257773118fd6ceaf43f1a543a4a04a410e9af4a59
OP_PUSHBYTES_33 03ba37b6c04aaf7099edc389e22eeb5eae643ce0ab89ac5afa4fb934f575f24b4e
OP_PUSHBYTES_33 03d95ef2dc0749859929f3ed4aa5668c7a95baa47133d3abec25896411321d2d2d
OP_PUSHNUM_3
OP_CHECKMULTISIG

Además, la dirección estudiada 3PUv9tQMSDCEPSMsYSopA5wDW86pwRFbNF se reutiliza en más de 220.000 transacciones diferentes, lo que suele ser característico de las plataformas de intercambio, generalmente poco preocupadas por su confidencialidad.

La heurística temporal aplicada a esta dirección también muestra una emisión regular de transacciones casi a diario durante un periodo de 3 meses, con horarios extendidos durante más de 24 horas, lo que sugiere la actividad continua de una plataforma de intercambio.

Por último, los volúmenes manejados por esta entidad son colosales. La dirección recibió y envió 44 BTC en 222.262 transacciones entre diciembre de 2022 y marzo de 2023. Estos grandes volúmenes confirman aún más el carácter probable de la actividad de una plataforma de intercambio.

Ejercicio 7:

Analizando las horas de confirmación de las transacciones, se pueden identificar las siguientes horas UTC:

Un análisis de estos horarios muestra que UTC-7 y UTC-8 son coherentes con un rango de actividad humana actual (entre las 08:00 y las 23:00) para la mayoría de los horarios:

05:43 UTC > 22:43 UTC-7
20:51 UTC > 13:51 UTC-7
18:12 UTC > 11:12 UTC-7
17:16 UTC > 10:16 UTC-7
04:28 UTC > 21:28 UTC-7
23:38 UTC > 16:38 UTC-7
07:45 UTC > 00:45 UTC-7
21:55 UTC > 14:55 UTC-7
05:43 UTC > 21:43 UTC-8
20:51 UTC > 12:51 UTC-8
18:12 UTC > 10:12 UTC-8
17:16 UTC > 09:16 UTC-8
04:28 UTC > 20:28 UTC-8
23:38 UTC > 15:38 UTC-8
07:45 UTC > 23:45 UTC-8
21:55 UTC > 13:55 UTC-8

El huso horario UTC-7 es especialmente relevante en verano, ya que incluye estados y regiones como :

California (con ciudades como Los Ángeles, San Francisco y San Diego);
Nevada (con Las Vegas) ;
Oregón (con Portland) ;
Washington (con Seattle) ;
La región canadiense de Columbia Británica (con ciudades como Vancouver y Victoria).

Esta información sugiere que es probable que Loïc resida en la costa oeste de Estados Unidos o Canadá.

Ejercicio 8:

El análisis de esta transacción revela 5 entradas y una única salida, lo que sugiere una consolidación. Aplicando la heurística CIOH, podemos suponer que todos los UTXO de entrada son propiedad de una única entidad, y que el UTXO de salida también pertenece a esta entidad. Parece que el usuario optó por agrupar varios UTXO de su propiedad para formar un único UTXO de salida, con el objetivo de consolidar sus piezas. Probablemente, este movimiento estaba motivado por el deseo de aprovechar los bajos costes de transacción de la época, con el fin de reducir los costes futuros.

Para escribir esta parte 3 sobre el análisis de la cadena, me he basado en los siguientes recursos:

La serie de cuatro artículos titulada: Understanding Bitcoin Privacy with OXT, elaborada por Samourai Wallet en 2021 ;*
Los diversos informes de OXT Research, así como su herramienta gratuita de análisis de blockchain (ya no disponible por el momento tras la detención de los fundadores de Samourai Wallet) ;*
En términos más generales, mis conocimientos proceden de varios tweets y contenidos de @LaurentMT y @ErgoBTC ;*
El Space Kek #19 en el que participé en compañía de @louneskmt, @TheoPantamis, @Sosthene___ y @LaurentMT.*

Me gustaría dar las gracias a sus autores, desarrolladores y productores. Gracias también a los correctores que corrigieron meticulosamente el artículo en el que se basa esta parte 3 y me dieron sus expertos consejos :

Gilles Cadignan ;*
Ludovic Lars

Dominar las mejores prácticas para proteger su privacidad

Reutilización de direcciones

Habiendo estudiado las técnicas que pueden romper su confidencialidad en Bitcoin, en esta tercera parte veremos ahora las mejores prácticas a adoptar para protegerse. El objetivo de esta parte no es explorar métodos para mejorar la confidencialidad, tema que se tratará más adelante, sino comprender cómo interactuar correctamente con Bitcoin para conservar la confidencialidad que ofrece de forma natural, sin recurrir a técnicas adicionales.

Obviamente, para empezar esta tercera parte, vamos a hablar de la reutilización de direcciones. Este fenómeno es la principal amenaza para la confidencialidad de los usuarios. Este capítulo es seguramente el más importante de todo el curso.

¿Qué es una dirección de recepción?

Una dirección de recepción de Bitcoin es una cadena o identificador utilizado para recibir bitcoins en un monedero.

Técnicamente, una dirección receptora de Bitcoin no "recibe" bitcoins en sentido literal, sino que sirve para definir las condiciones en las que se pueden gastar bitcoins. En concreto, cuando se le envía un pago, la transacción del remitente crea un nuevo UTXO para usted como salida de los UTXOs que ha consumido como entradas. En esta salida, coloca un guión que define cómo puede gastarse este UTXO en una fecha posterior. Este script se conoce como "ScriptPubKey" o "Locking Script". Tu dirección de recepción, o más exactamente su carga útil, está integrada en este script. En términos sencillos, este script básicamente dice:

"Para gastar este nuevo UTXO, debe proporcionar una firma digital utilizando la clave privada asociada a esta dirección de recepción."

Las direcciones Bitcoin vienen en diferentes tipos, dependiendo del modelo de scripting utilizado. Los primeros modelos, conocidos como "Legacy*", incluyen las direcciones P2PKH (Pay-to-PubKey-Hash) y P2SH (Pay-to-Script-Hash). Las direcciones P2PKH empiezan siempre por 1, y las P2SH por 3. Aunque siguen siendo seguros, estos formatos han quedado obsoletos, ya que conllevan mayores costes de transacción y ofrecen menos confidencialidad que los nuevos estándares.

Las direcciones SegWit V0 (P2WPKH y P2WSH) y Taproot / SegWit V1 (P2TR) representan formatos modernos. Las direcciones SegWit empiezan por bc1q y las Taproot, introducidas en 2021, empiezan por bc1p.

Por ejemplo, esta es una dirección de recepción de Taproot:

bc1ps5gd2ys8kllz9alpmcwxqegn7kl3elrpnnlegwkm3xpq2h8da07spxwtf5

La forma en que se construya la ScriptPubKey dependerá del estándar que esté utilizando:

| ScriptPubKey | Plantilla de script

| ---------------- | ----------------------------------------------------------- |

| P2PKH | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG |

| P2SH | OP_HASH160 <scriptHash> OP_EQUAL |

0 <pubKeyHash> | P2WPKH | 0 <pubKeyHash> |

| P2WSH 0 <witnessScriptHash> |

| P2SH - P2WPKH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2SH - P2WSH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2TR | 1 <pubKey> |

La construcción de las direcciones de recepción también depende del modelo de guión elegido:

Para las direcciones P2PKH y P2WPKH, la carga útil, es decir, el núcleo de la dirección, representa el hash de la clave pública;
Para las direcciones P2SH y P2WSH, la carga útil representa el hash de un archivo ;
En cuanto a las direcciones P2TR, la carga útil es una clave pública modificada. Las salidas P2TR combinan aspectos de Pay-to-PubKey y Pay-to-Script. La clave pública retocada es el resultado de añadir una clave pública de gasto clásica con un "retoque", derivada de la raíz Merkle de un conjunto de scripts que también pueden utilizarse para gastar bitcoins.

Las direcciones que aparecen en el software de su cartera también incluyen una HRP (Human-Readable Part), normalmente bc para direcciones post-SegWit, un separador 1 y un número de versión q para SegWit V0 y p para Taproot/SegWit V1. También se añade una suma de comprobación para garantizar la integridad y validez de la dirección durante la transmisión.

Por último, las direcciones se colocan en un formato estándar:

Base58check para direcciones Legacy antiguas ;
Bech32 para direcciones SegWit ;
Bech32m para direcciones Taproot.

Aquí está la matriz de suma para los formatos bech32 y bech32m (SegWit y Taproot) de base 10:

| + | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

| --- | --- | --- | --- | --- | --- | --- | --- | --- |

| 0 | q | p | z | r | y | 9 | x | 8 |

| 8 | g | f | 2 | t | v | d | w | 0 |

| 16 | s | 3 | j | n | 5 | 4 | k | h |

| 24 | c | e | 6 | m | u | a | 7 | l |

¿Qué es la reutilización de direcciones?

La reutilización de direcciones es el uso de la misma dirección de recepción para bloquear varios UTXO diferentes.

Como vimos en la sección anterior, cada UTXO tiene su propia ScriptPubKey, que lo bloquea y debe ser satisfecha para que el UTXO sea consumido como entrada en una nueva transacción. Es dentro de esta ScriptPubKey donde se integran las direcciones de carga útil.

Cuando diferentes ScriptPubKeys contienen la misma dirección receptora, esto se denomina reutilización de direcciones. En la práctica, esto significa que un usuario ha proporcionado repetidamente la misma dirección a los remitentes para recibir bitcoins a través de múltiples pagos. Y es precisamente esta práctica la que resulta desastrosa para tu privacidad.

¿Por qué es un problema la reutilización de direcciones?

Como la blockchain es pública, es fácil ver qué direcciones bloquean qué UTXO y cuántos bitcoins. Si se utiliza la misma dirección para varias transacciones, es posible deducir que todos los bitcoins asociados a esa dirección pertenecen a la misma persona. Esta práctica compromete la privacidad del usuario al permitir establecer vínculos deterministas entre distintas transacciones y rastrear los bitcoins en la blockchain. El propio Satoshi Nakamoto ya puso de manifiesto este problema en el Libro Blanco de Bitcoin:

Como cortafuegos adicional, podría utilizarse un nuevo par de claves para cada transacción a fin de mantenerlas desvinculadas de un propietario común

Fuente: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

La intención de Satoshi con esta frase era crear un cortafuegos adicional en caso de asociación entre la identidad de un usuario y un par de claves en Bitcoin, para evitar que toda su actividad se vinculara públicamente a su identidad. Hoy en día, con la proliferación de empresas de análisis de blockchain y las normativas KYC, el uso de direcciones únicas ya no es un "cortafuegos adicional", sino una práctica indispensable para cualquiera que desee preservar un mínimo de privacidad.

Cuando reutilizas una dirección, estableces un vínculo casi innegable entre todas las transacciones asociadas a esa dirección. Aunque esto no pone directamente en peligro tus fondos, ya que la criptografía de curva elíptica garantiza la seguridad de tus claves privadas, sí facilita el seguimiento de tus actividades. En efecto, cualquiera que disponga de un nodo puede observar las transacciones y saldos de las direcciones, comprometiendo totalmente tu anonimato.

Para ilustrar este punto, tomemos el ejemplo de Bob, un usuario que compra regularmente bitcoins en pequeñas cantidades en DCA y los envía siempre a la misma dirección. Al cabo de dos años, esta dirección contiene una cantidad considerable de bitcoins. Si Bob utiliza esta dirección para hacer un pago a un comerciante local, éste podrá ver todos los fondos asociados y deducir la riqueza de Bob. Esto puede conllevar riesgos para la seguridad personal, como intentos de robo o extorsión. Si Bob hubiera utilizado una dirección en blanco para recibir cada compra periódica, habría revelado infinitamente menos información a su comerciante.

En el análisis de cadenas, existen 2 tipos de reutilización de direcciones:

Reutilización externa ;
Reutilización interna dentro de una transacción.

La primera es cuando una dirección se reutiliza en varias transacciones Bitcoin diferentes. Es de lo que hablábamos antes: esta heurística deduce que todos los UTXO que pasan por esta dirección pertenecen a una única entidad.

La reutilización interna de direcciones no se produce cuando la reutilización se produce a lo largo de varias transacciones, sino cuando se produce dentro de una misma transacción. En efecto, si la misma dirección utilizada para bloquear una entrada se utiliza como salida de una transacción, podemos deducir que esta salida sigue perteneciendo al mismo usuario (intercambio), y que la segunda salida representa el pago real. Esta otra heurística permite perpetuar un rastro de fondos a lo largo de varias transacciones.

La reutilización de direcciones es una auténtica lacra en Bitcoin. Según el sitio web OXT.me (actualmente inaccesible), la tasa global de reutilización de direcciones en Bitcoin rondaba el 52 % en 2022:

Esta tasa es enorme, pero procede en su inmensa mayoría de plataformas de intercambio y no de usuarios individuales.

¿Cómo evitar la reutilización de direcciones?

Evitar la reutilización de direcciones es muy sencillo: Simplemente utilice una nueva dirección en blanco para todos los nuevos pagos a su monedero.

Gracias a BIP32, las carteras modernas son ahora deterministas y jerárquicas. Esto significa que un usuario puede generar un gran número de direcciones a partir de un único dato inicial: la semilla. Al guardar esta única información, es posible restaurar todas las claves privadas de la cartera, lo que permite acceder a los fondos garantizados por las direcciones correspondientes.

Por eso, cuando pulsas el botón "recibir" en el software de tu monedero, siempre se sugiere una dirección de recepción no utilizada. Después de recibir bitcoins en esta dirección, el software sugiere automáticamente una nueva.

PD: Recientemente, algunos programas de software de monedero han anunciado su intención de dejar de generar direcciones en blanco, temiendo que esto sea percibido como una forma de blanqueo de dinero por las autoridades. Si su software es uno de estos, le aconsejo encarecidamente que lo sustituya inmediatamente, ya que esto no es aceptable para el usuario. Si necesita un identificador estático para recibir pagos, como donaciones, no es aconsejable utilizar una dirección Bitcoin clásica por el riesgo de reutilización. En su lugar, utilice una dirección Lightning, u opte por un identificador de pago estático onchain, como BIP47 o Silent Payments. Estos protocolos se explican en detalle en la Parte 6 de este curso de formación.

Etiquetado y control de piezas

Como descubrimos en la sección sobre análisis de cadenas, existen multitud de heurísticas y patrones que pueden utilizarse para deducir información sobre una transacción. Como usuario, es importante conocer estas técnicas para protegerse mejor contra ellas.

Esto implica una gestión rigurosa de su monedero en autocustodia, lo que significa conocer el origen de sus UTXOs, así como seleccionar cuidadosamente qué UTXOs consumir al realizar pagos. Esta gestión eficiente del monedero se basa en dos características importantes de los buenos monederos Bitcoin: el etiquetado y el control de monedas.

En este capítulo, examinaremos estas características y veremos cómo puede usarlas inteligentemente, sin añadir demasiada carga de trabajo, para optimizar enormemente su privacidad en Bitcoin.

¿Qué es el etiquetado?

El etiquetado es la práctica de asignar una anotación o etiqueta a un UTXO específico en un monedero Bitcoin. Estas anotaciones son almacenadas localmente por el software del monedero y nunca se transmiten a través de la red Bitcoin. El etiquetado es, por tanto, una herramienta de gestión personal.

Por ejemplo, si tengo un UTXO de una compra P2P en Bisq con Charles, podría etiquetarlo como "Non-KYC Bisq Charles".

El etiquetado es una buena práctica que ayuda a recordar el origen o el destino previsto de un UTXO, lo que facilita la gestión de los fondos y la optimización de la privacidad. En efecto, su monedero Bitcoin seguramente asegura varios UTXOs. Si las fuentes de estos UTXOs son diferentes, es posible que no desee fusionar estos UTXOs en el futuro, de lo contrario podría revelar su propiedad común. Etiquetando adecuadamente todas sus piezas, puede estar seguro de que recordará de dónde proceden cuando necesite utilizarlas, aunque eso sea dentro de años.

¿Qué es el control de esquinas?

El uso activo del etiquetado resulta aún más interesante cuando se combina con una opción de control de monedas en el software de su cartera.

El control de monedas es una característica que se encuentra en un buen software de monedero Bitcoin, que le da la posibilidad de seleccionar manualmente UTXOs específicos para utilizarlos como entradas para completar una transacción. De hecho, para satisfacer un pago de salida, necesita consumir un UTXO de entrada a cambio. Por una serie de razones, que veremos más adelante, es posible que desee elegir con precisión qué partes consumir como entradas para satisfacer un pago determinado. Esto es exactamente lo que le permite hacer el control de monedas. Para darle una analogía, esta característica es similar a la elección de una moneda específica de su cartera cuando usted paga por su baguette.

El uso de software de cartera con control de monedas, junto con el etiquetado de UTXO, permite a los usuarios distinguir y seleccionar con precisión los UTXO para sus transacciones.

¿Cómo etiqueta sus UTXO?

No existe un método único para etiquetar los UTXO. Depende de usted definir un sistema de etiquetado que sea fácil de entender para su cartera. En cualquier caso, tenga en cuenta que un buen etiquetado es un etiquetado que pueda entender cuando lo necesite. Si su cartera Bitcoin está destinada principalmente al ahorro, puede que las etiquetas no le sean útiles durante décadas. Así que asegúrese de que sean claras, precisas y completas.

Es importante que sus seres queridos puedan identificar fácilmente el origen de los fondos si, algún día, necesitan acceder a su cartera. Esto les ayudará tanto por razones de confidencialidad como a efectos legales, en caso de que tengan que justificar el origen de los fondos ante una autoridad.

Lo más importante que hay que anotar en la etiqueta es la procedencia de la UTXO. Simplemente debe indicar cómo llegó la moneda a su monedero. ¿Es el resultado de una compra en una plataforma de intercambio? ¿El pago de una factura de un cliente? ¿Un intercambio entre pares? ¿O representa el intercambio de un gasto? Por ejemplo, podría especificar:

eliminar Exchange.com` ;
pago del cliente David` ;
comprar P2P Charles` ;
Cambiar compra de sofá

Para afinar su gestión de UTXO y respetar sus estrategias de segregación de fondos dentro de su cartera, podría enriquecer sus etiquetas con un indicador adicional que refleje estas separaciones. Si su cartera contiene dos categorías de UTXO que le interesa no mezclar, podría incorporar un marcador en sus etiquetas para distinguir claramente estos grupos. Estos marcadores de separación dependerán de sus propios criterios, como por ejemplo distinguir entre UTXO resultantes de un proceso de adquisición que implique KYC, o entre fondos profesionales y personales. Tomando los ejemplos de etiquetas mencionados anteriormente, esto podría traducirse en:

KYC - Retiro Exchange.com ;
KYC - Pago del cliente David ;
NO KYC - Comprar P2P Charles ;
NO KYC - Cambio sofá compra

También es aconsejable perpetuar el etiquetado de una parte a lo largo de las transacciones. Por ejemplo, al consolidar UTXO no-KYC, asegúrese de marcar el UTXO resultante no sólo como "consolidación", sino específicamente como "consolidación no-KYC" para mantener un registro claro de la procedencia de las monedas.

Por último, no es obligatorio poner una fecha en una etiqueta. La mayoría de los programas de monedero ya muestran la fecha de la transacción, y siempre es posible encontrar esta información en un explorador de bloques gracias a su TXID.

¿Cómo elegir las piezas adecuadas?

Cuando realizas una transacción, el control de monedas te permite elegir específicamente qué UTXOs consumir como entradas para satisfacer la salida del pago. Esta elección tiene dos aspectos:

La posibilidad de que el receptor del pago vincule parte de su identidad a los UTXO utilizados en las entradas;
La capacidad de un observador externo para establecer vínculos entre todas las UTXO consumidas como entradas.

Para ilustrar el primer punto, pongamos un ejemplo concreto. Supongamos que compras una baguette en bitcoins a tu panadero. Utilizas uno o varios UTXO que posees como entradas para satisfacer al menos el precio de la baguette en salidas, así como las comisiones de la transacción. Su panadero podría entonces asociar su cara, o cualquier otra parte de su identidad que conozca, con las monedas utilizadas como entradas. Conociendo la existencia de este vínculo, es posible que prefieras elegir un UTXO concreto en lugar de otro a la hora de pagar.

Por ejemplo, si uno de tus UTXO procede de una plataforma de intercambio y prefieres que el panadero no sepa nada de tu cuenta en esa plataforma, evitarás utilizar ese UTXO para pagar. Si tienes un UTXO de alto valor que revela una cantidad significativa de bitcoins, también podrías optar por no usarlo para evitar que el panadero se entere de tu fortuna en BTC.

Elegir qué UTXOs utilizar para este primer punto es, por tanto, una decisión personal, influida por lo que estés dispuesto a revelar o no. Las etiquetas que asignes a tus UTXO cuando los recibas te ayudarán a seleccionar aquellos que, una vez gastados, sólo expongan información que te sientas cómodo revelando al destinatario.

Más allá de la información potencialmente revelada al destinatario, la elección de las entradas también influye en lo que revelas a todos los observadores de la cadena de bloques. De hecho, al utilizar varios UTXO como entradas en tu transacción, revelas que son propiedad de la misma entidad, según la heurística CIOH (Common Input Ownership Heuristic).

Por lo tanto, al seleccionar sus piezas, debe tener en cuenta que la transacción que va a emitir creará un vínculo entre todos los UTXO utilizados. Este vínculo puede ser problemático para tu intimidad personal, sobre todo si los UTXO proceden de fuentes distintas.

Tomemos el ejemplo de mi UTXO no-KYC de Bisq; quiero evitar combinarlo con un UTXO de, por ejemplo, una plataforma de intercambio regulada que conozca mi identidad. De hecho, si alguna vez utilizo estos 2 UTXO como entradas de la misma transacción, la plataforma regulada podrá vincular mi identidad con el UTXO que compré en Bisq, que no estaba previamente vinculado a mi identidad.

Por último, a la hora de elegir qué UTXOs utilizar como entradas para una transacción, lo más importante es evitar utilizar múltiples UTXOs. Como mucho, cuando pueda, seleccione una sola moneda lo suficientemente grande como para satisfacer su pago. De este modo, evitará por completo los riesgos asociados a CIOH. Sin embargo, si una sola UTXO no es suficiente para el pago y necesitas consumir varias, asegúrate de que proceden de fuentes similares para minimizar el riesgo de vínculos no deseados. Ten en cuenta también que el receptor podría asociar la información que posee sobre ti con el historial de monedas utilizadas en las entradas.

Comprender la selección automática de piezas

En las secciones anteriores, hemos hablado de la selección manual de UTXOs que se utilizarán para una transacción. Pero, ¿qué ocurre cuando el software del monedero realiza esta selección automáticamente? Existen varios métodos para determinar qué monedas consumir, y la selección de UTXOs constituye un verdadero campo de investigación en Bitcoin. El objetivo principal de este proceso automático suele ser minimizar los costes de transacción para el usuario.

Los métodos de selección UTXO como FIFO (First In First Out) y LIFO (Last In First Out) son de los más sencillos, pero también de los menos eficientes. Con FIFO, se utilizan primero las piezas más antiguas de la cartera. Este enfoque suele ser ineficaz tanto para minimizar los costes de transacción como para preservar la confidencialidad, excepto en los casos en los que se utilizan calendarios relativos que deben renovarse periódicamente. Por el contrario, el método LIFO da prioridad al uso de los UTXO más recientes. Ambos métodos, aunque sencillos, suelen resultar ineficaces.

Un método más avanzado es el Knapsack Solver. Este fue usado en el monedero Bitcoin Core hasta la versión 0.17. Consiste en seleccionar iterativa y aleatoriamente UTXOs del monedero, sumarlos en subconjuntos, y quedarse con la solución que reduzca al máximo el peso de la transacción, para reducir el coste al usuario.

El Branch-and-Bound (BNB), a menudo apodado "algoritmo Murch" por su inventor, ha sustituido al Knapsack Solver en Bitcoin Core a partir de la versión 0.17. Este método más avanzado pretende encontrar un conjunto de UTXOs que se corresponda exactamente con la cantidad necesaria para satisfacer las salidas de una transacción. El objetivo de BNB es minimizar la cantidad de intercambio así como las comisiones, reduciendo el llamado criterio de desperdicio, que tiene en cuenta tanto los costes inmediatos como los costes futuros esperados del intercambio. Este método deriva del concepto original de Branch-and-Bound, concebido en 1960 por Ailsa Land y Alison Harcourt, y ofrece una optimización más precisa de las tasas que el Knapsack Solver.

Todos estos métodos de selección automática de UTXO pueden ser eficaces para reducir los costes de transacción, pero a menudo son ineficaces para preservar la confidencialidad del usuario. En efecto, estos algoritmos pueden fusionar varios UTXOs en entradas, revelando así una propiedad común de estos UTXOs debido a CIOH. Obviamente, estos métodos no pueden tener en cuenta las etiquetas colocadas en los UTXO, que sin embargo son cruciales para elegir conscientemente qué partes revelar al destinatario de la transacción. En la actualidad, la única forma de optimizar la confidencialidad al seleccionar las monedas es hacerlo manualmente.

Tutorial sobre etiquetado UTXO

Si quieres saber cómo etiquetar tus UTXOs, hemos hecho un completo tutorial sobre los principales software de monederos Bitcoin que existen:

https://planb.network/tutorials/privacy/on-chain/utxo-labelling-d997f80f-8a96-45b5-8a4e-a3e1b7788c52

CSC e identificación de claves

KYC significa "Know Your Customer" (Conozca a su cliente). Es un procedimiento reglamentario aplicado por determinadas empresas que operan en el sector del Bitcoin. El objetivo de este procedimiento es verificar y registrar la identidad de sus clientes, con el objetivo declarado de luchar contra el blanqueo de capitales y la financiación del terrorismo.

En términos prácticos, el CSC implica la recopilación de diversos datos personales del cliente, que pueden variar según la jurisdicción, pero que generalmente incluyen el DNI, una fotografía y un justificante de domicilio. Esta información se verifica y almacena para su uso futuro.

Este procedimiento se ha convertido en obligatorio para todas las plataformas de intercambio reguladas en la mayoría de los países occidentales. Esto significa que cualquier persona que desee cambiar divisas estatales por bitcoin a través de estas plataformas debe cumplir los requisitos KYC.

Este procedimiento no está exento de riesgos para la privacidad y seguridad de los usuarios. En este capítulo, examinaremos estos riesgos en detalle y analizaremos los impactos específicos de los procesos KYC y de identificación sobre la privacidad de los usuarios de Bitcoin.

Facilitar el rastreo en la cadena

El primer riesgo asociado a KYC es que ofrece un punto de entrada privilegiado para el análisis de blockchain. Como vimos en la sección anterior, los analistas pueden agrupar y rastrear la actividad en la blockchain utilizando patrones de transacciones y heurística. Una vez que han conseguido agrupar la actividad onchain de un usuario, todo lo que necesitan hacer es encontrar un único punto de entrada entre todas sus transacciones y claves para comprometer por completo su confidencialidad.

Cuando realizas un KYC, proporcionas un punto de entrada de alta calidad para el análisis de blockchain, ya que asocias tus direcciones de recepción utilizadas al retirar tus bitcoins de una plataforma de intercambio con tu identidad completa y verificada. En teoría, esta información sólo la conoce la empresa a la que se la has proporcionado, pero, como veremos más adelante, el riesgo de fuga de datos es real. Es más, el mero hecho de que una empresa posea esta información puede ser problemático, aunque no la comparta.

Por lo tanto, si usted no toma otras medidas para limitar la agregación de sus actividades en la blockchain, cualquiera con conocimiento de este punto de entrada KYC puede potencialmente vincular toda su actividad en Bitcoin a su identidad. Desde el punto de vista de esa empresa, su uso de Bitcoin pierde toda confidencialidad.

Para ilustrar esto con una comparación, es como si su banquero del Banco X no sólo tuviera acceso a todas sus transacciones con el Banco X, sino que también pudiera observar sus transacciones con el Banco Y y todas sus transacciones en efectivo.

Recuerda la primera parte de este curso de formación: El modelo de confidencialidad de Bitcoin, tal y como fue concebido por Satoshi Nakamoto, se basa en la separación entre la identidad del usuario y sus pares de claves. Aunque esta capa de confidencialidad ya no es suficiente hoy en día, sigue siendo prudente limitar al máximo su degradación.

Exposición a la vigilancia estatal

El segundo gran problema de KYC es que revela al estado que has poseído bitcoin en algún momento. Cuando compras bitcoins a través de un actor regulado, es posible que el Estado conozca esta posesión. De momento, esto puede parecer trivial, pero es importante recordar que el futuro político y económico de tu país no está en tus manos.

En primer lugar, el Estado puede adoptar rápidamente una postura autoritaria. La historia está llena de ejemplos en los que las políticas han cambiado bruscamente. Hoy, en Europa, los Bitcoiners pueden escribir artículos sobre Bitcoin, participar en conferencias y gestionar sus carteras en autocustodia. Pero, ¿quién puede decir lo que nos deparará el mañana? Si Bitcoin se convierte de repente en el enemigo público número uno, estar asociado a él en los archivos gubernamentales podría resultar problemático.

Entonces, ante crisis económicas graves, el Estado podría plantearse confiscar los bitcoins en poder de los ciudadanos. Quizás el día de mañana, los bitcoiners sean percibidos como especuladores de la crisis, y se les apliquen impuestos excesivos por sus plusvalías ante la devaluación de la moneda fiduciaria.

Podrías pensar que esto no es un problema, ya que tus bitcoins están mezclados y, por tanto, no se pueden rastrear. Sin embargo, el rastreo no es el problema aquí. El verdadero problema es que el Estado sabe que has tenido bitcoins. Esta información por sí sola podría ser suficiente para incriminarte o pedirte cuentas. Podrías intentar alegar que has gastado tus bitcoins, pero eso tendría que reflejarse en tu declaración de la renta, y te pillarían. También podrías decir que perdiste las llaves en un accidente de barco, pero más allá de la broma de Twitter, ¿de verdad crees que eso bastaría para exculparte?

Así que es importante tener en cuenta el riesgo de que el Estado sepa que has poseído BTC, por muy remoto que ese riesgo pueda parecer hoy.

Otro problema que plantea el KYC en términos de supervisión estatal es la obligatoriedad de informar por parte de las plataformas reguladas. Aunque no estoy familiarizado con las normativas de otras jurisdicciones, en Francia, los Prestataires de Services sur Actifs Numériques (PSAN) están obligados a informar a las autoridades de supervisión financiera de cualquier movimiento de fondos que consideren sospechoso.

En Francia, en 2023, los PSAN comunicaron 1.449 actos sospechosos. Por el momento, la mayoría de estos actos están relacionados con la delincuencia. Sin embargo, las autoridades también están pidiendo a las plataformas reguladas que informen de cualquier transacción sospechosa de Bitcoin basándose únicamente en su estructura. Si realizas una transacción colaborativa, o incluso simplemente una transacción con un patrón ligeramente atípico, y esta transacción se produce no muy lejos de la retirada de tus Bitcoins de estas plataformas, podrías encontrarte denunciado ante las autoridades. Incluso en ausencia de delito y en el ejercicio legítimo de sus derechos, esta denuncia podría dar lugar a un aumento de los controles y la vigilancia, inconvenientes que habría evitado sin KYC.

Riesgo de fuga de datos personales

Otro problema del sistema KYC es que exige que todos tus datos personales se almacenen en los servidores de una empresa privada.

Los últimos acontecimientos nos han recordado que nadie es inmune a los fallos financieros o informáticos. En 2022, los clientes de Celsius sufrieron las consecuencias. Tras la quiebra de la empresa, los tribunales estadounidenses hicieron públicos los nombres de los acreedores y el importe de sus activos durante el procedimiento administrativo.

Hace poco más de dos años, fue un buque insignia de la ciberseguridad de las criptomonedas el que vio cómo robaban los datos personales de sus clientes. Aunque este incidente no estaba directamente relacionado con la compra de bitcoins, este riesgo también sigue existiendo para las plataformas de intercambio. Por tanto, existe un riesgo indudable asociado a los datos personales.

Es cierto que ya confiamos muchos de nuestros datos personales a empresas privadas. Sin embargo, en este caso el riesgo es doble, ya que estos datos no sólo le identifican, sino que también están vinculados a la actividad en Bitcoin. En efecto, cuando un pirata informático accede a los datos de los clientes de una plataforma de intercambio, puede suponer razonablemente que estos clientes poseen Bitcoins. Este riesgo se ve agravado por el hecho de que Bitcoin, como cualquier otro bien valioso, atrae la atención de los ladrones.

En caso de fuga de datos, en el mejor de los casos podría ser objeto de intentos de phishing selectivo. En el peor de los casos, podrías encontrarte en el centro de amenazas físicas a tu hogar.

Además de los riesgos específicos asociados a Bitcoin, también existen los peligros asociados a la transmisión de documentos de identidad. En efecto, en caso de filtración de datos, es posible convertirse en víctima de una usurpación de identidad. Así que lo que está en juego no se limita a proteger la confidencialidad de las transacciones, sino que también afecta a la seguridad personal de cada individuo.

Algunas ideas preconcebidas sobre KYC

Es importante deconstruir algunas de las ideas preconcebidas sobre KYC que nos encontramos con frecuencia en Twitter o en nuestros intercambios entre bitcoiners.

En primer lugar, es inexacto pensar que proteger la privacidad de los Bitcoins adquiridos a través de KYC no tiene sentido. Las herramientas y métodos de privacidad en Bitcoin son variados y sirven para diferentes propósitos. Utilizar transacciones coinjoin en Bitcoins adquiridos vía KYC, por ejemplo, no es una mala idea. Por supuesto, hay que tener cuidado con las plataformas de intercambio reguladas para evitar que su cuenta sea congelada o bloqueada, pero desde un punto de vista estrictamente técnico, estas prácticas no son incompatibles. Coinjoin tiene el efecto de romper el historial de una moneda, lo que le ayuda a frustrar ciertos riesgos de análisis de cadena asociados a KYC. Aunque no elimina todos los riesgos, representa una ventaja significativa.

La confidencialidad en Bitcoin no debe verse de forma binaria, como una distinción entre bitcoins "anónimos" y otros que no lo son. Poseer Bitcoins adquiridos mediante KYC no significa que todo esté perdido; al contrario, el uso de herramientas de confidencialidad puede resultar aún más beneficioso.

Por el contrario, la adquisición de bitcoin mediante un método que no sea el de CSC no garantiza una confidencialidad perfecta, ni le exime de la necesidad de adoptar otras medidas de protección. Si usted posee bitcoin sin método CSC pero reutiliza varias veces las direcciones de recepción, sus transacciones pueden ser rastreadas y agregadas. El más mínimo vínculo con el mundo exterior a Bitcoin podría comprometer la única capa de confidencialidad de la que dispone. Así que es importante considerar todas las herramientas y métodos de mejora de la privacidad en Bitcoin como complementarios. Cada técnica aborda un riesgo específico y puede añadir una capa extra de protección. Por tanto, poseer Bitcoin no KYC no significa que no necesite tomar otras precauciones.

¿Se puede anular el CSC?

A veces me preguntan si es posible "volver atrás" después de realizar un KYC, y como puedes imaginar por los párrafos anteriores, la respuesta tiene matices. La forma más sencilla de evitar los riesgos asociados al KYC es no utilizarlo a la hora de adquirir bitcoins. Profundizaremos en este tema en el próximo capítulo. Sin embargo, si ya se ha realizado el KYC y se han comprado bitcoins, ¿hay formas de mitigar los riesgos que conlleva?

Cuando se trata del riesgo de que rastreen tus transacciones, el uso de coinjoin es una solución. Veremos este método en detalle más adelante en el curso, pero debes saber que coinjoin te permite romper el historial de una moneda y evitar que sea rastreada pasado-presente y presente-pasado. Incluso en el caso de BTC obtenidos a través de una plataforma regulada, esta técnica puede impedir su rastreo.

Sin embargo, coinjoin no borra el segundo riesgo asociado al KYC: el hecho de que el Estado pueda estar informado de tu posesión de bitcoins. En efecto, aunque sus monedas ya no sean rastreables, el Estado, dependiendo de la jurisdicción, puede tener acceso a sus declaraciones de transferencia de criptoactivos. Como este riesgo no es técnico, sino administrativo, no hay soluciones específicas para Bitcoin para eliminarlo, aparte de no exponerse a KYC en primer lugar. El único enfoque legal para mitigar este riesgo es vender en plataformas reguladas sus Bitcoins adquiridos a través de plataformas reguladas, y luego recomprarlos a través de medios libres de KYC. Al vender y declarar la transferencia, las autoridades deberían ver que ya no los posee.

En cuanto al riesgo de filtración de sus datos personales y documentos de identidad, se trata de un peligro externo a Bitcoin, y no existe ninguna solución técnica para evitarlo. Una vez que tus datos han sido revelados, es difícil deshacer la operación. Puede intentar cerrar su cuenta en la plataforma, pero esto no garantiza la eliminación de sus datos KYC, especialmente cuando la verificación de identidad está externalizada. La verificación de la eliminación completa de su información es imposible. Por lo tanto, no existe ninguna solución para prevenir completamente este riesgo y garantizar que ya no exista.

Diferencia entre CSC e identificación de claves

A veces, algunos bitcoiners tienden a extender el término "KYC" a cualquier intercambio de BTC que implique una transferencia bancaria o un pago con tarjeta de crédito, ya que estos medios también pueden revelar el origen del pago, al igual que lo haría un KYC. Sin embargo, no hay que confundir KYC con identificación de claves. A título personal, debo admitir que mi percepción de este tema ha evolucionado con el tiempo.

KYC se refiere específicamente a un procedimiento reglamentario aplicado por ciertas empresas para verificar y registrar la identidad de sus clientes. Es algo binario: al adquirir tus bitcoins, o haces KYC, o no lo haces. Sin embargo, la identificación clave, que se refiere al vínculo entre una faceta de la identidad de un usuario y la actividad onchain, no es tan binaria, sino que representa más bien un continuo. De hecho, en el contexto de la adquisición o transferencia de bitcoins, dicha identificación siempre es posible en diversos grados.

Por ejemplo, si compra bitcoins en una plataforma regulada en Suiza, no se exige el CSC. Sin embargo, sus claves pueden ser identificadas, ya que la compra se realizó a través de su cuenta bancaria. Aquí es donde los dos primeros riesgos asociados al KYC -facilitar el rastreo onchain y la exposición a la vigilancia estatal- también pueden manifestarse en un intercambio sin KYC. Si la entidad suiza informa de transacciones sospechosas a las autoridades de su país, pueden simplemente comprobar la cuenta bancaria utilizada para la compra para descubrir su identidad. Así pues, comprar sin KYC en plataformas reguladas es bastante alto en la escala de riesgo para la identificación de claves.

Sin embargo, evitar las plataformas reguladas y optar por métodos de adquisición P2P no elimina totalmente el riesgo de identificación de claves, sino que simplemente lo reduce. Tomemos el ejemplo de una compra en Bisq u otra plataforma P2P. Para pagar a tu contraparte, probablemente utilizarás tu cuenta bancaria. Si las autoridades interrogan a la persona con la que ha negociado y le piden su nombre, volvemos a los riesgos 1 y 2. Aunque estos riesgos son mucho menores que al comprar en una plataforma sin KYC, e incluso menores que al comprar con KYC, siguen estando presentes en menor medida.

Por último, aunque adquieras tus bitcoins mediante un intercambio físico por dinero en efectivo, no eres totalmente anónimo. La persona con la que has intercambiado ha visto tu cara, que forma parte de tu identidad. Aunque mínima en este ejemplo, sigue existiendo la posibilidad de una identificación clave.

En conclusión, cuando se intercambian bitcoins por otros activos, ya sea una compra en moneda estatal o una venta contra un bien real, siempre existe algún tipo de identificación clave. Dependiendo del método de intercambio elegido, esta identificación puede variar en intensidad. Es importante no confundir esta identificación con el KYC, que es un proceso reglamentario bien definido. Sin embargo, existe un vínculo entre el KYC y el espectro de identificación, ya que el KYC se sitúa en el extremo superior del espectro, puesto que facilita sistemáticamente la identificación de las claves de usuario por parte de las autoridades.

Métodos de venta y adquisición

Después de leer el capítulo anterior, es posible que se pregunte cómo puede comprar o vender bitcoin sin tener que someterse a un procedimiento de verificación de identidad, con el fin de evitar los riesgos asociados a KYC. Hay varias formas de comerciar con bitcoin.

Intercambios de efectivo P2P

Como hemos visto, el mejor método en términos de confidencialidad sigue siendo el intercambio P2P (persona a persona) con liquidación en efectivo. Este método permite minimizar los rastros dejados y reduce considerablemente la posibilidad de identificación de claves, tanto si se compra como si se vende.

No obstante, existen riesgos para la seguridad personal. El principal peligro radica en que, durante el intercambio, la contraparte sabrá que usted tiene en su poder una gran suma de dinero, ya sea en efectivo o en bitcoins. Esta información puede atraer la atención de personas malintencionadas. De hecho, en general es aconsejable ser discreto sobre tus tenencias de bitcoins. Este consejo también podría aplicarse al dinero en efectivo. Sin embargo, cuando se intercambia en persona, es inevitable revelar que se poseen bitcoins, y esto puede atraer una atención no deseada.

Para limitar este riesgo, le aconsejo que favorezca las transacciones en efectivo con personas de confianza, como familiares o amigos íntimos. Alternativamente, también podría considerar la posibilidad de intercambiar en encuentros locales de Bitcoin, después de asistir unas cuantas veces. Esto le permitirá conocer mejor a los demás participantes y no estar solo cuando intercambie físicamente. Sin embargo, es importante reconocer que los intercambios de efectivo P2P conllevan intrínsecamente riesgos para su seguridad personal que no existen cuando compra a través de una plataforma regulada y su cuenta bancaria.

Además, dependiendo de dónde vivas, transportar y almacenar grandes sumas de dinero puede ser arriesgado, ya sea bitcoin o efectivo.

Intercambiar dinero en efectivo también puede plantear riesgos legales en caso de controles policiales o de otro tipo. Aunque en la mayoría de los países no hay restricciones sobre la cantidad de dinero que se puede llevar encima, una cantidad excesiva puede levantar sospechas. Así que tenga cuidado, sobre todo si tiene que viajar largas distancias, y evite hacer demasiadas transacciones grandes a la vez, para no tener que justificar la posesión de grandes sumas.

Por último, otra desventaja de las compras P2P es que el precio suele ser más alto que en las plataformas reguladas. Los vendedores suelen cobrar un recargo que oscila entre el 1% y a veces más del 10%. Hay varias razones que explican esta diferencia de precios. En primer lugar, se trata de una práctica habitual entre los vendedores P2P que se ha consolidado con el tiempo. En segundo lugar, los vendedores tienen comisiones asociadas a la transacción para enviar los fondos al comprador. También existe un mayor riesgo de robo en las ventas P2P en comparación con las transacciones en plataformas, lo que justifica una compensación por el riesgo asumido. Por último, el coste adicional puede estar relacionado con la demanda y la calidad del intercambio en términos de confidencialidad. Como comprador, la ganancia en confidencialidad tiene un precio que se refleja en el margen aplicado por el vendedor. Algunos bitcoiners también creen que el precio con margen del BTC comprado en P2P refleja su verdadero precio, y argumentan que los precios más bajos de las plataformas reguladas son el resultado de un compromiso en la confidencialidad de sus datos personales.

Intercambios P2P a través de una plataforma de matchmaking

Una alternativa menos arriesgada en términos de seguridad personal es realizar intercambios P2P exclusivamente en línea, a través de métodos de pago electrónico como PayPal, transferencias bancarias o Revolut.

Este enfoque evita muchos de los riesgos asociados a las transacciones en efectivo. Sin embargo, el riesgo de impago de la contraparte en un intercambio en línea es mayor. En efecto, en un intercambio físico, si entregas dinero al vendedor que no te envía los bitcoins a cambio, puedes pedirle cuentas inmediatamente, ya que está delante de ti. En cambio, en Internet suele ser imposible localizar a alguien que te ha robado.

Para mitigar este riesgo, es posible utilizar plataformas especializadas en intercambios P2P. Estas plataformas utilizan mecanismos de resolución de conflictos para proteger a los usuarios perjudicados. Normalmente, ofrecen un sistema de custodia, en el que los bitcoins se mantienen hasta que el vendedor confirma el pago en moneda fiduciaria.

En términos de seguridad personal, este método de compra es considerablemente más seguro que un intercambio físico de efectivo. Sin embargo, como se ha mencionado anteriormente, los intercambios P2P en línea dejan más rastros que un intercambio físico, lo que puede ir en detrimento de la privacidad en Bitcoin. Al utilizar un método de pago fiat online como un banco, usted expone más información que podría facilitar la identificación de claves.

Una vez más, yo no recomendaría hacer demasiadas operaciones grandes en una sola transacción en estas plataformas. Al dividir las transacciones, se distribuye el riesgo de robo de contrapartida.

Una vez más, otra desventaja de las compras P2P es que el precio suele ser más alto que el observado en las plataformas reguladas. Los vendedores suelen cobrar un recargo que oscila entre el 1% y a veces más del 10%. Hay varias razones que explican esta diferencia de precios. En primer lugar, se trata de una práctica habitual entre los vendedores P2P que se ha consolidado con el tiempo. En segundo lugar, los vendedores tienen comisiones asociadas a la transacción para enviar los fondos al comprador. También existe un mayor riesgo de robo en las ventas P2P en comparación con las transacciones en plataformas, lo que justifica una compensación por el riesgo asumido. Por último, el coste adicional puede estar relacionado con la demanda y la calidad del intercambio en términos de confidencialidad. Como comprador, la ganancia en confidencialidad tiene un precio que se refleja en el margen aplicado por el vendedor. Algunos bitcoiners también creen que el precio con margen del BTC comprado en P2P refleja su verdadero precio, y argumentan que los precios más bajos de las plataformas reguladas son el resultado de un compromiso en la confidencialidad de sus datos personales.

En cuanto a las soluciones, personalmente siempre he utilizado Bisq y estoy muy contento con ella. Su sistema está probado y parece fiable. Sin embargo, Bisq sólo está disponible para PC y su interfaz puede resultar demasiado compleja para los principiantes. Otro inconveniente es que Bisq sólo opera con transacciones onchain, lo que puede resultar costoso durante los periodos de altas tasas de transacción de Bitcoin.

-> Consulte nuestro tutorial sobre Bisq.

https://planb.network/tutorials/exchange/peer-to-peer/bisq-fe244bfa-dcc4-4522-8ec7-92223373ed04

Para una opción más sencilla, puedes probar Peach, una aplicación móvil que pone en contacto a compradores y vendedores con un sistema integrado de resolución de conflictos. El proceso es más intuitivo que el de Bisq.

-> Consulte nuestro tutorial sobre el melocotón.

https://planb.network/tutorials/exchange/peer-to-peer/peach-c6143241-d900-4047-9b73-1caba5e1f874

Otra opción en línea es HodlHodl, una plataforma bien establecida que ofrece buena liquidez, aunque no la he probado personalmente.

-> Consulte nuestro tutorial HodlHodl.

https://planb.network/tutorials/exchange/peer-to-peer/hodlhodl-d7344cd5-6b18-40f5-8e78-2574a93a3879

Para soluciones basadas en Lightning Network, prueba RoboSats y LNP2PBot. RoboSats es accesible a través de un sitio web y su uso es relativamente sencillo. LNP2PBot es más atípico, ya que funciona a través de un sistema de intercambio en la aplicación de mensajería Telegram.

-> Consulte nuestro tutorial sobre RoboSats.

-> Consulta nuestro tutorial LNP2PBot.

https://planb.network/tutorials/exchange/peer-to-peer/robosats-b60e4f7c-533a-4295-9f6d-5368152e8c06

https://planb.network/tutorials/exchange/peer-to-peer/lnp2pbot-v2-e6bcb210-610b-487d-970c-7cce85273e3c

Plataformas reguladas sin CSC

Dependiendo del país en el que vivas, puedes tener acceso a plataformas reguladas que no requieren procedimientos KYC para comprar o vender bitcoins. En Suiza, por ejemplo, puedes utilizar plataformas como Relai y MtPelerin.

-> Consulte nuestro tutorial sobre Relai.

https://planb.network/tutorials/exchange/centralized/relai-v2-30a9671d-e407-459d-9203-4c3eae15b30e

Como vimos en el capítulo anterior, este tipo de plataformas le ahorran los riesgos asociados a los procedimientos KYC, pero presentan un mayor nivel de riesgo para la identificación de claves. En términos de confidencialidad de Bitcoin, por tanto, estas plataformas ofrecen mejor protección que los métodos de compra con KYC, pero siguen siendo menos atractivas que los intercambios P2P.

Sin embargo, en términos de seguridad personal, el uso de estas plataformas es mucho menos arriesgado que los intercambios P2P. También suelen ser más sencillas de utilizar que las plataformas P2P.

Cajeros automáticos

Otra opción para comprar o vender bitcoins sin KYC son los cajeros automáticos de criptomonedas. Personalmente, nunca he tenido la oportunidad de probar esta solución, ya que no hay ninguno en mi país. Pero este método puede ser muy interesante, dependiendo de dónde vivas.

El problema de los cajeros automáticos es que están prohibidos en algunos países o muy regulados en otros. Si un cajero automático requiere un procedimiento de verificación de la identidad, entonces está expuesto a los mismos riesgos que los inherentes a las plataformas reguladas por el sistema KYC. Por otro lado, si el cajero automático permite transacciones sin verificación de identidad para pequeñas cantidades, entonces su uso puede ofrecer un nivel de confidencialidad comparable al de un intercambio de efectivo P2P, evitando al mismo tiempo la mayoría de los riesgos asociados a este tipo de intercambio.

La principal desventaja de los cajeros automáticos son sus elevadas comisiones de cambio, que oscilan entre unos pocos puntos porcentuales y a veces el 15% del importe canjeado.

Tarjetas regalo

Por último, también quería presentarles una solución que funciona bien para aquellos que quieren utilizar sus bitcoins a diario para hacer compras en lugar de venderlos contra monedas fiduciarias.

La mejor manera de gastar BTC es, por supuesto, utilizar Bitcoin o la Lightning Network directamente para comprar un bien o servicio. Sin embargo, en muchos países, el número de comerciantes que aceptan Bitcoin sigue siendo limitado. Una alternativa práctica es utilizar tarjetas regalo.

Varias plataformas que no exigen procedimientos KYC ofrecen la posibilidad de canjear bitcoins por tarjetas regalo que pueden utilizarse en los principales comercios. Entre ellas se encuentran CoinsBee, The Bitcoin Company y Bitrefill. Estas plataformas facilitan enormemente el uso diario de los bitcoins y permiten acceder a una amplia gama de productos y servicios sin tener que convertirlos en moneda fiduciaria.

https://planb.network/tutorials/exchange/centralized/bitrefill-8c588412-1bfc-465b-9bca-e647a647fbc1

Otros métodos de adquisición

Otras formas de adquirir bitcoins protegiendo tu privacidad incluyen, por supuesto, la minería. Para empezar a minar sats, no necesitas revelar tu identidad; basta con encontrar una prueba de trabajo válida y enviarla a la red. Si optas por la minería en pool, algunos pools exigen algún tipo de identificación, como un KYC, mientras que otros no.

Otro método consiste en trabajar a cambio de bitcoins. Este método de adquisición puede ser interesante, pero el grado de identificación exigido varía considerablemente según las circunstancias.

*Para escribir este capítulo, he utilizado el curso de formación BTC205 impartido por @pivi___ en la Red Plan ₿ (disponible sólo en francés por el momento)

Consolidación, gestión de UTXO y CIOH

Uno de los aspectos más complicados de gestionar una cartera de autocustodia es la consolidación. ¿Hay que consolidar? ¿Qué sentido tiene? ¿Qué tamaño de UTXO debe respetarse? ¿Cuáles son los compromisos en términos de confidencialidad? Eso es lo que vamos a analizar en esta sección.

¿Qué es la consolidación?

Bitcoin funciona como un mercado de subastas, en el que los mineros dan preferencia a las transacciones que ofrecen las comisiones más bajas. Sin embargo, cada bloque tiene un peso máximo, que limita el número de transacciones que pueden incluirse. Como se produce un bloque cada 10 minutos de media, el espacio disponible en cada bloque es un recurso escaso.

Los mineros, cuyas actividades generan importantes costes de electricidad, inmovilizado y mantenimiento, buscan naturalmente maximizar su rentabilidad. Por ello, tienden a favorecer las transacciones que generan las comisiones más elevadas en relación con su peso.

No todas las transacciones de Bitcoin tienen el mismo peso. Las que tengan más entradas y salidas pesarán más. Por ejemplo, imaginemos 2 transacciones:

La transacción A comprende 1 entrada y 1 salida. Asigna 1.994 sats de tasas y tiene un peso de 141 vB ;
La transacción B, una transacción más compleja con 2 entradas y 2 salidas, asigna 2.640 sats en tasas para un peso de 220 vB.

En este ejemplo, aunque la transacción B ofrece una comisión total más alta, los mineros preferirán la transacción A, ya que ofrece una mejor relación entre comisión y peso. He aquí el cálculo para cada transacción, expresado en sats por byte virtual (sat/vB):

TXA : 1994 / 141 = 14 sats/vB
TXB : 2640 / 220 = 12 sats / vB

Esto significa que por cada unidad de peso, la transacción A ofrece más costes que la transacción B, aunque la transacción B ofrezca más costes en términos absolutos.

Por lo tanto, siempre es más interesante para el usuario consumir la menor cantidad posible de insumos en sus transacciones. Sin embargo, necesita consumir cantidades suficientes para poder satisfacer el pago de salida. A la hora de gestionar su cartera, necesita disponer de UTXOs suficientemente grandes.

El principio de la consolidación es precisamente aprovechar los periodos en los que las comisiones son bajas en Bitcoin para fusionar sus UTXOs más pequeños en uno solo más grande. De esta forma, cuando las tasas suban en Bitcoin, podrá realizar transacciones con un mínimo de insumos y, por lo tanto, gastar menos en tasas en términos absolutos. Se trata, por tanto, de anticipar las transacciones obligatorias a realizar durante los periodos de tasas elevadas.

Además de ahorrar en costes de transacción, la consolidación de UTXOs ayuda a prevenir la formación de "polvo". El "polvo" se refiere a los UTXO cuyo valor en sats es tan bajo que resulta insuficiente para cubrir los costes de transacción necesarios para gastarlos. Esto hace que el uso de estos UTXOs sea económicamente irracional mientras los costes de transacción sigan siendo altos. Al agrupar proactivamente tus UTXOs, evitas que se conviertan en polvo, asegurando que todos tus fondos sigan siendo utilizables.

¿Cuál es el tamaño mínimo de sus UTXO?

A veces me preguntan cuál es el valor mínimo recomendado para un UTXO. Por desgracia, no hay una respuesta universal, ya que depende de sus preferencias y de las condiciones del mercado de comisiones. No obstante, aquí tienes una fórmula que puede ayudarte a determinar un umbral adecuado a tus necesidades:

 $\frac {P \times F}T = M$

Dónde:

p$ es el peso de la transacción;
$F$ representa la tasa de carga máxima en satoshis por vbyte (sats/vB) contra la que se cubre;
t$ es el porcentaje de la comisión de transacción que está dispuesto a pagar en relación con el valor total del UTXO ;
m$ es la cantidad mínima en satoshis para cada UTXO.

Supongamos que planea cubrir las comisiones de una transacción SegWit estándar con 1 entrada y 2 salidas, con un peso de 141 vB. Si estás cubriendo hasta 800 sats/vB, y estás dispuesto a gastar hasta un 12% del valor UTXO en comisiones como máximo, entonces el cálculo sería:

 $\frac{141 \times 800}{0.12} = 940\ 000$

En este ejemplo, por tanto, sería prudente mantener un valor mínimo de 940.000 sats para UTXOs en su cartera.

Consolidación y CIOH

Una de las heurísticas más utilizadas en el análisis de blockchain es la CIOH (Common Input Ownership Heuristic), que asume que todas las entradas de una transacción Bitcoin pertenecen a la misma entidad. El principio mismo de la consolidación es consumir varios UTXO como entradas y crear un único UTXO como salida. La consolidación permite así aplicar la ICOH.

En la práctica, esto significa que un observador externo puede deducir que todos los UTXO consolidados pertenecen probablemente a la misma persona, y que la salida única generada también le pertenece. Esta situación puede poner en peligro su confidencialidad al asociar diferentes historiales de transacciones. Por ejemplo, supongamos que consolido 3 UTXOs adquiridos a través de P2P con un UTXO obtenido a través de una plataforma que requiere KYC :

De este modo, cualquier entidad con acceso a los datos de la plataforma de intercambio, incluidas las agencias gubernamentales, podrá identificar que poseo otras cantidades de BTC. Antes, estos UTXO no estaban directamente vinculados a mi identidad; ahora sí. Es más, revela a todas las fuentes que estoy en posesión de cierta cantidad de bitcoins.

A la hora de gestionar los UTXO, las consideraciones económicas, que impulsan la consolidación para reducir costes, entran en conflicto con las buenas prácticas en materia de confidencialidad, que recomendarían no fusionar nunca los UTXO. La elección entre economía y confidencialidad depende, por tanto, de las prioridades de cada usuario.

Lo ideal es evitar la consolidación manteniendo unos UTXO sustanciales. Para ello, optimiza tus métodos de adquisición. Si compras tus bitcoins en DCA, intenta espaciar al máximo tus compras puntuales para consolidar el valor en menos UTXOs. Será más fácil gestionar una compra única de 1.000 euros cada 2 meses, que una compra de 120 euros cada semana. Esto minimiza el número de UTXOs generados y simplifica la gestión de su cartera, preservando al mismo tiempo su confidencialidad.

Si te ves obligado a consolidar tus bitcoins, da preferencia en primer lugar a consolidar UTXOs de la misma fuente. Por ejemplo, fusionar 10 UTXOs de una misma plataforma afectará menos a tu confidencialidad que mezclar 5 UTXOs de la plataforma A con 5 UTXOs de la plataforma B. Si la consolidación de varias fuentes es inevitable, intenta separarlas según sus características. Por ejemplo, agrupe los UTXO adquiridos mediante KYC en una operación y los obtenidos mediante P2P en otra.

En cualquier caso, no olvide que toda consolidación conlleva inevitablemente una pérdida de confidencialidad. Así que evalúe cuidadosamente la necesidad de esta operación y el impacto potencial sobre su privacidad, teniendo en cuenta el CIOH.

Otras buenas prácticas

Echemos un vistazo a otras buenas prácticas para optimizar su privacidad en Bitcoin.

El nudo completo

Poseer tus bitcoins en autocustodia es genial, ¡pero usar tu propio nodo completo es aún mejor! He aquí por qué tener tu propio nodo es crucial para un uso plenamente soberano de Bitcoin:

Resistencia a la censura**: Tus transacciones no pueden ser bloqueadas por nadie;
Independencia de terceros**: Ya no dependes de ningún servicio externo para verificar los datos de blockchain;
Participación activa**: Puede definir sus propias reglas de validación y participar directamente en el consenso;
Contribución a la red**: Al gestionar un nodo, ayudas a fortalecer y distribuir la red Bitcoin;
Formación técnica**: Gestionar un nodo completo es una gran forma de profundizar en tus conocimientos técnicos sobre Bitcoin.

Además de estas ventajas, el uso de un nodo completo también mejora su confidencialidad a la hora de emitir sus transacciones. Cuando emite una transacción, primero se crea y firma a través de su monedero. Para difundirla en la red Bitcoin, debe ser conocida por al menos un nodo. Al utilizar su propio nodo, usted tiene control directo sobre esta distribución, reforzando así su confidencialidad y limitando el riesgo de fuga de datos.

Si no dispone de su propio nodo Bitcoin, se verá obligado a utilizar uno de terceros, como el que ofrece el proveedor de software de su monedero. Además de emitir transacciones, su monedero necesita acceder a diversa información como transacciones pendientes, saldos asociados a sus direcciones y el número de confirmaciones de sus transacciones. Para acceder a todos estos datos, necesita consultar un nodo.

El principal riesgo cuando no está utilizando su propio nodo Bitcoin es que el operador del nodo de terceros podría observar sus actividades en la blockchain, o incluso compartir esta información con otras entidades. Para limitar este riesgo, una solución intermedia es utilizar un software de monedero que enmascare sus conexiones a través de Tor. Esto puede reducir la exposición de tus datos. Sin embargo, la solución óptima es tener su propio nodo Bitcoin y utilizarlo para difundir sus transacciones. Por supuesto, también tendrá que tener cuidado de no filtrar ninguna información a través de su nodo, pero ese es otro tema que veremos en secciones posteriores.

Más allá de la ventaja obvia para su privacidad, tener su propio nodo completo también le asegura la veracidad de los datos en la blockchain, le protege contra la censura y le permite participar activamente en la gobernanza de Bitcoin. Al utilizar tu propio nodo, contribuyes con tu peso económico a la cadena de tu elección, lo cual es importante durante los conflictos dentro de la comunidad, como por ejemplo durante la Guerra del Tamaño de Bloque de 2015 a 2017. En caso de bifurcación, utilizar un nodo de terceros podría llevarle a apoyar una cadena que no desea favorecer, ya que el operador del nodo elige por usted.

Como puede ver, en aras de la confidencialidad y la soberanía individual, ¡es esencial que ejecute y utilice su propio nodo completo!

Heurística de análisis engañosa

En términos más generales, es importante comprender los heurísticos de los que hemos hablado en la sección anterior, para evitarlos o engañarlos mejor. Adoptar una serie de buenas prácticas puede ser beneficioso, aunque no sean esenciales. Ofrecen una capa extra de protección que puede ser importante para mantener la confidencialidad cuando se usa Bitcoin.

El primer consejo que podría dar es mezclarse con la multitud más densa. En Bitcoin, esto significa utilizar las plantillas de scripts más ampliamente adoptadas. Por ejemplo, los scripts P2WSH, a menudo utilizados para configuraciones SegWit V0 multisig, son muy poco comunes. No permiten esconderse en un gran conjunto de anonimato. Lo mismo ocurre con modelos más antiguos como P2PKH o P2SH. Aunque están muy presentes en el conjunto UTXO, cada vez se utilizan menos para nuevas transacciones.

En general, es más prudente optar por el estándar de scripting más reciente, siempre que haya sido suficientemente adoptado. Así, si en 2022 hubiera desaconsejado el uso de P2TR (Taproot) debido a su escasa adopción, en 2024 recomendaría optar en su lugar por este tipo de script o, en su defecto, por el script SegWit V0, ya que el número de transacciones que utilizan P2TR empieza a representar una proporción muy significativa.

Fuente : txstats.com

Otro consejo para preservar su confidencialidad es intentar evitar la heurística interna de las transacciones. Por ejemplo, al hacer un pago, puedes intentar evitar crear una salida con una cantidad redonda, ya que esto podría señalar que la otra salida representa divisas. Si necesitas enviar 100 k sats a un amigo, considera transferir una cantidad ligeramente superior para escapar a esta heurística. Del mismo modo, intenta no crear salidas de divisas que sean desproporcionadamente altas en relación con el pago realizado, ya que esto también podría revelar cuál de las salidas representa divisas.

Por último, si realiza transacciones de Bitcoin de forma regular, asegúrese de no difundirlas siempre a las mismas horas. Repartiendo la emisión de sus transacciones a lo largo del día y de la semana, evitará dar a los observadores externos la oportunidad de detectar un patrón temporal basado en la zona horaria que podría reforzar su análisis.

Además de todas estas buenas prácticas a adoptar en el día a día, existen métodos aún más eficaces para romper por completo la trazabilidad de tus bitcoins. Entre ellos se encuentran, por supuesto, las transacciones coinjoin, que veremos en profundidad en la siguiente sección.

Comprender las transacciones coinjoin

¿Qué es una transacción coinjoin?

Una vez estudiados los fundamentos de la protección de la privacidad, vamos a ver ahora técnicas más sofisticadas destinadas a defender activamente tu confidencialidad, en particular desvinculando tu historial de bitcoins. En la próxima parte, veremos toda una serie de pequeñas técnicas, pero antes, me gustaría hablarte de coinjoin.

Coinjoin suele considerarse el método más eficaz para proteger la privacidad de los usuarios de Bitcoin. Pero, ¿qué es exactamente una transacción coinjoin? Averigüémoslo.

Principios básicos de coinjoin

Coinjoin es una técnica para romper el seguimiento de bitcoins en la blockchain. Se basa en una transacción colaborativa con una estructura específica del mismo nombre: la transacción coinjoin.

Como vimos en las primeras partes de este curso, las transacciones de Bitcoin son conocidas por todos los usuarios a través de su nodo. Por lo tanto, es fácil comprobar la cadena de firmas electrónicas de cada moneda y observar su historial. Esto significa que todos los usuarios pueden intentar analizar las transacciones de otros usuarios. Como resultado, el anonimato a nivel de transacción es imposible. Sin embargo, el anonimato se mantiene a nivel de identificación individual. A diferencia del sistema bancario convencional, en el que cada cuenta está vinculada a una identidad personal, en Bitcoin los fondos están asociados a pares de claves criptográficas (o scripts), ofreciendo a los usuarios una forma de pseudonimato tras los identificadores criptográficos.

La confidencialidad de Bitcoin se ve socavada cuando observadores externos son capaces de asociar UTXOs específicos con usuarios identificados. Una vez establecida esta asociación, es posible rastrear sus transacciones y analizar su historial Bitcoin. Coinjoin es precisamente una técnica desarrollada para romper la trazabilidad de los UTXOs, con el fin de ofrecer a los usuarios de Bitcoin una cierta capa de confidencialidad a nivel de transacción.

Los Coinjoins refuerzan la confidencialidad de los usuarios de Bitcoin haciendo más complejo el análisis de la cadena para los observadores externos. Su estructura permite fusionar múltiples monedas de distintos usuarios en una única transacción, difuminando las líneas y dificultando la determinación de los vínculos entre las direcciones de entrada y salida.

Es importante entender que el objetivo de una transacción coinjoin es romper el historial de una moneda. Esta técnica no confiere un anonimato permanente ni bloquea definitivamente el rastreo de bitcoins, contrariamente a lo que podría pensarse. Coinjoin sólo pretende romper el historial en el momento en que se realiza la transacción coinjoin. Sin embargo, antes y después de esta operación, la moneda sigue estando sujeta a los mismos riesgos en términos de confidencialidad.

¿Cómo funcionan las uniones conjuntas?

El principio de coinjoin se basa en un enfoque colaborativo: varios usuarios que desean mezclar sus bitcoins depositan cantidades idénticas como entradas de la misma transacción. A continuación, estas cantidades se redistribuyen en salidas de igual valor para cada usuario.

Al final de la transacción, resulta imposible asociar una salida específica a un usuario conocido como entrada. No existe un vínculo directo entre las entradas y las salidas, lo que rompe la asociación entre los usuarios y sus UTXO, así como el historial de cada pieza.

Tomemos el ejemplo de Alice. Quiere enviar unos 100.000 sats a su hermana Eve por su cumpleaños. Sin embargo, Alice no quiere que Eve pueda rastrear su historial de transacciones, ya que no quiere revelar cuántos bitcoins tiene ni cómo los consiguió. Para ello, Alice decide romper su historial UTXO con una transacción coinjoin. Se organiza con Bob, Charles, David y Frank para llevar a cabo una transacción colaborativa:

Alice, Bob, Charles, David y Frank comprometen cada uno un UTXO de 105.000 sats (con 5.000 sats para tasas de minería) como entradas a la transacción:

A cambio de consumir estas entradas, cada una genera una dirección en blanco para crear cinco salidas idénticas de 100.000 sats cada una. Cada una recupera una salida:

Alice se encuentra con un UTXO de 100.000 sats cuyo historial está mezclado. Utiliza este UTXO en una nueva transacción para enviar la cantidad a Eve por su cumpleaños:

Si Eve intenta analizar esta transacción para extraer información, se encontrará con la transacción coinjoin en la que participan Alice, Bob, Charles, David y Frank. Al no poder distinguir qué entrada pertenece a quién debido a la uniformidad de las cantidades, Eve no puede rastrear el historial de UTXO de Alice, ni determinar cuántos bitcoins posee su hermana ni cómo los adquirió:

En este caso, Alice ha utilizado la técnica coinjoin para aumentar la confidencialidad con respecto al análisis retrospectivo. En efecto, Alice se está protegiendo contra un posible análisis por parte de Eve, que comenzaría a partir de una transacción específica y trabajaría hacia atrás a través de la historia del UTXO. Esta protección contra el análisis desde el presente hacia el pasado se conoce como anonset retrospectivo. Veremos este concepto con más detalle en los últimos capítulos de esta sección.

Sin embargo, coinjoin también ofrece la posibilidad de reforzar la confidencialidad ante un análisis del pasado al presente, lo que se conoce como anonset prospectivo. Volvamos a nuestro ejemplo en el que Alicia envió a Eva 98.000 sats por su cumpleaños, pero con los papeles invertidos. Ahora imaginemos que es Eva la que está preocupada por su privacidad. De hecho, Alice podría tener la tentación de rastrear la moneda que envió a Eve para extraer información de ella. Eve bien podría consolidar este UTXO que acaba de recibir con todos sus otros UTXOs, lo que podría revelar a Alice la cantidad de bitcoins que tiene en su cartera. Para evitar esto, Eve también puede romper el historial de la moneda que acaba de recibir:

Eve, Grace, Mallory, Oscar y Victor ponen cada uno un UTXO de 98.000 sats como entrada para una transacción Bitcoin:

A cambio de consumir estas entradas, cada usuario proporciona una dirección en blanco que se utilizará para crear 5 salidas de 97.500 saturaciones perfectamente iguales. Cada usuario obtiene una salida:

Eve posee ahora un UTXO de 97.500 sats cuyo historial se ha roto. Puede utilizarlo sin miedo para realizar futuras transacciones. De hecho, si Alice intenta rastrear los bitcoins que ha enviado a Eve, se encontrará con una transacción coinjoin. No podrá determinar qué UTXO saliente pertenece a Eve. El análisis se hace imposible:

En el primer ejemplo, vimos cómo la coinjoin puede proteger la privacidad de una sala en relación con su pasado, y en el segundo ejemplo, cómo también puede asegurar la historia de una sala en relación con su futuro. Por eso mencioné que la coinjoin debe verse como un acontecimiento único que segmenta una parte de la historia en ambas direcciones:

Mezclador, coinjoin, mezclador... ¿Cuál es la diferencia?

Los coinjoins se describen a veces como "mezcladores", un término que algunos bitcoiners rechazan, temiendo que pueda confundirse con los mezcladores de custodia. Sin embargo, creo que esta aprensión es infundada, ya que, en un contexto matemático, el coinjoin encarna precisamente el concepto de mezcla.

En el campo general de las matemáticas, la mezcla se refiere a la propiedad de un sistema dinámico en el que, tras un cierto periodo de tiempo, todas las porciones del espacio inicial pueden teóricamente mezclarse con cualquier otra porción. La mezcla implica que la posición de una partícula o el estado de un sistema evolucionan de tal manera que su distribución futura es independiente de su distribución inicial, alcanzando así un estado en el que las características del estado inicial se distribuyen uniformemente por todo el espacio del sistema. Esto es exactamente lo que ocurre en una coinjoin con bitcoins. Así que, en mi opinión, coinjoin es realmente un método de mezcla de monedas.

Por otro lado, es importante distinguir coinjoin de los shufflers. Un shuffler es un servicio al que los usuarios envían sus bitcoins para que sean barajados. Estos servicios fueron populares durante la década de 2010, pero su uso ha disminuido debido a dos grandes inconvenientes en comparación con coinjoin:

Exigen a los usuarios que renuncien a la custodia de sus fondos durante el proceso de mezcla, lo que les expone al riesgo de robo;
No hay garantía de que el mezclador no registre los detalles de la transacción, o incluso venda esta información a empresas de análisis de cadenas.

Por ello, los usuarios actuales prefieren coinjoin, ya que les permite mantener un control total sobre sus fondos durante todo el proceso. Los participantes en Coinjoin no corren ningún riesgo de que sus bitcoins sean robados por las otras partes implicadas. Veamos cómo es posible todo esto en el próximo capítulo.

Zerolink y chaumian coinjoins

La privacidad que proporciona un coinjoin se gana con el tamaño del grupo en el que se esconde nuestra pieza. Esto implica encontrar el mayor número posible de participantes. Es perfectamente posible crear un coinjoin manualmente, con usuarios que hayamos encontrado nosotros mismos, pero es un proceso complejo, y no te hará ganar grandes anonsets.

Esta es la razón por la que se han desarrollado coordinadores de coinjoin en Bitcoin. Su función es poner en contacto a los distintos usuarios y transmitir la información necesaria para completar la transacción colaborativa.

Pero, ¿cómo podemos asegurarnos de que el coordinador nunca tenga en sus manos los bitcoins de los usuarios, y a pesar de que es la persona que construye la transacción coinjoin, cómo podemos asegurarnos de que no pueda vincular las entradas y salidas de los usuarios, lo que podría constituir una fuga de confidencialidad?

Firmas ciegas de Chaum

Las implementaciones modernas de coinjoin utilizan las firmas ciegas de David Chaum para evitar fugas de información. Echemos un vistazo rápido a cómo funcionan estas firmas ciegas.

Las firmas ciegas de Chaum son una forma de firma digital en la que el emisor de una firma desconoce el contenido del mensaje que está firmando. Pero la firma puede verificarse con el mensaje original. Esta técnica fue desarrollada por el criptógrafo David Chaum en 1983.

Tomemos el ejemplo de una empresa que desea autentificar un documento confidencial, como un contrato, sin revelar su contenido. La empresa aplica un proceso de enmascaramiento que transforma criptográficamente el documento original de forma reversible. Este documento modificado se envía a una autoridad de certificación, que estampa una firma ciega sin conocer el contenido subyacente. Tras recibir el documento firmado, la empresa desenmascara la firma. El resultado es un documento original autenticado por la firma de la autoridad, sin que ésta haya visto nunca el contenido original.

Así, las firmas ciegas de Chaum pueden certificar la autenticidad de un documento sin conocer su contenido, garantizando tanto la confidencialidad de los datos del usuario como la integridad del documento firmado.

Chaumian coinjoins

Los llamados coinjoins "chaumianos" combinan el uso de Tor y las firmas ciegas de David Chaum para garantizar que el coordinador no pueda saber qué salida pertenece a qué usuario.

El proceso de construcción de una transacción coinjoin consta de 3 etapas principales: registro de entrada, registro de salida y firma de la transacción. Veamos este proceso a través del ejemplo de Alice, una de las participantes en coinjoin. Todos los demás participantes siguen los mismos pasos que Alice, cada uno por su cuenta.

**Paso 1: Registro de entrada

Alice transmite al coordinador la UTXO que desea utilizar como entrada para la transacción, así como la dirección de recepción enmascarada que desea utilizar como salida para recibir sus bitcoins. Por lo tanto, el coordinador no tiene forma de conocer la dirección de Alice. Sólo ve su versión enmascarada:

El coordinador comprueba la validez de las entradas y firma la dirección enmascarada de Alice con su clave privada. Devuelve la firma ciega a Alice:

Paso 2: Registro de salidas

Alice puede desenmascarar su dirección, ahora firmada por la clave privada del coordinador. Establecerá una nueva conexión bajo una identidad Tor diferente. El coordinador no puede identificar que es Alice quien se conecta bajo esta nueva identidad:

Alice envía la dirección desenmascarada y la firma al coordinador (que sigue sin saber que es Alice):

Paso 3: Firma de la transacción

Del mismo modo, el coordinador recupera los resultados no enmascarados de todos los participantes. Gracias a las firmas asociadas, puede comprobar que cada salida enviada de forma anónima ha sido firmada previamente por su clave privada, garantizando así su legitimidad. A continuación, está listo para construir la transacción coinjoin y la envía a los participantes para que la firmen:

Alice, al igual que los demás participantes, comprueba que su entrada y su salida están correctamente incluidas en la transacción construida por el coordinador. Si todo es satisfactorio, envía al coordinador la firma que desbloquea su guión de entrada:

Después de recoger las firmas de todos los participantes en coinjoin, el coordinador puede difundir la transacción en la red Bitcoin, para que pueda añadirse a un bloque.

En este sistema, el coordinador no puede vincular una entrada a una salida concreta. Además, no puede apropiarse de los fondos de los participantes, ya que nunca tiene acceso a las claves privadas necesarias para desbloquear sus UTXO. Durante todo el proceso, hasta el final del paso 3, tampoco tiene acceso a las firmas. Cuando Alice y el resto de participantes firman la transacción global, tras comprobar que todo es correcto, el coordinador ya no puede modificar la transacción, incluidas las salidas, sin invalidarla. Esto impide que el coordinador robe bitcoins.

Por último, al registrar su resultado en la transacción, el usuario de coinjoin desea tener garantías similares a las de un ciudadano que vota en unas elecciones. Existe una dualidad entre los aspectos públicos y privados de estas acciones. Por un lado, está lo que se quiere mantener en privado: para el votante, no quiere que su papeleta esté vinculada a su identidad; para el usuario de coinjoin, no quiere que su salida esté asociada a su entrada. De hecho, si el coordinador, o cualquier otra parte, consigue establecer un vínculo entre una entrada y una salida, la coinjoin pierde todo interés. Como ya se ha explicado, el coinjoin debe funcionar como una interrupción en la historia de una moneda. Esta parada se produce precisamente por la imposibilidad de asociar una entrada específica con una salida específica en la transacción coinjoin (anonset prospectivo) y viceversa (anonset retrospectivo).

Por otro lado, está el aspecto público: el votante quiere estar seguro de que su papeleta está incluida en la urna; del mismo modo, el usuario de coinjoin quiere estar seguro de que su resultado está incluido en la transacción coinjoin. De hecho, los participantes en coinjoin deben poder verificar absolutamente la presencia de su producto antes de firmar la transacción, pues de lo contrario el coordinador podría robar los fondos.

Son precisamente estos 2 aspectos público y privado, habilitados por el uso de las firmas ciegas de David Chaum, los que garantizan a los participantes en los coinjoins chaumianos que sus bitcoins no serán robados, y que sus fondos no podrán ser rastreados.

¿Quién inventó el concepto de coinjoin?

Es difícil decir con seguridad quién introdujo por primera vez la idea de coinjoin en Bitcoin, y a quién se le ocurrió la idea de utilizar las firmas ciegas de David Chaum en este contexto. A menudo se piensa que fue Gregory Maxwell quien lo mencionó por primera vez en un mensaje en BitcoinTalk en 2013 :

*"Utilizando las firmas ciegas de Chaum: Los usuarios se conectan y proporcionan entradas (e intercambian direcciones), así como una versión criptográficamente enmascarada de la dirección a la que desean enviar sus partes privadas; el servidor firma los tokens y los envía de vuelta. Los usuarios vuelven a conectarse de forma anónima, desenmascaran sus direcciones de salida y las envían de nuevo al servidor. El servidor puede ver que todas las salidas han sido firmadas por él y que, en consecuencia, todas las salidas proceden de participantes válidos. Más tarde, las personas vuelven a conectarse y firman Maxwell, G. (2013, 22 de agosto). CoinJoin: Privacidad Bitcoin para el mundo real. Foro BitcoinTalk. https://bitcointalk.org/index.php?topic=279249.0

Sin embargo, hay otras menciones anteriores, tanto para firmas Chaum como parte de la mezcla, pero también para coinjoins. En junio de 2011, Duncan Townsend presentó en BitcoinTalk un mezclador que utiliza firmas Chaum de forma bastante similar a los modernos coinjoins chaumianos.

En el mismo hilo, podemos encontrar un mensaje de hashcoin en respuesta a Duncan Townsend para mejorar su mezclador. El proceso descrito en este mensaje es exactamente de lo que tratan los coinjoins. También se puede encontrar mención a un sistema similar en un mensaje de Alex Mizrahi en 2012, cuando asesoraba a los creadores de Tenebrix, una de las primeras altcoins que sirvió de base para crear posteriormente Litecoin. Incluso se dice que el propio término "coinjoin" no fue acuñado por Greg Maxwell, sino que procede de una idea de Peter Todd.

Zerolink

Zerolink es un protocolo de mezcla integral que incorpora coinjoins chaumianos y varias estrategias para proteger el anonimato de los usuarios frente a varias formas de análisis de cadenas, en particular minimizando los errores asociados a la gestión de carteras. Este protocolo fue presentado por nopara73 y TDevD en 2017.

Como su nombre indica, el principio en que se basa Zerolink es crear transacciones coinjoin que garanticen que los vínculos entre entradas y salidas no puedan rastrearse. Esto se consigue garantizando que todas las salidas tengan importes perfectamente idénticos.

Una importante medida preventiva adoptada por Zerolink consiste en mantener los UTXO no mezclados completamente separados de los UTXO mezclados, utilizando conjuntos de claves criptográficas separados, o incluso carteras separadas. De este modo se diferencia el monedero "pre-mix", destinado a las piezas antes de ser mezcladas, del monedero "post-mix", reservado a las piezas que han sido mezcladas.

Esta separación rigurosa de los UTXO sirve sobre todo para evitar asociaciones accidentales entre un UTXO mixto y un UTXO no mixto. En efecto, si se producen tales vínculos, la eficacia del coinjoin sobre el UTXO mixto se anula sin que el usuario sea consciente de ello, comprometiendo así la confidencialidad de un UTXO cuyo historial creía haber roto. Estos enlaces pueden producirse mediante la reutilización de direcciones al asegurar un UTXO mezclado con otro no mezclado, o mediante la aplicación de la heurística CIOH (Common-Input-Ownership Heuristic), si el usuario consume UTXOs mezclados y no mezclados como entradas de la misma transacción. Al separar las carteras premezclada y postmezclada, evitamos tales asociaciones accidentales y protegemos al usuario contra errores involuntarios.

Esta separación también ofrece la posibilidad de aplicar reglas distintas entre las carteras premezcla y postmezcla a nivel del software de la cartera. Por ejemplo, en la cartera post-mix, el software puede prohibir la fusión de UTXOs en entradas para evitar la aplicación de CIOH, que comprometería el anonset del usuario. También es posible estandarizar el uso de scripts y opciones de transacción (como los informes RBF, por ejemplo) para evitar la identificación por huellas dactilares de la cartera.

Actualmente, Whirlpool es la única implementación coinjoin que aplica rigurosamente el protocolo Zerolink. En el próximo capítulo, veremos las distintas implementaciones de coinjoin que existen, así como las ventajas y desventajas de cada una.

Implementaciones de Coinjoin

*En 2024, estamos siendo testigos de grandes cambios en las herramientas disponibles para los usuarios que deseen hacer coinjoins en Bitcoin. Nos encontramos en un punto de inflexión, y el mercado de coinjoins está sufriendo una importante reestructuración. Este capítulo se actualizará con el tiempo

Por el momento existen principalmente 3 implementaciones diferentes de coinjoin en Bitcoin:

Whirlpool;
Wabisabi;
JoinMarket.

Cada una de estas implementaciones pretende romper el historial de UTXOs mediante transacciones coinjoin. Sin embargo, sus mecanismos varían considerablemente. Por lo tanto, es esencial entender cómo funciona cada uno, para que puedas elegir la opción que mejor se adapte a tus necesidades.

JoinMarket

JoinMarket, fundada en 2015 por Adam Gibson y Chris Belcher, se distingue claramente de otras implementaciones de coinjoins gracias a su modelo único para conectar usuarios. El sistema se basa en un mercado de intercambio P2P en el que algunos usuarios, los "creadores", ponen a disposición sus bitcoins para mezclarlos, mientras que otros, los "tomadores", utilizan este efectivo para hacer coinjoins a cambio de una comisión.

En este modelo, los "creadores" ponen sus bitcoins a disposición de los "tomadores" y reciben una comisión por su servicio. Los tomadores, a su vez, pagan por utilizar los bitcoins de los creadores para realizar sus propias transacciones coinjoin. Las comisiones por servicio varían en función de la función ocupada: los "makers" acumulan comisiones por ofrecer liquidez, mientras que los "takers" pagan las comisiones. El mercado funciona libremente, sin condiciones de uso.

Uno de los principales inconvenientes de JoinMarket es su complejidad de uso, que requiere un cierto grado de comodidad con los terminales para manejarlo con eficacia. Aunque esta complejidad no es un obstáculo para el usuario experimentado, puede limitar el acceso al público en general. Sin embargo, la reciente introducción de una interfaz web denominada JAM ha facilitado un poco su uso.

Fuente : JAM

Sin embargo, la barrera técnica sigue siendo un obstáculo importante. En el ecosistema de los coinjoins, donde la confidencialidad se ve reforzada por el número de participantes, cualquier limitación que reduzca la accesibilidad afecta directamente a la liquidez disponible, que es un factor crucial en la eficiencia de la mezcla. Bitcoin, siendo ya un nicho en las transacciones financieras, ve su uso de coinjoins como un sub-nicho, y JoinMarket representa una fracción aún más especializada del mismo, lo que por tanto restringe su potencial para aumentar el anonimato de sus usuarios.

A pesar de su innovador modelo de enlace P2P para coinjoiners, JoinMarket presenta algunas desventajas significativas, sobre todo en términos de estructura transaccional. A diferencia de otras implementaciones como Whirlpool, JoinMarket no garantiza una igualdad perfecta entre las salidas, y es posible trazar vínculos deterministas entre entradas y salidas. Además, no dispone de herramientas para impedir que las piezas ya mezcladas vuelvan a mezclarse, lo que podría comprometer la confidencialidad buscada por los usuarios.

Por último, aunque el concepto de JoinMarket es interesante, sobre todo para los interesados en un mercado de liquidez dinámico, sus deficiencias estructurales y su complejidad técnica lo hacen, en mi opinión, menos interesante tanto para los principiantes como para los expertos que buscan una aplicación de coinjoin.

Wabisabi

Wabisabi es otra implementación de coinjoin, con un enfoque que centraliza la coordinación de las transacciones. Este modelo fue concebido por Ádám Ficsór (nopara73), Yuval Kogman, Lucas Ontivero e István András Seres en 2021, y se integró en el software Wasabi 2.0 al año siguiente. Wabisabi es precisamente una evolución del modelo de coinjoin del software Wasabi lanzado en 2018.

Hacia finales de la década de 2010, Wasabi adoptó una estructura de transacciones coinjoin radicalmente diferente a la de Whirlpool. Wasabi utilizó transacciones coinjoin muy grandes que implicaban a docenas de participantes para aumentar los anonsets de sus participantes. En cambio, Whirlpool optó por múltiples transacciones pequeñas, lo que permitió que los anonsets crecieran exponencialmente con cada ciclo.

Los métodos de gestión de las divisas también distinguían las dos implementaciones. Con Whirlpool, las divisas se excluían y aislaban de los UTXO antes de los ciclos coinjoin gracias a TX0, un concepto que explicaré más adelante en el próximo capítulo. Con Wasabi, en cambio, las divisas formaban una de las salidas de la transacción coinjoin, manteniendo vínculos deterministas entre ciertas entradas y salidas.

Con Wabisabi, la versión 2.0 de Wasabi ha adaptado su enfoque de los coinjoins al de Whirlpool. Aunque las transacciones de coinjoin siguen siendo muy grandes, ahora es posible encadenar varios ciclos sucesivos, siguiendo el modelo de Whirlpool. También se ha prestado especial atención a la gestión del tipo de cambio: a diferencia de Wasabi 1.0, donde el tipo de cambio estaba directamente vinculado a las entradas del usuario, Wabisabi intenta subdividir el tipo de cambio en varias sumas pequeñas, divididas en denominaciones iguales para todos los participantes.

Ilustrémoslo con un ejemplo simplificado en el que sólo intervienen 2 usuarios: Alice desea mezclar 115.000 sats y Bob, 210.000 sats. Ignorando las comisiones, con Wasabi 1.0, una transacción coinjoin habría generado 3 salidas de 100.000 sats, más 1 intercambio de 15.000 sats para Alice y 1 intercambio de 10.000 sats para Bob. Las salidas de intercambio seguirían vinculadas a las entradas:

Con Wabisabi, la misma transacción habría producido 3 salidas de 100.000 sats y 5 salidas de 5.000 sats, dispersando así el intercambio para que no pudiera vincularse directamente a un insumo específico:

Personalmente, considero que la gestión de divisas de Wabisabi presenta varios riesgos que podrían comprometer su eficacia en términos de confidencialidad:

Cuando un usuario contribuye con un UTXO que es significativamente mayor que los de otros participantes, inevitablemente termina con una cantidad de intercambio que estará vinculada a su aportación. Esto va en contra del objetivo original del protocolo, que es eliminar todos los intercambios identificables;
La multiplicación de las denominaciones con el fin de fragmentar el intercambio puede, paradójicamente, ir en detrimento de la eficacia de la mezcla. Este proceso puede conducir a una reducción de los anonimatos de determinados productos, ya que se vuelven más fácilmente identificables;
Este método también genera UTXOs de poco valor que plantean un problema de gestión para el usuario. Estos pequeños UTXOs, si se vuelven demasiado costosos de gastar en relación con su valor, pueden convertirse en "polvo". Este fenómeno lleva al usuario a fusionar varios UTXO en entradas para futuras transacciones, o a consolidarlos. En ambos casos, debido a la CIOH, esto puede reducir los anonsets obtenidos, o anular completamente los beneficios de confidencialidad adquiridos por la coinjoin inicial.

A diferencia de Whirlpool, que aplica el protocolo ZeroLink garantizando una separación rigurosa entre los UTXO previos y posteriores a la mezcla, Wabisabi no mantiene esta estricta segregación. También ha habido problemas de reutilización de direcciones por parte de algunos clientes de Wasabi, lo que obviamente es muy perjudicial para el usuario.

En la versión 2.0 de Wasabi, se ha implementado una nueva política de comisiones por coinjoin. A partir de ahora, las tasas de coordinación se fijan en el 0,3% para UTXOs superiores a 0,01 bitcoin, mientras que para UTXOs más pequeños, estas tasas se ofrecen en su totalidad. Además, las remezclas para estos UTXO más pequeños son gratuitas, aunque las tasas de minería siguen siendo pagaderas por el usuario para todas las transacciones, incluidas las remezclas.

Esto contrasta con la política de Whirlpool, donde las tasas permanecen fijas, independientemente del tamaño de los anonsets obtenidos. Con Wasabi 2.0, aunque se exime de tasas de coordinador a los UTXO pequeños, el usuario sigue teniendo que pagar tasas de minería en todas las transacciones, incluidas las remezclas.

Mientras escribo estas líneas, el uso de Wabisabi se ha vuelto significativamente más complejo como consecuencia de los últimos acontecimientos. Tras la detención de los fundadores de Samourai Wallet, zkSNACKs, la empresa que financia y gestiona el desarrollo de Wasabi, anunció que su servicio de coordinador de coinjoin dejaría de funcionar el 1 de junio de 2024. Este coordinador, establecido por defecto en Wasabi, era responsable de la gran mayoría de la liquidez.

Con la desaparición de este coordinador principal, los usuarios deben conectarse a nuevos coordinadores independientes. Este cambio plantea una serie de problemas: por un lado, los nuevos coordinadores pueden no tener suficiente liquidez, lo que reduce la eficacia de los coinjoins en términos de confidencialidad. Por otro, existe el riesgo de toparse con un coordinador malintencionado. Esta situación añade nuevos riesgos importantes para quienes deseen utilizar Wabisabi.

Más allá de las cuestiones técnicas, la decisión de zkSNACKs, la empresa detrás de Wasabi, de utilizar los servicios de una empresa de análisis de cadenas para filtrar a los participantes en coinjoins plantea serias cuestiones éticas y estratégicas. La idea inicial era evitar el uso de coinjoins en Wasabi por parte de delincuentes, una medida que puede parecer legítima. Sin embargo, plantea una paradoja: pagar cuotas a un coordinador cuya misión principal es reforzar la confidencialidad de los usuarios, sólo para que financie a una empresa cuyo objetivo es comprometer esa misma confidencialidad.

Aún más preocupante es el principio de filtrado, que contrasta radicalmente con la filosofía de Bitcoin de ofrecer un sistema financiero abierto y sin censura. Aunque pueda parecer justificado querer excluir actividades delictivas, este filtrado también podría afectar a individuos cuyas acciones, aunque clasificadas como ilegales en determinados contextos, podrían ser moralmente justificables o socialmente beneficiosas. El ejemplo de Edward Snowden ilustra perfectamente esta dicotomía: considerado un criminal por algunos gobiernos por sus revelaciones, es visto por otros como un denunciante que actuó en interés público. Esta complejidad subraya el peligro potencial del filtrado que, aunque bienintencionado, puede acabar socavando los derechos y la seguridad de los usuarios legítimos. También podría haber mencionado a los activistas y periodistas perseguidos por ciertos regímenes autoritarios.

Como ya habrás deducido, mi preferencia es definitivamente por el modelo Whirlpool para coinjoins en Bitcoin. Este sistema destaca por su rigor y ofrece garantías superiores de confidencialidad. También es el único que ofrece una mezcla considerada perfecta en un contexto matemático. En mi opinión, este modelo representa el futuro de los coinjoins en Bitcoin. Le invito a profundizar en este modelo en el próximo capítulo.

Cómo funciona Whirlpool

Lo que diferencia a Whirlpool de otros métodos de coinjoin es el uso de transacciones "ZeroLink", que garantizan que no exista estrictamente ningún vínculo técnico posible entre todas las entradas y salidas. Esta mezcla perfecta se consigue mediante una estructura en la que cada participante contribuye con una cantidad idéntica de insumos (a excepción de las tasas de minería), generando productos de cantidades perfectamente iguales.

Este enfoque restrictivo de los insumos confiere a las transacciones coinjoin de Whirlpool una característica única: la ausencia total de vínculos deterministas entre insumos y productos. En otras palabras, cada resultado tiene la misma probabilidad de ser atribuido a cualquier participante, en relación con todos los demás resultados de la transacción.

Cómo funciona Whirlpool

Inicialmente, el número de participantes en cada coinjoin de Remolino se limitaba a 5, con 2 nuevos participantes y 3 remezcladores (explicaremos estos conceptos más adelante). Sin embargo, el aumento de las tasas de transacción en la cadena observado en 2023 llevó a los equipos de Samourai a replantearse su modelo para mejorar la confidencialidad y reducir al mismo tiempo los costes. Así, teniendo en cuenta la situación del mercado de comisiones y el número de participantes, el coordinador puede ahora organizar coinjoins que incluyan 6, 7 u 8 participantes. Estas sesiones mejoradas se conocen como "Surge Cycles". Es importante señalar que, sea cual sea la configuración, siempre hay sólo 2 nuevos participantes en los coinjoins de Remolino.

Así, las transacciones de Whirlpool se caracterizan por un número idéntico de entradas y salidas, que pueden ser :

5 entradas y 5 salidas ;

6 entradas y 6 salidas ;

7 entradas y 7 salidas ;

8 entradas y 8 salidas.

El modelo de Whirlpool se basa en pequeñas transacciones coinjoin. A diferencia de Wabisabi y JoinMarket, donde la solidez de los anonsets se basa en el volumen de participantes en un único ciclo (o en unos pocos ciclos), Whirlpool se basa en la secuencia de varios ciclos pequeños.

En este modelo, los usuarios sólo pagan tasas cuando se unen por primera vez a un pool, lo que les permite participar en multitud de remezclas sin coste adicional. Los nuevos participantes pagan las tasas de minería de los remezcladores.

Con cada coinjoin adicional en el que participe una pieza, así como sus pares encontrados en el pasado, los anonsets crecerán exponencialmente. El objetivo es aprovechar estas remezclas gratuitas que, cada vez que se producen, contribuyen a reforzar la densidad de los anonsets asociados a cada pieza mezclada.

Whirlpool se ha diseñado teniendo en cuenta dos requisitos importantes:

La accesibilidad de la aplicación en dispositivos móviles, dado que Samourai Wallet es ante todo una aplicación para teléfonos inteligentes;
Ciclos de remezcla rápidos para promover un aumento significativo de los anonsets.

Estos imperativos guiaron las decisiones tomadas por los desarrolladores de Samourai Wallet a la hora de diseñar Whirlpool, lo que les llevó a restringir el número de participantes a un número limitado por ciclo. Demasiados pocos habría comprometido la eficiencia de coinjoin, reduciendo drásticamente los anonsets generados por ciclo, mientras que demasiados habría planteado problemas de gestión en las aplicaciones móviles y obstaculizado el flujo del ciclo.

Por último, en Whirlpool no es necesario tener un número elevado de participantes por coinjoin, ya que los anonsets se realizan sobre la acumulación de varios ciclos de coinjoin. El principio más importante aquí es la homogeneidad de los UTXO de todos los participantes, ya que esto garantiza una mezcla perfecta y, por tanto, el pleno beneficio de los ciclos de mezcla y remezcla.

Coinjoin pools y tasas

Para que estos ciclos múltiples aumenten los anonsets de las partes mezcladas, se necesita un marco determinado para restringir las cantidades de UTXOs utilizadas. Whirlpool define diferentes pools.

Un pool representa a un grupo de usuarios que desean mezclarse y que acuerdan la cantidad de UTXOs que se utilizarán para optimizar el proceso de coinjoin manteniendo una homogeneidad perfecta de las piezas. Cada pool especifica una cantidad fija de UTXO, que el usuario debe respetar para poder participar. Por lo tanto, para hacer coinjoins con Whirlpool, es necesario seleccionar un pool. Actualmente están disponibles los siguientes pools:

0.5 bitcoins ;
0.05 bitcoin ;
0.01 bitcoin ;
0.001 bitcoin (= 100.000 sats).

Cuando entres en un pool con tus bitcoins, se dividirán para generar UTXOs perfectamente homogéneos con los de los demás participantes en el pool. Cada pool tiene un límite máximo, por lo que para cantidades que superen este límite, tendrás que hacer dos entradas separadas en el mismo pool, o moverte a otro pool con una cantidad superior:

| Cantidad máxima por entrada (bitcoin)

|----------------|--------------------------------------|

| 0,5 | 35 |

| 0,05 | 3,5 |

| 0,01 | 0,7 |

| 0,001 | 0,025 |

Se considera que un UTXO pertenece a un pool cuando está listo para integrarse en un coinjoin. Sin embargo, esto no significa que el usuario pierda su posesión. Como vimos en los primeros capítulos de esta sección, a través de los distintos ciclos de mezcla, el usuario conserva el control total de sus claves y, en consecuencia, de sus bitcoins. Esto es lo que diferencia a la técnica coinjoin de otras técnicas de mezcla centralizadas.

Para unirse a un pool de coinjoin, hay que pagar una cuota de servicio y una cuota de minería. Las cuotas de servicio son fijas para cada pool y están destinadas a remunerar a los equipos responsables del desarrollo y mantenimiento de Whirlpool.

La cuota de servicio por el uso de Whirlpool se paga una sola vez al unirse a la piscina. Una vez que se haya unido, podrá participar en un número ilimitado de remezclas sin coste adicional. Estas son las tarifas fijas actuales para cada pool:

| Fondo común (bitcoin) Cuota de inscripción (bitcoin)

|----------------|---------------------------------|

| 0,5 | 0,0175 |

| 0,05 | 0,00175 |

| 0.01 | 0.0005 (50,000 sats) |

| 0.001 | 0.00005 (5,000 sats) |

Estas comisiones funcionan esencialmente como un ticket de entrada al pool elegido, independientemente de la cantidad que pongas en coinjoin. Así, tanto si entras en el pool 0,01 con exactamente 0,01 BTC como si lo haces con 0,5 BTC, las comisiones seguirán siendo las mismas en términos absolutos.

Antes de proceder a las uniones por remolino, el usuario puede elegir entre 2 estrategias:

Opta por un grupo más pequeño para minimizar los costes de servicio, sabiendo que a cambio obtendrá varios UTXO más pequeños;
O bien optar por un grupo más grande, dispuesto a pagar comisiones más altas, sólo para acabar con un número menor de UTXOs de mayor valor.

Por lo general, no es aconsejable fusionar varios UTXOs mixtos después de ciclos coinjoin, ya que esto podría comprometer la confidencialidad adquirida, en particular debido a la heurística de propiedad de entrada común (CIOH: Common-Input-Ownership-Heuristic). En consecuencia, puede tener sentido elegir un pool más grande, aunque esto signifique pagar más, para evitar tener demasiados UTXOs de poco valor en la salida. El usuario debe evaluar estas compensaciones para elegir el pool que prefiera.

Además de la tasa de servicio, también hay que tener en cuenta la tasa de minería específica de cualquier transacción de Bitcoin. Como usuario de Whirlpool, deberás pagar la tasa de minería por la transacción de preparación (Tx0), así como por el primer coinjoin. Todas las remezclas posteriores serán gratuitas, gracias al modelo de Whirlpool basado en el pago a los nuevos participantes.

De hecho, en cada coinjoin de Remolino, 2 usuarios entre las entradas son nuevos entrantes. Los demás insumos proceden de remezcladores. Como resultado, los costes de minería para todos los participantes en la transacción son asumidos por estos 2 nuevos entrantes, que también pueden beneficiarse de remezclas gratuitas:

Gracias a este sistema de tasas, Whirlpool destaca realmente de otras implementaciones de coinjoin, ya que el anonimato de los UTXOs no es proporcional al precio pagado por el usuario. Como resultado, es posible alcanzar niveles considerablemente más altos de anonimato pagando únicamente la cuota de entrada al pool y la cuota de minado de 2 transacciones (la Tx0 y la mezcla inicial).

Es importante tener en cuenta que el usuario también tendrá que pagar las tasas de minería para retirar sus UTXOs del pool después de completar sus múltiples coinjoins, a menos que haya seleccionado la opción mix to, que proporciona una dirección externa que recibirá los fondos directamente de coinjoin, sin ninguna transacción adicional.

Cuentas de cartera HD

Para crear una coinjoin a través de Whirlpool, el monedero debe generar varias cuentas separadas. Este es el principio en el que se basa el protocolo ZeroLink. Una cuenta, en el contexto de una cartera HD (Hierarchical Deterministic), constituye una sección totalmente aislada de las demás, produciéndose esta separación en el nivel de la tercera profundidad de la jerarquía de la cartera, es decir, en el nivel xpub.

Un monedero HD puede teóricamente derivar hasta 2^(31) cuentas diferentes. La cuenta inicial, utilizada por defecto en todos los monederos Bitcoin, corresponde al índice 0'.

Para las carteras adaptadas a Whirlpool, se utilizan 4 cuentas para satisfacer las necesidades del proceso ZeroLink:

La cuenta depósito, identificada por el índice 0' ;
La cuenta del banco malo (o "cambio doxémico"), identificada por el índice 2.147.483.644' ;
La cuenta premix, identificada por el índice 2 147 483 645' ;
La cuenta postmix, identificada por el índice 2 147 483 646'.

Cada una de estas cuentas cumple una función concreta en el proceso de coinjoin, que exploraremos en las siguientes secciones.

Todas estas cuentas están vinculadas a una única semilla, lo que permite al usuario recuperar el acceso a todos sus bitcoins utilizando su frase de recuperación y, en su caso, su frase de contraseña. Sin embargo, durante la operación de recuperación, el programa informático debe ser informado de los distintos índices de cuentas utilizados.

Veamos las distintas fases de una coinyección de Whirlpool en estas cuentas.

El TX0

El punto de partida de cualquier coinjoin de Whirlpool es la cuenta de depósito. Esta es la cuenta que utilizas automáticamente cuando creas un nuevo monedero Bitcoin. Esta cuenta tendrá que ser acreditada con los bitcoins que desea mezclar.

Tx0" es el primer paso del proceso de mezcla de Whirlpool. Su objetivo es preparar e igualar los UTXO para el coinjoin, dividiéndolos en unidades correspondientes a la cantidad del pool seleccionado, para garantizar una mezcla homogénea. Los UTXOs así igualados se envían a la cuenta premix. En cuanto a la diferencia que no puede entrar en el pool, se separa en una cuenta específica: el banco malo (o "cambio doxémico").

Esta transacción inicial Tx0 también se utiliza para pagar la cuota de servicio debida al coordinador de coinjoin. A diferencia de los pasos siguientes, esta transacción no es colaborativa, por lo que el usuario debe asumir el coste total de la minería:

En este ejemplo de transacción Tx0, una entrada de 372.000 sats de nuestra cuenta de depósito se divide en varias UTXOs de salida, que se desglosan de la siguiente manera:

Un importe de 5.000 satspara el coordinador en concepto de gastos de servicio, correspondiente a la entrada en el pool de 100.000 sats;
3 UTXOs preparados para la mezcla, redirigidos a nuestra cuenta premix y registrados con el coordinador. Estos UTXOs se igualan a 108.000 sats cada uno, para cubrir los costes de extracción de su futura mezcla inicial;
El excedente, que no puede entrar en el pool por ser demasiado pequeño, se considera divisa tóxica. Se envía a su cuenta específica. Aquí, este intercambio asciende a 40.000 sats ;
Por último, quedan 3.000 sats, que no constituyen una salida, sino que son los costes mineros necesarios para confirmar Tx0.

Por ejemplo, aquí hay un Whirlpool Tx0 real (no es mío): edef60744f539483d868caff49d4848e5cc6e805d6cdc8d0f9bdbbaedcb5fc46

Los cambios doxídicos

El excedente que no ha podido integrarse en el fondo común, aquí equivalente a 40.000 sats, se redirige a la cuenta del banco malo, también conocida como "intercambio doxídico", para garantizar una separación estricta de los demás UTXO de la cartera.

Este UTXO es peligroso para la confidencialidad del usuario, porque no sólo sigue ligado a su pasado y, por tanto, posiblemente a la identidad de su propietario, sino que además está anotado como perteneciente a un usuario que ha hecho un coinjoin.

Si este UTXO se fusiona con salidas mixtas, estas últimas perderán toda la confidencialidad obtenida durante los ciclos de coinjoin, debido especialmente a la CIOH (Common-Input-Ownership-Heuristic). Si se fusiona con otras modificaciones doxxicas, el usuario corre el riesgo de perder la confidencialidad, ya que enlazará las distintas entradas del ciclo coinjoin. Por lo tanto, debe tratarse con precaución. Entraremos en más detalle sobre la gestión de estos UTXOs doxxic en la última sección de este capítulo.

La mezcla inicial

Después de Tx0, los UTXO ecualizados se envían a la cuenta premix de nuestra cartera, listos para ser introducidos en su primer ciclo de coinjoin, también conocido como "mezcla inicial". Si, como en nuestro ejemplo, la Tx0 genera varios UTXOs para mezclar, cada uno de ellos se integrará en una mezcla inicial independiente.

Al final de estas primeras mezclas, la cuenta premix estará vacía, mientras que nuestras monedas, habiendo pagado las tasas de minado por este primer coinjoin, se ajustarán exactamente a la cantidad definida por el pool elegido. En nuestro ejemplo, nuestros UTXOs iniciales de 108.000 sats se habrán reducido exactamente a 100.000 sats.

Remezclas

Tras la mezcla inicial, los UTXO se transfieren a la cuenta postmix. Esta cuenta recoge los UTXO ya mezclados y los que están pendientes de remezcla. Cuando el cliente de Remezcla está activo, los UTXO situados en la cuenta postmix están automáticamente disponibles para remezclas y se seleccionarán aleatoriamente para participar en estos nuevos ciclos.

Como recordatorio, las remezclas son entonces 100% gratuitas: no se requieren cargos adicionales por servicio o tasas de minería. Mantener UTXOs en la cuenta postmix por lo tanto mantiene su valor intacto, y mejora sus anonsets al mismo tiempo. Por eso es importante permitir que estas monedas participen en varios ciclos coinjoin. No te cuesta absolutamente nada, y aumenta sus niveles de anonimato.

Cuando decida gastar UTXOs mixtos, podrá hacerlo directamente desde esta cuenta postmix. Le aconsejamos que guarde los UTXO mixtos en esta cuenta para beneficiarse de las remezclas gratuitas y evitar que salgan del circuito de Remolino, lo que podría reducir su confidencialidad.

¿Cómo gestiona sus postmezclas?

Después de ejecutar ciclos de coinjoin, la mejor estrategia es mantener tus UTXOs en la cuenta postmix, a la espera de un uso futuro. Incluso es recomendable dejar que se remezclen indefinidamente hasta que necesites gastarlos.

Algunos usuarios podrían considerar transferir sus bitcoins mezclados a un monedero asegurado por un monedero hardware. Esto es posible, pero es importante seguir escrupulosamente las recomendaciones de Samourai Wallet para no comprometer la confidencialidad adquirida.

Fusionar UTXOs es el error más común. Para evitar CIOH (Common-Input-Ownership-Heuristic), debe evitar combinar UTXOs mezclados con UTXOs no mezclados en la misma transacción. Esto requiere una gestión cuidadosa de sus UTXOs dentro de su cartera, sobre todo en términos de etiquetado.

También hay que tener cuidado al consolidar UTXOs mixtos. Una consolidación moderada es posible si sus UTXO mixtos tienen anonsets significativos, pero esto reducirá inevitablemente la confidencialidad de sus piezas. Asegúrese de que las consolidaciones no sean demasiado extensas ni se realicen tras un número insuficiente de remezclas, a riesgo de establecer vínculos deducibles entre sus UTXO antes y después de los ciclos de coinjoin. En caso de duda sobre estas manipulaciones, la mejor práctica consiste en no consolidar los UTXO posteriores al remix, sino transferirlos uno a uno a su monedero físico, generando cada vez una nueva dirección en blanco. Una vez más, recuerda etiquetar cada UTXO que recibas.

Tampoco es aconsejable transferir tus UTXOs postmix a un monedero usando scripts que no son muy utilizados. Por ejemplo, si entras en Whirlpool desde un monedero multisig usando scripts P2WSH, hay pocas posibilidades de que te mezcles con otros usuarios que originalmente tenían el mismo tipo de monedero. Si vuelves a mezclar tus postmixes a este mismo monedero multisig, el nivel de confidencialidad de tus bitcoins mezclados se reducirá considerablemente. Más allá de los scripts, hay muchas otras huellas dactilares de monedero que pueden jugarte una mala pasada.

Como con cualquier transacción Bitcoin, también es importante no reutilizar la dirección de recepción. Cada nueva transacción debe recibirse en una nueva dirección en blanco.

La solución más sencilla y segura es dejar tus UTXOs mezclados en reposo en su cuenta postmix, dejando que se remezclen y sólo tocándolos para gastar. Los monederos Samurai y Sparrow cuentan con protecciones adicionales contra todos estos riesgos de análisis de cadena. Estas protecciones te ayudan a evitar cometer errores.

¿Cómo se gestionan los intercambios tóxicos?

A continuación, tendrás que tener cuidado con la gestión de los intercambios doxxic, los intercambios que no entraron en el pool de coinjoin. Estos UTXOs tóxicos, resultantes del uso de Whirlpool, suponen un riesgo para tu privacidad, ya que establecen un vínculo entre tú y el usuario de coinjoin. Por lo tanto, es imperativo gestionarlos con cuidado y no combinarlos con otros UTXOs, especialmente UTXOs mixtos.

He aquí algunas estrategias para utilizarlos:

Mézclelos en piscinas más pequeñas:** Si su UTXO tóxico es lo suficientemente grande como para caber en una piscina más pequeña por sí solo, considere la posibilidad de mezclarlo. Esta suele ser la mejor opción. Sin embargo, no es aconsejable fusionar varios UTXO tóxicos para acceder a un pool, ya que esto podría vincular sus diferentes entradas;
Marcarlos como "no gastables":** Otro enfoque es dejar de usarlos, marcarlos como "no gastables" en su cuenta dedicada, y simplemente hodl. Así se asegura de no gastarlos accidentalmente. Si el valor del bitcoin sube, pueden surgir nuevos pools más adecuados para tus UTXOs tóxicos;
Hacer donaciones:** Considera hacer donaciones, por modestas que sean, a los desarrolladores que trabajan en Bitcoin y software relacionado. También puedes donar a asociaciones que acepten BTC. Si gestionar tus UTXO tóxicos te parece demasiado complicado, puedes simplemente deshacerte de ellos y hacer una donación;
Comprar tarjetas regalo:** Plataformas como Bitrefill permiten canjear bitcoins por tarjetas regalo que pueden utilizarse en diversos comercios. Esta puede ser una forma de deshacerte de tus UTXO tóxicos sin perder el valor asociado;
Consolidarlos en Monero:** Samourai Wallet ofrece un servicio de intercambio atómico entre BTC y XMR. Esto es ideal para gestionar UTXOs tóxicos consolidándolos en Monero, sin comprometer su confidencialidad a través de CIOH, antes de enviarlos de vuelta a Bitcoin. Sin embargo, esta opción puede ser costosa en términos de tasas de minería y prima debido a las restricciones de liquidez;
Enviarlos a la Lightning Network:** Transferir estos UTXO a la Lightning Network para beneficiarse de tarifas de transacción reducidas puede ser una opción atractiva. Sin embargo, este método puede revelar cierta información en función de cómo utilices Lightning, por lo que debe utilizarse con precaución.

¿Cómo se utiliza Whirlpool?

Tras la detención de los fundadores de Samourai Wallet y la incautación de sus servidores el 24 de abril de 2024, la herramienta Remolino ya no funciona, ni siquiera para aquellos que tienen su propio Dojo. Anteriormente, estaba disponible en Samourai Wallet y Sparrow Wallet.

No obstante, sigue siendo posible que esta herramienta se reactive en las próximas semanas, en función del resultado de las pruebas, o que se relance de otra forma. En cualquier caso, no creo que el mercado de coinjoin de Bitcoin se quede sin oferta durante mucho tiempo, ya que la demanda está ahí. Además, como el modelo de Whirlpool es el más avanzado en términos de confidencialidad, seguramente será el modelo elegido para otras implementaciones en el futuro.

Seguimos de cerca este caso y la evolución de las herramientas asociadas. Le aseguramos que actualizaremos este curso de formación a medida que dispongamos de nueva información.

En el próximo capítulo, descubriremos qué son los "anonsets", cómo se calculan estos indicadores y cómo pueden ayudarnos a estimar la eficiencia de los ciclos coinjoin.

https://planb.network/tutorials/privacy/on-chain/coinjoin-sparrow-wallet-84def86d-faf5-4589-807a-83be60720c8b

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/coinjoin-dojo-c4b20263-5b30-4c74-ae59-dc8d0f8715c2

Conjuntos de anonimato

Una vez estudiado cómo funcionan los coinjoins y los problemas que plantea una mezcla eficaz, ahora vamos a averiguar cómo medir su eficacia. ¿Cómo podemos determinar si un proceso de coinjoining ha sido eficaz y qué grado de anonimato ha adquirido una parte? Eso es lo que vamos a averiguar en este capítulo con los conjuntos de anonimato o "anonsets".

Un recordatorio de la utilidad de coinjoin

La utilidad de coinjoin reside en su capacidad para producir una negación plausible, al incrustar tu parte dentro de un grupo de partes indistinguibles. El objetivo de esta acción es romper los vínculos de trazabilidad, tanto del pasado al presente como del presente al pasado.

En otras palabras, un analista que conozca su transacción inicial (Tx0) a la entrada de los ciclos de coinjoin no debería ser capaz de identificar con certeza su UTXO a la salida de los ciclos de remix (análisis de entrada de ciclo a salida de ciclo).

A la inversa, un analista que conozca su UTXO a la salida de los ciclos de coinjoin no podrá determinar la transacción original a la entrada de los ciclos (análisis de salida de ciclo a entrada de ciclo).

Para evaluar lo difícil que es para un analista relacionar el pasado con el presente y viceversa, tenemos que cuantificar el tamaño de los grupos de piezas homogéneas dentro de los cuales se oculta su pieza. Esta medida nos indica cuántos análisis tienen la misma probabilidad. Así, si el análisis correcto se ahoga entre otros 3 análisis de igual probabilidad, su nivel de ocultación es muy bajo. En cambio, si el análisis correcto se encuentra dentro de un conjunto de 20.000 análisis igualmente probables, su parte está muy bien oculta. El tamaño de estos grupos representa indicadores conocidos como "anonsets".

Entender los anonsets

Los anonsets se utilizan como indicadores para evaluar el grado de confidencialidad de un UTXO concreto. Más concretamente, miden el número de UTXO indistinguibles dentro del conjunto que incluye la parte objeto de estudio. El requisito de un conjunto homogéneo de UTXO significa que los anonsets se calculan normalmente en ciclos coinjoin. El uso de estos indicadores es especialmente relevante para los coinjoints Whirlpool, debido a su uniformidad.

Si es necesario, se pueden utilizar anonsets para juzgar la calidad de los coinjoins. Un anonset grande significa un alto nivel de anonimato, ya que resulta difícil distinguir un UTXO específico dentro del conjunto homogéneo.

existen 2 tipos de anonsets:

El anonset prospectivo ;**
Retrospectiva anonset.**

La anonset prospectiva

El anonset prospectivo indica el tamaño del grupo en el que se oculta el UTXO estudiado al final del ciclo, dado el UTXO del principio, es decir, el número de partes indistinguibles presentes dentro de este grupo. El nombre de este indicador es "métrica prospectiva".

Este indicador mide la resistencia de la confidencialidad de la sala a un análisis pasado-presente (entrada-salida).

Esta métrica se utiliza para estimar el grado de protección de tu UTXO frente a los intentos de reconstruir su historia desde su punto de entrada hasta su punto de salida en el proceso de coinjoin.

Por ejemplo, si su transacción ha participado en su primer ciclo coinjoin y se han completado otros dos ciclos descendentes, el anonset prospectivo de su moneda sería 13 :

Por ejemplo, imaginemos que nuestra moneda al inicio del ciclo de coinjoin tiene un anonset prospectivo de 86,871. En la práctica, esto significa que está oculta entre "86.871" partes indistinguibles. Para un observador externo que conozca esta moneda al inicio de los ciclos de coinjoin e intente rastrear su salida, se encontrará con 86.871 UTXO posibles, cada una con una probabilidad idéntica de ser la moneda que busca.

La anonset retrospectiva

El anonset retrospectivo indica el número de fuentes posibles para una pieza determinada, conociendo el UTXO al final del ciclo. Este indicador mide la resistencia de la confidencialidad de la pieza a un análisis de presente a pasado (de salida a entrada), es decir, lo difícil que es para un analista rastrear su pieza hasta su origen, antes de los ciclos de coinjoin. El nombre de este indicador es "backward anonset", o "métrica retrospectiva".

Conociendo su UTXO a la salida de los ciclos, la anonset retrospectiva determina el número de transacciones Tx0 potenciales que podrían haber constituido su entrada en los ciclos coinjoin. En el diagrama siguiente, esto corresponde a la suma de todas las burbujas naranjas.

Por ejemplo, imaginemos que nuestra parte coinjoin tiene un anonset retrospectivo de 42,185. En términos prácticos, esto significa que hay "42.185" fuentes potenciales para este UTXO. Si un observador externo identifica esta moneda al final de los ciclos y busca su origen, se encontrará con "42.185" fuentes posibles, todas ellas con la misma probabilidad de ser el origen buscado.

¿Cómo se calculan los anonsets?

Es posible calcular anonsets manualmente utilizando un explorador de bloques para conjuntos pequeños. Sin embargo, para anonsets más grandes, se hace imprescindible el uso de una herramienta especializada. Hasta donde yo sé, el único software capaz de realizar esta tarea es Whirlpool Stats Tool, una herramienta Python desarrollada por los equipos Samourai y OXT. Por desgracia, esta herramienta está actualmente fuera de servicio tras la detención de los fundadores de Samourai y la interrupción de OXT, que se utilizaba para extraer datos de la blockchain.

Como hemos visto en este capítulo, los anonsets sólo pueden calcularse si existe una cierta homogeneidad en la estructura del coinjoin. En el próximo capítulo, descubriremos cómo cuantificar esta homogeneidad en una transacción Bitcoin, ya sea una coinjoin o una transacción más tradicional.

https://planb.network/tutorials/privacy/analysis/wst-anonsets-0354b793-c301-48af-af75-f87569756375

Entropía

Como hemos visto en esta sección sobre coinjoins, la homogeneidad de UTXOs en entrada y salida juega un papel importante en la mejora de la confidencialidad de una transacción Bitcoin. Este parámetro crea una negación plausible frente al análisis de blockchain. Se pueden utilizar varios métodos para medir esta homogeneidad, pero uno de los más eficaces, en mi opinión, es el uso de los indicadores proporcionados por la herramienta Boltzmann, desarrollada por los equipos de OXT y Samourai Wallet, y en particular la entropía de la transacción. Esto es lo que veremos en detalle en este capítulo.

A diferencia de los anonsets, que se calculan sobre un conjunto de transacciones, los indicadores presentados aquí se centran en una única transacción, ya sea una coinjoin o una transacción más tradicional.

El número de interpretaciones

El primer indicador que puede observarse en una transacción de Bitcoin es el número total de interpretaciones posibles ante un análisis de un observador externo. Teniendo en cuenta los valores de los UTXO implicados en la transacción, este indicador muestra el número de formas en que las entradas pueden asociarse con las salidas. En otras palabras, determina el número de interpretaciones posibles que una transacción puede suscitar en los flujos de bitcoins desde el punto de vista de un observador externo que la analice.

Por ejemplo, una operación de pago simple con 1 entrada y 2 salidas sólo tendrá una interpretación, a saber, que la entrada nº 0 financió la salida nº 0 y la salida nº 1. No hay ninguna otra interpretación posible. No hay ninguna otra interpretación posible:

Por otro lado, una esquina Whirlpool 5x5 tiene $1\.496$ de combinaciones posibles:

A Whirlpool Surge Cycle 8x8 coinjoin tiene $9\,934\,563$ posibles interpretaciones:

Entropía

A partir del número de interpretaciones de una transacción Bitcoin, podemos calcular su entropía.

En el contexto general de la criptografía y la información, la entropía es una medida cuantitativa de la incertidumbre o imprevisibilidad asociada a una fuente de datos o un proceso aleatorio. En otras palabras, la entropía es una forma de medir lo difícil que es predecir o adivinar un dato.

En el contexto específico del análisis de blockchain, entropía es también el nombre de un indicador, derivado de la entropía de Shannon e inventado por LaurentMT, que puede calcularse sobre una transacción Bitcoin.

Cuando una transacción presenta un gran número de interpretaciones posibles, suele ser más pertinente referirse a su entropía. Este indicador mide el desconocimiento de los analistas sobre la configuración exacta de la transacción. En otras palabras, cuanto mayor sea la entropía, más difícil será para los analistas identificar el flujo de bitcoins entre entradas y salidas.

En la práctica, la entropía revela si, desde el punto de vista de un observador externo, una transacción presenta múltiples interpretaciones posibles, basadas únicamente en las cantidades de entrada y salida, sin tener en cuenta otros patrones y heurísticos externos o internos. Por lo tanto, una entropía elevada es sinónimo de una mayor confidencialidad de la transacción.

La entropía se define como el logaritmo binario del número de combinaciones posibles. He aquí la fórmula utilizada con $E$ la entropía de la transacción y $C$ el número de interpretaciones posibles:

 $E = \log_2(C)$

En matemáticas, el logaritmo binario (logaritmo de base 2) es la operación inversa de la exponenciación de 2. En otras palabras, el logaritmo binario de $x$ es el exponente al que hay que elevar $2$ para obtener $x$ . Por lo tanto, este indicador se expresa en bits.

Tomemos el ejemplo del cálculo de entropía para una transacción coinjoin estructurada según el modelo Whirlpool 5x5, que, como se ha mencionado en la sección anterior, tiene un número de interpretaciones posibles de $1\,496$ :

 $\begin{align*} C &= 1\,496 \\ E &= \log_2(1\,496) \\ E &= 10.5469 \text{ bits} \end{align*}$

Así, esta transacción coinjoin tiene una entropía de 10,5469$ bits, lo que se considera muy satisfactorio. Cuanto mayor sea este valor, más interpretaciones diferentes admite la transacción, lo que refuerza su nivel de confidencialidad.

Para una transacción coinjoin 8x8 con $9\,934\,563$ interpretaciones, la entropía sería :

 $\begin{align*} C &= 9\,934\,563 \\ E &= \log_2(9\,934\,563) \\ E &= 23.244 \text{ bits} \end{align*}$

Tomemos otro ejemplo con una operación de pago clásica, con 1 entrada y 2 salidas: 1b1b0c3f0883a99f1161c64da19471841ed12a1f78e77fab128c69a5f578ccce

En el caso de esta transacción, la única interpretación posible es: (In.0) > (Out.0 ; Out.1). En consecuencia, su entropía es de $0$ :

 $\begin{align*} C &= 1 \\ E &= \log_2(1) \\ E &= 0 \text{ bits} \end{align*}$

Eficacia

A partir de la entropía de la transacción, también podemos calcular su eficacia en términos de confidencialidad. Este indicador evalúa la eficacia de la transacción comparándola con la transacción óptima que podría preverse en una configuración idéntica.

Esto nos lleva al concepto de entropía máxima, que corresponde a la entropía más alta que una estructura de transacción específica puede alcanzar teóricamente. La eficiencia de la transacción se calcula comparando esta entropía máxima con la entropía real de la transacción analizada.

La fórmula utilizada es la siguiente con :

e_R$: la entropía real de la transacción expresada en bits;
e_M$: la máxima entropía posible para una estructura de transacción, también expresada en bits;
$Ef$ : eficacia de la transacción en bits :

 $Ef = E_R - E_M$

Por ejemplo, para una estructura Whirlpool 5x5 coinjoin, la entropía máxima es de 10,5469$ :

 $\begin{align*} E_R &= 10.5469 \\ E_M &= 10.5469 \\ Ef &= E_R - E_M \\ Ef &= 10.5469 - 10.5469 \\ Ef &= 0 \text{ bits} \end{align*}$

Este indicador también se expresa en porcentaje. La fórmula utilizada es la siguiente :

c_R$ : el número de interpretaciones reales posibles ;
c_M$: el número máximo de interpretaciones posibles de una misma estructura;
$Ef$ : eficiencia expresada en porcentaje:

 $\begin{align*} E_f &= \frac{C_R}{C_M} \\ E_f &= \frac{1\,496}{1\,496} \\ E_f &= 100 \% \end{align*}$

Una eficiencia de 100 dólares indica que la operación aprovecha al máximo su potencial de confidencialidad, en función de su estructura.

Densidad de entropía

La entropía es un buen indicador para medir la confidencialidad de una transacción, pero depende en parte del número de entradas y salidas de la transacción. Para comparar la entropía de 2 transacciones diferentes con distinto número de entradas y salidas, podemos calcular la densidad de entropía. Este indicador proporciona una perspectiva de la entropía relativa a cada entrada o salida de la transacción. La densidad es útil para evaluar y comparar la eficiencia de transacciones de diferentes tamaños.

Para calcularla, simplemente dividimos la entropía total de la transacción por el número total de entradas y salidas implicadas en la transacción:

e_D$: densidad de entropía expresada en bits;
e$: la entropía de la transacción expresada en bits;
t$: número total de entradas y salidas en la transacción:

 $E_D = \frac{E}{T}$

Tomemos el ejemplo de un coinjoin Whirlpool 5x5:

 $\begin{align*} T &= 5 + 5 = 10 \\ E &= 10.5469 \\ E_D &= \frac{E}{T} \\ E_D &= \frac{10.5469}{10} \\ E_D &= 1.054 \text{ bits} \end{align*}$

Calculemos también la densidad de entropía de una unión por remolino de 8x8:

 $\begin{align*} T &= 8 + 8 = 16 \\ E &= 23.244 \\ E_D &= \frac{E}{T} \\ E_D &= \frac{23.244}{16} \\ E_D &= 1.453 \text{ bits} \end{align*}$

Al analizar la densidad de entropía de estos dos tipos de coinjoin, queda claro que, incluso normalizando la entropía por el número de elementos, el coinjoin "Surge Cycle 8x8" genera más incertidumbre para el análisis.

La puntuación Boltzmann

Otra información que se analiza en una operación es la puntuación de Boltzmann de cada elemento en relación con otro. Se trata de la tabla de probabilidades de correspondencia entre entradas y salidas. Esta tabla indica, a través de la puntuación de Boltzmann, la probabilidad condicional de que una entrada específica esté vinculada a una salida determinada. Se trata, por tanto, de una medida cuantitativa de la probabilidad condicional de que se produzca una asociación entre un input y un output en una operación, basada en la relación entre el número de ocurrencias favorables de este evento y el número total de ocurrencias posibles, en un conjunto de interpretaciones.

Utilizando el ejemplo de un coinjoin de Whirlpool, la tabla de probabilidades condicionales destacaría las posibilidades de que exista un vínculo entre cada entrada y salida, ofreciendo una medida cuantitativa de la ambigüedad de las asociaciones en la transacción:

| ------- | -------- | -------- | -------- | -------- | -------- |

| Entrada 0 | 34% | 34% | 34% | 34% | 34% | 34% |

| Entrada 1 | 34% | 34% | 34% | 34% | 34% | Entrada 1

| Entrada 2 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

| Entrada 3 | 34% | 34% | 34% | 34% | 34% | Entrada 3

| Entrada 4 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

Evidentemente, cada entrada tiene las mismas posibilidades de estar asociada a cualquier salida, lo que refuerza la confidencialidad de la transacción.

La puntuación de Boltzmann se calcula dividiendo el número de interpretaciones en las que se produce un determinado suceso por el número total de interpretaciones disponibles. Así, para determinar la puntuación que asocia la entrada #0 con la salida #3 (suceso presente en $512$ interpretaciones), procedemos como sigue:

 $\begin{align*} \text{Interpretations (IN.0 > OUT.3)} &= 512 \\ \text{Interpretations totales} &= 1496 \\ \text{Score} &= \frac{512}{1496} \\ \text{Score} &= 34 \% \end{align*}$

Si tomamos el ejemplo de un coinjoin Whirlpool 8x8 Surge Cycle, la tabla de Boltzmann tendría el siguiente aspecto:

| OUT.0 | OUT.1 | OUT.2 | OUT.3 | OUT.4 | OUT.5 | OUT.6 | OUT.7 |

|-------|-------|-------|-------|-------|-------|-------|-------|-------|

| IN.0 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.1 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.2 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.3 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.4 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| IN.5 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.6 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

| EN.7 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

Sin embargo, en el caso de una transacción simple con una sola entrada y 2 salidas, la situación es diferente:

| Salida 0 Salida 1

|---------|----------|----------|

| Entrada 0 | 100% | 100% |

Aquí vemos que la probabilidad de que cada salida proceda de la entrada nº 0 es del 100%. Por tanto, una probabilidad menor refleja una mayor confidencialidad, diluyendo los vínculos directos entre entradas y salidas.

Enlaces deterministas

También podemos calcular el número de conexiones deterministas de una transacción. Este indicador revela cuántas de las conexiones entre entradas y salidas en la transacción analizada son incuestionables, con una probabilidad del 100%. Este indicador puede completarse calculando la proporción de enlaces deterministas. El ratio proporciona una perspectiva sobre el peso de estos enlaces deterministas dentro del total de enlaces de la transacción.

Por ejemplo, una transacción de coinjoin de Whirlpool no tiene vínculos deterministas entre entradas y salidas, y por tanto muestra un indicador de 0 vínculos y un ratio del 0%. Por el contrario, en nuestra segunda transacción de pago simple examinada (con una entrada y 2 salidas), el indicador nos dice que existen 2 enlaces deterministas, y el ratio alcanza el 100%. En otras palabras, un indicador cero indica una excelente confidencialidad, gracias a la ausencia de vínculos directos e indiscutibles entre entradas y salidas.

¿Cómo se calculan estos indicadores?

Calcular manualmente estos indicadores utilizando las ecuaciones que he proporcionado es relativamente sencillo. La dificultad reside principalmente en determinar el número de interpretaciones posibles de una transacción. Para una transacción clásica, este cálculo puede hacerse a mano. Para una coinjoin, sin embargo, la tarea es mucho más compleja.

Anteriormente, existía una herramienta Python llamada Boltzmann Calculator, desarrollada por los equipos OXT y Samourai, que calculaba automáticamente todos estos indicadores para una transacción de Bitcoin :

También fue posible utilizar el sitio web KYCP.org para estos análisis:

Lamentablemente, tras la detención de los fundadores de Samourai, estas herramientas ya no están operativas.

Ahora que hemos cubierto los coinjoins en detalle, veremos las otras técnicas de privacidad disponibles en Bitcoin en la sección final de nuestro curso. Veremos los payjoins, tipos específicos de transacciones pseudo-coinjoin, protocolos de direcciones estáticas, así como medidas para reforzar la confidencialidad no a nivel de las transacciones en sí, sino a nivel de la red de nodos.

https://planb.network/tutorials/privacy/analysis/boltzmann-entropy-738e45af-18a6-4ce6-af1a-1bf58e15f1fe

Comprender los retos de otras técnicas avanzadas de confidencialidad

Transacciones Payjoin

Coinjoin es actualmente el método más eficaz para introducir incertidumbre en el trazado de las piezas en un análisis de cadena. Como hemos visto en capítulos anteriores, para obtener una mezcla de alto rendimiento, las entradas y salidas deben ser lo más homogéneas posible. Además, es importante que las partes se integren en un grupo lo más grande posible para maximizar los anonsets. Así pues, para que las coinjoins sean eficaces, deben incluir un gran número de piezas uniformes. Esta multitud de requisitos hace que las transacciones coinjoin tengan una estructura muy rígida: las cantidades se fijan de antemano, y todos los participantes deben atenerse a ellas para garantizar la uniformidad del proceso. Además, las coinjoins requieren la sincronización entre todos los participantes y el coordinador durante la construcción de la transacción.

Estos requisitos hacen que coinjoin no sea adecuado para pagos directos. Por ejemplo, si tienes una moneda de 1M de sats en un pool de coinjoin, utilizarla directamente como pago sería complejo. Requeriría sincronización con los demás participantes y el coordinador para construir la transacción colaborativa precisamente en el momento en que necesitas hacer un pago, y el importe de la compra tendría que corresponder exactamente al valor de tu moneda, lo que es prácticamente inviable. Por tanto, la transacción coinjoin es, por su propia naturaleza, una transacción de barrido colaborativo, es decir, suelen ser los mismos propietarios de las entradas los que encontramos en las salidas.

Sin embargo, sería interesante disponer de estructuras de transacción que permitan realizar pagos de forma práctica, al tiempo que se introduce la duda en el análisis de la cadena. Esto es precisamente lo que estudiaremos en este capítulo y en el siguiente.

¿Qué es una transacción payjoin?

El payjoin es una estructura de transacción específica de Bitcoin que mejora la privacidad del usuario a la hora de gastar colaborando con el receptor del pago.

Fue en 2015 cuando LaurentMT mencionó por primera vez este método bajo la denominación de "steganographic transactions", según un documento disponible aquí. Esta técnica fue adoptada posteriormente por el monedero Samourai Wallet, que en 2018 fue el primer cliente en implementarla con la herramienta Stowaway. El concepto de payjoin también se encuentra en el BIP79, el BIP78 y el BIP77. Así, se utilizan varios términos para referirse a un payjoin:

Payjoin ;
Polizón;
P2EP (Pago por punto final) ;
Transacción esteganográfica.

La particularidad de payjoin reside en su capacidad para generar una transacción que a primera vista parece ordinaria, pero que en realidad es un mini Coinjoin entre dos personas. Para conseguirlo, la estructura de la transacción incluye al receptor del pago en las entradas junto al emisor real. De este modo, el receptor se incluye un pago a sí mismo en medio de la transacción que, a su vez, le permite cobrar.

Pongamos un ejemplo para entender mejor este proceso. Alice compra una baguette por 4.000 sats utilizando un UTXO de 10.000 sats y opta por un payjoin. Su panadero, Bob, añade un UTXO de 15.000 sats de su propiedad como entrada, que recupera íntegramente como salida, además de los 4.000 sats de Alice.

En este ejemplo, Bob el panadero entra 15.000 sats y sale con 19.000 sats, la diferencia es exactamente 4.000 sats, es decir, el precio de la baguette. Por parte de Alice, entra 10.000 sats y sale con 6.000 sats, lo que representa un saldo de -4.000 sats, es decir, el precio de la baguette. Para simplificar el ejemplo, he omitido deliberadamente los costes de minería en esta transacción.

¿Para qué sirve el payjoin?

La transacción payjoin cumple dos objetivos, ya que permite a los usuarios aumentar la confidencialidad de su pago.

En primer lugar, payjoin pretende engañar a un observador externo creando un señuelo en el análisis de la cadena. Esto es posible gracias a la heurística CIOH (Common Input Ownership Heuristic). Como vimos en la parte 3, normalmente, cuando una transacción en la blockchain tiene varias entradas, se asume que todas estas entradas pertenecen a la misma entidad o usuario.

Así, cuando un analista examina una transacción payjoin, se le hace creer que todas las entradas proceden de la misma persona. Sin embargo, esta percepción es errónea, porque el beneficiario también contribuye a las entradas junto con el pagador real. Por lo tanto, el análisis de la cadena se desvía hacia una interpretación que resulta ser errónea.

Tomemos nuestro ejemplo de una transacción payjoin para el pago de una baguette:

Viendo esta transacción en la blockchain, un observador externo que siguiera la heurística habitual del análisis de blockchain haría la siguiente interpretación: "Alice fusionó 2 UTXOs como entradas de la transacción para pagar 19.000 sats a Bob".

Esta interpretación es obviamente incorrecta, porque como ya sabes, los dos UTXO de las entradas no pertenecen a la misma persona. Uno procede de Alice, la compradora de baguettes, y el otro de Bob, el panadero.

De este modo, se orienta el análisis del observador externo hacia una conclusión errónea, garantizando la confidencialidad de las partes interesadas.

La transacción esteganográfica

El segundo propósito de payjoin es engañar a un observador externo sobre el importe real del pago que se ha realizado. Examinando la estructura de la transacción, el analista podría creer que el pago equivale al importe de una de las salidas.

Si volvemos a nuestro ejemplo de la compra de una baguette, el analista pensará que el importe del pago corresponde o bien al UTXO de 6.000 sats, o bien al UTXO de 19.000 sats. En este caso, el analista pensará más bien que el importe del pago es de 19.000 sats, porque hay 2 UTXO en salidas, al menos una de las cuales es superior a 6.000 sats (no hay ninguna razón lógica para utilizar 2 UTXO para pagar 6.000 sats cuando un solo UTXO habría bastado para satisfacer este pago).

Pero en realidad, este análisis es erróneo. El importe del pago no corresponde a ninguna de las salidas. En realidad, es la diferencia entre el UTXO del beneficiario en output y el UTXO del beneficiario en input.

En este sentido, la transacción payjoin entra en el ámbito de la esteganografía. Permite ocultar el importe real de una transacción dentro de una transacción falsa que actúa como señuelo.

La esteganografía es una técnica para ocultar información dentro de otros datos u objetos, de modo que la presencia de la información oculta no sea perceptible. Por ejemplo, se puede ocultar un mensaje secreto dentro de un punto en un texto no relacionado, haciéndolo indetectable a simple vista (es la técnica del micropunto).

A diferencia del cifrado, que hace incomprensible la información sin la clave de descifrado, la esteganografía no modifica la información. Ésta permanece en texto claro. Su objetivo es más bien ocultar la existencia misma del mensaje secreto, mientras que el cifrado revela claramente la presencia de información oculta, aunque inaccesible sin la clave. Por eso el nombre original de payjoin era "transacciones esteganográficas".

Se puede establecer una analogía entre criptografía y coinjoin, y entre esteganografía y payjoin. Coinjoin tiene atributos similares a la criptografía: el método es reconocible, pero la información es indescifrable. A la inversa, el payjoin es similar a la esteganografía: la información es teóricamente accesible, pero como el método de ocultación no es reconocible, resulta inaccesible.

¿Cómo se utiliza payjoin?

Entre los programas de software más conocidos que admiten payjoin se incluyen Sparrow Wallet, Wasabi Wallet, Mutiny, BitMask, BlueWallet y JoinMarket, así como el procesador de pagos BTCPay.

La implementación más avanzada de payjoin era sólo Stowaway en Samourai Wallet. Sin embargo, desde el arresto de los fundadores del software, esta herramienta es ahora sólo parcialmente funcional. La ventaja de Stowaway es que es un protocolo completo y fácil de usar, que soporta tanto la recepción como el envío de payjoins. Las transacciones parcialmente firmadas pueden intercambiarse manualmente escaneando varios códigos QR, o automáticamente por Tor a través de Soroban. Esta última opción de comunicación está actualmente fuera de servicio.

La dificultad de utilizar payjoin radica en su dependencia de la participación del comerciante. Como cliente, no puedes utilizar payjoin si el comerciante no lo admite. Esto añade otra dificultad al proceso de compra: no sólo es difícil encontrar comercios que acepten bitcoin, sino que si además buscas los que admiten payjoins, la cosa se complica aún más.

Una solución sería utilizar estructuras de transacción que introduzcan ambigüedad en el análisis de la cadena sin requerir la cooperación del receptor. Esto nos permitiría mejorar la confidencialidad de nuestros pagos sin depender de la participación activa de los comerciantes. Esto es precisamente lo que estudiaremos en el próximo capítulo.

https://planb.network/tutorials/privacy/on-chain/payjoin-sparrow-wallet-087a0e49-61cd-41f5-8440-ac7b157bdd62

https://planb.network/tutorials/privacy/on-chain/payjoin-samourai-wallet-48a5c711-ee3d-44db-b812-c55913080eab

Pago mini-coinjoin

Cuando se desea realizar una transacción de pago manteniendo un cierto grado de confidencialidad, payjoin es una buena opción. Pero como acabamos de ver, payjoin requiere la participación del destinatario. Entonces, ¿qué hacer si el destinatario se niega a participar en un payjoin, o si usted simplemente prefiere no involucrarlo? Una alternativa es utilizar una transacción Stonewall o Stonewall x2. Echemos un vistazo más de cerca a estos dos tipos de transacción.

La transacción Stonewall

Stonewall es una forma específica de transacción Bitcoin diseñada para aumentar la confidencialidad del usuario a la hora de gastar imitando una pseudo-coinjoin entre dos personas, sin serlo realmente. De hecho, esta transacción no es colaborativa. Un usuario puede construirla por sí mismo, utilizando sólo los UTXOs que posee como entradas. Así, puede crear una transacción Stonewall para cualquier ocasión, sin necesidad de sincronizarse con otro usuario o con el destinatario.

La transacción Stonewall funciona de la siguiente manera: como entrada a la transacción, el emisor utiliza 2 UTXOs que le pertenecen. A la salida, la transacción produce 4 UTXOs, 2 de los cuales son exactamente de la misma cantidad. Los otros 2 UTXOs constituirán divisas. De las 2 salidas del mismo importe, sólo una irá realmente al beneficiario.

Así que sólo hay 2 papeles en una transacción Stonewall:

El emisor, que realiza el pago ;
El destinatario, que puede desconocer la naturaleza específica de la transacción y simplemente espera el pago del remitente.

Pongamos un ejemplo para entender esta estructura de transacción. Alice va al panadero Bob a comprar su baguette, que cuesta 4.000 sats. Ella quiere pagar en bitcoins, manteniendo algún tipo de confidencialidad con respecto a su pago. Así que decide construir una transacción Stonewall para el pago.

Analizando esta transacción, podemos ver que Bob, el panadero, recibió en realidad 4.000 sats como pago por la baguette. Alice utilizó 2 UTXOs como entradas: uno por 10.000 sats y otro por 15.000 sats. En outputs, ha recuperado 3 UTXOs: uno por 4.000 sats, otro por 6.000 sats y otro por 11.000 sats. Alice tiene por tanto un saldo neto de -4.000 sats en esta transacción, lo que corresponde al precio de la baguette.

En este ejemplo, he omitido intencionadamente las comisiones mineras para facilitar la comprensión. En realidad, los costes de transacción corren íntegramente a cargo del emisor.

¿Cuáles son los objetivos de una transacción Stonewall?

La estructura Stonewall añade una enorme cantidad de entropía a la transacción, desdibujando las líneas del análisis de la cadena. Vista desde fuera, una transacción de este tipo podría interpretarse como una minicadena de monedas entre dos personas. Pero en realidad, es un pago. Por lo tanto, este método crea incertidumbres en el análisis de la cadena, o incluso conduce a pistas falsas.

Tomemos el ejemplo de Alicia en casa de Bob el panadero. La transacción en la cadena de bloques tendría este aspecto:

Un observador externo que se base en la heurística común de análisis de cadenas podría concluir erróneamente que "dos personas han realizado un pequeño coinjoin, con un UTXO cada una en la entrada y dos UTXOs cada una en la salida". Analizar esta transacción desde el exterior no conduce a la aplicación de la CIOH, ya que la presencia de dos salidas del mismo importe sugiere un patrón coinjoin. Por lo tanto, desde un punto de vista externo, la CIOH no es aplicable en este caso concreto.

Esta interpretación es inexacta, porque, como sabes, un UTXO fue enviado a Bob el panadero, las 2 entradas UTXO vinieron de Alice, y ella recuperó 3 salidas de intercambio.

Y lo que es particularmente interesante de la estructura de la transacción Stonewall es que, desde el punto de vista de un observador externo, se parece a la de una transacción Stonewall x2 en todos los sentidos.

La transacción Stonewall x2

Stonewall x2 es otra forma específica de transacción Bitcoin que también pretende aumentar la confidencialidad del usuario al realizar un gasto, pero esta vez colaborando con una tercera persona no implicada en dicho gasto. Este método funciona como un pseudo-coinjoin entre dos participantes, a la vez que se realiza un pago a una tercera persona.

El funcionamiento de la transacción Stonewall x2 es relativamente sencillo: utilizamos un UTXO en nuestro poder para realizar el pago, y conseguimos la ayuda de un tercero que también contribuye con un UTXO de su propiedad. La transacción termina con cuatro salidas: dos de ellas en cantidades iguales, una destinada a la dirección del beneficiario, la otra a una dirección perteneciente al colaborador. Un tercer UTXO se devuelve a otra dirección perteneciente al colaborador, lo que le permite recuperar la cantidad inicial (una acción neutra para él, módulo los costes de minería), y un último UTXO vuelve a una dirección perteneciente a nosotros, lo que constituye el intercambio de pago.

Así pues, en las transacciones Stonewall x2 se definen tres papeles diferentes:

El emisor, que realiza el pago efectivo ;
El destinatario, que puede desconocer la naturaleza específica de la transacción y simplemente espera el pago del remitente;
El colaborador, que pone a disposición bitcoins para poner en duda el análisis de la transacción, mientras recupera íntegramente sus fondos al final (una acción neutra para él, módulo los costes de minería).

Volvamos a nuestro ejemplo de Alice, que está en la panadería de Bob para comprar su baguette, que cuesta 4.000 sats. Ella quiere pagar en bitcoins, manteniendo un cierto nivel de confidencialidad con respecto a su pago. Así que llama a su amigo Charles, que la ayudará en este proceso.

Analizando esta transacción, podemos ver que Bob, el panadero, recibió en realidad 4.000 sats como pago por la baguette. Alice utilizó 10.000 sats en la entrada y recuperó 6.000 sats en la salida, es decir, un saldo neto de -4.000 sats, que corresponde al precio de la baguette. En cuanto a Charles, aportó 15.000 sats y obtuvo dos resultados: uno de 4.000 sats y otro de 11.000 sats, lo que arroja un saldo de 0.

En este ejemplo, he omitido intencionadamente las comisiones para que sea más fácil de entender. En realidad, las tasas mineras suelen repartirse a partes iguales entre el emisor del pago y el contribuyente.

¿Cuáles son los objetivos de una transacción Stonewall x2?

Al igual que la estructura Stonewall, la estructura Stonewall x2 añade una gran cantidad de entropía a la transacción y confunde el análisis de la cadena. Vista desde fuera, una transacción de este tipo puede interpretarse como una pequeña coinjoin entre dos personas. Pero en realidad, se trata de un pago. Por lo tanto, este método crea incertidumbres en el análisis de la cadena, o incluso conduce a pistas falsas.

Tomemos el ejemplo de Alicia, Bob el Panadero y Carlos. La transacción en la cadena de bloques tendría este aspecto:

Un observador externo que se base en la heurística común de análisis de cadenas podría concluir erróneamente que "Alice y Charles han realizado un pequeño coinjoin, con un UTXO cada uno en la entrada y dos UTXOs cada uno en la salida". De nuevo, analizar esta transacción desde fuera no conduce a la aplicación del ICOH, ya que la presencia de dos salidas de la misma cantidad sugiere un patrón coinjoin. Por lo tanto, desde un punto de vista externo, la CIOH no es aplicable en este caso concreto.

Esta interpretación es incorrecta, porque, como sabes, se ha enviado un UTXO a Bob el panadero, Alicia sólo tiene una salida de intercambio y Carlos tiene dos.

Y una vez más, lo que es particularmente interesante acerca de la estructura de la transacción Stonewall x2 es que, desde el punto de vista de un observador externo, se asemeja a la de una transacción Stonewall en todos los sentidos.

¿Cuál es la diferencia entre Stonewall y Stonewall x2?

Una transacción StonewallX2 funciona exactamente igual que una transacción Stonewall, salvo que la primera es colaborativa, mientras que la segunda no lo es. Como hemos visto, una transacción Stonewall x2 implica la participación de un tercero (Charles), externo al pago, que pondrá a disposición sus bitcoins para reforzar la confidencialidad de la transacción. En una transacción Stonewall clásica, el papel de colaborador lo asume el remitente.

Desde un punto de vista externo, el modelo de transacción es exactamente el mismo.

El hecho de que estas dos estructuras de transacciones compartan exactamente el mismo patrón significa que incluso si un observador externo consigue identificar un patrón "Stonewall(x2)", no dispondrá de toda la información. No podrá determinar a cuál de los dos UTXO de los mismos importes corresponde el pago. Además, no podrá determinar si los dos UTXO con entradas proceden de dos personas diferentes (Stonewall x2) o si pertenecen a una única persona que los ha fusionado (Stonewall).

Esto último se debe a que las transacciones Stonewall x2 siguen exactamente el mismo patrón que las transacciones Stonewall. Visto desde fuera, y sin información contextual adicional, es imposible diferenciar una transacción Stonewall de una transacción Stonewall x2. Las primeras no son transacciones en colaboración, mientras que las segundas sí lo son. Esto añade aún más dudas al análisis de una de estas transacciones.

¿Cuándo deben utilizarse las transacciones de Stonewall y Stonewall x2?

La lógica debería ser la siguiente cuando se desea utilizar una herramienta de confidencialidad para un gasto:

Como prioridad, podemos optar por hacer un payjoin;
Si el comerciante no admite payjoins, se puede realizar una transacción colaborativa con otra persona ajena al pago utilizando la estructura Stonewall x2;
Si no encuentras a nadie que haga una transacción Stonewall x2, puedes hacer una transacción sólo Stonewall, que imitará el comportamiento de una transacción Stonewall x2.

¿Cómo se utilizan las transacciones Stonewall y Stonewall x2?

Las transacciones Stonewall y Stonewall x2 están disponibles tanto en la aplicación Samourai Wallet como en el software Sparrow Wallet.

Sin embargo, al igual que con los payjoins, tras la detención de los fundadores de Samourai, las transacciones Stonewall x2 ahora sólo funcionan mediante el intercambio manual de PSBT entre las partes implicadas. Lamentablemente, el intercambio automático a través de Soroban ya no está disponible.

También es posible realizar este tipo de transacción manualmente desde cualquier software de monedero Bitcoin.

En el próximo capítulo, veremos otra técnica de confidencialidad relativamente desconocida, pero muy útil como complemento de lo que ya hemos estudiado.

https://planb.network/tutorials/privacy/on-chain/stonewall-033daa45-d42c-40e1-9511-cea89751c3d4

https://planb.network/tutorials/privacy/on-chain/stonewall-x2-05120280-f6f9-4e14-9fb8-c9e603f73e5b

Los rebotes

El uso de estructuras de transacción Bitcoin que añaden ambigüedad al análisis de la cadena, como coinjoin, es particularmente beneficioso para la protección de la privacidad. Sin embargo, como comentamos en el capítulo sobre payjoins, las transacciones coinjoin son naturalmente identificables en la cadena. Recuerde la analogía que establecimos entre el cifrado y los coinjoins: cuando se cifra un archivo, un tercero que descubre el archivo cifrado no puede acceder a su contenido, pero puede identificar claramente que el archivo se ha modificado para ocultar su contenido. Lo mismo ocurre con las coinjoins: cuando un analista examina una transacción coinjoin, aunque no pueda establecer vínculos directos entre las entradas y las salidas (y viceversa), puede sin embargo reconocer que la transacción observada es una coinjoin.

Dependiendo de cómo pretenda utilizar su pieza después de los ciclos coinjoin, el hecho de que haya sufrido este proceso puede ser problemático. Por ejemplo, si planeas vender tu moneda en una plataforma de intercambio regulada, pero ha sufrido recientemente un coinjoin, la herramienta de análisis de cadena de la plataforma detectará este hecho. La plataforma puede entonces negarse a aceptar su UTXO coinjoined, o incluso pedirle una explicación, con el riesgo de que su cuenta sea suspendida o sus fondos congelados. En algunos casos, la plataforma también puede denunciar su comportamiento a las autoridades estatales (esto es, por ejemplo, lo que TRACFIN exige a las PSAN en Francia).

Lo que necesitamos para evitar esto es una herramienta capaz de difuminar las huellas del pasado de una moneda Bitcoin, con el fin de restaurar alguna forma de fungibilidad. Este es precisamente el propósito del rebote.

¿Qué es un rebote?

El rebote es una técnica que consiste en realizar varias transacciones ficticias hacia uno mismo (barrido) para simular una transferencia de propiedad de bitcoin. Esta herramienta difiere de las demás estructuras de transacción que hemos analizado, en que no se obtiene un anonimato prospectivo, sino una forma de anonimato retrospectivo. En efecto, el rebote difumina las especificidades que pueden comprometer la fungibilidad de una moneda Bitcoin debido a su pasado.

Para suavizar la huella dejada por un evento pasado en una moneda, como los ciclos de coinjoin, ricochet ejecuta cuatro transacciones sucesivas en las que el usuario se transfiere fondos a sí mismo en diferentes direcciones.

Tras esta secuencia de transacciones, la herramienta de rebote encamina finalmente los bitcoins a su destino final, como una plataforma de intercambio.

El objetivo es crear una distancia que afecte a la fungibilidad de la moneda, como una transacción coinjoin, y el acto final de gasto, que podría rechazar esta moneda debido a su pasado. Así, las herramientas de análisis de cadenas podrían llegar a la conclusión de que probablemente hubo un cambio de titularidad después del acto, y considerar que esta moneda es fungible. En el caso de un coinjoin, las herramientas de análisis de la cadena de bloques podrían asumir entonces que no fue la misma persona la que envió los bitcoins y llevó a cabo el coinjoin, y que por tanto no tiene sentido emprender acciones contra el remitente.

¿Por qué funciona?

Ante este método de rebote, cabría imaginar que los programas informáticos de análisis de cadenas profundizaran en su examen más allá de cuatro rebotes. Sin embargo, estas plataformas se enfrentan a un dilema a la hora de optimizar el umbral de detección. Tienen que fijar un límite al número de saltos tras el cual aceptan que probablemente se ha producido un cambio de propiedad, y que debe ignorarse el vínculo con un evento anterior (como un coinjoin).

Sin embargo, fijar este umbral es arriesgado: cada ampliación del número de saltos observados aumenta exponencialmente el volumen de falsos positivos, es decir, individuos marcados erróneamente como participantes en un evento, cuando en realidad la operación fue realizada por otra persona. Este escenario supone un riesgo importante para estas empresas, ya que los falsos positivos provocan insatisfacción, lo que puede llevar a los clientes afectados a la competencia. A largo plazo, un umbral de detección demasiado alto lleva a una plataforma a perder más clientes que sus competidores, lo que podría amenazar su viabilidad. Por ello, es complicado para estas plataformas aumentar el número de rebotes observados, y 4 suele ser un número suficiente para contrarrestar sus análisis.

El fenómeno observado aquí es en cierto modo análogo a la teoría de los seis grados de separación.

La teoría de los seis grados de separación sugiere que cada persona en la Tierra está conectada a cualquier otra por una cadena de relaciones que comprende como máximo seis intermediarios. Por tanto, bastaría con pasar por una serie de seis personas, cada una de las cuales conociera personalmente a la siguiente, para llegar a cualquier individuo del mundo.

En el caso de las transacciones de Bitcoin, encontramos un fenómeno similar. Al rastrear un número suficiente de transacciones de Bitcoin, inevitablemente nos encontramos con un coinjoin. El método ricochet aprovecha este principio utilizando un número de saltos superior al que las plataformas de intercambio pueden rastrear razonablemente. Si las plataformas deciden rastrear más transacciones, entonces es posible simplemente añadir un salto extra para eludir esta medida.

¿Cuándo y cómo utilizar el rebote?

El caso de uso más común para el rebote se produce cuando es necesario ocultar una participación previa en un coinjoin en un UTXO de su propiedad. Lo ideal es evitar transferir bitcoins que hayan sido objeto de una coinjoin a entidades reguladas. No obstante, en el caso de que no te quede otra opción, sobre todo ante la necesidad urgente de liquidar bitcoins en moneda estatal, el ricochet ofrece una solución eficaz.

Este método es eficaz no sólo para las coinjoins, sino también para cualquier otra marca que pueda comprometer la fungibilidad de una pieza.

La idea de este método de rebote surgió originalmente de los equipos de Samourai Wallet, que lo integraron en su aplicación para automatizar el proceso. El servicio no es gratuito en Samourai, ya que un rebote implica una tasa de servicio de 100.000 sats, más los costes de minería. Por tanto, se recomienda su uso para transferencias de importes significativos.

La aplicación Samurai ofrece dos variantes de rebote:

Rebote reforzado, o "entrega escalonada", que ofrece la ventaja de repartir el coste del servicio Samurai entre las cinco transacciones sucesivas. Esta opción también garantiza que cada transacción se emita en un momento distinto y se registre en un bloque diferente, imitando al máximo el comportamiento de un cambio de propietario. Aunque más lento, este método es preferible para los que no tienen prisa, ya que maximiza la eficacia del rebote reforzando su resistencia al análisis en cadena;

El rebote clásico, concebido para ejecutar la operación con rapidez, difunde todas las transacciones en un intervalo de tiempo reducido. Este método, por tanto, ofrece menos confidencialidad y menos resistencia al análisis que el método reforzado. Sólo debe utilizarse para envíos urgentes.

Rebotear significa simplemente enviarse bitcoins a uno mismo. Es perfectamente posible ricochear bitcoins manualmente en cualquier software de monedero, sin necesidad de utilizar una herramienta especializada. Todo lo que tienes que hacer es transferirte sucesivamente la misma moneda a ti mismo, utilizando una nueva dirección en blanco cada vez.

En el próximo capítulo, examinaremos distintas técnicas de transferencia secreta de la propiedad. Estos métodos difieren radicalmente de los que hemos examinado hasta ahora, tanto en su funcionamiento como en sus resultados.

https://planb.network/tutorials/privacy/on-chain/ricochet-e0bb1afe-becd-44a6-a940-88a463756589

Transferencias secretas de propiedad

Otra de las técnicas de confidencialidad de Bitcoin es la transferencia secreta de propiedad. Este método tiene como objetivo transferir la propiedad de Bitcoins de una persona a otra, y viceversa, sin que la transacción sea explícitamente visible en la blockchain. Veamos las diferentes técnicas disponibles, junto con sus ventajas e inconvenientes.

El canje de monedas

Coinwap se basa en un concepto relativamente sencillo: utiliza contratos inteligentes para facilitar una transferencia de propiedad de bitcoins entre dos usuarios, sin necesidad de confianza y sin que esta transferencia sea explícitamente visible en la blockchain.

Imaginemos un ejemplo ingenuo con Alice y Bob. Alice tiene 1 BTC asegurado con la clave privada $A$ , y Bob también tiene 1 BTC asegurado con la clave privada $B$ . En teoría, podrían intercambiar sus claves privadas a través de un canal de comunicación externo para realizar una transferencia secreta.

Sin embargo, este método ingenuo presenta un alto riesgo en términos de confianza. Nada impide que Alice guarde una copia de la clave privada $A$ después del intercambio y la utilice más tarde para robar los bitcoins, una vez que la clave esté en manos de Bob.

Además, no hay ninguna garantía de que Alicia no reciba la clave privada $B$ de Bob y nunca transmita a cambio su clave privada $A$ . Por tanto, este intercambio se basa en una confianza excesiva entre las partes, y es ineficaz para garantizar una transferencia secreta segura de la propiedad.

Para resolver estos problemas y permitir los intercambios entre partes que no confían entre sí, vamos a utilizar en su lugar sistemas de contratos inteligentes. Un contrato inteligente es un programa que se ejecuta automáticamente cuando se cumplen unas condiciones predefinidas. En nuestro caso, esto garantiza que el intercambio de bienes se produzca automáticamente, sin necesidad de confianza mutua.

Esto puede lograrse utilizando HTLC (Contratos de bloqueo temporal de hash) o PTLC (Contratos de bloqueo temporal de puntos). Estos dos protocolos funcionan de forma similar, utilizando un sistema de bloqueo temporal que garantiza que el intercambio se complete con éxito o se cancele por completo, protegiendo así la integridad de los fondos de ambas partes. La principal diferencia entre HTLC y PTLC es que HTLC utiliza hashes y preimágenes para asegurar la transacción, mientras que PTLC utiliza Firmas Adaptadoras.

En un escenario de intercambio de monedas mediante HTLC o PTLC entre Alice y Bob, el intercambio se produce de forma segura: o bien tiene éxito y cada uno recibe el BTC del otro, o bien falla y cada uno conserva su propio BTC. Esto hace imposible que cualquiera de las partes haga trampas o robe el BTC de la otra.

HTLC es también el mecanismo utilizado para encaminar de forma segura los pagos a través de los canales bidireccionales de la Lightning Network El uso de firmas adaptadoras es especialmente interesante en este contexto, ya que permite prescindir de los scripts tradicionales (un mecanismo a veces denominado "scriptless scripts"). Esta característica reduce los costes asociados al intercambio. Otra gran ventaja de las Firmas Adaptadoras es que no requieren el uso de un hash común para ambas partes de la transacción, evitando así la necesidad de revelar un vínculo directo entre ellas en determinados tipos de intercambio.

Firmas de adaptadores

Las firmas adaptadoras son un método criptográfico que integra una firma válida con una firma adicional, denominada "firma adaptadora", para revelar datos secretos. Este mecanismo está diseñado de tal forma que el conocimiento de 2 de los 3 elementos siguientes: la firma válida, la firma adaptadora y el secreto, nos permite deducir el tercer elemento que falta. Una propiedad interesante de este método es que, si conocemos la firma del adaptador de nuestro par y el punto específico de la curva elíptica asociado al secreto utilizado para calcular esa firma del adaptador, podemos deducir nuestra propia firma del adaptador que será compatible con ese mismo secreto, sin tener nunca acceso directo al propio secreto.

En un intercambio de monedas, el uso de Firmas Adaptadoras permite la divulgación simultánea de dos piezas de información sensible entre los participantes, evitando así la necesidad de confianza mutua. Tomemos un ejemplo para ilustrar este proceso con Alice y Bob, que desean intercambiar la posesión de 1 BTC cada uno, pero no confían el uno en el otro. Utilizan Firmas Adaptadoras para eliminar la necesidad de confiar el uno en el otro en este intercambio. Así es como lo hacen:

Alice inicia el intercambio creando una transacción $m_A$ que envía 1 BTC a Bob. Ella genera una firma $s_A$ , que valida esta transacción, utilizando su clave privada $p_A$ ( $P_A = p_A \cdot G$ ), un nonce $n_A$ ( $N_A = n_A \cdot G$ ) y un secreto $t$ ( $T = t \cdot G$ ) :

$s_A = n_A + t + H(N_A + T \paralelo P_A \paralelo m_A) \cdot p_A$

Alice calcula la firma del adaptador $s_A'$ restando el secreto $t$ de su verdadera firma $s_A$ :

$s_A' = s_A - t$

Alice envía a Bob su adaptador de firma $s'_A$ , su transacción sin firma $m_A$ , el punto correspondiente al secreto ( $T$ ), y el punto correspondiente al nonce ( $N_A$ ). Estos elementos constituyen lo que se conoce como un "adaptador". Es importante señalar que, con sólo esta información, Bob no puede recuperar el BTC de Alice.
Sin embargo, Bob puede comprobar que Alice no está intentando robarle. Para ello, comprueba si la firma $s_A'$ del adaptador de Alice corresponde realmente a la transacción propuesta $m_A$ . Si la siguiente ecuación es correcta, entonces puede estar seguro de que el adaptador de firma de Alice es válido:

$s_A' \cdot G = N_A + H(N_A + T \paralelo P_A \paralelo m_A) \cdot P_A$

Esta verificación proporciona a Bob garantías suficientes de que puede continuar el intercambio con total confianza. A continuación, crea su propia transacción $m_B$ , destinada a enviar 1 BTC a Alice, y genera su firma adaptadora $s_B'$ , que también estará vinculada al mismo secreto $t$ . En esta fase, sólo Alice conoce el valor de $t$ ; Bob sólo conoce el punto correspondiente $T$ que Alice le ha transmitido:

$s_B' = n_B + H(N_B + T \paralelo P_B \paralelo m_B) \cdot p_B$

Bob envía a Alice su firma adaptadora $s_B'$ , su transacción sin firma $m_B$ , así como el punto correspondiente al secreto ( $T$ ) y el punto correspondiente al nonce ( $N_B$ ). Alice, que conoce el secreto $t$ , puede ahora combinar la firma adaptadora $s_B'$ de Bob con este secreto para generar una firma $s_B$ válida para la transacción $m_B$ que le transferirá el BTC de Bob:

$s_B = s_B' + t$

$(s_B' + t) \cdot G = N_B + T + H(N_B + T \paralelo P_B \paralelo m_B) \cdot P_B$

Alice difunde esta transacción firmada $m_B$ en la blockchain de Bitcoin para recuperar los BTC prometidos por Bob. Cuando Bob ve esta transacción en la blockchain, puede extraer la firma $s_B = s_B' + t$ . Con esta información, Bob puede aislar el famoso secreto $t$ que necesitaba:

$t = (s_B' + t) - s_B' = s_B - s_B'$

Y este secreto $t$ era el único elemento que le faltaba a Bob para generar la firma válida $s_A$ a partir de la firma adaptadora $s_A'$ de Alice. Esta firma valida la transacción $m_A$ , que envía un BTC de Alice a Bob. Bob calcula entonces $s_A$ y difunde la transacción $m_A$ en la blockchain:

$s_A = s_A' + t$

$(s_A' + t) \cdot G = N_A + T + H(N_A + T \paralelo P_A \paralelo m_A) \cdot P_A$

Resumamos cómo funciona un Adaptador de Firma en un coinswap. Inicialmente, Alice envía a Bob una transacción sin firmar acompañada de un adaptador, permitiendo a Bob verificar que el secreto revelado más tarde le dará acceso a bitcoins. A cambio, Bob envía a Alice su propia transacción sin firmar y su adaptador. Alice puede entonces finalizar la transacción de Bob y recuperar los bitcoins emitiendo una transacción válida gracias al secreto. Cuando esta transacción se publica en la blockchain, Bob tiene la capacidad de extraer el secreto y desbloquear así la transacción de Alice. En consecuencia, si Alice inicia una transferencia del bitcoin de Bob, Bob puede, a su vez, acceder al bitcoin de Alice sin necesidad de confianza mutua.

Tenga en cuenta que los coinswaps fueron propuestos por primera vez por Gregory Maxwell en octubre de 2013 en BitcoinTalk.

Canje atómico

De forma similar al coinswap, y utilizando los mismos tipos de contratos inteligentes, también es posible realizar swaps atómicos. Un swap atómico permite un intercambio directo de diferentes criptomonedas, como BTC y XMR, entre dos usuarios sin necesidad de confianza ni de la intervención de un intermediario. Estos intercambios se denominan "atómicos" porque sólo tienen dos resultados posibles: o bien el swap tiene éxito y ambas partes quedan satisfechas, o bien fracasa y cada uno conserva sus criptodivisas originales, eliminando la necesidad de confiar en la otra parte.

El swap atómico y el coinswap comparten un método de funcionamiento similar y ofrecen las mismas ventajas e inconvenientes en términos de confidencialidad. De hecho, desde el punto de vista de Bitcoin, un swap atómico es comparable a un coinswap realizado en dos etapas. Primero, cambiamos nuestro BTC por otra criptodivisa, luego esta criptodivisa puede cambiarse por otros BTC. Al final, recuperamos el BTC de otro usuario. Por eso, en el análisis de los problemas de confidencialidad, agrupo estos dos protocolos en la categoría de intercambios secretos propietarios.

Tenga cuidado, sin embargo, que a diferencia del coinswap, el swap atómico puede tener desequilibrios en términos de liquidez disponible, particularmente en los intercambios BTC/XMR. En general, es más fácil cambiar bitcoins por altcoins, ya que hay una fuerte demanda de bitcoins, lo que mantiene las primas bajas para esta dirección de conversión. Sin embargo, cambiar altcoins por BTC puede ser más complejo debido a la menor demanda, lo que a menudo se traduce en primas muy elevadas.

Por último, cuando un canje atómico implica bitcoins onchain y bitcoins en la red Lightning, hablamos de un "canje submarino".

¿Es realmente útil?

Las transferencias secretas de propiedad, como los canjes de monedas y los canjes atómicos, tienen la ventaja de engañar a la heurística de análisis de cadenas. Estos métodos pueden sugerir que las transacciones implican al mismo usuario, mientras que la propiedad real ha cambiado de manos. Sin embargo, el principal inconveniente de estos métodos es que son muy arriesgados sin el uso de una técnica adicional para romper el historial de la moneda.

En efecto, cuando Alice realiza un coinswap o un swap atómico con Bob, intercambia la posesión de sus bitcoins con los de Bob. En el caso de un intercambio atómico, el intercambio incluye una altcoin, pero el principio sigue siendo el mismo. Así, Alice acaba con la moneda $B$ y Bob con la moneda $A$ . Esto añade dudas al análisis de la cadena, pero la historia de las monedas sigue siendo rastreable. Si un analista examina la parte $A$ , puede rastrear las actividades previas de Alice, y viceversa para la parte $B$ .

Desde el punto de vista de Alice, el riesgo es que el historial de la moneda $B$ pueda ser considerado sospechoso por determinadas entidades. Si, por ejemplo, Bob hubiera adquirido la moneda $B$ mediante un acto delictivo como la piratería informática, la moneda quedaría vinculada a sus actividades ilegales. Alice podría entonces encontrarse en posesión de una moneda que no podría transferir a plataformas de intercambio reguladas sin arriesgarse a que sus fondos fueran congelados, o incluso a ser acusada de los delitos de Bob, aunque ella no tuviera nada que ver con ellos.

Inevitablemente, métodos de confidencialidad como el coinswap o el intercambio atómico son los preferidos por los delincuentes cuyos fondos están bajo vigilancia de las autoridades. Estos protocolos les permiten deshacerse de sus bitcoins bajo vigilancia a cambio de bitcoins perfectamente fungibles. También les permite crear una distracción, dirigiendo a las autoridades hacia otros usuarios. Así que hay un doble propósito para estas personas.

Con coinjoin, incluso si tu moneda se mezcla con bitcoins monitorizados, el historial de la moneda se rompe, proporcionando una forma de negación plausible que no existe en protocolos secretos de transferencia de propiedad como coinswap o atomic swap.

Si Alice desea evitar cualquier riesgo, debe utilizar necesariamente un método para romper el historial de la moneda $B$ , como pasarla por coinjoins. Esto plantea una cuestión sobre la utilidad de combinar la transferencia secreta de propiedad y el coinjoin. El coinjoin, al romper el historial de una moneda, ya ofrece un nivel de confidencialidad suficiente para Alice. Por lo tanto, mi opinión es que si Alice busca proteger su privacidad, sería más prudente proceder directamente a un coinjoin en lugar de realizar un coinswap seguido de un coinjoin.

Para que los métodos secretos de transferencia de propiedad sean realmente eficaces, y eviten el riesgo de vincular el historial de un usuario $A$ a un usuario $B$ , paradójicamente sería necesario que su uso fuera ampliamente conocido. Si el coinswap se utiliza masivamente y las autoridades son conscientes de esta práctica común, entonces podría establecerse una forma plausible de denegación. Sin embargo, mientras el uso de estas transferencias siga siendo marginal, creo que estos métodos seguirán siendo demasiado arriesgados para los usuarios.

Hasta ahora, hemos estudiado principalmente los métodos de confidencialidad a nivel de las propias transacciones. En el próximo capítulo, estudiaremos los problemas a nivel de la red y de la difusión de las transacciones.

Privacidad en la red P2P

En la Parte 4, hablamos de la importancia de utilizar un nodo completo para proteger la confidencialidad de tus transacciones. Sin embargo, es importante entender que tu nodo puede ser objeto de ataques que intenten extraer información sobre tus actividades. En este capítulo, por tanto, veremos las distintas medidas que puedes tomar para proteger tu privacidad, no a nivel de las transacciones en sí o de los flujos de bitcoin, sino a nivel de la red.

Diente de león

Una forma de evitar los diversos ataques de desanonimización es utilizar la propuesta Dandelion. Este protocolo de difusión se formalizó en BIP156, pero nunca se ha implementado en Bitcoin.

La idea detrás de Dandelion es mejorar la confidencialidad del enrutamiento de transacciones en la red Bitcoin para contrarrestar diversas formas de ataque. Su principal objetivo es ocultar el nodo de origen que emite inicialmente una transacción en la red. La revelación de este nodo podría hacer posible vincular una transacción Bitcoin a una dirección IP específica (si el nodo opera en la clearnet), lo que podría proporcionar un punto de entrada para el análisis de la cadena.

Esta asociación entre la actividad en Bitcoin y una dirección IP representa un riesgo considerable para la confidencialidad del usuario. De hecho, muchas entidades están en condiciones de vincular fácilmente una dirección IP a una identidad personal. Esto incluye gobiernos y proveedores de servicios de Internet. Es más, esta información puede ser de acceso público, por ejemplo, si su dirección IP y sus datos personales se filtran cuando la base de datos de un sitio web es pirateada.

En el funcionamiento clásico de Bitcoin, las transacciones creadas por un usuario en su software monedero se transmiten a su nodo personal. Este nodo transmitirá inmediatamente la nueva transacción a todos los pares a los que esté conectado.

A continuación, estos pares comprueban la transacción para asegurarse de que cumple las normas de consenso y normalización local. Una vez validada, cada par reenvía a su vez la transacción a sus pares, y así sucesivamente.

Esta distribución de las transacciones a la espera de ser integradas en un bloque es bastante equilibrada y estadísticamente previsible. Esta debilidad puede ser explotada por nodos espía cómplices, que colaboran para vigilar y analizar la red, con el fin de identificar el primer nodo que ha difundido una transacción. Si un observador consigue localizar el nodo de origen, puede suponer que la transacción procede del operador de ese nodo. Este tipo de observación puede utilizarse para vincular transacciones normalmente anónimas a direcciones IP concretas.

El objetivo de BIP156 es resolver este problema. Para ello, introduce una fase adicional en la difusión de una nueva transacción para preservar el anonimato antes de una amplia propagación pública. Dandelion utiliza en primer lugar una fase "madre" en la que la transacción se envía a través de una ruta aleatoria de nodos.

La transacción se transmite posteriormente a toda la red durante la fase de "Fluff".

El tallo y la fase de "Fluff" hacen referencia al comportamiento de la propagación de la transacción a través de la red, que se asemeja a la forma y evolución de un diente de león ("Dandelion" en inglés).

Así, los nodos espía pueden potencialmente rastrear la transacción hasta el nodo que inició la fase de "Fluff" (la difusión masiva), pero ese nodo no es el que la transmitió primero, ya que la recibió del último nodo del tallo. Si los nodos espía no pueden rastrear el tallo, tampoco pueden identificar el nodo fuente.

Incluso en presencia de nodos espía durante la fase de tallo, siempre queda una duda, porque en cuanto encuentran un nodo honesto en el grafo de difusión, los espías no pueden determinar si este nodo es la fuente original o simplemente un intermediario.

Este método de enrutamiento difumina el rastro que lleva hasta el nodo de origen, dificultando el seguimiento de una transacción a través de la red hasta su origen. Dandelion mejora así la confidencialidad al limitar la capacidad de los adversarios para desanonimizar la red. Este método es aún más eficaz cuando, durante la fase de "stemming", la transacción atraviesa un nodo que encripta sus comunicaciones de red, como ocurre con Tor o P2P Transport V2.

BIP156 no ha sido integrado en Bitcoin Core y actualmente está clasificado como "rechazado". Una de las principales preocupaciones con este protocolo es que, durante la fase de tallo, las transacciones deben ser retransmitidas a través de nodos intermedios antes de ser verificadas. Como hemos visto, en el modelo normal de Bitcoin, cada nodo verifica primero la transacción antes de retransmitirla a sus pares. Si una transacción no cumple las reglas de consenso del nodo o las reglas de estandarización local, el nodo la ignora y no la distribuye. Este proceso es importante para contrarrestar los ataques DoS, ya que sólo las transacciones válidas se difunden a toda la red. Las transacciones no válidas, potencialmente generadas en masa para sobrecargar la red, se detienen en el primer nodo encontrado y no se propagan. El principal riesgo de Dandelion es que este nuevo protocolo podría introducir nuevos vectores de ataques DoS al permitir la difusión de transacciones no válidas por parte de la red.

Transporte P2P V2

P2P transport V2 es otro protocolo de red presentado en BIP324. Es una nueva versión del protocolo de transporte P2P de Bitcoin que incorpora cifrado oportunista para mejorar la confidencialidad y seguridad de las comunicaciones entre nodos.

Esta mejora pretende resolver varios problemas de la versión básica del protocolo P2P. Por un lado, hace que los datos intercambiados sean indistinguibles de otros tipos de datos que circulan por Internet para un observador pasivo. El objetivo principal es evitar que gobiernos, ISP y proveedores de VPN vigilen masivamente a los usuarios de Bitcoin. Esto también hace más difícil para estas entidades determinar si un usuario de Internet es también un usuario de Bitcoin, es decir, si está operando un nodo completo.

P2P V2 también ayuda a reducir el riesgo de censura y ataques al detectar patrones específicos en los paquetes de datos. Complica y hace más costosa la ejecución de varios tipos de ataques Sybil a nivel de red. Un ataque Sybil se produce cuando un actor crea múltiples identidades falsas para obtener una ventaja injusta. En el contexto de la red Bitcoin, esto se manifiesta a menudo como un actor que controla un gran número de nodos completos y los utiliza agresivamente para multiplicar las conexiones. Los ataques Sybil pueden ser pasivos, para recopilar información y comprometer la confidencialidad de los usuarios, o activos, en forma de ataques Eclipse. Estos últimos aíslan un nodo específico del resto de la red, censurando al usuario o alterando los datos que recibe. Por último, P2P V2 también hace que los ataques Man-In-The-Middle (MITM) sean más costosos y fáciles de detectar.

El cifrado implementado por P2P V2 no incluye autenticación, para no añadir complejidad innecesaria ni comprometer el hecho de que la conexión a la red sigue siendo sin permisos. No obstante, este nuevo protocolo de transporte P2P ofrece una mayor seguridad contra los ataques pasivos, y hace que los ataques activos sean considerablemente más costosos y detectables. La introducción de un flujo de datos pseudoaleatorio en los mensajes de la red hace más difícil que los atacantes censuren o manipulen las comunicaciones.

El transporte P2P V2 se incluyó como opción (desactivado por defecto) en la versión 26.0 de Bitcoin Core, desplegada en diciembre de 2023. Posteriormente se habilitó por defecto en la versión 27.0 de abril de 2024. Puede modificarse con la opción v2transport= en el archivo de configuración.

Tor

Otra solución sencilla para evitar el riesgo de pérdida de confidencialidad de un nodo de la red es ejecutarlo completamente bajo Tor.

Tor es una red de servidores de retransmisión (nodos) que anonimiza el origen de las conexiones TCP en Internet. Funciona encapsulando los datos en varias capas de encriptación. Cada nodo de retransmisión elimina una capa para revelar la dirección del siguiente nodo, hasta llegar al destino final. La red Tor garantiza el anonimato impidiendo que los nodos intermediarios conozcan tanto el origen como el destino de los datos, lo que hace muy difícil para un observador rastrear la actividad de un usuario.

Tor no sólo encripta los datos, sino que también enmascara el origen y destino de las comunicaciones. Usando Tor para las comunicaciones desde su nodo personal, refuerza la confidencialidad de sus transacciones: su ISP no puede desencriptar las comunicaciones, y otros nodos de la red Bitcoin no pueden identificar la dirección IP del nodo de origen. Lo que es más, Tor también oculta su propio uso de Bitcoin a su ISP.

El principal riesgo de este método es que Tor es un protocolo independiente de Bitcoin. Si tiene un nodo Bitcoin ejecutándose bajo Tor y Tor deja de funcionar, entonces su nodo Bitcoin ya no podrá comunicarse.

También es importante tener en cuenta que las comunicaciones en Tor son más lentas. Esta latencia es particularmente molesta durante el lanzamiento inicial de un nodo, ya que IBD (Descarga Inicial de Bloques) requiere mucha comunicación. Como resultado, su sincronización inicial con la red Bitcoin podría tardar significativamente más usando Tor. También es posible realizar IBD en la clearnet, y luego activar Tor como segundo paso. Aunque este método revela la existencia de su nodo Bitcoin a su ISP, protege su información personal de transacciones una vez que cambia a Tor.

Una vez explorados los distintos métodos de confidencialidad a nivel de red, en los próximos capítulos también me gustaría presentarte dos elegantes soluciones para evitar la reutilización de direcciones: BIP47 y Silent Payments.

BIP47 y códigos de pago reutilizables

Como vimos en la parte 3, la reutilización de direcciones es un serio obstáculo para la confidencialidad del usuario en el protocolo Bitcoin. Para mitigar estos riesgos, se recomienda encarecidamente generar una dirección receptora en blanco para cada nuevo pago recibido en un monedero. Aunque generar una nueva dirección se ha simplificado con el uso de software moderno y monederos deterministas jerárquicos, esta práctica puede parecer contra-intuitiva.

En el sistema bancario tradicional, por ejemplo, estamos acostumbrados a compartir nuestro IBAN, que siempre es el mismo. Una vez que se lo hemos dado a alguien, puede enviarnos múltiples pagos sin tener que volver a interactuar con nosotros. Los neobancos también ofrecen posibilidades más modernas, como el uso de direcciones de correo electrónico únicas en PayPal o RevTags en Revolut. Incluso fuera del ámbito financiero, nuestros identificadores cotidianos, como nuestra dirección postal, número de teléfono y dirección de correo electrónico, también son únicos y permanentes. No tenemos que renovarlos en cada nueva interacción.

Sin embargo, Bitcoin funciona de forma diferente: para cada transacción entrante debe generarse una nueva dirección de recepción. Este compromiso entre facilidad de uso y confidencialidad se remonta a los orígenes mismos del Libro Blanco de Bitcoin. Ya desde la publicación de la primera versión de su documento a finales de 2008, Satoshi Nakamoto alertaba de este riesgo:

**Como cortafuegos adicional, podría utilizarse un nuevo par de claves para cada transacción a fin de mantenerlas desvinculadas de un propietario común

Hay muchas formas de recibir varios pagos en un mismo identificador sin tener que reutilizar una dirección. Cada una tiene sus propias ventajas e inconvenientes. Entre estos métodos se encuentra BIP47, una propuesta desarrollada por Justus Ranvier y publicada en 2015. Esta propuesta pretende crear códigos de pago reutilizables que permitan realizar múltiples transacciones contra la misma persona, evitando al mismo tiempo la reutilización de direcciones. En definitiva, BIP47 pretende ofrecer un sistema de pago tan intuitivo como un identificador único, preservando al mismo tiempo la confidencialidad de las transacciones.

BIP47 no mejora directamente la confidencialidad del usuario, ya que un pago BIP47 ofrece el mismo nivel de confidencialidad que una transacción Bitcoin clásica utilizando direcciones en blanco. Sin embargo, hace que el uso de Bitcoin sea más cómodo e intuitivo, una facilidad que normalmente comprometería la confidencialidad. Gracias a BIP47, esta facilidad de uso alcanza el mismo nivel de confidencialidad que una transacción clásica. Por eso BIP47 es una herramienta tan valiosa para preservar la privacidad.

Inicialmente, BIP47 se propuso para su integración en Bitcoin Core, pero nunca llegó a implementarse. Sin embargo, algunas aplicaciones de software optaron por implementarlo por su cuenta. Por ejemplo, los equipos de Samourai Wallet han desarrollado su propia implementación de BIP47 llamada "PayNym".

Principio general de BIP47 y PayNym

El objetivo de BIP47 es permitir recibir un gran número de pagos sin reutilizar direcciones. Se basa en la utilización de un código de pago reutilizable, que permite a diferentes emisores enviar varios pagos a un mismo código perteneciente a otro usuario. De este modo, el beneficiario no tiene que proporcionar una nueva dirección en blanco para cada transacción, lo que facilita enormemente los intercambios al tiempo que preserva la confidencialidad.

Así, un usuario puede compartir su código de pago con total libertad, ya sea en las redes sociales o en su sitio web, sin riesgo de perder la confidencialidad, a diferencia de lo que ocurre con una dirección de destinatario o una clave pública convencionales.

Para realizar una transacción, ambas partes necesitan un monedero Bitcoin con una implementación de BIP47, como PayNym en Samurai Wallet o Sparrow Wallet. El uso conjunto de sus códigos de pago crea un canal secreto entre ellos. Para establecer este canal de forma efectiva, el emisor debe llevar a cabo una transacción específica en la blockchain de Bitcoin, conocida como "transacción de notificación" (más sobre esto más adelante).

La combinación de los códigos de pago de los dos usuarios genera secretos compartidos, que a su vez crean un gran número de direcciones de recepción Bitcoin únicas (exactamente 2^32, es decir, unos 4.000 millones). De este modo, los pagos realizados a través de BIP47 no se dirigen realmente al código de pago en sí, sino a direcciones de recepción clásicas derivadas de los códigos de pago de los usuarios implicados.

El código de pago sirve así de identificador virtual derivado de la semilla de la cartera. En la estructura jerárquica de derivación de la cartera, el código de pago se sitúa en el nivel 3, es decir, en el nivel de cuenta.

El objetivo de derivación para el BIP47 se identifica mediante el índice 47 (0x8000002F), que hace referencia al BIP47. Un ejemplo de ruta de derivación para un código de pago reutilizable sería el siguiente:

m/47'/0'/0'/

Para que te hagas una idea de cómo es un código de pago, aquí tienes el mío:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

Este código también puede codificarse como código QR, para facilitar la comunicación, igual que una dirección de recepción convencional.

En cuanto a los PayNym Bots, los robots que a veces se ven en Twitter, son representaciones visuales del código de pago, creadas por Samourai Wallet. Se generan mediante una función hash, lo que les confiere un carácter casi único. Adoptan la forma de una pequeña cadena de caracteres que comienza por + :

+throbbingpond8B1
+twilightresonance487
+billowingfire340

Estos avatares también pueden representarse como imágenes:

Aunque estos robots no tienen ninguna funcionalidad técnica específica dentro del marco del PIF47, sí desempeñan un papel a la hora de facilitar la interacción con el usuario, ya que ofrecen una identidad visual fácilmente reconocible.

En las siguientes secciones de este capítulo dedicadas al BIP47, veremos en detalle cómo funciona, haciendo especial hincapié en los métodos criptográficos utilizados. Para comprender completamente estas explicaciones algo técnicas, es esencial entender primero la estructura de los monederos HD, los procedimientos de derivación de claves y los fundamentos de la criptografía de curva elíptica. Si desea profundizar en estos conceptos, hay otro curso de formación gratuito disponible en Plan ₿ Network :

https://planb.network/courses/46b0ced2-9028-4a61-8fbc-3b005ee8d70f

Aun así, te aconsejo que las sigas, porque entender el funcionamiento técnico del PIF47 te facilitará mucho la comprensión de otras propuestas similares, que trataremos en los siguientes capítulos

El código de pago reutilizable

Como ya se ha mencionado, el código de pago reutilizable se encuentra en la profundidad 3 del monedero HD, lo que lo hace comparable a un xpub, tanto por su posición en la estructura del monedero como por su función.

El código de pago de 80 bytes se desglosa del siguiente modo:

Byte 0: La versión**. Para la primera versión de BIP47, este byte se establece en 0x01;
Byte 1: El campo de bits**. Este espacio está reservado para integrar indicaciones adicionales para usos específicos. Para el uso clásico de PayNym, este byte se establece en 0x00 ;
El byte 2: La paridad de y**. Este byte es 0x02 o 0x03, indicando si la ordenada de la clave pública es par o impar, ya que se utiliza una clave pública comprimida;
Del byte 3 al byte 34: El valor de x**. Estos bytes representan la abscisa de la clave pública. La concatenación de x y la paridad de y forma la clave pública comprimida completa;
Del byte 35 al byte 66: El código de cadena**. Este espacio contiene el código de cadena asociado a la clave pública;
Del byte 67 al byte 79: El relleno**. Este espacio está pensado para posibles evoluciones futuras. Para la versión actual, simplemente colocamos ceros aquí para alcanzar el tamaño de 80 bytes requerido para la salida OP_RETURN.

He aquí la representación hexadecimal de mi código de pago reutilizable ya presentado en la sección anterior:

0x010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

A continuación, debe añadirse el byte de prefijo P al principio para indicar claramente que se trata de un código de pago. Este byte se representa mediante 0x47:

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

Por último, para garantizar la integridad del código de pago, se realiza un cálculo de suma de comprobación utilizando HASH256, que consiste en un hash doble utilizando la función SHA256. Los cuatro primeros bytes de este hash se concatenan al final del código de pago:

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000567080c4

Una vez realizados estos pasos, el código de pago está listo. Solo queda convertirlo a base 58 para obtener la versión final:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

En el proceso de creación del código de pago, utilizamos una clave pública comprimida y un código de cadena. Ambos se derivan de forma determinista y jerárquica a partir de la semilla del monedero. La ruta de derivación utilizada para lograrlo es :

m/47'/0'/0'/

En concreto, para generar la clave pública comprimida y el código de cadena asociado al código de pago reutilizable, empezamos calculando la clave privada maestra a partir de la semilla del monedero. A continuación, derivamos un par de claves hijas utilizando el índice 47 + 2^31 (derivación reforzada). A continuación, se derivan otros dos pares de claves hijas, cada uno de ellos utilizando el índice 2^31 (derivación reforzada).

Intercambio de claves Diffie-Hellman en curvas elípticas (ECDH)

El protocolo criptográfico en el que se basa BIP47 se conoce por las siglas ECDH, de Elliptic-Curve Diffie-Hellman. Este método es una variante del intercambio de claves Diffie-Hellman original.

Introducido en 1976, Diffie-Hellman es un protocolo de acuerdo de claves que permite a dos partes, cada una equipada con un par de claves (pública y privada), ponerse de acuerdo sobre un secreto común, incluso cuando se comunican sólo a través de un canal público no seguro.

Este secreto compartido (en este caso, la clave azul) puede utilizarse para otras operaciones. Normalmente, este secreto compartido puede utilizarse para cifrar y descifrar una comunicación en una red no segura:

Para ello, Diffie-Hellman utiliza la aritmética modular para calcular el secreto compartido. Así es como funciona en términos sencillos:

Alice y Bob acuerdan un color común, en este caso el amarillo, que son datos públicos (los atacantes conocen este color);
Alice selecciona un color secreto, en este caso el rojo, y mezcla los dos para obtener el naranja;
Bob también elige un color secreto, en este caso el azul, y lo mezcla con el amarillo para obtener el verde;
A continuación, intercambian los colores resultantes, naranja y verde. Este intercambio puede tener lugar en una red insegura y ser observado por atacantes;
Al mezclar el verde de Bob con su propio color secreto, Alice produce marrón;
Bob, haciendo lo mismo con el naranja y el azul secreto de Alice, también obtiene el marrón.

En esta popularización, el color marrón representa el secreto compartido por Alice y Bob. Imagina que, en realidad, es imposible para el atacante separar los colores naranja y verde, con el fin de encontrar los colores secretos de Alice o Bob.

Veamos ahora cómo funciona realmente este protocolo, no con analogías de colores, sino utilizando números reales y aritmética modular

Antes de entrar en los mecanismos Diffie-Hellman, permíteme recordarte brevemente dos conceptos matemáticos esenciales que necesitaremos:

Un número primo es un número natural que sólo tiene dos divisores: $1$ y él mismo. Por ejemplo, $7$ es un número primo porque sólo se puede dividir por $1$ y $7$ . En cambio, $8$ no es un número primo, ya que es divisible por $1$ , $2$ , $4$ y $8$ . Por lo tanto, tiene cuatro divisores enteros positivos en lugar de dos;
El módulo (denominado $mod$ o $\%$ ) es una operación matemática que, entre dos números enteros, devuelve el resto de la división euclídea del primero por el segundo. Por ejemplo, $16\bmod 5 =$ 1$.

El intercambio de claves Diffie-Hellman entre Alice y Bob tiene lugar de la siguiente manera:

Alice y Bob están de acuerdo en dos números comunes: $p$ y $g$ . $p$ es un número primo, y cuanto mayor sea el número, más seguro será Diffie-Hellman. $g$ es una raíz primitiva de $p$ . Estos dos números se pueden comunicar en una red no segura. Representan el equivalente de el color amarillo en la popularización anterior. Por lo tanto, es importante que Alice y Bob utilicen exactamente los mismos valores para $p$ y $g$ .
Una vez definidos estos parámetros, Alice y Bob eligen cada uno un número aleatorio secreto. Alice nombra su número aleatorio secreto $a$ (equivalente a el color rojo) y Bob nombra el suyo $b$ (equivalente a el color azul). Estos números deben permanecer secretos.
En lugar de intercambiar directamente los números $a$ y $b$ , cada parte calcula $A$ y $B$ de la siguiente manera:

$A$ es igual a $g$ elevado a la potencia $a$ modulo $p$ :

 $A = g^a \bmod p$

$B$ es igual a $g$ elevado a la potencia $b$ modulo $p$ :

 $B = g^b \bmod p$

Las dos partes intercambian los valores $A$ (equivalente a el color naranja) y $B$ (equivalente a el color verde). Este intercambio puede tener lugar en texto claro en una red no segura;
Alicia, tras recibir $B$ , calcula el valor de $z$ de la siguiente manera:

$z$ es igual a $B$ elevado a la potencia $a$ módulo $p$ :

 $z = B^a \bmod p$

Un recordatorio:

 $B = g^b \bmod p$

El resultado es :

 $z = B^a \bmod p$

 $z = (g^b)^a \bmod p$

Aplicando las reglas del poder :

 $(x^n)^m = x^{nm}$

El resultado es :

 $z = g^{ba} \bmod p$

Por su parte, Bob, tras recibir $A$ , también calcula el valor de $z$ de la siguiente manera:

$z$ es igual a $A$ elevado a la potencia $b$ módulo $p$ :

 $z = A^b \bmod p$

El resultado es :

 $z = (g^a)^b \bmod p$

 $z = g^{ab} \bmod p$

 $z = g^{ba} \bmod p$

Gracias a la distributividad del operador módulo, Alice y Bob obtienen exactamente el mismo valor $z$ . Este número representa su secreto común, equivalente a el color marrón en la popularización anterior con botes de pintura. Ahora pueden utilizar este secreto común para cifrar simétricamente sus comunicaciones a través de una red no segura.

Un atacante, incluso en posesión de $p$ , $g$ , $A$ y $B$ (los valores públicos), no podrá calcular $a$ , $b$ o $z$ (los valores privados). Para conseguirlo, habría que invertir la exponenciación, operación imposible sin probar una a una todas las posibilidades, ya que equivale a calcular el logaritmo discreto, es decir, el recíproco de la exponencial en un grupo cíclico finito.

Por tanto, siempre que los valores de $a$ , $b$ y $p$ sean lo suficientemente grandes, el protocolo Diffie-Hellman es seguro. Normalmente, con parámetros de 2048 bits (un número decimal de 600 dígitos), probar todas las posibilidades para $a$ y $b$ sería poco práctico. Hasta la fecha, con tales números, este algoritmo se considera seguro.

Aquí radica el principal inconveniente del protocolo Diffie-Hellman. Para ser seguro, el algoritmo debe utilizar números grandes. Por eso, hoy en día, preferimos utilizar el algoritmo ECDH (Elliptic Curve Diffie-Hellman), una variante de Diffie-Hellman basada en una curva algebraica, más concretamente en una curva elíptica. Este enfoque permite trabajar con números mucho más pequeños manteniendo una seguridad equivalente, lo que reduce los recursos necesarios para el cálculo y el almacenamiento.

El principio general del algoritmo sigue siendo el mismo. Sin embargo, en lugar de utilizar un número aleatorio $a$ y un número $A$ calculado a partir de $a$ mediante exponenciación modular, utilizamos un par de claves establecidas en una curva elíptica. En lugar de basarnos en la distributividad del operador módulo, utilizamos la ley de grupo en curvas elípticas, y más concretamente la asociatividad de esta ley.

Para explicar brevemente el principio de la criptografía en curvas elípticas, una clave privada está representada por un número aleatorio comprendido entre $1$ y $n-1$ , donde $n$ representa el orden de la curva. La clave pública, por su parte, es un punto concreto de esta curva, obtenido a partir de la clave privada sumando y duplicando puntos a partir del punto generador, según la ecuación :

 $K = k \cdot G$

En esta fórmula, $K$ designa la clave pública, $k$ la clave privada y $G$ el punto generador.

Una característica esencial de estas claves es la facilidad con la que se puede calcular $K$ a partir de $k$ y $G$ , mientras que es prácticamente imposible encontrar $k$ a partir de $K$ y $G$ . Esta asimetría crea una función unidireccional. En otras palabras, es fácil calcular la clave pública si se conoce la clave privada, pero recuperar la clave privada a partir de la pública es imposible. Esta seguridad se ve reforzada por la dificultad computacional del logaritmo discreto.

Utilizaremos esta propiedad para adaptar nuestro algoritmo Diffie-Hellman. El principio de funcionamiento del ECDH es el siguiente:

Alice y Bob acuerdan una curva elíptica criptográficamente segura y sus parámetros. Esta información es pública;
Alice genera un número aleatorio $ka$ que será su clave privada. Esta clave privada debe permanecer secreta. Determina su clave pública $Ka$ añadiendo y duplicando puntos en la curva elíptica elegida:

 $K_a = k_a \cdot G$

Bob también genera un número aleatorio $kb$ , que será su clave privada. Calcula la clave pública asociada $Kb$ :

 $K_b = k_b \cdot G$

Alice y Bob intercambian sus claves públicas $Ka$ y $Kb$ en una red pública no segura.
Alice calcula un punto $(x,y)$ en la curva aplicando su clave privada $ka$ a la clave pública de Bob $Kb$ :

 $(x,y) = k_a \cdot K_b$

Bob calcula un punto $(x,y)$ en la curva aplicando su clave privada $kb$ a la clave pública de Alice $Ka$ :

 $(x,y) = k_b \cdot K_a$

Alice y Bob obtienen el mismo punto en la curva elíptica. El secreto compartido será la abscisa $x$ de este punto.

Obtienen el mismo secreto compartido porque :

 $(x,y) = k_a \cdot K_b = k_a \cdot (k_b \cdot G) = (k_a \cdot k_b) \cdot G = (k_b \cdot k_a) \cdot G = k_b \cdot (k_a \cdot G) = k_b \cdot K_a$

Un atacante potencial que observe la red pública no segura sólo podrá obtener las claves públicas de cada individuo y los parámetros de la curva elíptica elegida. Como ya se ha explicado, esta información por sí sola no es suficiente para determinar las claves privadas. En consecuencia, el atacante no podrá encontrar el secreto compartido entre Alice y Bob.

ECDH es, por tanto, un algoritmo de intercambio de claves. A menudo se utiliza junto con otros métodos criptográficos para establecer un protocolo completo. Por ejemplo, ECDH es el núcleo de TLS (Transport Layer Security), un protocolo de cifrado y autenticación utilizado para la capa de transporte de Internet. TLS utiliza ECDHE para el intercambio de claves, una variante de ECDH en la que las claves son efímeras, para proporcionar confidencialidad persistente. Además, TLS utiliza algoritmos de autenticación como ECDSA, algoritmos de cifrado como AES y funciones hash como SHA256.

TLS es responsable de la s en https y del candado en la barra de direcciones de su navegador - símbolos de comunicaciones encriptadas. Al realizar este curso, estarás utilizando ECDH, y es muy probable que lo utilices a diario sin ni siquiera saberlo.

La operación de notificación

Como vimos en la sección anterior, ECDH es una variante del intercambio Diffie-Hellman que utiliza pares de claves establecidos sobre una curva elíptica. ¡Menos mal que ya tenemos muchos pares de claves que respetan este estándar en nuestros monederos Bitcoin! La idea de BIP47 es utilizar los pares de claves de los monederos Bitcoin deterministas jerárquicos de ambas partes para establecer secretos compartidos y efímeros entre ellos. BIP47 utiliza ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) en su lugar.

ECDHE se utiliza por primera vez en BIP47 para transmitir el código de pago del remitente al destinatario. Se trata de la famosa transacción de notificación. Este paso es esencial, porque para que BIP47 funcione eficazmente, ambas partes implicadas (emisor y receptor) necesitan conocer los códigos de pago del otro. Este conocimiento permite derivar claves públicas efímeras y, en consecuencia, las direcciones de recepción en blanco asociadas.

Lógicamente, antes de este intercambio, el remitente ya conoce el código de pago del destinatario, al haberlo obtenido fuera de la cadena, por ejemplo, de su sitio web, factura o redes sociales. Sin embargo, el destinatario no conoce necesariamente el código de pago del remitente. Sin embargo, el código debe serle transmitido; de lo contrario, no podrá obtener las claves efímeras necesarias para identificar las direcciones donde se almacenan sus bitcoins, ni acceder a sus fondos. Aunque esta transmisión del código del remitente puede realizarse técnicamente fuera de la cadena por otros medios de comunicación, esto plantea un problema si el monedero debe recuperarse únicamente de la semilla.

Esto se debe a que, a diferencia de las direcciones convencionales, las direcciones BIP47 no se derivan directamente de la semilla del destinatario -utilizar un xpub sería más sencillo en este caso-, sino que resultan de un cálculo que combina los dos códigos de pago: el del remitente y el del destinatario. Así, si el destinatario pierde su monedero e intenta recuperarlo a partir de su semilla, recuperará su propio código de pago, que se deriva directamente de su semilla. Sin embargo, para recuperar las direcciones efímeras, necesitará también los códigos de pago de todos aquellos que le hayan enviado bitcoins a través de BIP47. De ahí la importancia de la transacción de notificación, que permite guardar esta información en la blockchain de Bitcoin, pudiendo encontrarla muy fácilmente sin tener que buscar entre los mil millones de transacciones ejecutadas desde su lanzamiento en 2009.

Por tanto, sería posible aplicar el BIP47 sin utilizar la transacción de notificación, siempre que cada usuario guarde una copia de seguridad de los códigos de pago de sus compañeros. Sin embargo, este método resulta complejo de gestionar hasta que se desarrolle una solución sencilla, robusta y eficaz para realizar, almacenar y actualizar estas copias de seguridad. Tal como están las cosas, la transacción de notificación es casi inevitable.

En los capítulos siguientes, sin embargo, estudiaremos otros protocolos con objetivos similares al BIP47, pero que no requieren una transacción de notificación. Estas alternativas, sin embargo, introducen sus propias compensaciones.

Además de su función de guardar los códigos de pago, la transacción de notificación también tiene una función de notificación para el destinatario, como su nombre indica. Alerta al cliente del destinatario de que se ha establecido un nuevo túnel de pago y le sugiere que vigile las direcciones efímeras resultantes.

El modelo de confidencialidad BIP47

Antes de detallar el funcionamiento técnico de la operación de notificación, es importante hablar del modelo de confidencialidad asociado al PIF47, que justifica ciertas medidas adoptadas a la hora de crear esta operación inicial.

El código de pago en sí no supone un riesgo directo para la confidencialidad. A diferencia del modelo tradicional de Bitcoin, que pretende romper el vínculo entre la identidad del usuario y sus transacciones (que son públicas) preservando el anonimato de claves y direcciones, el código de pago puede asociarse abiertamente a una identidad sin suponer una amenaza.

Esto se debe a que el código de pago no se utiliza para derivar directamente las direcciones que reciben los pagos del BIP47. En su lugar, estas direcciones se generan a través de la aplicación ECDH entre las claves derivadas de los códigos de pago de las dos partes implicadas.

Así pues, un código de pago en sí mismo no conlleva directamente una pérdida de confidencialidad, ya que de él sólo se deriva la dirección de notificación. Aunque esta dirección puede revelar cierta información, normalmente no revela las partes con las que se está realizando la transacción, a menos que se lleve a cabo un análisis exhaustivo de la cadena. En efecto, si el remitente utiliza UTXO que pueden vincularse a su identidad para realizar la transacción de notificación, entonces es posible deducir que su identidad está probablemente vinculada a pagos BIP47 a su código de pago. Esto no revelará las transacciones subyacentes, pero indicará su probable existencia.

Por lo tanto, es esencial mantener esta separación estricta entre los códigos de pago de los usuarios. En este sentido, la comunicación inicial del código es un momento crítico para la confidencialidad del pago, pero esencial para el buen funcionamiento del protocolo. Si uno de los códigos de pago puede obtenerse públicamente (por ejemplo, en un sitio web), el segundo código, el del remitente, no debe en ningún caso estar vinculado al primero.

Pongamos un ejemplo concreto: Quiero hacer una donación a un movimiento político a través del BIP47 :

La organización ha hecho público su código de pago en su sitio web o a través de sus redes sociales;
Por tanto, este código está vinculado al movimiento político;
Me aparece este código de pago ;
Antes de enviar, tengo que asegurarme de que conocen mi propio código de pago, que también está vinculado a mi identidad, ya que lo utilizo para recibir transacciones en mis redes sociales.

¿Cómo puedo transmitir mi código sin riesgo? Utilizar los medios de comunicación convencionales podría provocar una fuga de información y, por tanto, asociarme a este movimiento político. La transacción de notificación ofrece una solución, gracias a una capa de cifrado que impide precisamente esa asociación entre dos códigos. Aunque no es el único método de transmisión secreta del código de pago del remitente, es muy eficaz.

En el diagrama siguiente, las líneas naranjas indican los puntos en los que debe interrumpirse el flujo de información, y las flechas negras muestran las conexiones potencialmente observables por terceros:

En realidad, en el modelo de confidencialidad tradicional de Bitcoin, a menudo es complejo disociar completamente el flujo de información entre el par de claves y el usuario, especialmente en transacciones remotas. Por ejemplo, en el contexto de una campaña de donaciones, el receptor debe inevitablemente revelar una dirección o clave pública a través de su página web o redes sociales. El uso correcto de BIP47, en particular con la transacción de notificación, permite sortear este problema gracias a ECDHE y a la capa de cifrado que veremos más adelante.

Por supuesto, el modelo clásico de confidencialidad de Bitcoin sigue aplicándose a las claves públicas efímeras, que se derivan de la combinación de los dos códigos de pago. De hecho, ambos modelos son complementarios. Lo que quiero destacar aquí es que, a diferencia del uso habitual de una clave pública para recibir Bitcoins, el código de pago puede vincularse a una identidad específica, ya que la información "Alice está realizando una transacción con Bob" se rompe en otra etapa. El código de pago se utiliza para generar direcciones de pago, pero basándonos únicamente en la observación de la blockchain, es imposible vincular una transacción de pago BIP47 a los códigos de pago utilizados para ejecutarla, a menos que los UTXO implicados ya estuvieran vinculados a una identidad previamente y los usuarios asociaran sus códigos de pago a sus respectivas identidades.

En resumen, el modelo de confidencialidad que ofrecen los pagos BIP47 podría considerarse superior al modelo básico de Bitcoin, aunque esto no significa que sea mágico.

Creación de la operación de notificación

Veamos ahora cómo funciona esta transacción de notificación. Imaginemos que Alicia desea enviar fondos a Bob utilizando el BIP47. En mi ejemplo, Alice actúa como remitente y Bob como receptor. Bob ha publicado su código de pago en su página web. Por lo tanto, Alice ya conoce el código de pago de Bob.

1- Alice calcula un secreto compartido con ECDH :

Ella selecciona un par de claves de su monedero HD en una rama diferente de su código de pago. Tenga en cuenta que este par no debe asociarse fácilmente con la dirección de notificación de Alice, ni con la identidad de Alice (véase la sección anterior);
Alice selecciona la clave privada para este par. La llamamos $a$ (minúscula);

$a$

Alice recupera la clave pública asociada a la dirección de notificación de Bob. Esta clave es el primer hijo derivado del código de pago de Bob (índice $/0$ ). Llamamos a esta clave pública $B$ (mayúsculas). La clave privada asociada a esta clave pública se denomina $b$ (minúscula). $B$ se determina sumando y duplicando puntos de la curva elíptica a partir de $G$ (el punto generador) con $b$ (la clave privada):

$B = b \cdot G$

Alice calcula un punto secreto $S$ (mayúsculas) en la curva elíptica sumando y duplicando puntos, aplicando su clave privada $a$ a partir de la clave pública $B$ de Bob.

$S = a \cdot B$

Alice calcula el factor de ocultación $f$ que se utilizará para cifrar su código de pago. Para ello, utiliza la función HMAC-SHA512 para determinar un número pseudoaleatorio. La segunda entrada de esta función es un valor que sólo Bob podrá encontrar: $x$ , que es la abscisa del punto secreto calculado anteriormente. La primera entrada es $o$ , que es el UTXO consumido como entrada de esta operación (punto de salida).

$f = \text{HMAC-SHA512}(o, x)$

**2 - Alice convierte su código de pago personal a base 2 (binario) **

3- Utiliza este factor cegador como clave para realizar un cifrado simétrico en la carga útil de su código de pago. El algoritmo de cifrado utilizado es simplemente un XOR. La operación realizada es comparable al cifrado Vernam, también conocido como "One-Time Pad".

Alice divide primero su factor cegador en dos: los primeros 32 bytes se llaman $f1$ y los últimos 32 bytes se llaman $f2$ . Esto nos da :

$f = f1 || f2$

Alice calcula el cifrado $x'$ de la abscisa de la clave pública $x$ de su código de pago, y el cifrado $c'$ de su código de cadena $c$ por separado. $f1$ y $f2$ actúan como claves de cifrado respectivamente. La operación utilizada es XOR (o exclusiva).

$x' = x \oplus f1$

$c' = c \oplus f2$

Alice sustituye los valores reales de la abscisa de la clave pública $x$ y el código de cadena $c$ en su código de pago por los valores cifrados $x'$ y $c'$ .

**Por lo tanto, Alice tiene actualmente su código de pago con una carga cifrada. Ella construirá y transmitirá una transacción que incluye su clave pública $A$ como entrada, una salida a la dirección de notificación de Bob, y una salida OP_RETURN que consiste en su código de pago con la carga cifrada. Esta transacción es la transacción de notificación.

Un OP_RETURN es un opcode que marca la salida de una transacción Bitcoin como inválida. Actualmente, se utiliza para emitir o anclar información en la cadena de bloques de Bitcoin. Puede almacenar hasta 80 bytes de datos, que luego se escriben en la cadena y son visibles para el resto de usuarios.

Como hemos visto en secciones anteriores, ECDH se utiliza para generar un secreto compartido entre dos usuarios que se comunican a través de una red insegura, y potencialmente observada por atacantes. En BIP47, ECDH se utiliza para comunicarse en la red Bitcoin, que por su propia naturaleza es una red de comunicación transparente, y es observada por muchos atacantes. El secreto compartido calculado mediante el intercambio de claves ECDH se utiliza después para cifrar la información secreta que se va a transmitir: el código de pago del remitente (Alice).

Resumiré los pasos que acabamos de ver para realizar juntos una operación de notificación:

Alice recupera el código de pago y la dirección de notificación de Bob;
Alice selecciona un UTXO de su cartera de HD con el par de claves correspondiente;
Calcula un punto secreto en la curva elíptica utilizando ECDH ;
Utiliza este punto secreto para calcular un HMAC, que es el factor cegador;
Utiliza este factor cegador para encriptar la carga útil de su código de pago personal;
Utiliza una salida de transacción OP_RETURN para comunicar el código de pago oculto a Bob.

Notificación de transacciones: estudio práctico

Para entender cómo funciona con más detalle, y en particular el uso de OP_RETURN, echemos un vistazo a una transacción de notificación real. Llevé a cabo una transacción de este tipo en la testnet, que puedes encontrar haciendo clic aquí.

Observando esta operación, ya podemos ver que tiene una sola entrada y 4 salidas:

La primera salida es el OP_RETURN que contiene mi código de pago oculto;
La segunda salida de 546 saturaciones apunta a la dirección de notificación de mi destinatario;
La tercera salida de 15.000 sats representa la tarifa de servicio, ya que utilicé Samourai Wallet para construir esta transacción;
La cuarta salida de 2 millones de sats representa el tipo de cambio, es decir, la diferencia restante de mi entrada que vuelve a otra dirección que me pertenece.

La más interesante de estudiar es obviamente la salida 0 usando OP_RETURN. Echemos un vistazo más de cerca a lo que contiene. Aquí está la scriptPubKey en hexadecimal :

6a4c50010002b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d800000000000000000000000000

Este script consta de varias partes. En primer lugar, el archivo :

6a4c

Entre los opcodes, podemos reconocer 0x6a que designa el OP_RETURN y 0x4c que designa el OP_PUSHDATA1.

El byte que sigue a este último opcode indica el tamaño de la carga útil posterior. Indica 0x50, u 80 bytes:

6a4c50

A continuación, tenemos los metadatos de mi código de pago en texto claro:

La abscisa cifrada de la clave pública de mi código de pago :

b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164

El código de cadena encriptada de mi código de pago :

927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d8

Y por último, el relleno a 80 bytes, el tamaño estándar de un OP_RETURN :

00000000000000000000000000

Para ayudarle a entender, aquí está mi código de pago en texto plano en base 58 :

PM8TJQCyt6ovbozreUCBrfKqmSVmTzJ5vjqse58LnBzKFFZTwny3KfCDdwTqAEYVasn11tTMPc2FJsFygFd3YzsHvwNXLEQNADgxeGnMK8Ugmin62TZU

Y en base 16 :

4701000277507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42add94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc000000000000000000000000008604e4db

Si comparamos mi código de pago en texto plano con el OP_RETURN, podemos ver que el HRP (0x47) y la suma de comprobación (0x8604e4db) no se transmiten. Esto es normal, ya que esta información está destinada a los humanos.

A continuación, podemos reconocer la versión (0x01), el campo de bits (0x00) y la paridad de la clave pública (0x02). Y, al final del código de pago, los bytes vacíos (0x000000000000000000000000000000) que permiten el relleno hasta alcanzar un total de 80 bytes. Todos estos metadatos se transmiten sin cifrar.

Finalmente, podemos observar que la abscisa de la clave pública (0x77507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42a) y el código de cadena (0xdd94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc) han sido encriptados. Esta es la carga útil del código de pago.

¿Qué es XOR?

Hemos visto en secciones anteriores que el código de pago se transmite cifrado mediante la operación XOR. Veamos más detenidamente cómo funciona este operador, ya que es muy utilizado en criptografía.

XOR es un operador lógico bit a bit basado en el álgebra de Boole. Dados dos operandos en bits, devuelve 1 si los bits del mismo rango son diferentes, y devuelve 0 si los bits del mismo rango son iguales. Aquí está la tabla de verdad XOR según los valores de los operandos D y E :

| D | E | D XOR E |

| --- | --- | ------- |

| 0 | 0 | 0 |

| 0 | 1 | 1 |

| 1 | 0 | 1 |

| 1 | 1 | 0 |

Por ejemplo:

 $0110 \oplus 1110 = 1000$

O :

 $010011 \oplus 110110 = 100101$

Con ECDH, el uso de XOR como capa de cifrado es especialmente coherente. En primer lugar, gracias a este operador, el cifrado es simétrico. Esto significa que el destinatario puede descifrar el código de pago con la misma clave utilizada para el cifrado. Las claves de cifrado y descifrado se calculan a partir del secreto compartido mediante ECDH. Esta simetría es posible gracias a las propiedades de conmutatividad y asociatividad del operador XOR:

Otras propiedades :

 $D \oplus D = 0$

 $D \oplus 0 = D$

Conmutatividad :

 $D \oplus E = E \oplus D$

Asociatividad :

 $D \oplus (E \oplus Z) = (D \oplus E) \oplus Z = D \oplus E \oplus Z$

Si :

 $D \oplus E = L$

Entonces..:

 $D \oplus L = D \oplus (D \oplus E) = D \oplus D \oplus E = 0 \oplus E = E \\ \therefore D \oplus L = E$

En segundo lugar, este método de cifrado es muy similar al cifrado de Vernam (One-Time Pad), el único algoritmo de cifrado conocido hasta la fecha que tiene seguridad incondicional (o absoluta). Para que el cifrado de Vernam tenga esta característica, la clave de cifrado debe ser perfectamente aleatoria, del mismo tamaño que el mensaje y utilizarse una sola vez. En el método de cifrado utilizado aquí para el BIP47, la clave es efectivamente del mismo tamaño que el mensaje, y el factor de cegamiento es exactamente del mismo tamaño que la concatenación de la abscisa de la clave pública con el código de cadena del código de pago. Esta clave de cifrado sólo se utiliza una vez. Por otra parte, esta clave no se deriva de una aleatoriedad perfecta, ya que se trata de un HMAC. Más bien, es pseudoaleatoria. Así que no es un cifrado Vernam, pero el método se le acerca.

Recepción de la operación de notificación

Ahora que Alice ha enviado la transacción de notificación a Bob, veamos cómo la interpreta Bob. Como recordatorio, Bob debe tener acceso al código de pago de Alice. Sin esta información, como veremos en la siguiente sección, no podrá derivar los pares de claves creados por Alice, y por tanto no podrá acceder a sus bitcoins recibidos vía BIP47. Por el momento, el código de pago de Alice está encriptado. Veamos como Bob lo desencripta.

1- Bob controla las transacciones que crean salidas con su dirección de notificación.

2- Cuando una transacción tiene una salida en su dirección de notificación, Bob la analiza para ver si contiene una salida OP_RETURN que cumpla con el estándar BIP47.

3- Si el primer byte de la carga OP_RETURN es 0x01, Bob comienza su búsqueda de un posible secreto compartido con ECDH :

Bob selecciona la clave pública de entrada para la transacción. Es decir, la clave pública de Alice denominada $A$ con :

$A = a \cdot G$

Bob selecciona la clave privada $b$ asociada a su dirección de notificación personal :

$b$

Bob calcula el punto secreto $S$ (secreto compartido ECDH) en la curva elíptica sumando y duplicando puntos, aplicando su clave privada $b$ a la clave pública de Alice $A$ :

$S = b \cdot A$

Bob determina el factor cegador $f$ que permitirá descifrar la carga útil del código de pago de Alice. Del mismo modo que Alice lo había calculado anteriormente, Bob hallará $f$ aplicando HMAC-SHA512 a $x$ , el valor de abscisa del punto secreto $S$ , y a $o$ , el UTXO consumido como entrada de esta operación de notificación:

$f = \text{HMAC-SHA512}(o, x)$

4- Bob interpreta los datos OP_RETURN de la transacción de notificación como un código de pago. Él simplemente descifrará la carga útil de este código de pago potencial utilizando el factor cegador $f$ :

Bob divide el factor cegador $f$ en 2 partes: los primeros 32 bytes de $f$ serán $f1$ y los últimos 32 bytes serán $f2$ ;
Bob descifra el valor de la abscisa cifrada $x'$ a partir de la clave pública del código de pago de Alice:

$x = x' \oplus f1$

Bob descifra el valor del código de cadena cifrado $c'$ del código de pago de Alice:

$c = c' \oplus f2$

5- Bob comprueba si el valor de la clave pública del código de pago de Alice forma parte del grupo secp256k1. Si es así, lo interpreta como un código de pago válido. Si no, ignora la transacción.

Ahora que Bob conoce el código de pago de Alice, ésta puede enviarle hasta 2^32 pagos, sin tener que repetir nunca una operación de notificación de este tipo.

¿Por qué funciona? ¿Cómo puede Bob determinar el mismo factor de ceguera que Alice, y así descifrar su código de pago? Veamos más de cerca la acción de ECDH en lo que acabamos de describir.

En primer lugar, se trata de un cifrado simétrico. Esto significa que la clave de cifrado y la clave de descifrado tienen el mismo valor. Esta clave en la operación de notificación es el factor cegador:

$f = f1 || f2$

Por lo tanto, Alice y Bob deben obtener el mismo valor para $f$ , sin transmitirlo directamente, ya que un atacante podría robarlo y descifrar la información secreta. Este factor de cegamiento se obtiene aplicando HMAC-SHA512 a 2 valores:

la abscisa de un punto secreto ;
y el UTXO consumido en la entrada de transacción.

Por lo tanto, Bob necesita estas dos piezas de información para descifrar la carga útil del código de pago de Alice. Para el UTXO de entrada, Bob puede simplemente recuperarlo observando la transacción de notificación. Para el punto secreto, Bob necesitará usar ECDH. Como se ha visto en la sección anterior sobre Diffie-Hellman, simplemente intercambiando sus respectivas claves públicas y aplicando en secreto sus claves privadas a la clave pública del otro, Alice y Bob pueden encontrar un punto secreto preciso en la curva elíptica. La operación de notificación se basa en este mecanismo:

El par de llaves de Bob :

$B = b \cdot G$

Par de claves de Alice :

$A = a \cdot G$

Para un secreto $S (x, y)$ :

$S = a \cdot B = a \cdot (b \cdot G) = (b \cdot a) \cdot G = b \cdot A$

Ahora que Bob conoce el código de pago de Alice, podrá detectar sus pagos BIP47, y podrá deducir las claves privadas que bloquean los bitcoins recibidos.

Resumiré los pasos que acabamos de ver juntos para recibir e interpretar una operación de notificación:

Bob controla la salida de transacciones a su dirección de notificación;
Cuando detecta uno, recupera la información contenida en el OP_RETURN ;
Bob selecciona la clave pública como entrada y calcula un punto secreto utilizando ECDH ;
Utiliza este punto secreto para calcular un HMAC, que es el factor cegador;
Utiliza este factor cegador para desencriptar la carga útil del código de pago de Alice contenida en el OP_RETURN.

La operación de pago BIP47

Veamos el proceso de pago con BIP47. Para recordar la situación actual :

Alice conoce el código de pago de Bob, que simplemente ha recuperado de su página web;
Bob conoce el código de pago de Alice por la transacción de notificación;
Alice hará su primer pago a Bob. Ella puede hacer muchos más de la misma manera.

Antes de explicar este proceso, creo que es importante recordar en qué índices estamos trabajando actualmente. La ruta de derivación de un código de pago se describe del siguiente modo: m/47'/0'/0'. La siguiente profundidad divide los índices de la siguiente manera:

El primer par hijo normal (no reforzado) es el que se utiliza para generar la dirección de notificación comentada en el apartado anterior: m/47'/0'/0'/0 ;
Los pares de claves hijas normales se utilizan dentro de ECDH para generar direcciones de recibos de pago BIP47, como veremos en esta sección: de m/47'/0'/0'/0 a m/47'/0'/0'/2.147.483.647 ;
Los pares de claves hijas reforzadas son códigos de pago efímeros: de m/47'/0'/0'/0' a m/47'/0'/0'/2.147.483.647'.

Cada vez que Alicia quiere enviar un pago a Bob, obtiene una nueva dirección única en blanco, una vez más utilizando el protocolo ECDH:

Alice selecciona la primera clave privada derivada de su código de pago personal reutilizable :

$a$

Alice selecciona la primera clave pública no utilizada derivada del código de pago de Bob. Llamaremos a esta clave pública $B$ . Está asociada a la clave privada $b$ que sólo conoce Bob:

$B = b \cdot G$

Alice calcula un punto secreto $S$ en la curva elíptica sumando y duplicando puntos aplicando su clave privada $a$ a partir de la clave pública de Bob $B$ :

$S = a \cdot B$

A partir de este punto secreto, Alice calcula el secreto compartido $s$ (en minúsculas). Para ello, selecciona la abscisa del punto secreto $S$ denominada $Sx$ , y pasa este valor a la función hash SHA256:

$S = (Sx, Sy)$

$s = \text{SHA256}(Sx)$

Alice utiliza este secreto compartido $s$ para calcular una dirección de recepción de pagos Bitcoin. En primer lugar, comprueba que $s$ se encuentra en el orden de la curva secp256k1. Si no es así, incrementa el índice de la clave pública de Bob para obtener otro secreto compartido ;
En un segundo paso, calcula una clave pública $K0$ sumando los puntos $B$ y $s-G$ de la curva elíptica. En otras palabras, Alice añade la clave pública derivada del código de pago de Bob $B$ a otro punto calculado en la curva elíptica sumando y duplicando puntos con el secreto compartido $s$ del punto generador de la curva secp256k1 $G$ . Este nuevo punto representa una clave pública, y lo llamamos $K0$ :

$K0 = B + s \cdot G$

Con esta clave pública $K0$ , Alice puede derivar una dirección de recepción en blanco de la forma estándar (por ejemplo, SegWit V0 en bech32).

Una vez que Alice ha obtenido la dirección de recepción $K0$ de Bob, puede llevar a cabo una transacción Bitcoin de la forma estándar. Para ello, ella elige un UTXO que posee, asegurado por un par de claves de una rama diferente de su monedero HD, y lo consume para satisfacer una salida a la dirección $K0$ de Bob. Es importante señalar que este pago, una vez derivada la dirección, sigue un proceso clásico y ya no depende de las claves asociadas al BIP47.

Voy a resumir los pasos que acabamos de ver juntos para enviar un pago BIP47:

Alice selecciona la primera clave privada hija derivada de su código de pago personal ;
Calcula un punto secreto en la curva elíptica utilizando ECDH a partir de la primera clave pública hija no utilizada derivada del código de pago de Bob;
Utiliza este punto secreto para calcular un secreto compartido con SHA256 ;
Utiliza este secreto compartido para calcular un nuevo punto secreto en la curva elíptica;
Añade este nuevo punto secreto a la clave pública de Bob;
Obtiene una nueva clave pública efímera de la que sólo Bob tiene la clave privada asociada;
Alice puede realizar una transacción clásica a Bob con la dirección de recepción efímera derivada.

Si Alice quiere hacer un segundo pago, seguirá los mismos pasos que antes, excepto que esta vez seleccionará la segunda clave pública derivada del código de pago de Bob. En concreto, utilizará la siguiente clave no utilizada. Ella obtendrá así una nueva dirección de recepción perteneciente a Bob, designada $K1$ :

Puede continuar así y obtener hasta 2^32 direcciones en blanco pertenecientes a Bob.

Desde una perspectiva externa, mirando la blockchain, es teóricamente imposible diferenciar un pago BIP47 de un pago convencional. He aquí un ejemplo de transacción de pago BIP47 en Testnet:

94b2e59510f2e1fa78411634c98a77bbb638e28fb2da00c9f359cd5fc8f87254

Parece una transacción clásica con una entrada consumida, una salida de pago y un tipo de cambio:

Recepción del pago BIP47 y derivación de la clave privada

Alice acaba de realizar su primer pago a una dirección BIP47 en blanco perteneciente a Bob. Veamos ahora cómo recibe Bob este pago. También veremos por qué Alice no tiene acceso a la clave privada de la dirección que ella misma acaba de generar, y cómo Bob encuentra esta clave para gastar los bitcoins que acaba de recibir.

En cuanto Bob recibe la transacción de notificación de Alice, obtiene la clave pública BIP47 $K0$ incluso antes de que su corresponsal haya enviado un pago. Por lo tanto, observa cualquier pago a la dirección asociada. De hecho, deriva inmediatamente varias direcciones que observa ( $K0$ , $K1$ , $K2$ , $K3$ ...). He aquí cómo deriva esta clave pública $K0$ :

Bob selecciona la primera clave privada hija derivada de su código de pago. Esta clave privada se denomina $b$ . Está asociada a la clave pública $B$ con la que Alice realizó sus cálculos en el paso anterior:

$b$

Bob selecciona la primera clave pública de Alice derivada de su código de pago. Esta clave se llama $A$ . Está asociada a la clave privada $a$ con la que Alice hizo sus cálculos, y que sólo Alice conoce. Bob puede llevar a cabo este proceso, ya que conoce el código de pago de Alice, que le fue enviado con la transacción de notificación:

$A = a \cdot G$

Bob calcula el punto secreto $S$ , sumando y duplicando puntos en la curva elíptica, aplicando su clave privada $b$ a la clave pública de Alice $A$ . También en este caso se utiliza ECDH para garantizar que este punto $S$ será el mismo tanto para Bob como para Alice:

$S = b \cdot A$

De la misma manera que Alice, Bob aísla la abscisa de este punto $S$ . Hemos llamado a este valor $Sx$ . Él pasa este valor a la función SHA256 para encontrar el secreto compartido $s$ (minúsculas):

$s = \text{SHA256}(Sx)$

Al igual que Alice, Bob calcula el punto $s-G$ de la curva elíptica. A continuación, añade este punto secreto a su clave pública $B$ . Entonces obtiene un nuevo punto en la curva elíptica, que interpreta como una clave pública $K0$ :

$K0 = B + s \cdot G$

Una vez que Bob tiene esta clave pública $K0$ , puede obtener la clave privada asociada para gastar sus bitcoins. Sólo él puede generar esta clave privada:

Bob suma la clave privada $b$ de su hija derivada de su código de pago personal. Sólo él puede obtener el valor de $b$ . A continuación, suma $b$ al secreto compartido $s$ para obtener $k0$ , la clave privada de $K0$ :

$k0 = b + s$

Gracias a la ley de grupo de la curva elíptica, Bob obtiene exactamente la clave privada correspondiente a la clave pública utilizada por Alice. Por tanto, tenemos :

$K0 = k0 \cdot G$

Resumiré los pasos que acabamos de ver para recibir un pago BIP47 y calcular la clave privada correspondiente:

Bob selecciona la primera clave privada hija derivada de su código de pago personal ;
Calcula un punto secreto en la curva elíptica utilizando ECDH a partir de la primera clave pública hija derivada del código de cadena de Alice;
Utiliza este punto secreto para calcular un secreto compartido con SHA256 ;
Utiliza este secreto compartido para calcular un nuevo punto secreto en la curva elíptica;
Añade este nuevo punto secreto a su clave pública personal;
Obtiene una nueva clave pública efímera, a la que Alice enviará su primer pago;
Bob calcula la clave privada asociada a esta clave pública efímera añadiendo su clave privada hija derivada de su código de pago y el secreto compartido.

Como Alicia no puede obtener $b$ (la clave privada de Bob), no puede determinar $k0$ (la clave privada asociada a la dirección de recepción BIP47 de Bob). Esquemáticamente, podemos representar el cálculo del secreto compartido $S$ de la siguiente manera:

Una vez encontrado el secreto compartido con ECDH, Alice y Bob calculan la clave pública de pago BIP47 $K0$ , y Bob también calcula la clave privada asociada $k0$ :

Devolución del pago del PIF47

Como Bob conoce el código de pago reutilizable de Alice, ya tiene toda la información que necesita para enviarle el reembolso. No necesitará volver a ponerse en contacto con Alice para pedirle ninguna información. Simplemente necesita notificárselo con una transacción de notificación, para que ella pueda recuperar sus direcciones BIP47 con su semilla, y entonces también podrá enviarle hasta 2^32 pagos.

La función de reembolso es específica de BIP47 y es una de sus ventajas frente a otros métodos, como los pagos silenciosos, que veremos en capítulos posteriores.

Bob puede entonces reembolsar a Alice de la misma manera que ella le envió los pagos. Los papeles se invierten:

*Muchas gracias a Fanis Michalakis por su corrección y asesoramiento experto sobre el artículo que inspiró la redacción de este capítulo

https://planb.network/tutorials/privacy/on-chain/paynym-bip47-a492a70b-50eb-4f95-a766-bae2c5535093

Pagos silenciosos

El BIP47 ha sido ampliamente criticado por su ineficiencia onchain. Como se ha explicado en el capítulo anterior, requiere que se realice una transacción de notificación para cada nuevo destinatario. Esta restricción se vuelve insignificante si planeamos establecer un canal de pago sostenible con este destinatario. De hecho, una sola transacción de notificación allana el camino para un número casi infinito de pagos BIP47 posteriores.

Sin embargo, en determinadas situaciones, la transacción de notificación puede ser un obstáculo para el usuario. Tomemos el ejemplo de una donación puntual a un beneficiario: con una dirección Bitcoin clásica, basta una sola transacción para completar la donación. Pero con BIP47, se necesitan dos transacciones: una para la notificación y otra para el pago en sí. Cuando la demanda de espacio en bloque es baja y las comisiones por transacción son bajas, este paso adicional no suele suponer un problema. Sin embargo, en momentos de congestión, las tarifas de transacción pueden llegar a ser exorbitantes para un solo pago, duplicando potencialmente el coste para el usuario en comparación con una transacción Bitcoin estándar, lo que puede resultar inaceptable para el usuario.

Para situaciones en las que el usuario planea realizar sólo unos pocos pagos a un identificador estático, se han desarrollado otras soluciones. Entre ellas se encuentra Silent Payments, descrito en BIP352. Este protocolo permite utilizar un identificador estático para recibir pagos sin producir reutilizaciones de direcciones, y sin requerir el uso de transacciones de notificación. Veamos cómo funciona este protocolo.

Para entender completamente este capítulo, es esencial dominar el funcionamiento de ECDH (Curva Elíptica Diffie-Hellman) y la derivación de claves criptográficas en un monedero HD. Estos conceptos fueron tratados en detalle en el capítulo anterior sobre BIP47. No los repetiré aquí. Si aún no estás familiarizado con estos conceptos, te recomiendo que consultes el capítulo anterior antes de continuar con éste. No volveré sobre los riesgos asociados a la reutilización de direcciones de recepción, ni sobre la importancia de tener un identificador único para recibir pagos. Sólo mencionaré algunos puntos que me gustaría destacar aquí

¿Por qué no trasladar la notificación?

Tal y como se explica en el capítulo BIP47, la operación de notificación tiene dos funciones principales:

Notifica al destinatario ;
Transmite el código de pago del remitente.

Se podría pensar ingenuamente que este proceso de notificación podría llevarse a cabo fuera de la cadena. En teoría, es perfectamente factible: todo lo que tendría que hacer el destinatario es indicar un medio de comunicación para recibir los códigos de pago BIP47 de los remitentes. Sin embargo, este planteamiento plantea dos problemas importantes:

En primer lugar, trasladaría el proceso de transmisión de códigos a otro protocolo de comunicación. Los problemas relacionados con el coste y la confidencialidad del intercambio seguirían existiendo, pero simplemente se trasladarían a este nuevo protocolo. En términos de confidencialidad, esto también podría crear un vínculo entre la identidad de un usuario y la actividad onchain, que es lo que pretendemos evitar realizando la notificación directamente en la blockchain. Además, realizar la notificación fuera de la blockchain introduciría riesgos de censura (como el bloqueo de fondos) que no existen en Bitcoin;
En segundo lugar, esto plantearía un problema de recuperación. Con BIP47, el receptor debe conocer los códigos de pago de los remitentes para poder acceder a los fondos. Esto es cierto en el momento de la recepción, pero también en caso de recuperación de los fondos a través de la semilla si se pierde el monedero. Con las notificaciones onchain, este riesgo se evita, ya que el usuario puede recuperar y descifrar las transacciones de la notificación simplemente conociendo su semilla. Sin embargo, si la notificación se realiza fuera de la blockchain, el usuario tendría que mantener una copia de seguridad dinámica de todos los códigos de pago recibidos, lo que resulta poco práctico para el usuario medio.

Todas estas limitaciones hacen que el uso de la notificación onchain sea esencial para el BIP47. Sin embargo, Silent Payments pretende evitar este paso de notificación onchain precisamente por su coste. Por tanto, la solución adoptada no es desplazar la notificación, sino eliminarla por completo. Para lograrlo, hay que aceptar un compromiso: el escaneado. A diferencia de BIP47, donde el usuario sabe exactamente dónde encontrar sus fondos gracias a las transacciones de notificación, con Silent Payments, el usuario tiene que examinar todas las transacciones Bitcoin existentes para detectar cualquier pago destinado a él. Para reducir esta carga operativa, la búsqueda de Silent Payments se limita únicamente a las transacciones susceptibles de contener dichos pagos, es decir, aquellas con al menos una salida Taproot P2TR. La búsqueda también se centra exclusivamente en transacciones a partir de la fecha de creación del monedero (no hay necesidad de buscar transacciones que se remontan a 2009 si el monedero se creó en 2024).

Así que ya ve por qué el BIP47 y los pagos silenciosos, aunque persiguen un objetivo similar, implican contrapartidas diferentes y, por tanto, responden en realidad a casos de uso distintos. Para pagos puntuales, como donaciones únicas, los pagos silenciosos son más apropiados por su menor coste. En cambio, para transacciones periódicas a un mismo destinatario, como en el caso de las plataformas de intercambio o los pools de minería, puede ser preferible el BIP47.

Veamos el funcionamiento técnico de los pagos silenciosos para comprender mejor lo que está en juego. Para ello, propongo que adoptemos el mismo enfoque que el documento explicativo del BIP352. Desglosaremos progresivamente los cálculos a realizar, elemento por elemento, justificando cada nuevo añadido.

Algunos conceptos que conviene comprender

Antes de empezar, es importante señalar que Silent Payments se basa exclusivamente en el uso de tipos de script P2TR (Pay to Taproot). A diferencia de BIP47, no es necesario derivar las direcciones receptoras de las claves públicas de los niños mediante hashing. En el estándar P2TR, la clave pública retocada se utiliza directamente y sin cifrar en la dirección. Así que una dirección de recepción Taproot es esencialmente una clave pública con algunos metadatos. Esta clave pública retocada es la agregación de otras dos claves públicas: una que permite el gasto directo y tradicional mediante una simple firma, y otra que representa la raíz Merkle del MAST, que autoriza el gasto sujeto a la satisfacción de una de las condiciones potencialmente inscritas en el árbol Merkle.

La decisión de limitar los pagos silenciosos exclusivamente a Taproot obedece a dos razones principales:

En primer lugar, facilita considerablemente la aplicación y las futuras actualizaciones del software de cartera, ya que sólo hay que respetar una norma;
En segundo lugar, este enfoque contribuye a mejorar la anonset de los usuarios, al animarles a no dividirse entre distintos tipos de scripts, que generan huellas dactilares de cartera distintas en el análisis en cadena (para más información sobre este concepto, consulte el capítulo 4 de la parte 2).

Derivación ingenua de una clave pública de Silent Payments

Empecemos con un ejemplo sencillo para entender cómo funcionan los pagos silenciosos. Tomemos a Alice y Bob, dos usuarios de Bitcoin. Alice desea enviar Bitcoins a Bob a una dirección de recepción en blanco. Este proceso tiene tres objetivos:

Alice debe ser capaz de generar una dirección en blanco;
Bob debe ser capaz de identificar un pago enviado a esta dirección específica;
Bob necesita obtener la clave privada asociada a esta dirección para poder gastar sus fondos.

Alice tiene un UTXO en su monedero seguro de Bitcoin con el siguiente par de claves:

$a$ : la clave privada ;
$A$ : la clave pública ( $A = a \cdot G$ )

Bob tiene una dirección SP que ha publicado en Internet con :

$b$ : la clave privada ;
$B$ : la clave pública ( $B = b \cdot G$ )

Al recuperar la dirección de Bob, Alice puede calcular una nueva dirección en blanco que pertenezca a Bob utilizando ECDH. Llamemos a esta dirección $P$ :

$P = B + \text{hash}(a \cdot B) \cdot G$

En esta ecuación, Alice simplemente ha calculado el producto escalar de su clave privada $a$ y la clave pública de Bob $B$ . Ha introducido este resultado en una función hash conocida por todos. El valor resultante se multiplica escalarmente por el punto generador $G$ de la curva elíptica secp256k1. Por último, Alice añade el punto resultante a la clave pública $B$ de Bob. Una vez que Alice tiene esta dirección $P$ , la utiliza como salida en una transacción, es decir, le envía bitcoins.

En el contexto de Silent Payments, la función "hash" corresponde a una función hash SHA256 etiquetada específicamente con BIP0352/SharedSecret, que garantiza que los hashes generados son exclusivos de este protocolo y no pueden reutilizarse en otros contextos, al tiempo que ofrece protección adicional contra la reutilización de nonces en las firmas. Esta norma corresponde a la especificada en BIP340 para firmas Schnorr en secp256k1. Gracias a las propiedades de la curva elíptica en la que se basa ECDH, sabemos que :

$a \cdot B = b \cdot A$

Por tanto, Bob podrá calcular la dirección receptora a la que Alice ha enviado los bitcoins. Para ello, supervisa todas las transacciones de Bitcoin que cumplen los criterios de Silent Payments y aplica el siguiente cálculo a cada una de ellas para ver si el pago va dirigido a él (escaneo):

$P' = B + \text{hash}(b \cdot A) \cdot G$

Cuando escanea la transacción de Alice, se da cuenta de que $P'$ es igual a $P$ . Por tanto, sabe que el pago va dirigido a ella:

$P' = B + \text{hash}(b \cdot A) \cdot G = B + \text{hash}(a \cdot B) \cdot G = P$

A partir de aquí, Bob podrá calcular la clave privada $p$ que permite gastar la dirección $P$ :

$p = (b + \text{hash}(b \cdot A)) \bmod n$

Como puedes ver, para calcular esta clave privada $p$ , debes tener la clave privada $b$ . Sólo Bob tiene esta clave privada $b$ . Por lo tanto, será el único capaz de gastar los bitcoins enviados a su dirección de Silent Payments.

Leyenda:

$B$ : La clave pública/dirección estática publicada por Bob
$b$ : Clave privada de Bob
$A$ : la clave pública UTXO de Alice utilizada como entrada de la transacción
$a$ : la clave privada de Alice
$G$ : Punto generador de la curva elíptica secp256k1
$\text{SHA256}$ : La función hash SHA256 etiquetada con BIP0352/SharedSecret
$s$ : El secreto común ECDH
$P$ : La clave pública/dirección única para el pago a Bob

He aquí un enfoque inicial bastante ingenuo para utilizar la dirección estática de Bob, anotada $B$ , para derivar una dirección única $P$ a la que enviar bitcoins. Sin embargo, este método es demasiado simplista y tiene varios defectos que deben corregirse. El primer problema es que, en este esquema, Alice no puede crear múltiples salidas hacia Bob dentro de la misma transacción.

¿Cómo puedo crear varias salidas?

En el ejemplo de la sección anterior, Alice crea una única salida que irá a Bob a su dirección única $P$ . Con la misma entrada seleccionada, es imposible que Alice cree dos direcciones en blanco distintas para Bob, ya que el método utilizado llevaría siempre al mismo resultado para $P$ , es decir, la misma dirección. Sin embargo, puede haber muchas situaciones en las que Alice desee dividir su pago a Bob en varias cantidades más pequeñas, creando así varios UTXOs. Por lo tanto, es necesario encontrar un método para conseguirlo.

Para conseguirlo, vamos a modificar ligeramente el cálculo que realiza Alice para obtener $P$ , de forma que pueda generar dos direcciones distintas para Bob, a saber, $P_0$ y $P_1$ .

Para modificar el cálculo y obtener 2 direcciones diferentes, basta con añadir un número entero que modifique el resultado. Así, Alicia añadirá $0$ a su cálculo para obtener la dirección $P_0$ y $1$ para obtener la dirección $P_1$ . Llamemos a este entero $i$ :

$P_i = B + \text{hash}(a \cdot B \text{ ‖ } i) \cdot G$

El proceso de cálculo no cambia respecto al método anterior, salvo que esta vez Alice concatenará $a \cdot B$ con $i$ antes de proceder al hash. A continuación, simplemente modificará $i$ para obtener una nueva dirección perteneciente a Bob. Por ejemplo:

$P_0 = B + \text{hash}(a \cdot B \text{ ‖ } 0) \cdot G$

$P_1 = B + \text{hash}(a \cdot B \text{ ‖ } 1) \cdot G$

Cuando Bob escanea la cadena de bloques en busca de pagos silenciosos destinados a él, empieza utilizando $i = 0$ para la dirección $P_0$ . Si no encuentra ningún pago en $P_0$ , concluye que esta transacción no contiene pagos silenciosos destinados a él y abandona la búsqueda. Sin embargo, si $P_0$ es válido y contiene un pago para él, continúa con $P_1$ en la misma transacción para comprobar si Alice ha realizado un segundo pago. Si $P_1$ resulta no ser válido, abandona la búsqueda de esta transacción; en caso contrario, continúa comprobando los sucesivos valores $i$ :

$P_0 = B + \text{hash}(b \cdot A \text{ ‖ } 0) \cdot G$

$P_1 = B + \text{hash}(b \cdot A \text{ ‖ } 1) \cdot G$

Dado que Bob se detiene inmediatamente en $i = 0$ si $P_0$ no funciona, el uso de este entero no añade casi ninguna carga operativa adicional a Bob para la etapa de exploración de transacciones.

Bob puede entonces calcular las claves privadas de la misma manera:

 $p_0 = (b + \text{hash}(b \cdot A \text{ ‖ } 0)) \bmod n$

 $p_1 = (b + \text{hash}(b \cdot A \text{ ‖ } 1)) \bmod n$

Leyenda:

$B$ : La clave pública/dirección estática publicada por Bob
$b$ : Clave privada de Bob
$A$ : la clave pública UTXO de Alice utilizada como entrada de la transacción
$a$ : la clave privada de Alice
$G$ : Punto generador de la curva elíptica secp256k1
$\text{SHA256}$ : La función hash SHA256 etiquetada con BIP0352/SharedSecret
$s_0$ : El primer secreto común ECDH
$s_1$ : El segundo secreto común ECDH
$P_0$ : La primera clave pública / dirección única para el pago a Bob
$P_1$ : La segunda clave pública / dirección única para el pago a Bob

Con este método, empezamos a tener un buen protocolo, pero aún quedan algunos retos por superar, entre ellos la prevención de la reutilización de direcciones.

¿Cómo evitar la reutilización de direcciones?

Como vimos en las secciones anteriores, Alice utiliza el par de claves que asegura su UTXO, que gastará para calcular el secreto compartido ECDH con Bob. Este secreto le permite obtener la dirección única $P_0$ . Sin embargo, el par de claves ( $a$ , $A$ ) utilizado por Alice puede asegurar varios UTXOs si ha reutilizado esta dirección varias veces. En el caso de que Alicia realice dos pagos a la dirección estática $B$ de Bob utilizando dos UTXOs asegurados por la misma clave $A$ , esto resultaría en una reutilización de la dirección para Bob.

La reutilización de direcciones es una muy mala práctica desde el punto de vista de la confidencialidad de los usuarios. Para saber por qué, te aconsejo que revises las primeras partes de este curso de formación. De hecho, como la dirección única $P_0$ se deriva de $A$ y $B$ , pues si Alice deriva una segunda dirección para un segundo pago a $B$ , con la misma clave $A$ , acabará exactamente en la misma dirección $P_0$ . Para evitar este riesgo y prevenir la reutilización de direcciones dentro de Silent Payments, tendremos que modificar un poco nuestros cálculos.

Lo que queremos es que cada UTXO consumido por Alice como entrada para un pago dé una dirección única en el lado de Bob, incluso si varios UTXOs están asegurados por el mismo par de claves. Así que todo lo que necesitamos hacer es añadir una referencia al UTXO al calcular la dirección única $P_0$ . Esta referencia será simplemente el hash del UTXO consumido como entrada:

$\text{inputHash} = \text{hash}(\text{outpoint} \text{ ‖ } A)$

Y Alice añadirá esta referencia a la entrada de su cálculo de la dirección única $P_0$ :

$P_0 = B + \text{hash}(\text{inputHash} \cdot a \cdot B \text{ ‖ } 0) \cdot G$

Al escanear, Bob también puede añadir $\text{inputHash}$ , ya que todo lo que tiene que hacer es observar la transacción para deducir $\text{outpoint}$ :

$P_0 = B + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0) \cdot G$

Cuando encuentra una $P_0$ válida, puede calcular la clave privada $p_0$ correspondiente:

 $p_0 = (b + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0)) \bmod n$

Leyenda:

$B$ : La clave pública/dirección estática publicada por Bob
$b$ : Clave privada de Bob
$A$ : la clave pública UTXO de Alice utilizada como entrada de la transacción
$a$ : la clave privada de Alice
$H$ : hash UTXO utilizado como entrada
$G$ : Punto generador de la curva elíptica secp256k1
$\text{SHA256}$ : La función hash SHA256 etiquetada con BIP0352/SharedSecret
$s_0$ : El primer secreto común ECDH
$P_0$ : La primera clave pública / dirección única para el pago a Bob

Por el momento, nuestros cálculos suponen que Alicia utiliza una única entrada para su transacción. Sin embargo, debería poder utilizar varias entradas. En consecuencia, por parte de Bob, para cada transacción que implique varias entradas, teóricamente debería calcular el ECDH de cada entrada para determinar si un pago va destinado a él. Este método no es satisfactorio, por lo que debemos encontrar una solución para reducir la carga de trabajo

Transformación de claves públicas en entradas

Para resolver este problema, en lugar de utilizar el par de claves que asegura una entrada específica en el lado de Alice, utilizaremos la suma de todos los pares de claves utilizados en las entradas de la transacción. Esta suma se considerará un nuevo par de claves. Esta técnica se conoce como "tweaking".

Por ejemplo, imaginemos que la transacción de Alice tiene 3 entradas, cada una asegurada con un par de claves diferente:

$a_0$ se utiliza para asegurar la entrada #0 ;
$a_1$ se utiliza para asegurar la entrada #1;
$a_2$ asegura la entrada #2.

Siguiendo el método descrito anteriormente, Alice tendría que elegir un único par de claves de entre $a_0$ , $a_1$ y $a_2$ para calcular el secreto ECDH y generar la dirección de pago única $P$ a partir de la dirección estática $B$ de Bob. Sin embargo, este enfoque requiere que Bob pruebe cada posibilidad secuencialmente, comenzando con $a_0$ , luego $a_1$ , y así sucesivamente, hasta que identifique un par que genere una dirección $P$ válida. Este proceso requiere que Bob ejecute el cálculo ECDH en todas las entradas de todas las transacciones, lo que aumenta considerablemente la carga operativa del escaneo.

Para evitar esto, le pediremos a Alice que calcule $P$ utilizando la suma de todas las claves de entrada. Usando nuestro ejemplo, la clave privada $a$ se calcularía de la siguiente manera:

$a = a_0 + a_1 + a_2$

Del mismo modo, Alice y Bob pueden calcular la clave pública modificada:

$A = A_0 + A_1 + A_2$

Con este método, Bob sólo necesita calcular la suma de las claves públicas de la transacción, y luego calcular el secreto ECDH a partir de $A$ solamente, lo que reduce enormemente el número de cálculos necesarios para la etapa de escaneo.

Sin embargo, recuerde la sección anterior. Habíamos añadido el hash $\text{inputHash}$ a nuestro cálculo, que se utiliza como nonce para evitar la reutilización de direcciones:

$\text{inputHash} = \text{hash}(\text{outpoint} \text{ ‖ } A)$

Pero si se tienen varias entradas en una operación, es necesario poder determinar qué $\text{outpoint}$ se elige en este cálculo. Según BIP352, el criterio de selección $\text{outpoint}$ a utilizar es elegir el más pequeño lexicográficamente, lo que significa seleccionar el UTXO que aparezca primero en orden alfabético. Este método estandariza el UTXO a elegir en cada operación. Por ejemplo, si este $\text{outpoint}$ lexicográficamente más pequeño es $\text{outpoint}_L$ , el cálculo de $\text{inputHash}$ será :

$\text{inputHash} = \text{hash}(\text{outpoint}_L \text{ ‖ } A)$

Los cálculos siguen siendo idénticos a los presentados en la sección anterior, salvo que la clave privada $a$ y su correspondiente clave pública $A$ ya no son un par utilizado para asegurar una sola entrada, sino que ahora representan el ajuste para todos los pares de claves en las entradas.

Claves de gasto y de escaneado separadas

Por el momento, nos hemos referido a la dirección estática de pago silencioso $B$ como una clave pública única. Recuerde que es esta clave pública $B$ la que Alice utiliza para crear el secreto compartido ECDH, que a su vez calcula la dirección de pago única $P$ . Bob utiliza esta clave pública $B$ y la correspondiente clave privada $b$ para la etapa de escaneo. Pero también utilizará la clave privada $b$ para calcular la clave privada $p$ que permite el gasto a partir de la dirección $P$ .

La desventaja de este método es que la clave privada $b$ , que se utiliza para calcular todas las claves privadas de las direcciones que han recibido pagos silenciosos, también es utilizada por Bob para escanear las transacciones. Este paso requiere que la clave $b$ esté disponible en un software monedero conectado a Internet, lo que la expone más al riesgo de robo que mantenerla en un monedero frío. Lo ideal sería poder aprovechar las ventajas de los pagos silenciosos manteniendo la clave privada $b$ , que controla el acceso a todas las demás claves privadas, segura en un monedero físico. Afortunadamente, el protocolo se ha adaptado para permitir precisamente eso.

Para ello, BIP352 requiere que el receptor utilice 2 pares de llaves diferentes:

b_{text{spend}}$: para calcular las claves privadas de direcciones de pago únicas;
b_{text{scan}}$: para encontrar direcciones de pago únicas.

De este modo, Bob puede conservar la clave privada $b_{text{spend}}$ en un monedero físico y utilizar la clave privada $b_{text{scan}}$ en un software en línea para encontrar sus pagos silenciosos, sin revelar $b_{text{spend}}$ . Por otro lado, las claves públicas $B_{text{scan}}$ y $B_{text{spend}}$$ se revelan públicamente, ya que se encuentran en la dirección estática de Bob$ B$ :

$B = B_{\text{scan}} \text{ ‖ } B_{\text{spend}}$

Para calcular una dirección de pago única $P_0$ perteneciente a Bob, Alice realizará ahora el siguiente cálculo:

$P_0 = B_{{texto{gasto}} + \text{hash}(\text{inputHash} \cdot a \cdot B_{text{scan}} \text{ ‖ } 0) \cdot G$

Para averiguar los pagos que le corresponden, Bob realizará el siguiente cálculo:

$P_0 = B_{{texto{gasto}} + \text{hash}(\text{inputHash} \cdot b_{text{scan}} \cdot A \text{ ‖ } 0) \cdot G$

Como puede ver, hasta ahora Bob no ha necesitado usar $b_{{text{spend}}$ , que está en su monedero hardware. Cuando quiera gastar $P_0$ , puede hacer el siguiente cálculo para encontrar la clave privada $p_0$ :

$p_0 = (b_{\text{spend}} + \text{hash}(\text{inputHash} \cdot b_{text{scan}} \cdot A \text{ ‖ } 0)) \bmod n$

Leyenda:

$B_{text{scan}}$ : clave pública de escaneo de Bob (dirección estática)
$b_{{text{scan}}$ : La clave privada de escaneo de Bob
$B_{text{spend}}$ : Clave pública de gasto de Bob (dirección estática)
$b_{\text{spend}}$ : La clave privada de gasto de Bob
$A$ : Suma de las entradas de clave pública (ajuste)
$a$ : La clave privada correspondiente a la clave pública modificada
$H$ : El hash del UTXO más pequeño (lexicográficamente) utilizado como entrada
$G$ : Punto generador de la curva elíptica secp256k1
$\text{SHA256}$ : La función hash SHA256 etiquetada con BIP0352/SharedSecret
$s_0$ : El primer secreto común ECDH
$P_0$ : La primera clave pública / dirección única para el pago a Bob

Utilización de direcciones SP con una etiqueta

Bob tiene por tanto una dirección estática $B$ para Pagos Silenciosos como :

$B = B_{\text{scan}} \text{ ‖ } B_{\text{spend}}$

El problema de este método es que no permite segregar los diferentes pagos enviados a esta dirección. Por ejemplo, si Bob tiene 2 clientes diferentes para su negocio, y quiere diferenciar los pagos a cada uno, necesitará 2 direcciones estáticas diferentes. Una solución ingenua, con el enfoque actual, sería que Bob creara dos carteras separadas, cada una con su propia dirección estática, o incluso establecer dos direcciones estáticas diferentes dentro de la misma cartera. Sin embargo, esta solución requiere escanear toda la cadena de bloques dos veces (una por cada dirección) para detectar los pagos destinados a cada dirección respectivamente. Este doble escaneo incrementa desmesuradamente la carga operativa de Bob.

Para resolver este problema, BIP352 utiliza un sistema de etiquetas que permite diferentes direcciones estáticas, sin aumentar desmesuradamente la carga de trabajo de encontrar pagos silenciosos en la blockchain. Para ello, añadimos un entero $m$ a la clave pública de gasto $B_{text{spend}}. Este entero puede tomar el valor de$ 1 $para la primera dirección estática, luego$ 2 $para la segunda, y así sucesivamente. Las claves de gasto$ B_{text{spend}} $se llamarán ahora$ B_m$ y se construirán de esta forma:

$B_m = B_{texto{gasto}} + \text{hash}(b_{text{scan}} \text{ ‖ } m) \cdot G$

Por ejemplo, para la primera tecla de gastos con la etiqueta $1$ :

$B_1 = B_{\text{spend}} + \text{hash}(b_{text{scan}} \text{ ‖ } 1) \cdot G$

La dirección estática publicada por Bob constará ahora de $B_{text{scan}}$ y $B_m$ . Por ejemplo, la primera dirección estática con la etiqueta $1$ será :

$B = B_{\text{scan}} \text{ ‖ } B_1$

Sólo empezamos desde la etiqueta 1 porque la etiqueta 0 está reservada para el cambio. Alice, por su parte, obtendrá la dirección de pago único $P$ de la misma forma que antes, pero utilizando el nuevo $B_1$ en lugar de $B_{text{spend}}$ :

$P_0 = B_1 + \text{hash}(\text{inputHash} \cdot a \cdot B_{text{scan}} \text{ ‖ } 0) \cdot G$

En realidad, Alice ni siquiera sabe necesariamente que Bob tiene una dirección etiquetada, ya que simplemente está utilizando la segunda parte de la dirección estática que él proporcionó, y en este caso, es el valor $B_1$ en lugar de $B_{text{spend}}$ .

Para escanear los pagos, Bob siempre utilizará el valor de su dirección estática inicial con $B_{{text{spend}}$ de esta forma:

$P_0 = B_{{texto{gasto}} + \text{hash}(\text{inputHash} \cdot b_{text{scan}} \cdot A \text{ ‖ } 0) \cdot G$

A continuación, simplemente resta el valor que encuentra para $P_0$ de cada salida una por una. A continuación, comprueba si uno de los resultados de estas restas coincide con el valor de una de las etiquetas que está utilizando en su cartera. Si, por ejemplo, la salida nº 4 coincide con la etiqueta $1$ , esto significa que esta salida es un Pago silencioso asociado a su dirección estáticamente etiquetada $B_1$ :

$Out_4 - P_0 = \text{hash}(b_{text{scan}} \text{ ‖ } 1) \cdot G$

Funciona porque :

$B_1 = B_{\text{spend}} + \text{hash}(b_{text{scan}} \text{ ‖ } 1) \cdot G$

Gracias a este método, Bob puede utilizar multitud de direcciones estáticas ( $B_1$ , $B_2$ , $B_3$ ...), todas ellas derivadas de su dirección estática básica ($B = B_{texto{escaneado}} \texto{ ‖ } B_{texto{gasto}}), con el fin de mantener el uso separado.

Tenga en cuenta, no obstante, que esta separación de direcciones estáticas sólo es válida desde el punto de vista de la gestión de la cartera personal, pero no separa identidades. Dado que todas tienen el mismo $B_{text{scan}}, es muy fácil asociar todas las direcciones estáticas y deducir que pertenecen a una única entidad.

Leyenda:

$B_{text{scan}}$ : clave pública de escaneo de Bob (dirección estática)
$b_{{text{scan}}$ : La clave privada de escaneo de Bob
$B_{texto{gasto}}$ : clave pública de gasto de Bob (dirección inicial)
$B_m$ : Clave pública de gasto de Bob etiquetada (dirección estática)
$b_m$ : la clave privada de gasto de Bob etiquetada como
$A$ : Suma de las entradas de clave pública (ajuste)
$a$ : La clave privada correspondiente a la clave pública modificada
$H$ : El hash del UTXO más pequeño (lexicográficamente) utilizado como entrada
$G$ : Punto generador de la curva elíptica secp256k1
$\text{SHA256}$ : La función hash SHA256 etiquetada con BIP0352/SharedSecret
$s_0$ : El primer secreto común ECDH
$P_0$ : La primera clave pública / dirección única para el pago a Bob
$p_0$ : La clave privada de la primera dirección única de pago a Bob
$X$ : El hash de la clave privada de exploración con la etiqueta

¿Cómo puedo crear una dirección de pagos silenciosos?

Para crear una dirección dedicada a Silent Payments, primero necesita obtener 2 pares de claves de su monedero Bitcoin HD:

El par $b_{text{scan}}$ , $B_{text{scan}}$ para buscar pagos dirigidos a nosotros;
El par $b_{text{spend}}$ , $B_{text{spend}}$ para pensar en los bitcoins que hemos recibido.

Estos pares se derivan utilizando las siguientes rutas (Bitcoin Mainnet):

scan : m / 352' / 0' / 0' / 1' / 0
spend : m / 352' / 0' / 0' / 0' / 0

Una vez que tenemos estos 2 pares de claves, simplemente los concatenamos (de extremo a extremo) para crear la carga útil de la dirección estática:

$B = B_{\text{scan}} \text{ ‖ } B_{\text{spend}}$

Si queremos utilizar etiquetas, sustituiremos $B_{texto{gasto}}$ por $B_m$ :

$B = B_{\text{scan}} \text{ ‖ } B_m$

Con etiqueta $m$ :

$B_m = B_{{texto{gasto}} + \text{hash}(b_{text{scan}} \text{ ‖ } m) \cdot G$

Una vez que tenemos esta carga útil, añadimos la HRP (Human-Readable Part) sp y la versión q (= versión 0). También añadimos una suma de comprobación y formateamos la dirección como bech32m.

Por ejemplo, aquí está mi dirección estática de Pagos Silenciosos:

sp1qqvhjvsq2vz8zwrw372vuzle7472zup2ql3pz64yn5cpkw5ngv2n6jq4nl8cgm6zmu48yk3eq33ryc7aam6jrvrg0d0uuyzecfhx2wgsumcurv77e

Un punto importante relativo a las direcciones estáticas, que puede haber comprendido en las secciones anteriores, es que estas direcciones no son visibles en las transacciones Bitcoin. Sólo las direcciones de pago $P$ utilizadas en las salidas aparecen en la blockchain en el formato estándar de Taproot. Así que, desde fuera, es imposible distinguir una transacción que implique Silent Payment de una transacción ordinaria que utilice salidas P2TR.

Al igual que con BIP47, es imposible establecer una conexión entre una dirección estática $B$ y una dirección de pago $P$ derivada de $B$ . De hecho, incluso si Eve, un atacante potencial, intenta escanear la cadena de bloques con la dirección estática $B$ de Bob, no podrá realizar los cálculos necesarios para determinar $P$ . Para ello, necesitaría la clave privada $b_{text{scan}} de Bob o las claves privadas$ a$ del remitente, pero ambas son privadas. Por lo tanto, es posible vincular explícitamente la dirección estática de uno con una forma de identidad personal.

¿Cómo se utiliza Silent Payments?

La propuesta de Pagos Silenciosos es relativamente reciente y por el momento sólo ha sido implementada por un número muy limitado de monederos. Que yo sepa, solo hay 3 productos de software que los admitan:

Pronto le ofreceremos un tutorial detallado sobre cómo configurar su propia dirección estática de pagos silenciosos.

Dado que esta función es nueva, le aconsejamos que actúe con cautela y evite utilizar Pagos silenciosos para grandes cantidades en mainnet.

Para crear este capítulo sobre los pagos silenciosos, he utilizado el sitio explicativo de los pagos silenciosos y el documento explicativo del PIF352.

Sección final

Opiniones y valoraciones

true

Examen final

true

Conclusión

true