Lo que le falta a Bitcoin y en quién confías para añadirlo

Curiosidad

1. ¿Por qué Bitcoin no tiene un equivalente a la ‘aprobación’ de tokens?
2. ¿Qué se pierde cuando un lenguaje de script se vuelve lo suficientemente expresivo como para compilar cualquier programa?
3. ¿Cómo puede existir un mercado sin una parte central que tenga las claves o establezca las reglas?

Explorar

Parte ILo que Bitcoin ya elimina y lo que le falta

1. Bitcoin elimina al administrador. No existen claves de administración, ni aprobaciones de tokens, ni contratos actualizables. La emisión está limitada a 21 millones de monedas y sigue un calendario predecible, con un subsidio que se reduce a la mitad cada 210,000 bloques. Las reglas solo cambian mediante un amplio consenso entre miles de nodos independientes. Este diseño elimina un tipo de ataques presente en otros sistemas: si no hay clave que robar ni contrato que actualizar, no hay nada que un administrador pueda explotar ni de lo que una empresa pueda apoderarse.
2. El modelo UTXO hace que cada gasto sea explícito. Una transacción consume salidas anteriores concretas y crea otras nuevas. No existen saldos de cuenta que un contrato pueda debitar más adelante. Esta estructura impide las aprobaciones tipo “drainer”, en las que un usuario firma un permiso amplio que permite a otra parte mover fondos ilimitados más tarde. Con el tipo de firma predeterminado (SIGHASH_ALL), la firma se compromete exactamente con esas entradas y salidas; otros modos de firma pueden dejar las salidas abiertas, y algunas estafas los han explotado. Si el usuario no firma la siguiente transacción, nada se mueve.
3. Lo que le falta a Bitcoin es expresividad y velocidad. Script está deliberadamente limitado; no puede realizar cálculos arbitrarios ni ejecutar bucles indefinidamente. Los bloques llegan aproximadamente cada diez minutos, lo que significa que la liquidación es lenta en comparación con las cadenas que generan bloques en segundos. No existe soporte nativo para tokens ni mercados dentro del protocolo de la capa base. Estas restricciones son compromisos intencionales: limitar lo que puede hacer el script evita que los errores se conviertan en exploits que rompan el consenso, y los bloques más lentos permiten una validación sólida por parte de una red descentralizada de nodos completos.
4. La pregunta de diseño es cómo añadir mercados sin reintroducir las debilidades que Bitcoin evitó. Añadir un lenguaje de scripting complejo conlleva vulnerabilidades en los contratos inteligentes. Añadir bloques rápidos suele requerir centralización o validadores autorizados para mantener la finalidad de las transacciones. La introducción de tokens nativos puede crear nuevas superficies de ataque para la inflación o la manipulación. Cualquier extensión debe preservar la propiedad de que ninguna entidad individual controle la emisión o las reglas del activo, incluso si eso significa aceptar un proceso de liquidación más lento o tarifas más altas.
5. Las soluciones de capa 2 y los metaprotocolos intentan cerrar esta brecha. Añaden funcionalidades como pagos rápidos o emisión de tokens, al tiempo que anclan la seguridad en el consenso de Bitcoin. Sin embargo, estas capas introducen nuevos modelos de confianza: algunos dependen de federaciones de firmantes; otros, de juegos de verificación optimistas en los que al menos un operador honesto debe impugnar el fraude. Cada enfoque equilibra de forma distinta diferentes aspectos de la descentralización y la velocidad. El objetivo no es convertir a Bitcoin en una computadora de uso general, sino ampliar su utilidad sin comprometer el modelo de seguridad fundamental que lo hizo resiliente.
6. Abre un explorador de bloques y busca cualquier transacción reciente. Examina las entradas y salidas. Observa cómo cada entrada hace referencia a una salida anterior específica mediante su ID de transacción y su índice. Ahora compáralo con una cadena basada en cuentas, donde los saldos son simplemente números en un estado global. La diferencia es estructural: el modelo de Bitcoin obliga a que todo movimiento de valor sea explícito, auditable y esté vinculado a una firma específica, sin dejar espacio para anulaciones administrativas ocultas ni permisos amplios.

