Checklocktimeverify, o cómo un parche time-lock aumentará el potencial de bitcoin

100% Miners, 80% Masternodes, & Spork Still on Horizon | DASH: Detailed (Junio 2019).

Anonim

CheckLockTimeVerify (CLTV) se ha fusionado en Bitcoin Core. Esto generalmente se considera una gran noticia, porque significa que el potencial de Bitcoin ha mejorado drásticamente. En particular, el parche propuesto por el desarrollador de Bitcoin Core Peter Todd permite establecer correctamente los canales de pago. Esto significa que los usuarios de Bitcoin podrán realizar transacciones de forma más económica, rápida y con un volumen superior al habitual, manteniendo al mismo tiempo todas las ventajas ofrecidas por el blockchain.

¿Qué es CheckLockTimeVerify?

El concepto de CLTV es bastante simple. Básicamente, permite a los usuarios crear una transacción bitcoin cuyos resultados de transacción solo se pueden gastar en algún momento en el futuro. Como tal, el bitcoin enviado en esa transacción está bloqueado en el tiempo hasta una fecha especificada, o hasta que se haya extraído un cierto número de bloques.

Esto en sí mismo es una adición ordenada que se puede usar para varios propósitos. Sería fácil, por ejemplo, que un padre le otorgue a su hijo un regalo de bitcoin, pero que el hijo solo podría usar cuando cumpla 18 años. O tal vez podría usarse para pagar el alquiler en una fecha específica.

Este tipo de aplicaciones son relativamente sencillas. Pero CLTV se vuelve realmente interesante cuando se combina con trucos adicionales de Bitcoin.

¿Qué son los canales de pago?

Como quizás sea su función más importante, CLTV es necesaria para canales de pago funcionalmente adecuados. Estos canales son efectivamente una serie de & ldquo; fuera de la cadena y rdquo; transacciones, que se benefician de toda la seguridad de las transacciones típicas en cadena, y con algunos beneficios adicionales.

Digamos que Bob transmite un video, que cuesta un satoshi por segundo para mirar, y Alice quiere ver ese video. No sería una buena idea usar transacciones regulares de bitcoin que valgan un satoshi por cada segundo individual transmitido, ya que una tarifa de transacción típica cuesta más de un satoshi, y las transacciones solo confirman una vez cada 10 minutos en promedio. Además de eso, la red de Bitcoin se limita actualmente a un puñado de transacciones por segundo, lo que significa que las transacciones de Alice representarán una carga enorme para el sistema. Además, solo un puñado de personas podría ver el flujo de Bob al mismo tiempo antes de que toda la red Bitcoin se bloqueara.

Por lo tanto, Alice y Bob deciden abrir un canal de pago en su lugar. Antes de que ella comience a mirar el video, Alice envía, digamos, un bitcoin a una dirección de múltiples firmas. Y Alice y Bob controlan cada una de las dos claves necesarias para enviar fondos desde esa dirección.

Ahora, Alice quiere comenzar a mirar el video. Ella firma una transacción desde la dirección multigota, en la que envía 99,, satoshi a ella, y un satoshi a Bob. Ahora, Bob podría firmar esta transacción en cualquier momento y reclamar el satoshi que se le atribuye. Por lo tanto, permite que Alice vea un segundo de su transmisión.

Sin embargo, y lo que es más importante, Bob en realidad no reclama su satoshi de inmediato, porque cree que Alice probablemente quiera mirar más de un segundo. Y aquí viene el truco: Alice firma una nueva transacción desde la misma dirección múltiple, esta vez enviándose a sí misma 99,, 998 satoshi, y enviando a Bob 2 satoshi. Una vez más, Bob podría firmar esta transacción en cualquier momento y reclamar los dos satoshi que se le atribuyeron. ¡Pero no pudo firmar y transmitir ambas transacciones, ya que eso constituiría un gasto doble! Por lo tanto, él debería elegir. Y a menos que Bob esté interesado en perder dinero, siempre firmaría la transacción más grande. Si lo hace, recibirá efectivamente un satoshi por segundo, a pesar de que en realidad no recibió una nueva transacción que valga un solo satoshi por segundo.

Este proceso puede repetirse siempre que Bob no firme su parte de las transacciones. Entonces, por cada segundo que Alice ve el video, Bob puede reclamar un satoshi adicional, sin necesidad de esperar confirmaciones en la cadena de bloques. Y dado que solo una transacción, la última para que Bob lo reclame, se registra realmente en la cadena de bloques, Alice y Bob no obstruyen la red de Bitcoin con micro transacciones, y deben pagar solo una tarifa de minería.

¿Por qué los canales de pago requieren CLTV?

Hay un problema. ¿Qué pasa si, por alguna razón imprevisible, Bob no puede o no va a transmitir la transacción? Tal vez porque se cae de un precipicio, o pierde su llave privada, o tal vez tiene el rescate de Bitcoin de Alice y exige un corte más grande, o alguna otra razón. En ese caso, Alice habrá perdido su bitcoin, incluso si no ha visto el video de Bob el tiempo suficiente para que valga la pena un bitcoin.

Aquí es donde entra CLTV.

Alice puede agregar CLTV a la transacción inicial de bitcoin, usándola para enviar todo el bitcoin a su propia dirección. Esta transacción se valida, por ejemplo, un día más tarde, pero solo si Alice y Bob no firmaron la transacción de firma múltiple antes de esa fecha. Ahora, si Bob no firma la transacción en absoluto por el motivo que sea, Alicia puede firmarla por su cuenta y se le garantiza que le devolverá el dinero.

El peor escenario para Alice es que tendría que esperar un día. Ella puede estar un poco molesta, pero no perderá dinero. Como tal, todo el proceso se ha hecho completamente inseguro.

Activación

Como nota final, debe mencionarse que el concepto de CLTV en realidad no es nuevo en absoluto; ha existido en Bitcoin desde los primeros días. Sin embargo, con la encarnación anterior del concepto de tiempo limitado, las transacciones bloqueadas no se incluyeron realmente en el blockchain hasta cierto punto en el tiempo. Más bien, fueron mantenidos por Alice y (más importante) Bob, para transmitir a través de la red de Bitcoin una vez que el bloqueo de tiempo expiró.

Al combinarlo con el protocolo tal como lo hace CLTV, el proceso del canal de pago se racionaliza mejor y es más sólido. Quizás lo más importante es que desactiva las fallas del canal de pago causadas por la maleabilidad de las transacciones.

Aunque CLTV se fusionó oficialmente con Bitcoin Core ahora, todavía no se usa. En primer lugar, se implementará con la última versión de Bitcoin Core: 0. 12. Esto está programado para principios de 2016. Alternativamente, CLTV podría implementarse en una actualización de Bitcoin Core 0. 11, en cuyo caso CLTV estará disponible en una fecha anterior (hasta ahora no especificada).

Después de eso, una gran mayoría de los mineros de Bitcoin, el 75 por ciento de la potencia de hashing, necesitarán indicar que están listos y preparados para permitir CLTV. Parece poco probable que cause muchos problemas, ya que no existe una oposición real al parche.

Gracias al CTO de Blocktrail Ruben de Vries y al CEO de Bitonic Jouke Hofman por sus comentarios.