Skip to content

Commit 816fb40

Browse files
shannonashannona
authored
Merge pull request #280 from csralvall/spanish-11
Create chapter 11 spanish translation
2 parents 7d9d905 + cbeda81 commit 816fb40

4 files changed

+372
-0
lines changed

‎es/11_0_Potenciando_Bloqueos_de_Tiempo_con_Bitcoin_Scripts.md‎

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# Capitulo 11: Potenciando Bloqueos de Tiempo con Bitcoin Scripts
2+
3+
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.
4+
5+
## Objetivos para este Capitulo
6+
7+
Después de trabajar en este capítulo, un desarrollador podrá:
8+
9+
* Decidir cual bloqueo de tiempo usar.
10+
* Crear Scripts con CLTV.
11+
* Crear Scripts con CSV.
12+
13+
Los objetivos de apoyo incluyen la capacidad de:
14+
15+
* Entender las diferencias entre los diferentes bloqueos de tiempo.
16+
* Generar tiempos relativos.
17+
18+
## Tabla de contenido:
19+
20+
* [Sección Uno: Entendiendo las Opciones de los Bloqueos de Tiempo](11_1_Entendiendo_las_Opciones_de_los_Bloqueos_de_Tiempo.md)
21+
* [Sección Dos: Usando CLTV en Scripts](11_2_Usando_CLTV_en_Scripts.md)
22+
* [Sección Tres: Usando CSV en Scripts](11_3_Usando_CSV_en_Scripts.md)
23+

‎es/11_1_Entendiendo_las_Opciones_de_los_Bloqueos_de_Tiempo.md‎

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
# 11.1: Entendiendo las Opciones de los Bloqueos de Tiempo
2+
3+
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.
4+
5+
## Comprender las Limitaciones de nLockTime
6+
7+
`nLockTime` es una forma simple y poderosa de bloquear una transacción, pero tiene algunas limitaciones:
8+
9+
1. **No División.** `nLocktime` bloquea la transacción completa.
10+
2. **No Retransmisión.** La mayoría de los nodos modernos no aceptaran un `nLockTime` dentro de la mempool hasta que este casi finalizado.
11+
3. **No Scripts.** El original, simple uso de `nLockTime` no permitía su utilización en Scripts.
12+
4. **No Protección.** `nLockTime` permite que los fondos sean gastados con una transacción diferente, no bloqueada.
13+
14+
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.
15+
16+
## Comprender las Posibilidades de los Scripts con Bloqueos de Tiempo
17+
18+
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.
19+
20+
_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.
21+
22+
_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.
23+
24+
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.
25+
26+
### Comprender las Posibilidades de CLTV
27+
28+
_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.
29+
30+
CLTV fue detallado inicialmente en [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki).
31+
32+
### Comprender las Posibilidades de CSV
33+
34+
_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.
35+
36+
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).
37+
38+
## Resumen: Entendiendo las Opciones de los Bloqueos de Tiempo
39+
40+
Tiene ahora 4 opciones de Bloqueo de Tiempo:
41+
42+
* `nLockTime` para mantener una transacción fuera de la cadena de bloques hasta un tiempo específico.
43+
* `nSequence` para mantener una transacción fuera de la cadena de bloques hasta un tiempo relativo.
44+
* CLTV para hacer un UTXO no gastable hasta un tiempo específico.
45+
* CSV para hacer un UTXO no gastable hasta un tiempo relativo.
46+
47+
## ¿Que sigue?
48+
49+
Continúe "Potenciando los Bloqueos de Tiempo" con [§11.2: Usando CLTV en Scripts](11_2_Usando_CLTV_en_Scripts.md).

‎es/11_2_Usando_CLTV_en_Scripts.md‎

