¿Qué es el lenguaje de script de Bitcoin?

El script de Bitcoin es el lenguaje de programación que controla todas las transacciones de la red Bitcoin. Se trata de un lenguaje sencillo, basado en una pila, que define las condiciones exactas en las que se pueden gastar bitcoins, y todos los nodos completos de la red lo ejecutan cada vez que se valida una transacción. Sin él, Bitcoin no sería más que un libro mayor de números sin ningún mecanismo que garantizara quién es el propietario de qué.

La mayoría de los usuarios nunca ven directamente el lenguaje de scripting de Bitcoin. Sus carteras se encargan de ello de forma invisible. Pero cada vez que envías o recibes BTC, se ejecutan simultáneamente dos pequeños programas en miles de ordenadores, que comprueban si se han cumplido las condiciones de gasto. Entender cómo funciona esto explica en gran medida por qué Bitcoin está estructurado de la forma en que lo está, y qué puede y qué no puede hacer en comparación con plataformas como Ethereum.

Este artículo explica cómo funciona Bitcoin Script, repasa los principales tipos de transacciones que permite, describe la actualización Taproot que modernizó la capa de scripting en 2021 y analiza cuál es la situación actual del debate sobre el opcode «covenant» a fecha de junio de 2026.

Gestiona tus bitcoins de forma segura con la autocustodia Aplicación Bitcoin.com Wallet.

Puntos clave

• Bitcoin Script es un lenguaje de programación basado en pilas integrado en el protocolo de Bitcoin que define las condiciones en las que se puede gastar cualquier salida de bitcoins.
• Cada transacción de Bitcoin incluye dos scripts: un script de bloqueo (ScriptPubKey) establecido por el destinatario y un script de desbloqueo (ScriptSig) proporcionado por el remitente. Ambos deben ejecutarse correctamente para que la transacción sea válida.
• Bitcoin Script no es, de forma intencionada, Turing completo. No tiene bucles, no mantiene un estado persistente entre ejecuciones y tiene límites estrictos en cuanto al tamaño de los scripts. Esto garantiza que todos los scripts lleguen a su fin, lo cual es una característica de seguridad, no una limitación.
• El lenguaje de scripting ha evolucionado a través de cinco formatos principales: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) y Taproot (P2TR), cada uno de los cuales amplía las posibilidades sin dejar de ser compatible con versiones anteriores.
• Taproot (noviembre de 2021) introdujo las firmas Schnorr, las rutas de gasto basadas en MAST para garantizar la privacidad y Tapscript, un lenguaje de scripting actualizado con un mecanismo integrado que permite realizar actualizaciones futuras de forma más sencilla.
• Entre los casos de uso reales basados en Bitcoin Script se incluyen las carteras con múltiples firmas, las transacciones con bloqueo temporal, los contratos con bloqueo temporal de hash (la base de Lightning), los servicios de depósito en garantía y los contratos de registro discreto.
• A diferencia de los contratos inteligentes de Ethereum, Bitcoin Script carece de estado: cada script se ejecuta de forma totalmente aislada, sin tener conocimiento de ninguna otra transacción. Se trata de una elección arquitectónica deliberada.
• El ámbito más activo del desarrollo de Bitcoin Script en 2026 es el de los opcodes de covenant, en particular OP_CTV (BIP-119) y OP_CAT (BIP-347), que permitirían a los scripts establecer restricciones sobre cómo debe ser una transacción de gasto. Ninguno de los dos se ha activado todavía en la red principal.

¿Qué es Bitcoin Script?

Bitcoin Script es un lenguaje de scripting sin estado y basado en pila integrado en el protocolo de Bitcoin. Cada salida de transacción en la red de Bitcoin lleva asociado un script de bloqueo (denominado ScriptPubKey) que especifica las condiciones para gastar los fondos. Cualquiera que desee gastar esos fondos debe proporcionar un script de desbloqueo (denominado ScriptSig o, en las transacciones SegWit y Taproot, los datos de testigo) que cumpla dichas condiciones.

