Los desarrolladores de Bitcoin Core han estado discutiendo la posibilidad de estandarizar un método para almacenar datos arbitrarios en Bitcoin a través de una característica llamada apéndice Taproot.

De acuerdo con la propuesta de Joost Jager, ingeniero y desarrollador de Bitcoin y la red Lightning, actualmente “estableciendo un formato exacto [para el anexo] puede requerir una cantidad significativa de tiempo.”

El anexo Taproot es un formato para agregar datos en una extensión del campo conocida como Testigo, donde se incluyen las firmas de validación de transacciones comunes de Bitcoin. Esto es relevante hoy porque el Testigo de las transacciones raíz principal es el espacio donde se NFT ordinalesun protocolo que desde su creación a fines del año pasado generó todo tipo de debates por su efecto en la red y los mercados.

Este formato libre “permite ampliar los campos de transacciones habituales con nuevos registros de datos”, explica Antoine Riard, desarrollador de Bitcoin, en un propuesta presentado en julio de 2022 que sirvió de base para la propuesta de Jager. Además, prevé que estos datos puedan estar sujetos a nuevas reglas de validación.

En otras palabras, el archivo adjunto es una parte opcional de las transacciones Taproot, cuyo propósito aún no está definido, aunque idealmente se reserva para uso futuro. tenedores horquillas lisas o blandas. Un aspecto destacable es que, en los anexos, las firmas de transacciones y los datos adjuntos están comprometidos o vinculados. Esto hace que sea imposible cambiar nada en el registro.

Un formato gratuito para archivos adjuntos Taproot

Jager reconoce que hay un factor importante que puede retrasar el progreso del apéndice Taproot, que parece ser ampliamente aceptado entre los desarrolladores por su potencial. “Las conversaciones sobre estandarización parecen inclinarse hacia la adopción de un formato flexible tipo-longitud-valor (TLV)”, Explicar. En resumen, si el anexo utiliza este formato para registrar cualquier dato en las transacciones, habría muchos beneficios; pero el precio sería el tiempo que hay que pagar.

Así es como se codifica un archivo adjunto Taproot en el formato tipo-longitud-valor. Fuente: bips/bip-annex.mediawiki / GitHub.

Mientras tanto, los beneficios de hacer que el anexo esté disponible en forma no estructurada son obvios e inmediatos. Al permitir que los desarrolladores usen el complemento taproot sin demora, podemos aprovechar sus características hoy, sin la necesidad de esperar a que finalice un proceso de estandarización más largo.

Joost Jager, desarrollador e ingeniero de Bitcoin y Lightning.

que jager propone es un formato libre, “sin restricciones adicionales”, para todos aquellos archivos adjuntos que empiecen por “0”. Es decir, no tienen instrucciones.

El desarrollador concluye que existen al menos 3 beneficios al adoptar un formato como el que propone.

El primero “abre la puerta para que los desarrolladores use el apéndice de Taproot para una variedad de aplicaciones desde el primer momentoeliminando así la necesidad de esperar la implementación de TLV o cualquier otro formato estructurado.

La segunda consiste en mantener abiertas las opciones para desarrollos futuros, mientras se avanza en una estandarización del anexo.

El tercero se refiere al uso eficiente del espacio en la cadena de bloques, ya que “los datos no estructurados pueden requerir menos bytes en comparación con un formato TLV probable, que requeriría una codificación de longitud incluso cuando solo hay un campo”.

Aunque la propuesta de Riard no fue ampliamente aceptada, La idea de Jager podría despertar el interés de otros desarrolladores.. En este sentido, Greg Sanders, otro desarrollador de Bitcoin Core y Lightning, trajo a la mesa de debate una idea que había sido propuesta por el propio Riard en octubre del año pasado.

Esta es la posibilidad de usar archivos adjuntos para probar el Protocolo LN-Symetry o Eltoouna herramienta que reemplaza el actual sistema de penalización de transacciones en la red Red relámpago, que se ejecuta cuando un usuario emite una transacción de blockchain antigua y ya no válida, mediante un mecanismo que actualiza automáticamente los canales de pago. De esta manera, nadie puede usar una actualización de canal anterior que muestre un saldo falso (algo que podría explotarse para robar BTC).

Eltoo necesita usar un tipo de transacción específico que podría aprovechar las propiedades de los archivos adjuntos: bifurcación suave SIGHASH_ANYPREVOUT“a picadillo sighash donde el identificador del UTXO que se gasta no está firmado, lo que permite que la firma se use con cualquier UTXO que esté protegido por un script similar (es decir, usa la misma clave pública)”. UTXO significa salida de transacción no gastadao ‘transacción de salida no gastada’, en español.

Por su parte, Jager respondió que Se podrían crear bóvedas para almacenar bitcoins con bloqueo de tiempo utilizando transacciones prefirmadas con llaves efímeras. El desarrollador El sugirió que puede haber investigaciones previas en Bitcoin Core que corrigen el problema de retransmisión de archivos adjuntos en algunos protocolos multipartidistas.

En cualquier caso, los desarrolladores hablaron de cómo los archivos adjuntos podrían aumentar la eficiencia de los testigos al poder incluir datos arbitrarios sin comprometerse económicamente, más allá del gasto que genera esa transacción específica. De alguna manera, como lo hace el protocolo Ordinals. “Creo que la verdadera ventaja es que elimina la necesidad de publicar y pagar la transacción de confirmación en primer lugar. Cualquier gasto de una UTXO principal se puede complementar con datos arbitrarios en una sola transacciónañadió Jagger.

Ciertamente, cuando se habla de datos arbitrarios en Bitcoin, lo primero que viene a la mente son los tokens NFT y BRC-20 que tienen una gran influencia en el ecosistema actual. Y, en ese sentido, es imposible predecir cuál sería el destino final de un estándar que proporciona una utilidad similar. Solo el tiempo dirá qué tiene más valor para las personas que usan Bitcoin.

Leave a Reply

Your email address will not be published. Required fields are marked *