Lines changed: 152 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
# 11.2: Usando CLTV en Scripts
2+
3+
`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.
4+
5+
> :warning: **ADVERTENCIA DE VERSIÓN:** CLTV fue lanzado con Bitcoin Core 0.11.2, pero debería estar ampliamente implementado en este momento.
6+
7+
## Recordar nLockTime
8+
9+
Antes de profundizar en CLTV, primero debe recordar como funciona `nLockTime`.
10+
11+
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:
12+
13+
* Si el `nLockTime` es menor que 500 millones, es interpretado como altura de bloque.
14+
* Si el `nLockTime` es 500 millones o mas, es interpretado como una estampa de tiempo UNIX.
15+
16+
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.
17+
18+
## Comprender el opcode CLTV
19+
20+
`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.
21+
22+
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.
23+
24+
### Comprender el Tiempo Absoluto de CLTV.
25+
26+
Así es como `OP_CHECKLOCKTIMEVERIFY` se usaría como chequeo comparando con el 24 de Mayo de 2017:
27+
```
28+
1495652013 OP_CHECKLOCKTIMEVERIFY
29+
```
30+
Pero, usualmente representaremos esta abstracción de la siguiente manera:
31+
```
32+
<24 de Mayo de 2017> OP_CHECKLOCKTIMEVERIFY
33+
```
34+
O la siguiente:
35+
```
36+
<Tiempo Absoluto> OP_CHECKLOCKTIMEVERIFY
37+
```
38+
39+
### Comprender la Altura Absoluta de Bloque de CLTV
40+
41+
Así es como `OPCHECKLOCKTIMEVERIFY` se chequearía contra la altura de bloque que fue alcanzada el 24 de Mayo de 2017:
42+
```
43+
467951 OP_CHECKLOCKTIMEVERIFY
44+
```
45+
Pero, usualmente, lo abstraeremos de la siguiente manera:
46+
```
47+
<AlturaAbsolutaDeBloque> OP_CHECKLOCKTIMEVERIFY
48+
```
49+
50+
### Comprender Como Realmente Funciona CLTV
51+
52+
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.
53+
54+
Un script bloqueante solo permitirá a una transacción volver a gastar un UTXO bloqueado con CLTV si `OP_CHECKLOCKTIMEVALUE` verifica todo lo siguiente:
55+
56+
* El campo `nSequence` debe ser configurado a menos de 0xffffffff, usualmente 0xfffffffff-1, para evitar conflictos con los bloqueos de tiempo relativos.
57+
* CLTV debe sacar un operando fuera de la pila y este debe ser mayor o igual a 0.
58+
* 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.
59+
* El valor `nLockTime` debe ser mayor o igual al del operando de la pila.
60+
61+
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_.
62+
63+
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).
64+
65+
## Escribir un Script CLTV.
66+
67+
`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.
68+
69+
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.
70+
```
71+
<AñoSiguiente> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
72+
```
73+
74+
### Codificar un Script CLTV
75+
76+
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).
77+
78+
Asumiendo que `<SiguienteAño>` fuera el entero "1546288031" (hexadecimal en "little-endian": 0x9f7b2a5c) y `<HashLlavePública>` fuera "371c20fb2e9899338ce5e99908e64fd30b789313", este `redeemScript` seria construido como:
79+
```
80+
OP_PUSHDATA (4 bytes) 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_PUSHDATA (20 bytes) 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
81+
```
82+
El cual se traduce a hexadecimal como:
83+
```
84+
04 9f7b2a5c b1 75 76 a9 14 371c20fb2e9899338ce5e99908e64fd30b789313 88 ac
85+
```
86+
O si lo prefiere:
87+
```
88+
$ btcc 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
89+
049f7b2a5cb17576a914371c20fb2e9899338ce5e99908e64fd30b78931388ac
90+
```
91+
El RPC `decodescript` puede verificar que lo hicimos bien:
92+
```
93+
{
94+
"asm": "1546288031 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG",
95+
"type": "nonstandard",
96+
"p2sh": "2MxANZMPo1b2jGaeKTv9rwcBEiXcXYCc3x9",
97+
"segwit": {
98+
"asm": "0 07e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
99+
"hex": "002007e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
100+
"reqSigs": 1,
101+
"type": "witness_v0_scripthash",
102+
"addresses": [
103+
"tb1qqlj4hu02ah6ra3f274ah0ttnxpgxcgy6wrghlghps5esf25wfedse4yw4w"
104+
],
105+
"p2sh-segwit": "2N4HTwMjVdm38bdaQ5h3X3VktLY74D2qBoK"
106+
}
107+
}
108+
```
109+
110+
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.
111+
112+
## Gastar un UTXO CLTV
113+
114+
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.
115+
116+
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>`:
117+
118+
### Correr un Script CLTV
119+
120+
Para correr el Script, deberá primero concatenar los scripts de desbloqueo y de bloqueo:
121+
```
122+
Script: <firma> <LlavePública> <SiguienteAño> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
123+
Stack: [ ]
124+
```
125+
Las tres constantes serán empujadas en la pila:
126+
```
127+
Script: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
128+
Stack: [ <firma> <LlavePública> <SiguienteAño> ]
129+
```
130+
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):
131+
```
132+
Script: OP_DROP OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
133+
Running: <SiguienteAño> OP_CHECKLOCKTIMEVERIFY
134+
Stack: [ <firma> <LlavePública> <SiguienteAño> ]
135+
```
136+
Luego, `OP_DROP` se deshace de `<SiguienteAño>`, que quedaba rondando:
137+
```
138+
Script: OP_DUP OP_HASH160 <HashLlavePública> OP_EQUALVERIFY OP_CHECKSIG
139+
Running: <SiguienteAño> OP_DROP
140+
Stack: [ <firma> <LlavePública> ]
141+
```
142+
Finalmente, el resto del script se ejecuta, el cual es un chequeo normal de una firma y una llave pública.
143+
144+
## Resumen: Usando CLTV en Scripts
145+
146+
`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.
147+
148+
> :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.
149+
150+
## ¿Que sigue?
151+
152+
Continúe "Potenciando el Bloqueo de Tiempo" con [§11.3: Usando CSV en Scripts](11_3_Usando_CSV_en_Scripts.md).

0 commit comments

Comments
 (0)