Glosario / Protocolo y actualizaciones
OP_CAT
- ¿Qué es OP_CAT?
- OP_CAT une en uno solo los dos elementos de la cima de la pila del script, una operación que Satoshi desactivó en 2010 y que BIP-347 propone reactivar dentro de tapscript.
Se especifica en el BIP-347.
La concatenación parece trivial y no lo es. Con ella, un script puede reconstruir el hash de firma de una transacción a partir de partes apiladas, en fragmentos de no más de 520 bytes, y después comprobar ese hash con una verificación de firma corriente. Así es como un opcode (código de operación) desactivado por peligroso se convirtió en el elemento más debatido de la lista de covenants (restricciones sobre cómo se puede gastar una moneda).
Cómo funciona
Estado: desactivado desde agosto de 2010, cuando un lote de opcodes de cadenas de caracteres y de aritmética se desactivó en un barrido defensivo del motor de script. BIP-347 propone reactivarlo solo en tapscript. No está activo en la mainnet.
La operación en sí cabe en una línea: desapilar dos elementos y apilar sus bytes unidos uno detrás de otro. La razón por la que era peligrosa en 2010 es que nada limitaba cuánto podía crecer un elemento de la pila. Concatenar un elemento consigo mismo lo duplica, así que un bucle corto de inserciones de datos y uniones podía inflar unos pocos bytes hasta convertirlos en gigabytes y llevarse por delante la memoria del nodo. El motor moderno tiene un límite estricto de 520 bytes para cualquier elemento de la pila, así que BIP-347 simplemente hace fallar la operación cuando el resultado lo superaría, y el antiguo ataque desaparece.
Hay una rareza de numeración que hace que la reactivación sea inusualmente limpia. OP_CAT es el opcode 126. Cuando BIP-342 definió tapscript, declaró que los opcodes 126 a 129, entre otros, eran OP_SUCCESS: encontrar uno hace que el script tenga éxito en el acto. Por eso los nodos no actualizados ya aceptan cualquier tapscript que contenga el byte 126 sin ejecutarlo. Redefinirlo para que concatene solo restringe lo que esos nodos habrían permitido, lo que convierte el cambio en una bifurcación blanda (soft fork) y no en una división de la cadena.
Lo que la concatenación hace posible es desproporcionado respecto de su tamaño. Un script que puede construir cadenas de bytes puede verificar una prueba de Merkle, comprobar una firma Lamport o Winternitz construida a partir de hash en lugar de curvas elípticas y obligar a una firma a usar un nonce fijo para que la propia ecuación de la firma exponga al script la transacción de gasto. Ese último truco es el que convierte OP_CAT en una herramienta general de covenants sin ningún opcode específico para covenants.
Dónde aparece
OP_CAT no se ejecuta en bitcoin en absoluto. Los lugares donde sí se ejecuta son las cadenas laterales (sidechains) y las redes de pruebas que copiaron el motor de script de bitcoin y después revirtieron la decisión de 2010.
Elements, y por tanto Liquid, tiene el opcode activado, y por eso la mayoría de las demostraciones de covenants publicadas están escritas para Liquid y no para bitcoin. Las signets personalizadas con las reglas de BIP-347 son la otra plataforma, y existen para que los desarrolladores puedan construir lo que proponen antes de pedir a nadie que cambie el consenso.
Para quien compra o conserva monedas, el contenido práctico es breve: nada de su billetera, sus direcciones ni sus respaldos cambia si OP_CAT se activa o si nunca llega a activarse. Vale la pena conocer el nombre porque está en el centro de un desacuerdo real sobre cuánta programabilidad debería tener bitcoin, y porque las propuestas para añadir firmas basadas en hash de cara a un futuro con computadoras cuánticas suelen pasar por él.