Por qué CLTV fue una mala idea. por Craig Wright  

 

Por qué CLTV fue una mala idea.

Título y texto original:

 

Why CLTV was a bad idea  

Craig Wright  

08/01/2019

https://medium.com/@craig_10243/why-cltv-was-a-bad-idea-4b5d0c043e2a

https://archive.is/wNFNy

 

Podcast hecho con NoteBookLM (6:25 min)

El texto proporciona una crítica detallada de CheckLockTimeVerify (CLTV), argumentando que es una idea antigua y rechazada que fue resucitada innecesariamente en el desarrollo de Bitcoin. El autor sostiene que CLTV no es esencial y que sus funciones pueden ser mejor manejadas por nLockTime, una característica original de Bitcoin. Se enfatiza que CLTV limita la privacidad y la flexibilidad en las negociaciones de transacciones, ya que expone condiciones contractuales al público. Además, el autor sugiere que CLTV fue implementado para soportar protocolos «parásitos» como Lightning Network, los cuales, según el texto, comprometen la seguridad y la visión original de Bitcoin. En contraste, se presenta a nLockTime como una solución superior, que permite mayor control al usuario, fomenta la negociación privada entre pares y es más alineada con los principios del contrato en el derecho común.

 

 

Parece que la gente tiene la idea errónea de que los desarrolladores principales de SegWit-coin (BTC) son siquiera desarrolladores competentes que comprenden Bitcoin y buscan hacerlo funcionar. Tales extremos no pueden construirse lógicamente en la misma oración. O bien comprendieron Bitcoin y buscan subvertirlo, o bien no tienen ningún concepto de Bitcoin. Dichos desarrolladores no pueden ser competentes y comprender el sistema al mismo tiempo; los resultados y las consecuencias de sus cambios de BTC a Bitcoin descartan tal eventualidad.

CLTV o CheckLockTimeVerify no fue una idea o concepto nuevo descubierto por Core e implementado en 2015. De hecho, es una propuesta ANTIGUA rechazada que ha sido resucitada para permitir la introducción de un protocolo parásito que no tiene relación con Bitcoin (y, de hecho, no funciona; consulte Lightning Network).

OP_BLOCKNUMBER data de finales de 2010. Se discutió en foros y comunicaciones privadas con varias personas.

CLTV no es necesario. Se declaró una mala idea, una y otra vez. Sin embargo, en cuanto los ingenuos que querían jugar tomaron las riendas, decidieron experimentar y romper lo que no entendían.

CLTV no es necesario

En pocas palabras, no existe un uso válido de CLTV que sea seguro y no se pueda lograr utilizando nLockTime.Lightning no es Bitcoin, es un protocolo secundario parásito que destruye la seguridad del sistema.Por lo tanto, incluso si funcionara (nunca lo hará), no sería un caso de uso apropiado.

La creación de una transacción bloqueada por CLTV requiere plantillas y negociación entre el usuario y el comerciante. Lo mismo ocurre cuando se utiliza nLockTime.

El “proceso de construcción de plantillas” y la negociación requeridos no se respaldan directamente mediante CLTV, e incluso si se implementaran, serían complicados en la cadena y limitarían el desarrollo de protocolos adicionales dentro de Bitcoin, como pronto ilustraremos a continuación.

¿Cuál es/fue el problema?

¿Por qué surgió el concepto CLTV? Comenzó con el concepto erróneo de OP_BLOCKNUMBER (OBN en adelante). Al analizar CLTV, debemos partir del principio y preguntarnos por qué fue una mala idea en aquel entonces y por qué nunca fue necesario.

Bitcoin fue diseñado para permitir múltiples transacciones. El código es rico y permite intercambiar una gran cantidad de transacciones. El sistema es, en efecto, ilimitado.

Al explorar por qué un usuario llamado ByteCoin quería añadir OP_CODES adicionales a Bitcoin, debemos analizar la lógica errónea de la solicitud y, por una vez, responder con detalle, sin simplemente descartarla, diciendo: «No podemos ejecutar OP_BLOCKNUMBER de forma segura». Si bien es cierto que también es insatisfactorio y, por lo tanto, ha sido motivo de controversia durante la última década, suelo ser breve cuando veo algo con lo que no estoy de acuerdo y cuando me molesta que la gente no vea lo que creo que está claro. Pero el próximo año intentaré corregir la falta de claridad (aunque responderé brevemente a los trolls).

