¿Ha caído usted en la ‘madriguera’ de los pactos?
Entrevistador: Hua, escritora independiente, investigadora independiente. X: @AmelieHua
Entrevistado: Poly, un especialista en controles, mantiene múltiples sistemas de control distribuido (DCS) y ha trabajado con otros cinco y nueve sistemas (disponibilidad de tiempo de actividad del 99,999 %). X: @Polyd_
Los pactos son un tema antiguo pero nuevo. Ya en 2013, los desarrolladores comenzaron a discutir este tema y, en los últimos años, se han propuesto Múltiples BIP destinados a implementar convenios, lo que generó intensos debates y lo convirtió en uno de los temas más candentes.
Los pactos merecen un debate serio debido a sus poderosas capacidades. Se considera que aportan nuevas posibilidades a la programabilidad de Bitcoin y se cree que permiten contratos inteligentes. Para Bitcoin, esto es sin duda un arma de doble filo. En este artículo, exploraremos qué son los convenios, cómo funcionan, su sólida funcionalidad y su importancia para Bitcoin. Al analizar los detalles, este artículo suele utilizar el CTV como ejemplo, pero el CTV no es el único método para implementar convenios.
Este artículo profundiza en la exploración de los convenios, pero también magnifica una porción de Bitcoin bajo un microscopio para su observación. A través de esta observación, podemos entender cómo opera Bitcoin a nivel granular, comprendiendo tanto sus capacidades como sus limitaciones. Comprender lo que no puede hacer es tan crucial como entender lo que puede hacer porque sólo entonces podremos elegir el camino correcto para construir sobre Bitcoin.
1.
Hua:
Antes de discutir los convenios, puede ser necesario aclarar dos cuestiones relacionadas con Bitcoin, lo que puede ayudarnos a comprender mejor los convenios.
Sabemos que Bitcoin utiliza un lenguaje de secuencias de comandos y se sabe que los lenguajes de secuencias de comandos apoyan la implementación de contratos inteligentes. Sin embargo, en realidad, los contratos inteligentes no se han implementado en la cadena principal de Bitcoin. Esto inevitablemente crea la sensación de que la implementación de contratos inteligentes en Bitcoin enfrenta algunos obstáculos insuperables, y parece imposible en la red Bitcoin.
Sin embargo, es posible que muchas personas no sepan que, aunque Bitcoin se puede programar utilizando un lenguaje de programación, el conjunto de códigos de operación es extremadamente limitado. Este conjunto limitado de códigos de operación restringe el alcance de la programabilidad de Bitcoin, lo que significa que, aunque el lenguaje de programación puede implementar contratos inteligentes, los programadores no tienen suficientes «herramientas» para implementar contratos inteligentes.
Escuela politécnica:
Definitivamente, Bitcoin Script puede considerarse limitante ya que solo puede realizar operaciones básicas, como realizar pagos simples. Algunas de las razones por las que las personas pueden encontrar «limitante» es que no tiene un estado global, no se considera completo, utiliza un sistema basado en UTXO (que tiene «ceguera de valores») en lugar de un sistema basado en cuentas . sistema. La última gran razón es que muy pocos datos de la propia cadena de bloques pueden integrarse en los contratos, lo que provoca la ceguera de la cadena de bloques.
Esto ha creado muchos desafíos a lo largo de los años a medida que las personas han solucionado estas limitaciones. También hemos tenido un cambio semántico con el término «contrato inteligente» para significar una cosa específica cuando se debe considerar la red Lightning como una producción de muchos contratos inteligentes formados por muchos individuos. Esas firmas múltiples con hashlocks y timelocks no solo son contratos inteligentes, sino que también tienen acuerdos basados en el tiempo.
El problema es que, tal como mencionaste antes, debido a que Bitcoin solo tiene códigos de operación simples para realizar solo lo básico, si intentas escalar más allá de dos personas en un contrato inteligente, puedes obtener mucha dificultad para una huella en la cadena o Es posible que las cosas que deseas hacer simplemente no sean posibles. Esta limitación estricta proviene de algunos lugares, creo que lo más importante fue que cuando ocurrió el error de inflación en 2010, Satoshi había deshabilitado una lista completa de códigos de operación de orden superior, incluido OP_CAT, que nos habría permitido crear contratos inteligentes más dinámicos. a través de transacciones. introspección.
Desde entonces, BCH ha superado esta limitación dentro de su propio script, lo que demuestra que Script no es tan débil como todos suponen, solo que Bitcoin siempre ha sido más lento debido a su descentralización y la coordinación es casi imposible, excepto durante largos períodos. de tiempo. Tampoco hemos tocado apenas Taproot y Tapscript, lo que aliviará muchas de las preocupaciones sobre la huella y permitirá nuevos comportamientos como BitVM al incorporar el contrato en la firma y usted solo lo revela cuando sea necesario.
Hua:
¿Por qué existen limitaciones estrictas en los códigos de operación? ¿Puedes utilizar OP_CAT como ejemplo para ayudarnos a entender este punto?
Escuela politécnica:
Entonces OP_CAT es engañosamente simple: tomará dos cadenas y las sumará. Originalmente estaba deshabilitado porque tenía problemas de recursos y podía usarlo para provocar que los nodos fallaran, pero no estoy seguro de si esa es la historia completa, ya que Satoshi desarrolló el límite de pila de 520 bytes. y OP_CAT deshabilitado en la misma confirmación, por lo que podría haber más que un simple agotamiento de recursos.
Pero solo para dar una breve lista de lo que OP_CAT puede realizar: convenios CTV/TXHASH, verificar pruebas de SPV, protección de doble gasto para TX de 0 configuración, aritmética de 64 bits, bóvedas, firmas resistentes a cuánticos. La lista continúa, solo con OP_CAT, puede emular tanto CTV como[CheckTemplateVerify] y estilo transacciones TXHASH. El único problema es que es altamente ineficiente en la forma en que se realizan estas acciones que podrían ser posibles, pero eso podría simplemente impedir que estas transacciones sean deseables excepto para usuarios de escala como los custodios.
2.
Hua:
Hablemos de otra «limitación» de Bitcoin. Bitcoin sólo admite la «verificación» como forma de cálculo y no puede realizar cálculos de propósito general.
También sabemos que, por ejemplo, los contratos inteligentes en Ethereum contienen reglas para las transiciones de estado. Completa la transición de estado a través de la computación, permitiendo la funcionalidad de contratos inteligentes. En comparación, Bitcoin no puede realizar cálculos de propósito general, lo que significa que no puede lograr transiciones de estado mediante el cálculo por sí solo.
¿Es correcto mi entendimiento?
Escuela politécnica:
Sí, estoy de acuerdo en que es un resumen simple del estado actual de las cosas. Se podría hacer que Bitcoin admita transacciones computacionales y la línea puede volverse bastante delgada cuando se trata de pactos y transiciones estatales, pero esas propuestas no están tan bien investigadas y podrían no ser algo que se considere deseable.
En realidad, no soy muy partidario de la forma en que Ethereum hace las cosas. Debido a que es de naturaleza computacional con la verificación incorporada, si intento realizar una operación, mi ventana podría cambiar y podría «fallar al operar», pero la transacción para el intento de operar aún era válida, por lo que igual pagué. por tarifas que desperdiciaron mi dinero en lo que me gustaría considerar una transacción fallida y espacio de bloques desperdiciado para otra persona. Otro aspecto extraño son los Oráculos en Ethereum. Los oráculos deben pagar gasolina para actualizar los precios de sus oráculos, mientras que en los DLC de Bitcoin, los oráculos están cegados y solo proporcionan una firma y no pueden ser «fijados» debido a un cambio en las tarifas, ni los oráculos pueden apuntar. a contratos específicos.
Anteriormente hablé de todas las desventajas del modelo UTXO en comparación con el modelo de cuenta y el modelo de estado global, pero lo que permite que el modelo UTXO brille es el paralelismo. La única preocupación que tiene son las transacciones secundarias al mismo UTXO, nada más importante, esto permite que el sistema escale mucho mejor.
3.
Hua:
Comenzamos a discutir los pactos ahora. ¿Qué son los pactos?
Escuela politécnica:
Los pactos suelen referirse a restricciones sobre cómo se pueden transferir las monedas. La palabra pacto parece tener algún tipo de connotación, por lo que ayuda a desmitificarla y explicarla como simples mecanismos de bloqueo que solo puedes colocar en tu *propia* moneda.
Ya tenemos dos pactos dentro de Bitcoin y alimentan Lightning Network, CSV [CheckSequenceVerify] y CLTV [CheckLockTimeVerify]. Algunos simplemente llaman a estos códigos de operación «primitivos de contrato inteligente», ya que son simples bloqueos de tiempo, pero también pueden clasificarse como acuerdos de tiempo.
CTV [CheckTemplateVerify] es una propuesta de actualización de Bitcoin y está incluida en BIP 119. Es diferente de CSV y CLTV, puedes pensar en CTV como un “TXID [Transaction ID] lock” o “UTXO lock”, solo estos TXID se pueden crear desde este bloqueo. Para CTV, nos referimos a este bloqueo TXID como «Pactos de igualdad», ya que las transacciones resultantes deben ser iguales a las transacciones originales que se confirmaron. También se le llama pacto de compromiso diferido, como puede ver, su UTXO se ha comprometido, pero aún no se ha colocado en la cadena.
La alternativa más conocida es SH_APO. [Any Previous Out or AnyPrevOut] que se centra en garantizar el compromiso de pago y al mismo tiempo permite que el método de pago sea flexible. Algunos otros discutidos son OP_CCV [also known as MATT]OP_EXPIRE, TXHASH y CLAVE DE PLANTILLA.
Hua:
Cuando mencionas que «los convenios generalmente se refieren a restricciones sobre cómo se pueden transferir las monedas», ¿puedo entenderlo así: los convenios son un método para especificar cómo se pueden usar los fondos o, en otras palabras, es una forma de restringir dónde ¿Se pueden usar los fondos? gastado.
Escuela politécnica:
Sí, efectivamente asigna el UTXO para que se distribuya de una manera específica; una vez que se compromete con él, no puede retirarlo, ahora está sujeto a consenso y solo su nuevo propietario puede decidir cómo gastar sus fondos.
Cuando se crea una UTXO en cadena, nuestro instinto es asumir que una única clave privada mantiene esa UTXO en su lugar. Pero si se trata de un UTXO vinculado a CTV, cuando se gaste el UTXO, verá un hash adicional de 32 bytes emparejado con la nueva transacción que representa el estado oculto que estaba dentro del UTXO original.
Hua:
Ha mencionado «bloqueo TXID/bloqueo UTXO» varias veces. ¿Puedo entenderlo así? Para comprender cómo CTV logra su funcionalidad, debemos comprender qué es el bloqueo TXID y cómo funciona. El bloqueo TXID es un mecanismo clave.
Escuela politécnica:
Sí, crea una base sólida para construir futuros aviones. El TXID está determinado por el contenido de un tx. Y si puedes agregar entradas a un tx, puedes manipular el TXID. CTV te permite bloquear el número de entradas y salidas. Así es como nos aseguramos de que los compromisos de CTV no sean confiables; si el TXID pudiera ser maleable, podría robar los fondos de alguien. Una vez que tenga un mecanismo de bloqueo TXID, lo puede combinar con otros mecanismos de bloqueo, como los bloqueos de tiempo, para crear contratos inteligentes aún mayores.
4.
Hua:
¿Por qué crees que los convenios son una madriguera de conejo?
Escuela politécnica:
Llamo a los convenios una madriguera de conejo porque hay muchas cosas que se pueden hacer con restricciones simples en las transacciones, como un bloqueo de tiempo o un bloqueo TXID. Hemos logrado construir toda la red Lightning con bloqueos de tiempo simples y, si bien no es perfecta, es la única L2 verdaderamente descentralizada que existe. No me gusta cómo está cambiando lentamente hacia un enfoque centrado en la custodia, pero es exactamente por eso que comencé en esta madriguera para empezar: para hacer que nuestros contratos inteligentes sean más poderosos. Nos referimos al bloqueo TXID como Plantilla. ConT aroot, obtuvimos la capacidad de tener agregación de firmas. Con Plantillas y CTV, obtenemos la capacidad de agregar transacciones.
CTV sirve como reemplazo de un oráculo de transacciones prefirmadas, que elimina los requisitos de confianza e interactividad necesarios para crear contratos inteligentes más atractivos que se necesitan para cosas como bóvedas y grupos de pagos. Las bóvedas y grupos de pagos que puedes crear con CTV son técnicamente posibles hoy en día, pero actualmente se ven pedidos por la confianza o la interactividad necesaria para que funcione. Además, con CTV podemos construir fábricas de canales, soluciones adicionales de capa 2 como Ark, Timeout-Trees, Stakechains o Surfchains, y soluciones de bonos de fidelidad JIT como PathCoin.
Probablemente mi función favorita sean los canales no interactivos. [NIC’s] a los que también nos hemos referido como Canales Fríos. La idea básica es tomar un canal de rayos normal y simplemente colocarlo en una plantilla CTV. Lo que lo diferencia de un canal Lightning normal es que ninguna de las partes necesitaba estar en línea para crear este canal. Entonces, si necesito un canal con otra persona, no necesito que esté en línea para crearlo, ¡ni siquiera necesito decirle que lo cree hasta que esté listo para gastar en él! Esto permite la capacidad de almacenamiento en frío de los rayos porque no necesito una torre de vigilancia ni un nodo para salvar mis fondos. n cualquier canal que aún no esté activo. Los coordinadores externos también pueden establecer NIC para dos personas, por lo que hay mucha flexibilidad en lo que es posible.
Tal como está, CTV no le permitirá construir un DEX dentro de la cadena, pero no estoy seguro de si eso es algo tan malo, ya que la gente actualmente está intentando construir DEX fuera de la cadena usando Lightning Network como lo es hoy. . Creo que esto se relaciona con la discusión “Verificación versus Computación”, cuánto se desea realmente en la cadena versus cuánto se necesita verificar en la cadena. Una preocupación que tengo sobre los DEX en cadena, además de las excesivas actualizaciones en cadena que generan tarifas más altas, es MEV. Ya hemos detectado algo de MEV en las transacciones DEX de BCH y, a medida que el mercado madure, esto seguramente empeorará.
Hua:
¿Puede darnos un ejemplo que nos ayude a comprender cómo funciona CTV?
Escuela politécnica:
Digamos que espero recibir 5 BTC, a partir de ahora, lo único que puedo hacer es recibir el pago y verificarlo en la cadena. Con CTV, puedo comprometerme con direcciones o personas futuras y reducirlo a una simple clave pública que le doy a mi pagador para que me pague. No conocen los detalles, por lo que sigue siendo privado para todos menos para mí. Una vez que pueda confirmar que me pagaron, todas las acciones que realicé usando la plantilla CTV también surtieron efecto.
Entonces, si hubiera elegido crear un canal con Bob, una vez que Alice me paga, el canal con Bob ahora está comprometido, aunque el canal con Bob no se ve en ninguna parte de la cadena, solo es accesible mediante mi plantilla y la transacción. . que Alice había creado. Solo lo conozco hasta que comparto los detalles del canal con Bob. Una vez que comparta los detalles con Bob, podremos usar el canal normalmente. Cuando cerramos el canal de manera cooperativa, en lugar de necesitar colocar los detalles del canal abierto en la cadena, simplemente colocamos el canal de cierre en la cadena. Esto nos permite realizar transacciones transversales, reduciendo la cantidad total de transacciones que deben estar en la cadena al menos a la mitad para las soluciones de capa 2.
La parte inicial sólo necesita un compromiso, lo que realmente nos importa son los detalles finales. Si se trata de un UTXO compartido con varias personas, también podríamos colaborar para cerrar nuestras transacciones juntas, reduciendo aún más la cantidad de transacciones en cadena.
5.
Hua:
Como mencionaste antes, podemos introducir diferentes códigos de operación para implementar convenios.
Escuela politécnica:
Entonces, si reintroducimos OP_CAT, creo que permitiría casi todos los tipos de pactos posibles, ya que se puede emular cualquier forma de introspección para TXHASH. El método más limitado sería introducir códigos de operación que representen el comportamiento explícito deseado, como con CTV, CSFS o CheckSeperateSignature. CTV es la capacidad de realizar salidas diferidas. CSFS es la capacidad de realizar firmas diferidas para que pueda diferir el pago en sí. Suenan similar y, de hecho, funcionan bien juntos como componentes básicos para permitir la simetría LN, pero los compromisos se producen en diferentes niveles.
TXHASH y TEMPLATE KEY permiten la introspección y tienen el mismo propósito, pero TEMPLATE KEY usa un modo de un solo byte mientras que TXHASH usa indicadores de varios bytes. Esto permite capacidades mucho más poderosas dentro de scripts y contratos inteligentes, pero a muchos les preocupan los efectos secundarios que podrían tener. TXHASH y TEMPLATE KEY son más bien un CTVv2, algo que haría que CTV fuera más potente y expresivo.
Hua:
He notado que no parece haber un desacuerdo significativo sobre si se debe apoyar la implementación de convenios. Sin embargo, en comparación, parece haber una divergencia más significativa entre las personas con respecto a qué método o conjunto de códigos de operación para implementar los convenios.
Escuela politécnica:
Creo que en gran parte hay diferentes campos de pensamiento. Hay mucha falta de comprensión de la intención detrás de cada propuesta, ya que tienen diferentes objetivos en mente y están diseñados de maneras completamente diferentes.
Muchos desarrolladores solo han puesto sus ojos en Lightning y en cómo evolucionará, tenderán a favorecer códigos de operación como SH_APO ya que habilitan LN-Symmetry. Para muchos desarrolladores a quienes no les gusta particularmente Lightning debido a sus limitaciones, como las restricciones de liquidez entrante o el requisito de estar en línea, tienden a preferir códigos de operación como OP_CAT, TXHASH como soluciones de escalamiento más expresivos. Los desarrolladores que prefieren CTV son más neutrales y lo ven desde un punto de vista de sistemas; No necesariamente hace nada a la perfección, pero mejora en gran medida la capacidad de todos para hacer lo que prefieren, sea lo que sea, sin introducir riesgos que no se puede medir ya que no introduce la introspección.
6.
Hua:
Antes de discutir los convenios, hablamos sobre cuestiones relacionadas con los códigos de operación en el lenguaje de secuencias de comandos y el problema de la computación limitada que conduce a la transición de estado. Ya conocemos la relación entre convenios y códigos de operación. Ahora, profundizamos en el tema de la transición estatal. No estoy seguro de si mirar los pactos desde la perspectiva de la «transición de estado» sea correcta, pero esta perspectiva realmente me fascina.
Sin convenios, la función principal del lenguaje de programación es recuperar las firmas de las transacciones y verificarlas. La transacción solo se puede completar cuando la clave privada es correcta y no existe un estado intermedio. Con los convenios, una transacción se puede completar cuando se cumplen ciertas condiciones. Además, una transacción sólo puede completarse cuando se cumplen condiciones específicas (no sólo la exactitud de la clave privada). ¿Podemos entenderlo de esta manera: los pactos proporcionan indirectamente condiciones para la transición estatal?
Escuela politécnica:
El pacto es la plantilla o el «estado». Dentro de él, necesitará crear bloqueos de tiempo y otras funciones para habilitar la funcionalidad deseada que desee, ya sea una bóveda, un canal de rayos o alguna otra solución de capa 2.
Entonces, CTV permite que se produzca la creación del estado, pero hay que reconstruir dinámicamente el estado en cada transición para mantener en homeostasis, a esto lo llamamos meta-recursivo. Mientras que algo como SH_APO le permite crear un estado y luego actualizarlo periódicamente, haciendo recursivo. CTV también puede crear una cadena de transacciones que le permitirían “superar” ese estado.
Un buen ejemplo en el que pensar es Ark, es un contrato inteligente gigante, casi como una combinación de monedas gigantes y el que ejecuta el protocolo crea un nuevo estado. [or rounds as it’s called] cada pocos segundos para facilitar que los participantes paguen a otros según sea necesario. Una vez que el operador de Ark esté listo, envíe una transacción al mempool para confirmar el estado actual en la cadena. Estos marcadores de posición en la cadena pueden considerarse como los «estados de transición». El operador tiene que volver a calcular constantemente nuevos estados para presentarlos a los participantes de Ark y lo que se envía a la cadena es la verificación de ese estado.
Hua:
¿Podemos entenderlo de esta manera: los convenios implementan una forma de contrato inteligente basada en la verificación en lugar del cálculo?
Escuela politécnica:
Si. Definitivamente. Este contrato inteligente simplemente compara una transacción con un hash sha256 asociado. La verificación de la velocidad del bloque en realidad aumentaría ya que no hay operaciones de firma.
Hua:
Una dirección de desarrollo de las cadenas de bloques es la modularidad, incluida la computación fuera de la cadena. Sin embargo, Bitcoin parece diseñado naturalmente para la computación fuera de la cadena, y aparece detrás pero en realidad lidera el camino. ¿Qué opinas?
Escuela politécnica:
El tiempo es un círculo plano. Es una locura cómo parece que hemos cerrado el círculo de lo que se busca en una cadena de bloques. Bitcoin todavía parece tener algunos problemas de modularidad y de huella. Desearía que tuviéramos mejores cadenas laterales que no fueran simplemente soluciones de múltiples firmas y usaran medios criptográficos reales para proteger los fondos y permitieran salidas unilaterales. Creo que eso ayudaría a ampliar los límites de la modularidad de Bitcoin. Taproot ha permitido aún más cálculos fuera de la cadena con cosas como BitVM, lo que nos permitiría calcular casi cualquier cosa fuera de la cadena. Pero desafortunadamente, no se pueden emular cosas dentro de Bitcoin como CTV, por lo que parece que todavía tenemos avances que hacer.
7.
Hua:
¿Qué posibilidades se pueden conseguir combinando convenios con otros códigos de operación como DLC?
Escuela politécnica:
Entonces, los DLC tienen algunos problemas que se solucionarían con cláusulas como aumentar la flexibilidad de los parámetros del DLC al hacer muchos precios. [if we’re wagering on the price of something such as Bitcoin]. Otra es que las carteras de hardware [HWW] no puede interactuar con muchos DLC, las rondas de firma de DLC y el intento de hacerlo con HWW hacen que los DLC tarden varios minutos en abrirse. Con CTV, esta demora para ingresar a un DLC se puede reducir en segundos.
8.
Hua:
¿Hay algún otro punto que le gustaría presentar a los lectores?
Escuela politécnica:
Repasamos muchos conceptos. Hablamos de cómo se puede utilizar para mitigar la demanda excesiva de espacio de bloques y posibles ataques DDOS. Discutimos cómo las personas podrían ahorrar espacio creando canales no interactivos. Creo que otro buen tema para discutir es el «problema de salida de L2». Si logramos sacar a todos de la capa L1 y llevamos a una L2 grande, actualmente no existe una buena manera de sacar a las personas de esa L2 de manera acelerada. Podríamos pensar en ese L2 como Lightning. [we call the potential mass exodus on Lightning, the «Thundering Herd problem”], o podríamos pensar en Coinbase, Binance o Liquid como L2. Hay personas que tienen derechos sobre Bitcoin, pero su única forma de adquirir ese derecho es enviando una transacción para colocarlo en la cadena. Hay millones de personas en Coinbase, no tengo idea de cómo sacarlas de allí y llevarlas a Bitcoin de manera ordenada en el entorno actual. Habría un retraso de 6 meses en el mempool intentando sacar a la gente del intercambio. CTV puede solucionar este problema.
Haz un arca o un árbol de tiempo de espera con CTV. El intercambio podría incluso ofrecer el servicio directamente. Todos podrían ser descargados del «UTXO compartido» original que estaba bajo el consenso de Coinbase y empujados a un «UTXO compartido» con un consenso de su elecc. ión, ya sea un grupo simple o un árbol de tiempo de espera grande. Aquí es donde realmente se arruga el cerebro, esto fue una conversión pura de L2 <> L2. No hubo ningún paso intermedio que me obligara a bajar primero a L1. Y puedo seguir repitiendo este proceso indefinidamente, usando cualquier capa de mi elección. No es necesario volver a la capa base a menos que me obliguen allí, como por ejemplo por un cierre no cooperativo de mi canal o tal vez por una salida de mi bóveda. El problema de Ark y Timeout-Tree es que tienen requisitos de transferencia, usted debe mover sus fondos cada pocas semanas o meses o perderá sus fondos. Esta no es una solución ideal para fondos a largo plazo, pero funciona muy bien para participaciones a corto plazo y mercados más grandes.
Me gustaría proporcionar una lista completa de cada concepto que se ha desarrollado utilizando CTV y su capacidad para agregar de forma sencilla transacciones prefirmadas: canales no interactivos, árboles de tiempo de espera, Ark, Darkpools, grupos de pagos, canales de pago, Ball Lightning. , Control de Congestión, Dpool’s, Compactación, Tree Swaps, PathCoin, Stakechains, Surfchains. Pero no pienses en estas como Plantillas independientes; Si hay una característica de una que desea incluir en otra, puede crear su propia plantilla personalizada para intentar encontrar el comportamiento deseado.
Referencias:
Los pactos de Owen 101 https://x.com/OwenKemeys/status/1741575353716326835
Los pactos de Owen 102 https://x.com/OwenKemeys/status/1744181234417140076
Demostración de CTV de Owen https://x.com/OwenKemeys/status/1752138051105493274
Manual de Dallas https://x.com/dallasirushing/status/1740443095689318566
Convenios requeridos para el procesamiento por lotes de canales Lightning https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022006.html
Arboles de tiempo de espera https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021941.html
Pozas oscuras https://gist.github.com/moonsettler/6a214f5d01148ea204e9131b86a35382
Esta es una publicación invitada de Aemlie Hua. Las opiniones expresadas son enteramente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.