Parte IILas capas 2 de Bitcoin y sus modelos de confianza

7. Los canales de Lightning Network amplían la capacidad de pago de Bitcoin sin transferir las monedas a un custodio. El whitepaper de Joseph Poon y Thaddeus Dryja se redactó por primera vez en 2015 y se publicó en su forma definitiva en 2016; su uso en la red principal llegó en 2018. Cada canal bloquea los fondos en un estado compartido entre dos partes; si una de ellas hace trampa, la otra transmite a Bitcoin una transacción de penalización. Este modelo minimiza la confianza, ya que ningún tercero posee las claves, pero sigue siendo punto a punto. Resuelve la finalidad de los pagos, no la liquidez compartida ni la creación de mercado.
8. Liquid, lanzado por Blockstream en 2018, funciona como una cadena lateral federada. Un grupo fijo de “funcionarios” (functionaries) firma los bloques y gestiona el peg entre los activos de Liquid y el bitcoin de la capa base. Se genera un bloque cada minuto y la liquidación es definitiva en unos dos minutos; además, los activos pueden emitirse de forma nativa. El compromiso es explícito: los usuarios deben confiar en que una supermayoría de funcionarios (el peg utiliza una multifirma 11 de 15) no se coludirá para robar los depósitos o detener los reembolsos. Es rápido, pero vuelve a introducir un grupo de confianza.
9. Stacks opera su propia cadena, anclada a Bitcoin mediante el registro de los hashes de sus bloques en transacciones de Bitcoin (Prueba de Transferencia). Su peg sBTC, abierto a depósitos desde diciembre de 2024 y a retiros desde abril de 2025, emite tokens respaldados por bitcoin nativo bloqueado y gestionado por un conjunto de firmantes. Este enfoque permite contratos inteligentes expresivos en Stacks (en Clarity, un lenguaje deliberadamente decidible), mientras que un conjunto de firmantes, de los cuales un umbral debe aprobar los retiros, custodia los bitcoins. Los usuarios obtienen flexibilidad de ejecución a cambio de depender de la integridad del conjunto de firmantes y de la continuidad operativa del puente.
10. BitVM representa una elección arquitectónica diferente, cuyo objetivo es llevar la computación general a Bitcoin sin necesidad de soft forks. La propuesta de Robin Linus de 2023 utilizaba la verificación optimista entre dos partes; BitVM2 (2024) permite que cualquiera presente un desafío. Proyectos como Citrea, operativo desde enero de 2026, se basan en este modelo, en el que un solo participante honesto entre muchos puede detener el fraude. Este modelo de “honestidad 1-de-n” traslada la confianza del consenso mayoritario a la presencia de un único desafiante vigilante, pero los operadores deben bloquear o adelantar capital, y los retiros deben esperar a que concluyan los períodos de desafío.
11. Al comparar estos modelos se revelan perfiles de riesgo distintos. Lightning no requiere terceros, pero ofrece una utilidad limitada para mercados compartidos. Liquid y Stacks dependen de federaciones o conjuntos de firmantes, donde la colusión representa la amenaza principal. Los rollups de BitVM dependen de la honestidad competitiva entre los operadores. La variable crítica en todos los casos es la custodia: quién posee las claves privadas del bitcoin subyacente y qué sucede si esa entidad falla, es hackeada o decide defraudar.
12. Los mecanismos de salida definen el verdadero modelo de confianza. En Lightning, salir implica cerrar el canal en la cadena; si la otra parte no responde, los fondos se recuperan tras un timelock. En Liquid o Stacks, la salida requiere una solicitud de canje procesada por la federación o los firmantes; si estos la demoran o se niegan, los usuarios quedan atrapados. En los puentes BitVM, la salida depende de que al menos un operador activo pague al usuario; las solicitudes de reembolso de los operadores pasan luego por un período de impugnación. Un usuario que no puede salir sin confiar en un tercero no está realmente en autocustodia, por muy descentralizada que parezca la red.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• S. Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• BIP-341: Taproot (activated 2021)
• J. Poon & T. Dryja, 'The Bitcoin Lightning Network' (2016)
• Blockstream Liquid Documentation
• Stacks sBTC Technical Documentation (December 2024)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023)