El lenguaje toma su estructura de Forth, un lenguaje de programación minimalista basado en una pila desarrollado en la década de 1960. Al igual que Forth, Bitcoin Script se lee de izquierda a derecha, opera sobre una estructura de datos denominada pila y utiliza la notación polaca inversa (RPN), en la que los operadores siguen a sus operandos en lugar de precederlos. Ejecuta una instrucción cada vez, no tiene bucles y no conserva memoria persistente entre ejecuciones.

Este último punto es el primero con el que se encuentra la mayoría de la gente al empezar a conocer Bitcoin Script a nivel de protocolo: el lenguaje no es, intencionadamente, Turing completo. Un lenguaje Turing completo puede realizar cualquier cálculo si se dispone de tiempo y recursos suficientes. Bitcoin Script, por su diseño, no puede hacerlo, y las razones de esa elección son de gran importancia para el funcionamiento de la red.

Cómo funciona Bitcoin Script: el modelo de pila

Para entender cómo funciona Bitcoin Script, hay que entender en qué consiste una pila. Una pila es una estructura de datos que funciona según el principio «último en entrar, primero en salir» (LIFO). Imagina una pila de platos: solo se puede añadir o retirar desde la parte superior. En Bitcoin Script, los datos se insertan en la pila y los códigos de operación (opcodes) manipulan lo que se encuentre en la parte superior.

Cuando un nodo de Bitcoin valida una transacción, ejecuta dos scripts de forma secuencial:

1. El script de desbloqueo (ScriptSig o testigo) proporcionados por la persona que gasta las monedas. Esto introduce datos en la pila, normalmente una firma digital y una clave pública.
2. El script de bloqueo (ScriptPubKey) asociado al gasto de la salida. Contiene códigos de operación que actúan sobre los datos de la pila y verifican si se cumplen las condiciones de gasto.

Si el script se ejecuta sin errores y deja un valor distinto de cero (TRUE) en la pila al final, la transacción es válida. Si falla o deja FALSE, el nodo rechaza la transacción y esta nunca llega a incluirse en un bloque.

Esta ejecución carece por completo de estado. El script no tiene conocimiento alguno de ninguna transacción anterior, no conoce los saldos actuales y no conserva ningún tipo de memoria una vez finalizada su ejecución. Cada script se ejecuta desde cero, de forma aislada, en cada ocasión.

Paso a paso: una transacción P2PKH estándar

«Pay-to-Public-Key-Hash» (P2PKH) es el tipo de transacción original de Bitcoin, en uso desde 2009. Las direcciones P2PKH comienzan por «1». A continuación se muestra cómo son, en la práctica, los campos ScriptPubKey y ScriptSig:

Script de desbloqueo (ScriptSig):

<firma> <clave pública>

Script de bloqueo (ScriptPubKey):

OP_DUP OP_HASH160 <hash de la clave pública> OP_EQUALVERIFY OP_CHECKSIG

Cuando el nodo concatena y ejecuta ambas cosas a la vez, las operaciones de la pila se desarrollan paso a paso:

• La firma y la clave pública de ScriptSig se añaden a la pila
• OP_DUP duplica la clave pública que se encuentra en la parte superior de la pila
• OP_HASH160 calcula el hash del duplicado (SHA-256 seguido de RIPEMD-160), lo que da como resultado un hash de 20 bytes
• El hash de la clave pública del script de bloqueo se añade a la pila
• OP_EQUALVERIFY comprueba que los dos hash coincidan. Si no coinciden, la ejecución se detiene y la transacción falla.
• OP_CHECKSIG comprueba que la firma sea válida para la clave pública

Si se superan todos los pasos, la pila termina con TRUE y se liberan los fondos. Todo el proceso dura milisegundos y se ejecuta de forma idéntica en todos los nodos de la red.

Explicación de los opcodes de Bitcoin

Los opcodes de Bitcoin son los comandos individuales que componen un script. Cada uno ocupa un solo byte, lo que da lugar a 256 ranuras de opcode posibles. De ellas, aproximadamente 80 están activas actualmente en la red principal. El resto están reservadas, desactivadas o asignadas al mecanismo de compatibilidad con versiones futuras OP_SUCCESS, introducido con Tapscript.

