mirror of
https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git
synced 2025-06-08 16:36:32 +00:00
Merge pull request #280 from csralvall/spanish-11
Create chapter 11 spanish translation
This commit is contained in:
Shannon Appelcline
GitHub
commit
816fb4055a
@ -0,0 +1,23 @@
|
||||
# Capitulo 11: Potenciando Bloqueos de Tiempo con Bitcoin Scripts
|
||||
|
||||
La mejora que introdujo `nLockTime` en [§8.1](08_1_Enviando_una_Transaccion_con_Bloqueo_de_Tiempo.md) fue solo el comienzo del principio de los bloqueos de tiempo. Cuando comienza a escribir Bitcoin Scripts, dispone de dos opcodes de bloqueo de tiempo.
|
||||
|
||||
## Objetivos para este Capitulo
|
||||
|
||||
Después de trabajar en este capítulo, un desarrollador podrá:
|
||||
|
||||
* Decidir cual bloqueo de tiempo usar.
|
||||
* Crear Scripts con CLTV.
|
||||
* Crear Scripts con CSV.
|
||||
|
||||
Los objetivos de apoyo incluyen la capacidad de:
|
||||
|
||||
* Entender las diferencias entre los diferentes bloqueos de tiempo.
|
||||
* Generar tiempos relativos.
|
||||
|
||||
## Tabla de contenido:
|
||||
|
||||
* [Sección Uno: Entendiendo las Opciones de los Bloqueos de Tiempo](11_1_Entendiendo_las_Opciones_de_los_Bloqueos_de_Tiempo.md)
|
||||
* [Sección Dos: Usando CLTV en Scripts](11_2_Usando_CLTV_en_Scripts.md)
|
||||
* [Sección Tres: Usando CSV en Scripts](11_3_Usando_CSV_en_Scripts.md)
|
||||
|
||||
@ -0,0 +1,49 @@
|
||||
# 11.1: Entendiendo las Opciones de los Bloqueos de Tiempo
|
||||
|
||||
En [§8.1: Enviando una Transacción con Bloqueo de Tiempo](08_1_Enviando_una_Transaccion_con_Bloqueo_de_Tiempo.md), `nLocktime` ofrecía una gran primera opción para bloquear transacciones así no podían ser gastadas hasta cierto punto en el futuro - basado tanto en el tiempo como en la altura de bloque. Pero, este no es el único modo de poner un bloqueo temporal sobre una transacción.
|
||||
|
||||
## Comprender las Limitaciones de nLockTime
|
||||
|
||||
`nLockTime` es una forma simple y poderosa de bloquear una transacción, pero tiene algunas limitaciones:
|
||||
|
||||
1. **No División.** `nLocktime` bloquea la transacción completa.
|
||||
2. **No Retransmisión.** La mayoría de los nodos modernos no aceptaran un `nLockTime` dentro de la mempool hasta que este casi finalizado.
|
||||
3. **No Scripts.** El original, simple uso de `nLockTime` no permitía su utilización en Scripts.
|
||||
4. **No Protección.** `nLockTime` permite que los fondos sean gastados con una transacción diferente, no bloqueada.
|
||||
|
||||
El último item era el factor decisivo para `nLockTime`. Este prevenía una transacción de ser gastada, pero no prevenía que los mismos fondos fueran usados en una transacción diferente. Es decir, tenía sus casos de uso, pero todo dependía de la confianza.
|
||||
|
||||
## Comprender las Posibilidades de los Scripts con Bloqueos de Tiempo
|
||||
|
||||
En años mas recientes, Bitcoin Core se ha expandido para permitir la manipulación de los bloqueos de tiempo al nivel de opcode con _OP_CHECKLOCKTIMEVERIFY_ (CLTV) y _OP_CHECKSEQUENCEVERIFY_ (CSV). Ambos trabajan bajo una nueva metodología que potencia aún más a Bitcoin.
|
||||
|
||||
_Son Opcodes._ Porque son opcodes, CLTV y CSV pueden ser usados como parte de condiciones de canje mas complejas. Habitualmente son relacionadas con condicionales descriptos en el próximo capítulo.
|
||||
|
||||
_Bloquean Outputs._ Porque son opcodes que son incluidos en las transacciones como parte de `sigPubKey`, solo bloquean un solo output. Esto significa que las transacciones son aceptadas en toda la red Bitcoin y que los UTXOs usados para financiar esas transacciones son gastados. No hay vuelta atrás en una transacción temporalmente bloqueada con CLTV o CSV como hay con una simple `nLockTime`. Volver a gastar los UTXO resultantes requiere entonces que las condiciones del bloqueo de tiempo sean satisfechas.
|
||||
|
||||
Aquí hay un obstáculo para usar bloqueos de tiempo: _Son bloqueos de una vía._ Los Bloqueos de tiempo están diseñados para desbloquear fondos en un cierto tiempo. No pueden re-bloquear un fondo: una vez que un fondo bloqueado temporalmente se desbloquea, va a permanecer siempre disponible para gastar.
|
||||
|
||||
### Comprender las Posibilidades de CLTV
|
||||
|
||||
_OP_CHECKLOCKTIMEVERIFY_ o CLTV es compatible con el clásico `nLockTime`, pero en el nuevo paradigma basado en opcodes. Permite a un UTXO volverse accesible en un cierto tiempo o a una cierta altura de bloque.
|
||||
|
||||
CLTV fue detallado inicialmente en [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki).
|
||||
|
||||
### Comprender las Posibilidades de CSV
|
||||
|
||||
_OP_CHECKSEQUENCEVERIFY_ o CSV depende de un nuevo tipo de "bloqueo de tiempo relativo", el cual es configurado en el campo _nSequence_ de la transacción. Como siempre, puede ser configurado tanto con tiempo como con altura de bloque. Si es configurado como tiempo, "n", entonces una transacción con bloqueo de tiempo relativo es gastable "n x 512" segundos después de que su UTXO fue minado, y si es configurado como bloque, "n", entonces una transacción con bloqueo de tiempo es gastable "n" bloques después de que su UTXO fue minado.
|
||||
|
||||
El uso de `nSequence` para bloqueos de tiempo relativos fue detallado por primera vez en [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), luego el opcode CSV fue agregado en [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki).
|
||||
|
||||
## Resumen: Entendiendo las Opciones de los Bloqueos de Tiempo
|
||||
|
||||
Tiene ahora 4 opciones de Bloqueo de Tiempo:
|
||||
|
||||
* `nLockTime` para mantener una transacción fuera de la cadena de bloques hasta un tiempo específico.
|
||||
* `nSequence` para mantener una transacción fuera de la cadena de bloques hasta un tiempo relativo.
|
||||
* CLTV para hacer un UTXO no gastable hasta un tiempo específico.
|
||||
* CSV para hacer un UTXO no gastable hasta un tiempo relativo.
|
||||
|
||||
## ¿Que sigue?
|
||||
|
||||
Continúe "Potenciando los Bloqueos de Tiempo" con [§11.2: Usando CLTV en Scripts](11_2_Usando_CLTV_en_Scripts.md).
|
||||
152
es/11_2_Usando_CLTV_en_Scripts.md
Normal file
152
es/11_2_Usando_CLTV_en_Scripts.md
Normal file
@ -0,0 +1,152 @@
|
||||
# 11.2: Usando CLTV en Scripts
|
||||
|
||||
`OP_CHECKLOCKTIMEVERIFY` (o CLTV) es el complemento natural a `nLockTime`. Este traslada la idea de transacciones bloqueantes por tiempo absoluto o altura de bloques al reino de los opcodes, permitiendo el bloqueo de UTXOs individuales.
|
||||
|
||||
> :warning: **ADVERTENCIA DE VERSIÓN:** CLTV fue lanzado con Bitcoin Core 0.11.2, pero debería estar ampliamente implementado en este momento.
|
||||
|
||||
## Recordar nLockTime
|
||||
|
||||
Antes de profundizar en CLTV, primero debe recordar como funciona `nLockTime`.
|
||||
|
||||
Como fue detallado en [§8.1: Enviando una Transacción con Bloqueo de Tiempo](08_1_Enviando_una_Transaccion_con_Bloqueo_de_Tiempo.md), el bloqueo de tiempo es habilitado configurando dos variables, `nLockTime` y `nSequence`. `nSequence` debe ser configurada a menos de 0xffffffff (habitualmente: 0xffffffff-1), luego el `nLockTime` es interpretado como sigue:
|
||||
|
||||
* Si el `nLockTime` es menor que 500 millones, es interpretado como altura de bloque.
|
||||
* Si el `nLockTime` es 500 millones o mas, es interpretado como una estampa de tiempo UNIX.
|
||||
|
||||
Una transacción con `nLockTime` configurado no puede ser gastada (o incluso puesta en la cadena de bloques) hasta que la altura de bloque o tiempo es alcanzado. Mientras tanto, la transacción puede ser cancelada gastando cualquiera de los UTXOs que forman la transacción.
|
||||
|
||||
## Comprender el opcode CLTV
|
||||
|
||||
`OP_CHECKLOCKTIMEVERIFY` funciona dentro del mismo paradigma de las alturas de bloques absolutas o los tiempos absolutos UNIX, pero este se ejecuta como parte de un Bitcoin Script. Este lee un argumento, el cual puede ser la altura de bloque o el tiempo absoluto UNIX. A través de una complicada metodología, compara esos argumentos con el tiempo actual. Si es anterior, el script falla; si la condición es cumplida, el script continua.
|
||||
|
||||
A raíz de que CLTV es solo parte de un script (y presumiblemente parte de una transacción P2SH), una transacción CLTV no es dejada fuera de la mempool como las transacciones `nLockTime`; tan pronto como es verificada, es incluida en la cadena de bloques y los fondos se consideran gastados. El truco es que todos los outputs que fueron bloqueados con CLTV no se encuentran disponibles para _gastar nuevamente_ hasta que CLTV lo permita.
|
||||
|
||||
### Comprender el Tiempo Absoluto de CLTV.
|
||||
|
||||
Así es como `OP_CHECKLOCKTIMEVERIFY` se usaría como chequeo comparando con el 24 de Mayo de 2017:
|
||||
```
|
||||
1495652013 OP_CHECKLOCKTIMEVERIFY
|
||||
```
|
||||
Pero, usualmente representaremos esta abstracción de la siguiente manera:
|
||||
```
|
||||
<24 de Mayo de 2017> OP_CHECKLOCKTIMEVERIFY
|
||||
```
|
||||
O la siguiente:
|
||||
```
|
||||
<Tiempo Absoluto> OP_CHECKLOCKTIMEVERIFY
|
||||
```
|
||||
|
||||
### Comprender la Altura Absoluta de Bloque de CLTV
|
||||
|
||||
Así es como `OPCHECKLOCKTIMEVERIFY` se chequearía contra la altura de bloque que fue alcanzada el 24 de Mayo de 2017:
|
||||
```
|
||||
467951 OP_CHECKLOCKTIMEVERIFY
|
||||
```
|
||||
Pero, usualmente, lo abstraeremos de la siguiente manera:
|
||||
```
|
||||
<AlturaAbsolutaDeBloque> OP_CHECKLOCKTIMEVERIFY
|
||||
```
|
||||
|
||||
### Comprender Como Realmente Funciona CLTV
|
||||
|
||||
La explicación de arriba es suficiente para usar y entender CLTV. Sin embargo, [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki), expone todos los detalles.
|
||||
|
||||
Un script bloqueante solo permitirá a una transacción volver a gastar un UTXO bloqueado con CLTV si `OP_CHECKLOCKTIMEVALUE` verifica todo lo siguiente:
|
||||
|
||||
* El campo `nSequence` debe ser configurado a menos de 0xffffffff, usualmente 0xfffffffff-1, para evitar conflictos con los bloqueos de tiempo relativos.
|
||||
* CLTV debe sacar un operando fuera de la pila y este debe ser mayor o igual a 0.
|
||||
* Tanto el operando de la pila como `nLockTime` deben estar sobre o debajo de los 500 millones, para representar el mismo tipo de bloqueo de tiempo absoluto.
|
||||
* El valor `nLockTime` debe ser mayor o igual al del operando de la pila.
|
||||
|
||||
Entonces, la primera cosa a notar aquí es que `nLockTime` sigue siendo usado con CLTV. Para ser precisos, es requerido en las transacciones que intentan _volver a gastar_ un UTXO bloqueado temporalmente con CLTV. Esto significa, que no es parte de los requerimientos del script. Es solo un temporizador que es usado para liberar fondos, _como esta definido en el script_.
|
||||
|
||||
Esto es gestionado a través de un perspicaz entendimiento de como `nLockTime` funciona: un valor para `nLockTime` debe ser siempre elegido para que sea menor o igual al tiempo presente (o altura de bloque), para que así la transacción que vuelve a gastar los fondos pueda ser incluida en la cadena de bloques. Sin embargo, debido a los requerimientos de CLTV, un valor también debe ser elegido para ser mayor o igual al operando CLTV. La unión de estos dos conjuntos es `NULL` hasta que el tiempo actual sea igual al operando CLTV. Después de todo, cualquier valor puede ser elegido entre el operando CLTV y el tiempo actual. Usualmente, usted solo lo configurara al tiempo actual (o bloque).
|
||||
|
||||
## Escribir un Script CLTV.
|
||||
|
||||
`OP_CHECKLOCKTIMEVERIFY` incluye un `OP_VERIFY`, lo que significa que se detendrá inmediatamente el script si su verificación no tiene éxito. Tiene otra peculiaridad: a diferencia de la mayoría de los comandos de verificación, este deja lo que se esta comprobando en la pila (solo en caso de que quiera hacer mas comparaciones contra el tiempo). Esto significa que un `OP_CHECKLOCKTIMEVERIFY` es usualmente seguido por un `OP_DROP` para limpiar la pila.
|
||||
|
||||
El siguiente simple script de bloqueo puede ser usado para transformar el output de una transacción P2PKH a una transacción P2PKH con bloqueo de tiempo.
|
||||
```
|
||||
<AñoSiguiente> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
|
||||
```
|
||||
|
||||
### Codificar un Script CLTV
|
||||
|
||||
Por supuesto, como con cualquier Bitcoin Script complejo, este script CLTV sera codificado de hecho en un script P2SH, como se explica en [§10.1: Comprendiendo la base de P2SH](10_1_Comprendiendo_la_Base_de_P2SH.md) y [§10.2: Construyendo la estructura de P2SH](10_2_Construyendo_la_Estructura_de_P2SH.md).
|
||||
|
||||
Asumiendo que `<SiguienteAño>` fuera el entero "1546288031" (hexadecimal en "little-endian": 0x9f7b2a5c) y `<HashLlavePública>` fuera "371c20fb2e9899338ce5e99908e64fd30b789313", este `redeemScript` seria construido como:
|
||||
```
|
||||
OP_PUSHDATA (4 bytes) 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_PUSHDATA (20 bytes) 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
|
||||
```
|
||||
El cual se traduce a hexadecimal como:
|
||||
```
|
||||
04 9f7b2a5c b1 75 76 a9 14 371c20fb2e9899338ce5e99908e64fd30b789313 88 ac
|
||||
```
|
||||
O si lo prefiere:
|
||||
```
|
||||
$ btcc 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
|
||||
049f7b2a5cb17576a914371c20fb2e9899338ce5e99908e64fd30b78931388ac
|
||||
```
|
||||
El RPC `decodescript` puede verificar que lo hicimos bien:
|
||||
```
|
||||
{
|
||||
"asm": "1546288031 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG",
|
||||
"type": "nonstandard",
|
||||
"p2sh": "2MxANZMPo1b2jGaeKTv9rwcBEiXcXYCc3x9",
|
||||
"segwit": {
|
||||
"asm": "0 07e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
|
||||
"hex": "002007e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
|
||||
"reqSigs": 1,
|
||||
"type": "witness_v0_scripthash",
|
||||
"addresses": [
|
||||
"tb1qqlj4hu02ah6ra3f274ah0ttnxpgxcgy6wrghlghps5esf25wfedse4yw4w"
|
||||
],
|
||||
"p2sh-segwit": "2N4HTwMjVdm38bdaQ5h3X3VktLY74D2qBoK"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
No vamos a estar mostrando continuamente como todos los Bitcoin Scripts se codifican en transacciones P2SH, pero en su lugar ofrecemos estas abreviaturas: cuando describimos un script, sera un `redeemScript`, el cual sera normalmente serializado y codificado mediante una función hash en el script con bloqueo de tiempo y serializado en el script de desbloqueo; cuando mostremos un procedimiento de desbloqueo, sera la segunda ronda de validaciones, siguiendo la confirmación del hash del script con bloqueo de tiempo.
|
||||
|
||||
## Gastar un UTXO CLTV
|
||||
|
||||
Para poder gastar un UTXO que esta bloqueado con CLTV, debe configurar `nLockTime` en su nueva transacción, Usualmente, solo querrá configurarlo al tiempo actual o bloque actual, como corresponde. Mientras el tiempo CLTV o la altura de bloque se encuentre en el pasado, y mientras suministre cualquier otro dato requerido por el script de desbloqueo, sera capaz de procesar el UTXO.
|
||||
|
||||
En el caso del ejemplo de arriba, el siguiente script de desbloqueo sera suficiente, dado que `nLockTime` fue configurado a algún momento antes de la fecha `<SiguienteAño>`, y que fuera, en efecto, al menos `<SiguienteAño>`:
|
||||
|
||||
### Correr un Script CLTV
|
||||
|
||||
Para correr el Script, deberá primero concatenar los scripts de desbloqueo y de bloqueo:
|
||||
```
|
||||
Script: <firma> <LlavePública> <SiguienteAño> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
|
||||
Stack: [ ]
|
||||
```
|
||||
Las tres constantes serán empujadas en la pila:
|
||||
```
|
||||
Script: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
|
||||
Stack: [ <firma> <LlavePública> <SiguienteAño> ]
|
||||
```
|
||||
Luego, corre `OP_CHECKLOCKTIMEVERIFY`. Este encuentra algo en la pila y verifica que `nSequence` no sea 0xffffffff. Finalmente, compara `<SiguienteAño>` con `nLockTime`. Si ambos tienen el mismo tipo de representación y si `nLockTime >= <SiguienteAño>`, entonces procesa exitosamente (caso contrario, finaliza el script):
|
||||
```
|
||||
Script: OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
|
||||
Running: <SiguienteAño> OP_CHECKLOCKTIMEVERIFY
|
||||
Stack: [ <firma> <LlavePública> <SiguienteAño> ]
|
||||
```
|
||||
Luego, `OP_DROP` se deshace de `<SiguienteAño>`, que quedaba rondando:
|
||||
```
|
||||
Script: OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
|
||||
Running: <SiguienteAño> OP_DROP
|
||||
Stack: [ <firma> <LlavePública> ]
|
||||
```
|
||||
Finalmente, el resto del script se ejecuta, el cual es un chequeo normal de una firma y una llave pública.
|
||||
|
||||
## Resumen: Usando CLTV en Scripts
|
||||
|
||||
`OP-CHECKLOCKTIMEVERIFY` es un simple opcode que solo recibe un solo argumento, lo interpreta como altura de bloque o una estampa de tiempo UNIX, y solo permite a sus UTXO ser desbloqueadas si la altura de bloque o la estampa de tiempo UNIX esta en el pasado. Configurar `nLockTime` en la transacción de gasto es lo que permite a Bitcoin hacer este cálculo.
|
||||
|
||||
> :fire: ***¿Cual es el Poder de CLTV?** Usted ya a visto que los simples bloqueos de tiempo son las bases de los Contratos Inteligentes. CLTV toma el siguiente paso. Ahora puede garantizar que un UTXO no pueda ser gastado antes de cierto tiempo _y_ garantizar que no sera gastado tampoco. En su forma mas simple, esto podría ser usado para crear un fondo al que alguien solo pueda acceder cuando haya alcanzado los 18 años o un fondo de retiro al que solo pueda acceder cuando llegue a los 50. Sin embargo, su verdadero poder surge cuando es combinado con condicionales, donde el CLTV solo se activa ante ciertas situaciones.
|
||||
|
||||
## ¿Que sigue?
|
||||
|
||||
Continúe "Potenciando el Bloqueo de Tiempo" con [§11.3: Usando CSV en Scripts](11_3_Usando_CSV_en_Scripts.md).
|
||||
148
es/11_3_Usando_CSV_en_Scripts.md
Normal file
148
es/11_3_Usando_CSV_en_Scripts.md
Normal file
@ -0,0 +1,148 @@
|
||||
# 11.3: Usando CSV en Scripts
|
||||
|
||||
`nLockTime` y `OP_CHECKLOCKTIMEVERIFY` (o CLTV) son solo una lado de la ecuación de los bloqueos de tiempo. En el otro lado están `nSequence` y `OP_CHECKSEQUENCEVERIFY`, las cuales pueden ser usadas para chequear contra tiempos relativos en lugar de tiempos absolutos.
|
||||
|
||||
> :warning: **ADVERTENCIA DE VERSIÓN:** CSV fue lanzado con Bitcoin Core 0.12.1, en la primavera de 2016.
|
||||
|
||||
## Entienda nSequence
|
||||
|
||||
Todo input dentro de una transacción tiene un valor `nSequence` (o si usted prefiere `sequence`). Este a sido una herramienta primaria en la expansión de Bitcoin, como fue discutido previamente en [5.2: Reenviando una Transacción con RBF](05_2_Reenviando_a_Transaccion_con_RBF.md) y [8.1: Enviando una Transacción con un Bloqueo de Tiempo](08_1_Enviando_una_Transaccion_con_un_Bloqueo_de_Tiempo.md), donde fue usado para señalar RBF y `nLockTime`, respectivamente. Sin embargo, hay un uso mas para `nSequence`, descrito por [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): usted puede usarlo para crear un bloqueo de tiempo relativo en una transacción.
|
||||
|
||||
Un bloqueo de tiempo relativo es un bloqueo de tiempo sobre un input especifico de una transacción y es calculado en relación a la fecha de minado del UTXO siendo usado como input. Por ejemplo, si un UTXO fue minado en el bloque #468260 y una transacción fue creada donde al input para este UTXO se le dio un `nSequence` de 100, entonces la nueva transacción no va a poder ser minada hasta el bloque #468360.
|
||||
|
||||
Fácil!
|
||||
|
||||
> :information_source: **NOTA — SECUENCIA:** Este es el tercer uso del valor `nSequence` en Bitcoin. Cualquier valor `nSequence` sin el trigésimo segundo bit configurado (1<<31),de 0x00000001 a 0x7ffffffff, sera interpretado como un bloqueo de tiempo relativo. Si `nVersion ≥ 2` (el cual es el valor por defecto desde Bitcoin Core 0.14.0). Debe ser cuidadoso para asegurarse que los bloqueos de tiempo relativo no entran en conflicto con los otros dos usos de `nSequence`, para señalar `nTimeLock` y RBF. `nTimeLock` usualmente se configura a un valor de 0xffffffff-1, donde un bloqueo de tiempo relativo no es permitido; y RBF usualmente configura su valor a "1", donde un bloqueo de tiempo relativo es irrelevante, porque este define un bloqueo de tiempo de 1 bloque.
|
||||
|
||||
> En general, recuerda: con un valor de `nVersion` de 2, un valor de `nSequence` de 0x00000001 a 0x7fffffff permite un bloqueo relativo de tiempo, RBF, y `nTimeLock`; un valor de `nSequence` de 0x7fffffff a 0xffffffff-2 permite RBF y `nTimeLock`; un valor `nSequence` de 0xffffffff-1 permite solo `nTimeLock`; un valor `nSequence` igual a 0xffffffff no habilita nada; y `nVersion` puede ser configurada al valor 1 para no permitir los bloqueos de tiempo relativo para cualquier valor de `nSequence`. Uf!
|
||||
|
||||
### Crea una transacción CSV con Tiempo de Bloque Relativo
|
||||
|
||||
El formato para usar `nSequence` para representar bloqueos de tiempo relativo esta definido en [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) y es levemente mas complejo que solo introducir un numero, como hizo para `nTimeLock`. En su lugar, las especificaciones BIP dividen los cuatro bytes en tres partes:
|
||||
|
||||
* Los primeros dos bytes son usados para especificar un bloqueo de tiempo relativo.
|
||||
* El vigésimo tercer bit es usado para señalar positivamente si el bloqueo se refiere a un tiempo en lugar de a una altura de bloque.
|
||||
* El trigésimo segundo bit es usado para señalar positivamente si los bloqueos de tiempo relativos están desactivados.
|
||||
|
||||
Con todo eso dicho, la construcción de un bloqueo relativo de tiempo basado en el bloque es todavía bastante fácil, porque los dos bits marcados son configurados a un valor `0`, por lo que solo tiene que configurar `nSequence` a un valor entre 1 y 0xffff (65535). La nueva transacción puede ser minada ese numero de bloques después de que el UTXO asociado fue minado.
|
||||
|
||||
### Crea una transacción CSV de Tiempo Relativo
|
||||
|
||||
Puede en cambio configurar `nSequence` como un tiempo relativo, donde el bloque dura por 512 segundos multiplicado por el valor de `nSequence`.
|
||||
|
||||
Con el fin de hacer eso:
|
||||
|
||||
1. Decida cuan lejos en el futuro configurar su bloqueo de tiempo relativo.
|
||||
2. Convierta ese valor a segundos.
|
||||
3. Divida por 512.
|
||||
4. Redondee ese valor hacia arriba o abajo y configure `nSequence` a ese valor.
|
||||
5. Configure el vigésimo tercer bit a verdadero.
|
||||
|
||||
Para configurar un tiempo de 6 meses en el futuro, debe primero calcularlo como sigue:
|
||||
```
|
||||
$ segundos=$((6*30*24*60*60))
|
||||
$ nvalor=$(($segundos/512))
|
||||
```
|
||||
Luego, conviértalo a hexadecimal:
|
||||
```
|
||||
$ valorhexadecimal=$(printf '%x\n' $nvalor)
|
||||
```
|
||||
Finalmente, haga un or bit a bit del vigésimo tercer bit dentro del valor hexadecimal que creo:
|
||||
```
|
||||
$ valorrelativo=$(printf '%x\n' $((0x$valorhexadecimal | 0x400000)))
|
||||
$ echo $valorrelativo
|
||||
4224679
|
||||
```
|
||||
Si usted convierte el valor a binario vera que 4224679 = 10000000111011010100111. El vigésimo tercer dígito es configurado a "1"; mientras tanto, los primeros 2 bytes, 0111011010100111, convierta a 76A7 en hexadecimal o 30375 en decimal. Multiplique eso por 512 y obtendrá 15.55 millones de segundos, lo que es, de hecho, 180 días.
|
||||
|
||||
## Crea una transacción con Bloqueo de Tiempo Relativo
|
||||
|
||||
¿Entonces, usted quiere crear una transacción simple con bloqueo de tiempo relativo? Todo lo que tiene que hacer es emitir una transacción donde el valor `nSequence` en un input es configurado como se muestra arriba: con el valor `nSequence` para ese input configurado de forma tal que los primeros dos bytes definan el bloqueo de tiempo, el vigésimo tercer bit defina el tipo de bloque de tiempo y el trigésimo segundo bit tenga un valor de falso.
|
||||
|
||||
Emita la transacción y usted vera que no puede ser minada legalmente hasta que suficientes bloques o suficiente tiempo haya pasado mas allá del tiempo en el que esa UTXO fue minada.
|
||||
|
||||
Prácticamente nadie hace eso. En el [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) definiciones para `nSequence` fueron incorporadas dentro de Bitcoin Core al mismo tiempo que [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki), el cual describe el opcode CSV, el equivalente al `nSequence` para el opcode CLTV. Al igual que CLTV, CSV ofrece capacidades mejoradas. Entonces, casi todo el uso de bloqueos de tiempo relativo han sido con el opcode CSV, no con el valor crudo `nSequence` por si mismo.
|
||||
|
||||
| | Bloqueos de Tiempo Absolutos | Bloqueos de Tiempo Absolutos |
|
||||
|:-----------------------:|------------------------------|------------------------------|
|
||||
| **Bloquea transacción** | nTimeLock | nSequence |
|
||||
| **Bloquea Output** | OP_CHECKLOCKTIMEVERIFY | OP_CHECKSEQUENCEVERIFY |
|
||||
|
||||
## Entienda el Opcode CSV
|
||||
|
||||
`OP_SEQUENCEVERIFY` en Bitcoin Scripts funciona bastante parecido a `OP_LOCKTIMEVERIFY`.
|
||||
|
||||
Puede que requiera conservar una UTXO por una centena de bloques mas allá de su minado:
|
||||
```
|
||||
100 OP_CHECKSEQUENCEVERIFY
|
||||
```
|
||||
O puede hacer un calculo mas complejo que requiera que conserve un UTXO por seis meses, en cuyo caso terminara con un numero mas complejo:
|
||||
```
|
||||
4224679 OP_CHECKSEQUENCEVERIFY
|
||||
```
|
||||
En este caso usaremos una abreviatura:
|
||||
```
|
||||
<+6Meses> OP_CHECKSEQUENCEVERIFY
|
||||
```
|
||||
|
||||
> :warning: **ADVERTENCIA:** Recuerde que un bloqueo de tiempo relativo es un lapso de tiempo desde el minado de el UTXO usado como input. _No_ es un lapso de tiempo después de que la transacción es creada. Si usa un UTXO que ya ha sido confirmado una centena de veces, y usted configura un bloqueo de tiempo de 100 bloques sobre este, sera elegible para minarse inmediatamente. Los bloqueos de tiempo relativos tienen usos bien específicos, pero probablemente no apliquen si su único objetivo es determinar algún tiempo fijado en el futuro.
|
||||
|
||||
### Entienda Como Funciona Realmente CSV
|
||||
|
||||
CSV tiene muchas de las sutilezas en su uso como CLTV:
|
||||
|
||||
* El campo `nVersion` le debe ser asignado el valor 2 o mayor.
|
||||
* El campo `nSequence` debe ser menor que 0x80000000.
|
||||
* Cuando CSV es ejecutado, debe haber un operando en la pila que este entre 0 y 0xf0000000-1.
|
||||
* Ambos, el operando de la pila y `nSequence` deben tener el mismo valor en el vigésimo tercer bit.
|
||||
* El valor `nSequence` debe ser mayor o igual al operando de la pila.
|
||||
|
||||
Tal como con CLTV, cuando esta gastando un UTXO con CSV, en sus condiciones de bloqueo, debe configurar el campo `nSequence` para habilitar la transacción. Usted usualmente lo configurara al valor exacto del script bloqueante.
|
||||
|
||||
## Escriba un Script CSV
|
||||
|
||||
Al igual que `OP_CHECKLOCKTIMEVERIFY`, `OP_CHECKSEQUENCEVERIFY` incluye un `OP_VERIFY` implícito y deja sus argumentos en la pila, requiriendo un `OP_DROP` cuando haya terminado.
|
||||
|
||||
Un script que bloqueara fondos hasta que hayan pasado seis meses después del minado del input, y que requerirá una firma P2PKH estándar se vera de la siguiente manera:
|
||||
```
|
||||
<+6Meses> OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 <HashLlavePublica> OP_EQUALVERIFY OP_CHECKSIG
|
||||
```
|
||||
|
||||
### Codifique un Script CSV
|
||||
|
||||
Cuando codifica un script CSV, sea cuidadoso en como codifica el valor entero para el bloqueo de tiempo relativo. Este debe pasarse como un entero de 3 bytes, lo que significa que se ignora el byte mas grande, lo cual podría no activar el bloqueo de tiempo relativo. Dado que es un entero, asegúrese de convertirlo al formato 'little-endian'.
|
||||
|
||||
Esto puede realizarse con el shell script `integer2lehex.sh` del capitulo previo.
|
||||
|
||||
Para un tiempo relativo de 100 bloques:
|
||||
```
|
||||
$ ./integer2lehex.sh 100
|
||||
Integer: 100
|
||||
LE Hex: 64
|
||||
Length: 1 bytes
|
||||
Hexcode: 0164
|
||||
```
|
||||
Aunque eso debería ser rellenado a `000064`, requiriendo un código de `03000064`.
|
||||
|
||||
Para un tiempo relativo de 6 meses:
|
||||
```
|
||||
$ ./integer2lehex.sh 4224679
|
||||
Integer: 4224679
|
||||
LE Hex: a77640
|
||||
Length: 3 bytes
|
||||
Hexcode: 03a77640
|
||||
```
|
||||
|
||||
## Gaste una UTXO CSV
|
||||
|
||||
Para gastar un UTXO bloqueado con un script CSV, debe configurar el valor `nSequence` de ese input a un valor mas grande que el requerido en el script, pero menor que el tiempo entre el UTXO y el bloque actual. Sí, esto significa que usted necesita saber exactamente el requerimiento en el script bloqueante... pero tiene una copia de `redeemScript`, entonces, si no conoce los requerimientos, deserializa la copia y luego configura el valor `nSequence` al numero que se muestra en esta.
|
||||
|
||||
## Resumen: Usando CSV en Scripts
|
||||
|
||||
`nSequence` y CSV ofrecen una alternativa a `nLockTime` y CLTV donde usted bloquea una transacción basada en un tiempo relativo desde que el input fue minado, en lugar de basar el bloqueo en un tiempo fijado en el futuro. Estos funcionan casi de la misma manera, mas allá del hecho que el valor de `nSequence` es codificado levemente distinto que el valor de `nLockTime`, con bits específicos significando cosas especificas.
|
||||
|
||||
> :fire: ***¿Cual es el poder de CSV?*** CSV no es solo una forma perezosa de bloquear, cuando usted no quiere calcular un tiempo en el futuro. En su lugar, es un paradigma totalmente diferente, un bloqueo que utilizaría si fuera importante crear una duración mínima especifica cuando una transacción es minada y cuando sus fondos pueden ser re-gastados. El uso mas obvio es (una vez mas) para deposito, cuando usted quiere un tiempo preciso entre el input de los fondos y su output. Sin embargo, tiene posibilidades mucho mas poderosas en transacciones fuera de la cadena, incluyendo canales de pago. Esas aplicaciones son por definición construidas sobre transacciones que no han sido puestas en la cadena de bloques, lo cual significa que si son introducidas en la cadena un lapso de tiempo forzado podría ser muy útil. [Contratos por Bloqueos de Tiempo Hasheados](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) ha sido una de estas implementaciones, potenciando la red de pagos Lightning. Estos son debatidos en [§13.3: Potenciando Bitcoin con Scripts](13_3_Potenciando_Bitcoin_con_Scripts.md).
|
||||
|
||||
## ¿Que sigue?
|
||||
|
||||
Avanza a través de "Bitcoin Scripting" con [12.0: Expandiendo Scripts Bitcoin](12_0_Expandiendo_Scripts_Bitcoin.md)
|
||||
Loading…
x
Reference in New Issue
Block a user