La explicación que ofrecí era correcta. Tampoco fue suficiente. La respuesta ofrecida es como cuando uno habla con niños: fue abrupta y terminó. Incluso podría considerarse condescendiente y sin la suficiente sustancia como para que muchos comprendieran el sistema y lo desarrollaran. Así que llega una década tarde, pero ya se puede abordar. Es demasiado tarde para BTC, pero con Bitcoin, solo puede haber uno.

Analicemos ahora la respuesta de Bytecoin tal como debería haberse abordado hace casi una década.

• En este momento, si haces un pago a alguien pero esa persona ha vaciado su billetera, las monedas se pierden irremediablemente.

El dicho era cierto hasta cierto punto, pero también es un non sequitur . He presentado varios documentos sobre diversas técnicas de umbral que permitirán a los usuarios proteger sus claves, pero no justifican el CLTV ni ningún otro bloqueo temporal en cadena.

Cuando se explica en detalle es realmente sencillo.

El concepto general para bloquear temporalmente una transacción con nLockTime es que se puede tener una transacción que permita su recuperación posterior, donde los valores se almacenan en la cadena. Por lo tanto, con nLockTime , Alice y Bob podrían crear una transacción válida solo después de un tiempo o una altura de bloque determinados.

Supongamos que Alice y Bob desean realizar una transacción. En este escenario, Bob está realizando un trabajo para Alice, y Alice ha acordado pagarle por ello. Para comprometer los fondos al contrato, Alice realiza su pago en una transacción 2×2. Es fundamental que Alice tenga la seguridad de que, si Bob no realiza el trabajo, podrá recuperar su dinero. Esto significa que puede recuperar el depósito realizado, pero solo después de transcurrido el plazo acordado. Para ello, Alice le pide a Bob que firme una transacción de devolución desde la dirección de depósito en garantía 2×2, que Alice aún no ha recibido.

Por lo tanto, podemos crear una transacción 2×2 para financiarla y garantizar la devolución de los fondos si Bob no completa su tarea correctamente. Alice puede pedirle a Bob que firme una transacción de devolución. Esta transacción puede configurarse de forma que Bob reciba el pago si completa la tarea.

Así que podemos decir que si Alice desea realizar la típica transacción bloqueada de CLTV, siempre puede hacerlo usando nLockTime, pero sin las complicaciones de CLTV. Al hacerlo, Alice desea enviar un pago a Bob, pero también establecer una condición para recuperar sus fondos si el contrato no se ejecuta. Puede usar un rompecabezas hash o incluso una condición de depósito en garantía que permita a Bob y Alice establecer un mediador por adelantado. Cuando Bob completa una tarea, Alice y Bob realizan un intercambio que permite a Alice acceder a sus bienes y a Bob recibir el pago.

Al mismo tiempo, ¿qué pasa si Bob no cumple con su parte del trato? Bueno, con un bloqueo de tiempo, Alice podrá recuperar su depósito de entrada más adelante. En CLTV, la idea es crear una transacción cuyo valor de retorno se encuentra dentro del script. Es necesario tener toda la lógica configurada de antemano, y esta es pública y visible.

La lógica de un sistema así debería estar en la billetera.

La billetera debe guardar la transacción que ha sido parcialmente firmada por Bob y ahora está disponible para que Alice la envíe si el pago se debe revertir por cualquier motivo.

¿Qué pasa si Alice pierde la transacción de reembolso firmada?

Esta es la respuesta típica a la necesidad de introducir CTLV y sus variantes en la cadena. Como dije, es una falacia lógica.

• La transacción nTimeLock (y posiblemente también nSequence-locked) es un archivo.
• La clave privada que usa Alice es un archivo.

Si Alice puede perder la transacción, también puede perder la clave privada. Ambas son archivos. En el ejemplo, CLTV se vende como requisito, ya que permite a Alice recuperarla posteriormente y no necesita guardar la transacción firmada de Bob. Sin embargo, lo que se pasa por alto es que Alice debe conservar la clave que se utiliza para acceder a los fondos bloqueados por CLTV, y dicha clave es un archivo.

Entonces, Alice de alguna manera tiene que encontrar los medios para proteger una transacción que está vinculada a un archivo que necesita proteger…

Alice puede proteger fácilmente la transacción bloqueada de Bob. En el uso correcto de las claves en Bitcoin, Alice y Bob usan la clave pública una sola vez. Su identidad queda protegida del mundo. Si Alice publica la transacción que Bob firmó en un foro público, podría hacerse de forma que no revele su identidad. De hecho, es mucho más sencillo guardar un archivo que con el tiempo será público que tener que exigir modificaciones del script y restringir a los usuarios a un subconjunto limitado de sus posibilidades. Por ejemplo, las partes pueden permitir modificaciones del script e incluso negociar puntos alternativos dentro del contrato. El proceso puede incluir el importe o las condiciones. En la práctica, muchos problemas que no se pueden resolver simplemente surgen después. Si queremos evitar que se recurra a los tribunales para resolver disputas, debemos permitir que las partes de un acuerdo sigan teniendo la oportunidad de negociar. Cabe destacar que he mencionado la oportunidad de negociar, ya que las partes no necesitan hacerlo.