Los códigos de operación se clasifican en varias categorías:

• Códigos de operación de inserción de datos insertar en la pila valores como claves públicas, firmas y hash
• Códigos de operación aritméticos realizar operaciones de suma, resta y comparación. Cabe destacar que la multiplicación y la división están desactivadas.
• Códigos de operación criptográficos incluyen OP_SHA256, OP_HASH160 y OP_SHA1 para el cálculo de hash, y OP_CHECKSIG para la verificación de firmas
• Códigos de operación de control de flujo activar la lógica condicional: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Códigos de operación de manipulación de la pila entre ellas se encuentran OP_DUP (duplicar el elemento superior), OP_DROP (eliminar el elemento superior) y OP_SWAP (intercambiar los dos elementos superiores)

Satoshi Nakamoto desactivó varios códigos de operación en 2010 tras descubrirse vulnerabilidades en sus implementaciones originales. Entre ellos se encuentran OP_CAT (concatenar dos elementos de la pila), OP_MUL (multiplicar) y OP_DIV (dividir). Su ausencia ha tenido consecuencias duraderas en lo que Bitcoin Script puede expresar, y varias de las propuestas de actualización de Bitcoin más debatidas en 2026 giran en torno a si se deben volver a habilitar algunas de ellas.

Para consultar la referencia completa de códigos de operación, incluidos los valores hexadecimales y las descripciones, consulta la Página del script de Bitcoin Wiki es la fuente de referencia.

Por qué el hecho de no ser Turing completo es una ventaja

La explicación habitual es que Bitcoin Script no admite bucles, por lo que se garantiza que los scripts lleguen a su fin y, de este modo, la red queda protegida frente a una ejecución infinita. Eso es cierto, pero no refleja plenamente la realidad.

El argumento más profundo tiene que ver con la superficie de ataque. Un lenguaje Turing completo puede expresar cualquier tipo de cálculo. Esa capacidad de expresión es también el espacio donde se esconden los errores. Solidity, de Ethereum, ha generado algunas de las vulnerabilidades de software más costosas de la historia. El ataque al DAO de 2016 aprovechó un fallo de reentrada en un contrato inteligente y provocó pérdidas de unos 60 millones de dólares a los precios vigentes en aquel momento, lo que acabó dando lugar a una controvertida bifurcación dura de la red Ethereum. El ecosistema DeFi en general ha visto cómo se han perdido cientos de millones de dólares a lo largo de varios años debido a exploits en contratos inteligentes.

El script de Bitcoin hace que ese tipo de ataque sea estructuralmente imposible. No se puede escribir un script de Bitcoin que llame a otros scripts, entre en un bucle hasta que cambie una condición o almacene el estado entre transacciones. Cada script es un programa delimitado, que termina y que se puede inspeccionar. El tamaño máximo de un script es de 10 000 bytes. El número máximo de códigos de operación que no sean «push» por script es de 201. Un validador siempre puede calcular el coste de ejecución en el peor de los casos antes de ejecutar el script.

Para una red que alberga cientos de miles de millones de dólares en valor, esa previsibilidad vale más que la flexibilidad a la que se renuncia. Ethereum resuelve el problema del cálculo ilimitado mediante límites de gas, cobrando a los usuarios por cada código de operación ejecutado y deteniendo los scripts que agotan su presupuesto. Eso funciona, pero introduce su propia complejidad y modos de fallo. Bitcoin elude el problema por completo gracias a su diseño.

Dicho esto, «no ser Turing completo» no significa «no ser capaz de manejar una lógica compleja». Bitcoin Script admite requisitos de gasto multipartito, condiciones basadas en el tiempo, revelación de preimágenes de hash y combinaciones de todos estos elementos. La Red Lightning, que gestiona millones de pagos al día, se basa íntegramente en primitivas de Bitcoin Script.

Tipos de script: la evolución de P2PKH a Taproot

La capa de scripting de Bitcoin ha evolucionado considerablemente desde 2009, y cada actualización ha introducido un nuevo formato de transacción, sin dejar de ser compatible con todo lo anterior.

P2PK (Pay-to-Public-Key, 2009)

