Revise chapter 11 titles, fix typos

This commit is contained in:
namcios 2021-09-21 11:01:19 -03:00
parent a69d882a6a
commit 405c9fc7f9
No known key found for this signature in database
GPG Key ID: 8E3A368317269AB4
4 changed files with 27 additions and 27 deletions

View File

@ -1,9 +1,9 @@
# Capítulo 11: Expandindo o timelock com scripts do Bitcoin # Capítulo 11: Capacitando Timelock com Scripts do Bitcoin
O recurso ```nLockTime``` da seção [§8.1](08_1_Sending_a_Transaction_with_a_Locktime.md) foi apenas o começo dos Timelocks. Quando começamos a escrever scripts do Bitcoin, dois opcodes de timelocks ficam disponíveis. O recurso ```nLockTime``` da seção [§8.1](08_1_Sending_a_Transaction_with_a_Locktime.md) foi apenas o começo dos Timelocks. Quando começamos a escrever scripts do Bitcoin, dois opcodes de timelocks ficam disponíveis.
## Objetivos deste capítulo ## Objetivos deste Capítulo
Depois de trabalhar neste capítulo, um desenvolvedor será capaz de: Depois de trabalhar neste capítulo, um desenvolvedor será capaz de:
@ -18,6 +18,6 @@ Os objetivos secundários do capítulo incluem a capacidade de:
## Índice ## Índice
* [Seção 1: Compreendendo as Opções de Timelocks](11_1_Understanding_Timelock_Options.md) * [Seção 1: Compreendendo As Opções de Timelock](11_1_Understanding_Timelock_Options.md)
* [Seção 2: Usando o CLTV nos Scripts](11_2_Using_CLTV_in_Scripts.md) * [Seção 2: Usando CLTV em Scripts](11_2_Using_CLTV_in_Scripts.md)
* [Seção 3: Usando o CSV nos Scripts](11_3_Using_CSV_in_Scripts.md) * [Seção 3: Usando CSV em Scripts](11_3_Using_CSV_in_Scripts.md)

View File