Es un camino muy estrecho el que hay que recorrer cuando se trata de establecer cómo crees que los demás deberían operar, y es un camino que conduce al fracaso.

Alice también tiene más libertad que en el caso CLTV

Bob y Alice pueden continuar negociando, donde Alice sabe que puede recuperar sus fondos en su totalidad en cualquier momento. Bob no tiene forma de gastar la transacción sin la intervención de Alice, por lo que, una vez vencido el valor de nLockTime, Alice tiene todo el poder. Puede avalar y luego gastar la transacción para recuperar sus fondos o volver con Bob para negociar.

Alice debe mantener los archivos. Perder el acceso a la clave utilizada para canjear la transacción la convierte en perdida, lo cual no importa si la transacción se realiza en cadena en CLTV o no. Alice necesita tener acceso a un archivo seguro. Por lo tanto, lo anterior no es un argumento válido para CLTV. Es, como se mencionó, un non sequitur .

Gran parte de lo que parece argumentarse proviene de una comprensión errónea de qué es Bitcoin y cómo funciona. Peor aún, gran parte de ello se ve contaminado por una comprensión errónea de lo que algunos creen que debería ser Bitcoin. Bitcoin no es una implementación del sistema anarquista de Tim May. Está lejos de ser anónimo, y no puede serlo. Bitcoin es privado y está diseñado para funcionar dentro de los marcos legales del derecho consuetudinario que definen el dinero y el comercio.

• De manera similar, si la red se inunda con transacciones con una tarifa de 0,01 y usted realiza un pago urgente pero olvida incluir una tarifa más alta, entonces no podrá volver a emitir ese pago respaldado por las mismas monedas pero con una tarifa.

De nuevo, tenemos un argumento lógicamente defectuoso: si la red se satura, no se puede enviar una alternativa en ningún caso. Por lo tanto, también es un non sequitur . Es más, ni siquiera describe cómo debería funcionar Bitcoin, sino el concepto de límite máximo que promueve la moneda SegWit; no refleja cómo está diseñado Bitcoin.

Aquí, la solución CLTV no tiene relación con el problema planteado en la publicación original.

Más importante aún, CLTV y las ideas mencionadas anteriormente no te ayudan en este caso. Si realizas una transacción y las comisiones son demasiado bajas, establecer un tiempo de vencimiento a la altura del bloque la convierte en algo que ningún comerciante en su sano juicio tocaría. Con nLockTime, un comerciante puede tener una transacción encadenada, o puedes esperar. El concepto de reemplazo por comisión es defectuoso, y si se hubiera utilizado nSequence (en un intercambio contractual acordado con un comerciante), todas las partes podrían haber logrado el resultado previsto en la versión original de Bitcoin.

Si nos desvelamos por los comentarios de la publicación original, quizá intuyamos que el misterioso método CLTV con la solución propuesta quizá consistía en enviar una transacción CLTV que duplica el gasto original con una comisión mucho mayor. Pero, de nuevo, ¿para qué necesitaríamos CLTV? Simplemente reemplazarlo con una comisión más alta. Así que la conexión con CLTV sigue sin estar clara. Es otra solución que busca un problema.

• Si pudieras hacer que el número de bloque actual se coloque en la pila y hacer algunos cálculos con él, entonces podrías implementar un pago que debe gastarse por el destinatario antes de que se alcance un cierto número de bloque o, de lo contrario, el script permitiría que el remitente lo gaste nuevamente, por ejemplo.

En la publicación original de 2010, la preocupación era que se pudiera construir una transacción que enviara datos de una entrada válida a una salida no válida. Pero, ¿cómo ayuda CLTV en este caso? Si no se construye una transacción que pueda recuperarse, CLTV no servirá de nada.

Esto tampoco es un problema. Si está negociando, envíe el valor firmado que permite que la transacción nLockTime se use como transacción de canje.

La idea, de nuevo, de perder el archivo tampoco es preocupante, ya que, si se pierde la transacción de canje, sería lo mismo que perder la clave. La falsa idea de que se pierde un archivo pero no otro, o que, en un solo almacén, la clave está segura, pero se pierde la transacción, es simplemente absurda. Lo siento, no hay otra forma de decirlo. La transacción de canje podría guardarse en la misma base de datos o archivo que las claves. Perder la transacción también es perder la clave.