El formato original, utilizado en las primeras transacciones de Bitcoin, incluido el pago de Satoshi a Hal Finney en el bloque 170. Los fondos se vinculaban directamente a una clave pública completa, en lugar de a su hash. Hoy en día apenas se utiliza en las nuevas transacciones, ya que expone la clave pública en la cadena antes de realizar el gasto, lo que se considera una medida de seguridad menos sólida que aplicar primero el hash a la clave.

P2PKH (Pay-to-Public-Key-Hash, 2009)

El formato estándar desde hace más de una década. P2PKH vincula los fondos a un hash de la clave pública en lugar de a la propia clave, lo que mantiene la clave pública privada hasta el momento del gasto, genera una dirección más corta de 20 bytes y constituye la base de todas las direcciones que comienzan por «1». Según los datos en cadena de Unchained (abril de 2026), las direcciones P2PKH albergan actualmente aproximadamente el 43 % del suministro de bitcoins minados.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Introducido mediante un soft fork el 1 de abril de 2012, P2SH trasladó la carga de los complejos scripts de gasto del remitente al destinatario. En lugar de incluir un script de bloqueo completo en la salida, las salidas P2SH se comprometen con un hash de 20 bytes de un «script de canje». El script completo solo se revela cuando se gastan las monedas. Esto hizo que la firma múltiple resultara práctica para los usuarios habituales: una configuración de firma múltiple 2 de 3 ya no requería que las tres claves públicas fueran visibles para el remitente en el momento del pago. Las direcciones P2SH comienzan por «3».

Para obtener un desglose detallado de cómo funciona la validación de P2SH a nivel de protocolo, Guía de transacciones de developer.bitcoin.org explica paso a paso el funcionamiento del mecanismo de scripts «redeem».

P2WPKH y P2WSH (SegWit nativo, 2017, BIP 141)

Segregated Witness, activado en agosto de 2017 en el bloque 481 824, trasladó los datos de la firma fuera del cuerpo principal de la transacción a una estructura de testigo independiente. Los datos del testigo se benefician de un descuento del 75 % en el peso, lo que hace que las transacciones SegWit sean considerablemente más baratas. Una transacción P2WPKH estándar de una entrada y dos salidas pesa aproximadamente 141 bytes virtuales, frente a los 226 vbytes de la transacción P2PKH equivalente, según Análisis de los tipos de direcciones de Bitcoin de Spark a partir de marzo de 2026. SegWit también solucionó el problema de la maleabilidad de las transacciones, lo cual era un requisito previo para la red Lightning. Las direcciones SegWit nativas comienzan por «bc1q».

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot se activó en noviembre de 2021 en el bloque 709 632 y es la actualización más importante de la capa de scripts de Bitcoin desde SegWit. Introdujo las firmas Schnorr, un nuevo tipo de salida compatible con MAST y Tapscript como lenguaje de scripts actualizado. Las direcciones de Taproot comienzan por «bc1p».

Taproot y Tapscript: cómo cambió el lenguaje de scripting de Bitcoin en 2021

Taproot no es un único cambio. Se trata de tres propuestas de mejora de Bitcoin diseñadas conjuntamente y activadas al mismo tiempo.

BIP 340: Firmas de Schnorr

En un principio, Bitcoin utilizaba el algoritmo ECDSA (algoritmo de firma digital de curva elíptica). Satoshi lo eligió, en parte, porque las firmas Schnorr estaban protegidas por una patente en aquel momento. Esa patente expiró en 2008, y Taproot incorporó finalmente las firmas Schnorr al protocolo.

Las firmas Schnorr son más pequeñas, con 64 bytes, frente a los 71-73 bytes de las firmas ECDSA. Y lo que es más importante, admiten la agregación de claves mediante un esquema denominado MuSig2. La agregación de claves permite a varios firmantes combinar sus claves y firmas individuales en una única clave y firma agregadas que, en la cadena de bloques, son indistinguibles de un pago ordinario con una sola firma. Una cartera multisig de 2 de 3 que realice un gasto a través de la ruta de clave cooperativa de Taproot parece idéntica a un pago estándar en la cadena de bloques. Esto supone una ventaja real en materia de privacidad para cualquiera que posea bitcoins en un complejo acuerdo de custodia.