@ -1,8 +1,8 @@
# 11.1: Compreendendo as Opções de Timelocks # 11.1: Compreendendo As Opções de Timelock
Na seção [§8.1: Enviando uma transação com Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), o ```nLocktime``` ofereceu uma ótima opção inicial para bloquear as transações para que não pudessem ser gastas até algum ponto no futuro, com base no tempo (data/hora) ou na altura do bloco. Mas, essa não é a única maneira de colocar um timelock em uma transação. Na seção [§8.1: Enviando uma transação com Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), o ```nLocktime``` ofereceu uma ótima opção inicial para bloquear as transações para que não pudessem ser gastas até algum ponto no futuro, com base no tempo (data/hora) ou na altura do bloco. Mas, essa não é a única maneira de colocar um timelock em uma transação.
## Compreendendo as limitações do nLockTime ## Compreendendo as Limitações do nLockTime
O ```nLockTime``` é uma maneira simples e poderosa de bloquear uma transação, mas possui algumas limitações: O ```nLockTime``` é uma maneira simples e poderosa de bloquear uma transação, mas possui algumas limitações:
@ -13,7 +13,7 @@ O ```nLockTime``` é uma maneira simples e poderosa de bloquear uma transação,
O último item costumava ser o _dealbreaker_ para o ```nLockTime```. Isso evitou que uma transação fosse gasta, mas não impediu que os fundos fossem usados em uma transação diferente. Então, havia certos usos, mas todos dependiam de confiança. O último item costumava ser o _dealbreaker_ para o ```nLockTime```. Isso evitou que uma transação fosse gasta, mas não impediu que os fundos fossem usados em uma transação diferente. Então, havia certos usos, mas todos dependiam de confiança.
## Compreendendo as possibilidades dos scripts de Timelock ## Compreendendo as Possibilidades dos Scripts de Timelock
Nos últimos anos, o Bitcoin Core foi expandido para permitir a manipulação dos timelocks no nível do opcode com os _OP_CHECKLOCKTIMEVERIFY_ (CLTV) e _OP_CHECKSEQUENCEVERIFY_ (CSV). Ambos trabalham sob uma nova metodologia que fortalece ainda mais o Bitcoin. Nos últimos anos, o Bitcoin Core foi expandido para permitir a manipulação dos timelocks no nível do opcode com os _OP_CHECKLOCKTIMEVERIFY_ (CLTV) e _OP_CHECKSEQUENCEVERIFY_ (CSV). Ambos trabalham sob uma nova metodologia que fortalece ainda mais o Bitcoin.
@ -23,19 +23,19 @@ _Eles bloqueiam as saídas._ Por serem opcodes incluídos nas transações como
Aqui está um ponto importante sobre a utilização dos timelocks: _Eles são bloqueios de mão única._ Os bloqueios de tempo são projetados para desbloquear fundos em um determinado momento. Eles não podem bloquear novamente um fundo: Uma vez que um fundo bloqueado por tempo está disponível, ele ficará disponível para ser gasto. Aqui está um ponto importante sobre a utilização dos timelocks: _Eles são bloqueios de mão única._ Os bloqueios de tempo são projetados para desbloquear fundos em um determinado momento. Eles não podem bloquear novamente um fundo: Uma vez que um fundo bloqueado por tempo está disponível, ele ficará disponível para ser gasto.
### Compreendendo as possibilidades do CLTV ### Compreendendo as Possibilidades do CLTV
O _OP_CHECKLOCKTIMEVERIFY_ ou CLTV é compativel com o clássico recurso ```nLockTime```, mas no novo paradigma baseado em opcode. Ele permite que uma UTXO se torne acessível em um determinado momento ou em uma determinada altura de bloco. O _OP_CHECKLOCKTIMEVERIFY_ ou CLTV é compativel com o clássico recurso ```nLockTime```, mas no novo paradigma baseado em opcode. Ele permite que uma UTXO se torne acessível em um determinado momento ou em uma determinada altura de bloco.
O CLTV foi detalhado pela primeira vez no [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). O CLTV foi detalhado pela primeira vez no [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki).
### Compreendendo as possibilidades do CSV ### Compreendendo as Possibilidades do CSV
O _OP_CHECKSEQUENCEVERIFY_ ou CSV depende de um novo tipo de "locktime relativo", que é definido no campo _nSequence_ da transação. Como de costume, ele pode ser definido como uma data/hora ou uma altura de bloco. Se for definido como um tempo "n", então uma transação bloqueada em um tempo relativo pode ser gasta "n x 512" segundos depois que a UTXO foi minerada, e se for definido como um bloco "n", então uma transação bloqueada em tempo relativo pode ser gasta em "n" blocos depois que a UTXO foi minerada. O _OP_CHECKSEQUENCEVERIFY_ ou CSV depende de um novo tipo de "locktime relativo", que é definido no campo _nSequence_ da transação. Como de costume, ele pode ser definido como uma data/hora ou uma altura de bloco. Se for definido como um tempo "n", então uma transação bloqueada em um tempo relativo pode ser gasta "n x 512" segundos depois que a UTXO foi minerada, e se for definido como um bloco "n", então uma transação bloqueada em tempo relativo pode ser gasta em "n" blocos depois que a UTXO foi minerada.
O uso do ```nSequence``` para um bloqueio de tempo relativo foi detalhado primeiramente no [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), e o opcode CSV foi adicionado no [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki). O uso do ```nSequence``` para um bloqueio de tempo relativo foi detalhado primeiramente no [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), e o opcode CSV foi adicionado no [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki).
## Resumo: Compreendendo as Opções de Timelocks ## Resumo: Compreendendo As Opções de Timelock
Agora possuímos quatro opções de Timelocks: Agora possuímos quatro opções de Timelocks:
@ -46,4 +46,4 @@ Agora possuímos quatro opções de Timelocks:
## O Que Vem Depois? ## O Que Vem Depois?
Vamos continuar "Aumentando o poder do timelock com scripts do Bitcoin" na seção [§11.2: Usando o CLTV nos Scripts](11_2_Using_CLTV_in_Scripts.md). Vamos continuar "Aumentando o poder do timelock com scripts do Bitcoin" na seção [§11.2: Usando CLTV em Scripts](11_2_Using_CLTV_in_Scripts.md).

View File