Por lo tanto, ni siquiera tener CLTV mitiga las pérdidas. Decir lo contrario sería engañoso.

Al menos Mike Hearn lo consiguió .

Bitcoin no es PGP

Bitcoin no es una red de confianza, y las claves no se protegen de la misma manera que en PGP. De hecho, la idea es mantener la clave pública privada y crear una dirección y un par de claves únicamente para una única interacción. La identidad no se utiliza en Bitcoin. Es un proceso independiente del protocolo Bitcoin.

Hay formas de permitir el uso privado de la identidad, pero por ahora habrá que esperar ya que las solicitudes de patentes necesitan madurar un poco más.

Uso de nLockTime

El proceso se documentó muchas veces, pero me referiré a uno aquí . En resumen, todos los problemas que los promotores de CLTV planteaban se pueden solucionar con nLockTime, de una manera mucho más sencilla y elegante. Además, permite al desarrollador explorar y crear sin estar limitado por los límites del protocolo.

La última línea es importante. No todas las negociaciones deben realizarse en la cadena; basta con que lo hagan las transacciones completadas y liquidadas.

Bitcoin no es peer to peer, como cuando los usuarios gestionan nodos; los nodos siempre son mineros. En Bitcoin, los nodos no forman parte del proceso peer, sino los usuarios. nLockTime siempre ha sido superior a CLTV, incluso eliminando los problemas de seguridad de CLTV, ya que nLockTime permitía una mayor interacción entre las partes. Es decir, los pares pueden actuar como pares: negociar en todo momento sin ser forzados.

Las billeteras necesitan tener una lógica más inteligente.

Una billetera que guarde la transacción que aún no se ha transmitido y que proteja, ofrecería mucho más valor que CLTV. Bitcoin está diseñado para ser simple en su núcleo; la lógica puede entonces, como en internet, crearse en la periferia. Generar complejidad innecesaria debilita el sistema.

CLTV y las variantes anteriores son una combinación de locura y estupidez anarquistas, añadidas para permitir un ataque contra Bitcoin, también conocido como Lightning. Es todo lo que permiten. La capacidad de Bitcoin para operar se vio mermada. Se invirtió mucho esfuerzo en crear un sistema para que unas pocas personas que nunca serían contratadas en el mundo real pudieran decir que habían «arreglado» Bitcoin.

Los mineros no son iguales

Es una falacia grave que debe terminar.

En Bitcoin, los mineros no son quienes determinan qué ocurre en una transacción, sino los usuarios. Los mineros validan y liquidan el sistema, y mantienen la seguridad, garantizando que las transacciones se ordenen correctamente y que no se produzcan gastos duplicados. Los mineros garantizan que el protocolo base no cambie, que sea estable e inmutable.

Los mineros no son quienes deciden qué se contrata y qué no. Siempre que se cumplan las reglas del protocolo y se pague la tarifa requerida, los mineros incorporan las transacciones. Los mineros desconocen quiénes son los individuos y no tienen forma de vincular las claves públicas con la identidad. Esto es algo que Core permitió cuando creó el falso mito de la conservación de claves.

Los usuarios necesitan tener acceso a las claves asociadas a las monedas no gastadas. No necesitan tener acceso a todas las claves que han usado, ni deberían tenerlo.

Mi artículo ya es más extenso de lo previsto, así que el tema se relegará a un tema posterior. Por ejemplo, el concepto de que una plataforma de intercambio envíe las monedas de retiro a una dirección antigua te deja en la posibilidad de no poder demostrar la integridad de la transacción o de que ya no tengas las claves. El modelo de «pagar a una dirección registrada» debe revisarse y modificarse.

Los usuarios pueden, y de hecho, mantener archivos. Deben hacerlo, independientemente de si tienen CLTV o simplemente una clave privada. Por lo tanto, el argumento falaz de que mantener una transacción firmada bloqueada para su posterior difusión mediante nLockTime reduce de alguna manera la funcionalidad de Bitcoin es erróneo; CLTV reduce el nivel de control, lo que resulta en una forma errónea de desprecio paternalista hacia el usuario, totalmente inapropiada. Dado que el usuario debe mantener un archivo (la clave privada) de forma segura, afirmar que podría perder la transacción o no poder enviarla es simplemente engañoso.