BIP 341: Pay-to-Taproot y MAST

P2TR introduce un nuevo tipo de salida con dos vías de gasto:

• A ruta clave realizar el pago mediante una firma de Schnorr, que se utiliza cuando todas las partes están de acuerdo y desean la opción más sencilla y económica
• A ruta del script realizar el gasto utilizando MAST (árbol de sintaxis abstracta merkelizado, que es la implementación de Taproot de este concepto)

MAST permite que una única salida se asigne a un árbol de múltiples scripts de gasto a través de una raíz de Merkle. Al realizar un gasto, solo se revela en la cadena la condición específica que se utiliza realmente. Todas las demás rutas de gasto posibles del árbol permanecen ocultas de forma permanente. En el caso de un usuario que haya configurado una política de gasto compleja, por ejemplo: «Puedo gastar normalmente, o dos de tres administradores pueden gastar al cabo de seis meses, o una clave de recuperación puede gastar al cabo de dos años», solo la ruta que se ejecuta realmente aparece en la cadena de bloques.

En 2024, la cuota de Taproot en las transacciones de Bitcoin había aumentado hasta situarse en torno al 42 %, impulsada en gran medida por la actividad de inscripción de Ordinals y BRC-20, según datos de Glassnode citados por Spark en marzo de 2026. Desde entonces, esa cuota ha fluctuado en función de las condiciones del mercado, pero la infraestructura es ahora un estándar en las principales carteras y plataformas de intercambio. Página temática sobre Taproot de Bitcoin Optech realiza un seguimiento del desarrollo actual del protocolo Taproot.

BIP 342: Tapscript

Tapscript es el lenguaje de scripting actualizado que se utiliza para los gastos con ruta de script dentro de Taproot. Comparte la mayoría de los códigos de operación con el Bitcoin Script tradicional, pero introduce varios cambios significativos:

• OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY están obsoletas. El antiguo código de operación multisig tenía una peculiaridad que obligaba a insertar un elemento ficticio en la pila como solución alternativa. Tapscript lo elimina y lo sustituye por OP_CHECKSIGADD, que verifica las firmas de Schnorr una por una y va sumando el recuento. Los esquemas de multifirma con umbral resultan más sencillos y económicos de ejecutar.
• Se han eliminado los límites de tamaño de los scripts por hoja MAST. Los scripts individuales dentro de una rama de Taproot pueden tener un tamaño ilimitado.
• Códigos de operación OP_SUCCESS son el cambio más innovador. En el Script tradicional, encontrar un código de operación (opcode) no definido provoca que el script falle. En Tapscript, los códigos de operación del rango OP_SUCCESS hacen que el script se ejecute con éxito de forma incondicional. Las futuras bifurcaciones suaves podrán asignar un comportamiento real a estos códigos de operación añadiendo restricciones sobre cuándo deben ejecutarse con éxito, sin necesidad de una nueva versión del script ni de un ciclo completo de reimplementación en todo el ecosistema. Se pueden añadir nuevas capacidades a la capa de scripts de Bitcoin de forma más limpia que en cualquier otro momento de la historia del protocolo.

Miniscript

Junto a Tapscript, un proyecto relacionado llamado Miniscript ha cobrado cada vez más relevancia entre los desarrolladores. Miniscript es una forma estructurada de escribir un subconjunto de Bitcoin Script que es analizable, combinable y firmable de forma genérica. Mientras que el Script sin procesar requiere una construcción manual y resulta difícil de auditar, los scripts de Miniscript pueden verificarse automáticamente para comprobar su corrección y combinarse en políticas más amplias. No amplía las capacidades de Script, pero hace que lo que ya hace resulte significativamente más accesible para los desarrolladores que crean carteras y herramientas de custodia.

Lo que permite Bitcoin Script: casos de uso en el mundo real

En la red principal de Bitcoin están activos actualmente los siguientes tipos de transacciones, todos ellos basados en primitivas de Bitcoin Script:

Carteras de multifirma (multisig) requiere M de N claves privadas para autorizar un gasto. El departamento de tesorería de una empresa podría exigir 3 de 5 aprobaciones para cualquier retirada de fondos. Una pareja casada podría utilizar 2 de 2 para sus ahorros conjuntos. Con Taproot y la agregación de claves Schnorr, los gastos multifirma cooperativos son ahora, en la cadena, indistinguibles de las transacciones estándar de firma única.

Transacciones con bloqueo temporal Utiliza OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify o CLTV) y OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify o CSV) para impedir que los fondos se transfieran antes de alcanzar una determinada altura de bloque o de que transcurra un tiempo determinado. Entre sus aplicaciones se incluyen la planificación de sucesiones, los calendarios de devengo de tokens para empleados, los mecanismos de ahorro obligatorio y las transacciones con penalización utilizadas dentro de los canales de Lightning Network.

Contratos con bloqueo temporal de hash (HTLC) combinar un requisito de preimagen de hash con un bloqueo temporal. La condición de gasto funciona así: hay que revelar la preimagen de este hash antes de alcanzar esta altura de bloque; de lo contrario, los fondos se devuelven al remitente. Los HTLC son la primitiva fundamental de la Red Lightning, ya que permiten el enrutamiento de pagos sin necesidad de confianza a través de cadenas de canales entre partes que no mantienen una relación directa.

Depósito en garantía Estos mecanismos bloquean los fondos en un script P2SH o Taproot, lo que requiere el acuerdo de varias partes antes de su liberación; normalmente, un árbitro externo es quien posee la clave de desempate.

Contratos de registro discreto (DLC) utilizan firmas de adaptador Schnorr basadas en oráculos para permitir la liquidación de contratos financieros a partir de datos del mundo real, como cotizaciones de precios o resultados de eventos, sin que sea necesario que el oráculo se haga cargo de la custodia de ningún fondo. Los DLC están activos en la red principal de Bitcoin y se utilizan para productos de opciones y futuros liquidados en Bitcoin.

El script de Bitcoin frente a los contratos inteligentes de Ethereum

Tanto Bitcoin Script como Solidity de Ethereum definen las condiciones en las que se pueden transferir fondos, pero representan opciones arquitectónicas fundamentalmente diferentes. Merece la pena realizar esta comparación directamente, ya que las diferencias explican en gran medida las concesiones que ha aceptado cada red.

La diferencia fundamental radica en el carácter «stateful». Los contratos de Ethereum almacenan y modifican datos que persisten entre transacciones, lo que hace posibles los protocolos de préstamo, los intercambios descentralizados, la gobernanza en cadena y los estándares de tokens. Bitcoin Script no tiene ningún equivalente. Cada script se ejecuta de forma aislada, sin tener conocimiento de ninguna otra transacción.

Se trata de una elección arquitectónica deliberada, no de una laguna que haya que subsanar. La capa de scripts de Bitcoin se diseñó para una función específica: garantizar el cumplimiento de las condiciones para gastar bitcoins, de forma predecible y segura, a gran escala. Para esa tarea, la ausencia de estado es una ventaja. La superficie de ataque es menor, la ejecución es determinista en millones de validadores independientes y no existe ninguna categoría de vulnerabilidad de contratos inteligentes a nivel de protocolo, ya que no hay contratos con estado a ese nivel.

Los proyectos que buscan una mayor programabilidad sobre Bitcoin la desarrollan por capas. La Red Lightning se encarga de los pagos. Los protocolos DLC gestionan los contratos financieros referenciados a datos externos. Los sistemas de capa 2, como Ark y la Red Liquid, abordan diferentes perfiles de escalabilidad. Nada de esto requiere modificar el modelo de scripting de la capa base.

El debate sobre Covenant: ¿qué podría cambiar en el script de Bitcoin?

La evolución de Bitcoin Script siempre ha sido lenta y conservadora. El ámbito de desarrollo más activo en estos momentos es el de los opcodes de «covenant», que son propuestas que permitirían a un script restringir no solo quién puede gastar una salida, sino también cómo debe ser la transacción resultante. Se trata de una ampliación significativa de la capacidad expresiva de Script.