@ -1,4 +1,4 @@
# 11.2: Usando o CLTV nos Scripts # 11.2: Usando CLTV em Scripts
O ```OP_CHECKLOCKTIMEVERIFY``` (ou CLTV) é o complemento natural para o ```nLockTime```. Ele muda a ideia de bloquear transações por um tempo absoluto ou altura de bloco para o âmbito dos opcodes, permitindo o bloqueio das UTXOs individuais. O ```OP_CHECKLOCKTIMEVERIFY``` (ou CLTV) é o complemento natural para o ```nLockTime```. Ele muda a ideia de bloquear transações por um tempo absoluto ou altura de bloco para o âmbito dos opcodes, permitindo o bloqueio das UTXOs individuais.
@ -21,7 +21,7 @@ O ```OP_CHECKLOCKTIMEVERIFY``` funciona dentro do mesmo paradigma de altura de b
Como o CLTV é apenas parte de um script (e presumivelmente parte de uma transação P2SH), uma transação CLTV não é mantida fora da mempool como uma transação ```nLockTime```. Logo, assim que for verificado, ele vai para a blockchain e os fundos são considerados gastos. O truque é que todas as saídas que foram bloqueadas com o CLTV não estão disponíveis para _serem gastas_ até que o CLTV permita. Como o CLTV é apenas parte de um script (e presumivelmente parte de uma transação P2SH), uma transação CLTV não é mantida fora da mempool como uma transação ```nLockTime```. Logo, assim que for verificado, ele vai para a blockchain e os fundos são considerados gastos. O truque é que todas as saídas que foram bloqueadas com o CLTV não estão disponíveis para _serem gastas_ até que o CLTV permita.
### Compreendendo um CLTV de tempo absoluto ### Compreendendo um CLTV de Tempo Absoluto
É assim que o ```OP_CHECKLOCKTIMEVERIFY``` seria utilizado para verificar o locktime de 24 de maio de 2017: É assim que o ```OP_CHECKLOCKTIMEVERIFY``` seria utilizado para verificar o locktime de 24 de maio de 2017:
``` ```
@ -36,7 +36,7 @@ Ou assim:
<AbsoluteTime> OP_CHECKLOCKTIMEVERIFY <AbsoluteTime> OP_CHECKLOCKTIMEVERIFY
``` ```
### Compreendendo um CLTV de altura de bloco absoluta ### Compreendendo um CLTV de Altura de Bloco Absoluta
É assim que o ```OPCHECKLOCKTIMEVERIFY``` compararia a uma altura de bloqueio alcançada no dia 24 de maio de 2017: É assim que o ```OPCHECKLOCKTIMEVERIFY``` compararia a uma altura de bloqueio alcançada no dia 24 de maio de 2017:
``` ```
@ -47,7 +47,7 @@ Mas geralmente vamos abstrair assim:
<AbsoluteBlockHeight> OP_CHECKLOCKTIMEVERIFY <AbsoluteBlockHeight> OP_CHECKLOCKTIMEVERIFY
``` ```
### Entendendo como o CLTV realmente funciona ### Entendendo como o CLTV Realmente Funciona
A explicação acima é suficiente para usar e entender o CLTV. No entanto, o [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) apresenta todos os seguintes detalhes. A explicação acima é suficiente para usar e entender o CLTV. No entanto, o [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) apresenta todos os seguintes detalhes.
@ -71,7 +71,7 @@ O seguinte script de bloqueio simples pode ser usado para transformar uma saída
<NextYear> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <NextYear> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
``` ```
### Codificando um script CLTV ### Codificando um Script CLTV
Obviamente, como acontece com quaisquer scripts Bitcoin complexos, este script CLTV seria realmente codificado em um script P2SH, conforme explicado na seção [§10.1: Entendendo a Fundação do P2SH](10_1_Understanding_the_Foundation_of_P2SH.md) e na [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md). Obviamente, como acontece com quaisquer scripts Bitcoin complexos, este script CLTV seria realmente codificado em um script P2SH, conforme explicado na seção [§10.1: Entendendo a Fundação do P2SH](10_1_Understanding_the_Foundation_of_P2SH.md) e na [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md).
@ -116,7 +116,7 @@ No caso do exemplo acima, o script de desbloqueio abaixo seria suficiente, desde
<signature> <pubKey> <signature> <pubKey>
``` ```
### Executando um script CLTV ### Executando um Script CLTV
Para executar o Script, primeiro devemos concatenar os scripts de desbloqueio e bloqueio: Para executar o Script, primeiro devemos concatenar os scripts de desbloqueio e bloqueio:
``` ```
@ -142,7 +142,7 @@ Stack: [ <signature> <pubKey> ]
``` ```
Finalmente, o restante do script é executado, que é uma verificação normal de uma assinatura e chave pública. Finalmente, o restante do script é executado, que é uma verificação normal de uma assinatura e chave pública.
## Resumo: Usando o CLTV nos Scripts ## Resumo: Usando CLTV em Scripts
O ```OP-CHECKLOCKTIMEVERIFY``` é um opcode simples que olha para um único argumento, o interpreta como uma altura de bloco ou timestamp UNIX, e só permite que a UTXO seja desbloqueada se àquela altura de bloco ou timestamp UNIX estiver no passado. Definir o ```nLockTime``` na transação de gastos é o que permite ao Bitcoin fazer este cálculo. O ```OP-CHECKLOCKTIMEVERIFY``` é um opcode simples que olha para um único argumento, o interpreta como uma altura de bloco ou timestamp UNIX, e só permite que a UTXO seja desbloqueada se àquela altura de bloco ou timestamp UNIX estiver no passado. Definir o ```nLockTime``` na transação de gastos é o que permite ao Bitcoin fazer este cálculo.
@ -150,4 +150,4 @@ O ```OP-CHECKLOCKTIMEVERIFY``` é um opcode simples que olha para um único argu
## O Que Vem Depois? ## O Que Vem Depois?
Vamos continuar "Aumentando o poder do timelock com scripts do Bitcoin" na seção [§11.3: Usando o CSV nos Scripts](11_3_Using_CSV_in_Scripts.md). Vamos continuar "Capacitando Timelock com Scripts no Bitcoin" na seção [§11.3: Usando CSV em Scripts](11_3_Using_CSV_in_Scripts.md).