• Si el usuario no puede acceder a la clave, no podrá acceder a los fondos en una transacción bloqueada por CLTV.
• Si el usuario no puede enviar una transacción firmada a la cadena de bloques, entonces no podrá canjear los fondos en una transacción basada en CLTV.
• Entonces, si puedes enviar un archivo, una transacción a la blockchain para canjear CLTV, también puedes canjearlo usando nLockTime.

Con CLTV, una vez que la transacción se incorpora a la cadena de bloques, el contrato queda establecido. Tanto Alice como Bob tienen las manos atadas. Pueden añadir una transacción independiente posteriormente si desean renegociarla, pero al hacerlo también se introducen aspectos de confianza.

Si Alice tiene una transacción firmada por Bob, este no puede forzar su envío ni necesita hacer nada. Bob puede negociar con Alice e intentar convencerla de que no envíe la transacción mientras negocian. Mientras la negociación está en curso, Alice puede finalizarla en cualquier momento enviando la transacción firmada por Bob.

Bob ahora sabe que Alice puede hacerlo y que no puede impedirle ofrecerle algo de valor.

nLockTime, además de ser más seguro, también es más justo y equitativo, y sigue el proceso de negociación de contratos estándar que se utiliza en el mundo del derecho consuetudinario.

Privacidad… CLTV la pierde

En CLTV, las condiciones se publican en el script con antelación. Con nLockTime, las partes de una transacción tienen varias opciones de script de canje que no se publican con antelación. Alice puede tener varias transacciones posibles firmadas por Bob. Solo las que se utilizan se hacen públicas.

En consecuencia, un intercambio entre Alice y Bob, como un proceso entre pares, es mucho más privado de lo que CLTV podría aspirar a ser. Con CLTV, todas las condiciones están a la vista del mundo. Para siempre.

CLTV es menos potente que nLockTime

nLockTime es más seguro, más privado y más potente que CLTV.

En nuestro ejemplo, tenemos un conjunto limitado de condiciones que se pueden usar en una transacción basada en CLTV, y todas se establecen con antelación. Sin embargo, nLockTime permite a Alice y Bob cambiar de opinión y renegociar hasta que se liquide la transacción en la blockchain.

Por ejemplo, en el ejemplo del contrato 2 de 2 anterior, supongamos que Alice posee un script de canje firmado por Bob, cuyo valor de nLockTime está establecido para dentro de 10 días. Alice puede volver con Bob y negociar en cualquier momento hasta el proceso final, sabiendo que puede recuperarlo el día 10.

Alice también puede acudir a Bob después del día 10 y negociar, sabiendo que tiene una alternativa para recuperar los fondos.

Pero, en nuestro escenario actual, Alice puede acudir a Bob en los días 7, 8 y 9 e intentar cerrar un nuevo acuerdo. El guion de redención firmado, que debía vencer en el día 10, ya no tiene por qué revelarse. Si Bob y Alice concluyen una negociación en el día 9, esto es lo que se publica. Nada de lo que Bob y Alice hubieran hecho tendría que hacerse público.

En tal escenario, tanto Alice como Bob tienen la capacidad de negociar entre sí, y el derecho se mantiene hasta que la transacción se finaliza y se codifica en un bloque.

Es algo bueno. Entiendo que a quienes buscan el socialismo y la anarquía no les guste el concepto de libre contratación, pero es fundamental para el comercio.

¡MÁS PODER!

Imagina que hay más opciones en el script. Alice, Bob y Charlie están negociando. Cada uno puede establecer diversas condiciones que cumplen nLockTime y que no pueden enviarse antes de una hora predefinida.

Alice puede tener un guión firmado por Bob a los 10 minutos y uno por Charlie a los 15 minutos, y otro posterior firmado por Bob y Charlie a los 17,5 minutos.

Bob podría tener un guión firmado por Alice que sea válido con condiciones a partir del minuto 11 y otro firmado por Alice y Charlie a los 20 minutos.

Al permitir que la billetera controle un nivel de procesamiento y devuelva el control del sistema a los usuarios, se vuelve más poderosa y flexible de lo que CLTV podría esperar lograr.

Conclusión

Había muchas áreas del código y sistema original de Bitcoin que necesitaban mejoras. La calidad del código distaba mucho de ser la deseable, y el sistema no estaba completo, con muchos fragmentos por finalizar. Pero Bitcoin, como protocolo, estaba completo, y los cambios realizados por los desarrolladores principales no han ayudado en absoluto.

Es hora de devolver a Bitcoin a lo que era, y con el cliente SV lo haremos.

Además de una nueva idea que pueda servir para crear un nuevo negocio, detallaré semanalmente los errores en las ideas relacionadas con Bitcoin. Debería haberlo hecho hace tiempo. Lamento no haberlo hecho antes.