Las propuestas más destacadas a fecha de junio de 2026 son:

• OP_CTV (BIP-119, CheckTemplateVerify), de autoría de Jeremy Rubin, añade un único código de operación que asigna un UTXO a una plantilla de gasto específica y predeterminada que incluye la versión de la transacción, el tiempo de bloqueo, el número de entradas, las secuencias, el número de salidas y las salidas. Por su diseño, no es recursiva, se considera la propuesta importante más conservadora y se centra principalmente en las «vaults», el control de la congestión y ciertas mejoras de Lightning. A fecha de abril de 2026, OP_CTV cuenta con parámetros de implementación concretos sobre la mesa que especifican una ventana de señalización «Speedy Trial», pero no ha logrado el amplio consenso de la comunidad necesario para su activación, según Análisis de las cláusulas restrictivas de BlockEden para abril de 2026.
• OP_CAT (BIP-347), propuesta por Ethan Heilman y Armin Sabouri, reactivaría un código de operación que Satoshi desactivó en 2010. OP_CAT concatena dos elementos de la pila, lo cual es sencillo en teoría pero tiene amplias implicaciones. Cuando se combina con las firmas de Schnorr, permite una introspección de las transacciones similar a la de los «covenants». En la red de pruebas Signet de Bitcoin, OP_CAT había generado un número significativamente mayor de transacciones de desarrolladores que APO o CTV, según el análisis en cadena de sCrypt de finales de 2024. OP_CAT ya está activo en Liquid Network y Fractal Bitcoin sin que se le hayan atribuido vulnerabilidades. El BIP-347 cuenta con un número de propuesta oficial y una investigación activa que lo respalda, pero su activación en la red principal requiere un consenso de la comunidad que aún no existe.
• LNHANCE combina OP_CTV con OP_CHECKSIGFROMSTACK (CSFS) y OP_INTERNALKEY, con el objetivo de introducir mejoras específicas en la creación de canales de Lightning Network, entre las que se incluyen la apertura de canales no interactivos y una gestión más eficiente de los canales multipartitos.

Ninguna de estas propuestas se ha activado en la red principal de Bitcoin a fecha de junio de 2026. Las discrepancias técnicas entre ellas son, en gran medida, superables. El problema más complicado es la mecánica de la activación. El proceso de «soft fork» de Bitcoin requiere un amplio consenso, y el debate sobre el pacto arrastra tensiones residuales de anteriores actualizaciones polémicas. Lo que queda claro del debate es que la capa de scripts de Bitcoin tiene un margen significativo de crecimiento dentro de su marco conservador. La cuestión que se está abordando es la secuencia de pasos y el acuerdo de la comunidad, no si el lenguaje de scripts tiene futuro.

Conclusión

Bitcoin Script es la infraestructura invisible que subyace a todas las transacciones de la red. La mayoría de los usuarios nunca entra en contacto directo con él. Los monederos crean scripts válidos, los firman y los transmiten sin revelar nunca su funcionamiento interno. Pero cada pago, cada canal Lightning, cada plan con bloqueo temporal y cada caja fuerte multisig se ejecuta mediante el mismo lenguaje de scripting de Bitcoin basado en pila que se incluyó con el protocolo en 2009.

La capa de scripting ha crecido considerablemente desde entonces: P2SH ha hecho viables los gastos complejos; SegWit ha reducido las comisiones y ha habilitado Lightning; y Taproot ha introducido las firmas Schnorr, la privacidad basada en MAST y el diseño de códigos de operación de Tapscript, compatible con futuras versiones. Las propuestas de «covenant» que se están debatiendo activamente en la actualidad representan el próximo capítulo potencial. A mediados de 2026, sigue sin saberse con certeza si alguna de ellas se activará ni en qué plazo.

Para comprender Script no hace falta ser desarrollador. Lo que sí hace falta es reconocer que el conservadurismo de Bitcoin —sus limitaciones deliberadas, el ritmo lento de las actualizaciones y el hecho de que no sea Turing-completo— no es un defecto. Las propiedades que hacen que Bitcoin Script sea predecible son las mismas que han mantenido limpia la capa de consenso durante dieciséis años.