View File

@ -1,4 +1,4 @@
# 11.3: Usando o CSV nos Scripts # 11.3: Usando CSV em Scripts
O ```nLockTime``` e o ```OP_CHECKLOCKTIMEVERIFY``` (ou CLTV) são apenas um lado da equação do timelock. Do outro lado estão o ```nSequence``` e o ```OP_CHECKSEQUENCEVERIFY```, que podem ser usados para verificar tempos relativos ao invés de tempos absolutos. O ```nLockTime``` e o ```OP_CHECKLOCKTIMEVERIFY``` (ou CLTV) são apenas um lado da equação do timelock. Do outro lado estão o ```nSequence``` e o ```OP_CHECKSEQUENCEVERIFY```, que podem ser usados para verificar tempos relativos ao invés de tempos absolutos.
@ -55,7 +55,7 @@ $ echo $relativevalue
``` ```
Se convertermos de volta, teremos o valor de 4224679 = 10000000111011010100111. O 23º dígito é definido como "1", enquanto os primeiros 2 bytes, 0111011010100111, são convertidos em 76A7 em hexadecimal ou 30375 em decimal. Multiplicando isso por 512, teremos 15,55 milhões de segundos, o que de fato é 180 dias. Se convertermos de volta, teremos o valor de 4224679 = 10000000111011010100111. O 23º dígito é definido como "1", enquanto os primeiros 2 bytes, 0111011010100111, são convertidos em 76A7 em hexadecimal ou 30375 em decimal. Multiplicando isso por 512, teremos 15,55 milhões de segundos, o que de fato é 180 dias.
## Criando uma transação com um timelock relativo ## Criando uma Transação com um Timelock Relativo
Então desejamos criar uma transação simples com um timelock relativo? Tudo que precisamos fazer é emitir uma transação onde o ```nSequence``` de uma entrada é definido como mostramos acima: Com o ```nSequence``` para essa entrada definido de forma que os primeiros dois bytes definam o timelock, o 23º bit define o tipo do timelock, e o 32º bit é definido como sendo falso. Então desejamos criar uma transação simples com um timelock relativo? Tudo que precisamos fazer é emitir uma transação onde o ```nSequence``` de uma entrada é definido como mostramos acima: Com o ```nSequence``` para essa entrada definido de forma que os primeiros dois bytes definam o timelock, o 23º bit define o tipo do timelock, e o 32º bit é definido como sendo falso.
@ -87,7 +87,7 @@ Neste caso, usaremos uma abreviatura:
> :warning: **ATENÇÃO:** Lembre-se de que um timelock relativo é um intervalo de tempo desde a mineração da UTXO usada como uma entrada. _Não_ é um intervalo de tempo após a criação da transação. Se usarmos uma UTXO que já foi confirmada cem vezes, e colocarmos um timelock relativo de 100 blocos nela, ela será elegível para mineração imediatamente. Os timelocks relativos têm alguns usos muito específicos, mas provavelmente não se aplicam se nosso único objetivo for determinar algum tempo definido no futuro. > :warning: **ATENÇÃO:** Lembre-se de que um timelock relativo é um intervalo de tempo desde a mineração da UTXO usada como uma entrada. _Não_ é um intervalo de tempo após a criação da transação. Se usarmos uma UTXO que já foi confirmada cem vezes, e colocarmos um timelock relativo de 100 blocos nela, ela será elegível para mineração imediatamente. Os timelocks relativos têm alguns usos muito específicos, mas provavelmente não se aplicam se nosso único objetivo for determinar algum tempo definido no futuro.
### Entendendo como o CSV realmente funciona ### Entendendo como o CSV Realmente Funciona
O CSV tem muitas das mesmas sutilezas de uso que CLTV: O CSV tem muitas das mesmas sutilezas de uso que CLTV:
@ -99,7 +99,7 @@ O CSV tem muitas das mesmas sutilezas de uso que CLTV:
Assim como no CLTV, quando estiver usando uma UTXO com um CSV em condições de bloqueio, devemos definir o ```nSequence``` para habilitar a transação. Normalmente, o configuraremos com o valor exato no script de bloqueio. Assim como no CLTV, quando estiver usando uma UTXO com um CSV em condições de bloqueio, devemos definir o ```nSequence``` para habilitar a transação. Normalmente, o configuraremos com o valor exato no script de bloqueio.
## Escrevendo um script CSV ## Escrevendo um Script CSV
Assim como o ```OP_CHECKLOCKTIMEVERIFY```, o ```OP_CHECKSEQUENCEVERIFY``` inclui um ```OP_VERIFY``` implícito e deixa os argumentos na pilha, exigindo um ```OP_DROP``` quando finalizar tudo. Assim como o ```OP_CHECKLOCKTIMEVERIFY```, o ```OP_CHECKSEQUENCEVERIFY``` inclui um ```OP_VERIFY``` implícito e deixa os argumentos na pilha, exigindo um ```OP_DROP``` quando finalizar tudo.
@ -108,7 +108,7 @@ Um script que bloquearia fundos por até seis meses após a mineração e que ex
<+6Months> OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <+6Months> OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
``` ```
### Codificando um script CSV ### Codificando um Script CSV
Ao codificar um script CSV, precisamos tomar cuidado ao codificar o valor inteiro para o timelock relativo. Deve ser passado como um número inteiro de 3 bytes, o que significa que iremos ignorar o maior byte, o que pode desativar o timelock relativo. Como é um número inteiro, precisamos nos certificar de convertê-lo para little-endian. Ao codificar um script CSV, precisamos tomar cuidado ao codificar o valor inteiro para o timelock relativo. Deve ser passado como um número inteiro de 3 bytes, o que significa que iremos ignorar o maior byte, o que pode desativar o timelock relativo. Como é um número inteiro, precisamos nos certificar de convertê-lo para little-endian.
@ -137,7 +137,7 @@ Hexcode: 03a77640
Para gastar uma UTXO bloqueado com um script CSV, devemos definir o ```nSequence``` dessa entrada para um valor maior que o requerido no script, mas menor que o tempo entre a UTXO e o bloco atual. Isso mesmo, isso significa que precisamos saber o requisito exato no script de bloqueio. Mas temos uma cópia do ```redeemScript```, então se não conhecermos os requisitos, podemos desserializá-lo e, em seguida, definir o ```nSequence``` como sendo o número que é mostrado lá. Para gastar uma UTXO bloqueado com um script CSV, devemos definir o ```nSequence``` dessa entrada para um valor maior que o requerido no script, mas menor que o tempo entre a UTXO e o bloco atual. Isso mesmo, isso significa que precisamos saber o requisito exato no script de bloqueio. Mas temos uma cópia do ```redeemScript```, então se não conhecermos os requisitos, podemos desserializá-lo e, em seguida, definir o ```nSequence``` como sendo o número que é mostrado lá.
## Resumo: Usando o CSV nos Scripts ## Resumo: Usando CSV em Scripts
O ```nSequence``` e o CSV oferecem uma alternativa para o ```nLockTime``` e o CLTV onde bloqueamos uma transação com base em um tempo relativo desde que a entrada foi extraída, ao invés de basear o bloqueio em um tempo definido no futuro. Eles funcionam quase de forma idêntica, exceto pelo fato de que o valor do ```nSequence``` é codificado de forma ligeiramente diferente do valor do ```nLockTime```, com bits específicos significando coisas específicas. O ```nSequence``` e o CSV oferecem uma alternativa para o ```nLockTime``` e o CLTV onde bloqueamos uma transação com base em um tempo relativo desde que a entrada foi extraída, ao invés de basear o bloqueio em um tempo definido no futuro. Eles funcionam quase de forma idêntica, exceto pelo fato de que o valor do ```nSequence``` é codificado de forma ligeiramente diferente do valor do ```nLockTime```, com bits específicos significando coisas específicas.
@ -145,4 +145,4 @@ O ```nSequence``` e o CSV oferecem uma alternativa para o ```nLockTime``` e o CL
## O Que Vem Depois? ## O Que Vem Depois?
Vamos avançar "Criando Scripts do Bitcoin" no capítulo [12: Expandindo os Scripts do Bitcoin](12_0_Expanding_Bitcoin_Scripts.md). Vamos avançar em "Programando no Bitcoin" com o [Capítulo 12: Expandindo os Scripts do Bitcoin](12_0_Expanding_Bitcoin_Scripts.md).