You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pt/13_3_Empowering_Bitcoin_with_Scripts.md
+33-33Lines changed: 33 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,20 @@
1
-
# 13.3: Expandindo o Bitcoin com os Scripts
1
+
# 13.3: Capacitando o Bitcoin com Scripts
2
2
3
-
Os scripts de Bitcoin podem ir muito além dos instrumentos financeiros relativamente simples detalhados até o momento. Eles também são a base dos usos mais complexos da rede Bitcoin, conforme demonstrado por esses exemplos do mundo real de funcionalidade fora da cadeia (offchain), extraídos dos exemplos da Lightning Network no [BIP 112](https://github.com/bitcoin /bips/blob/master/bip-0112.mediawiki).
3
+
Os scripts do Bitcoin podem ir muito além dos instrumentos financeiros relativamente simples detalhados até o momento. Eles também são a base dos usos mais complexos da rede Bitcoin, conforme demonstrado por esses exemplos do mundo real de funcionalidade fora da blockchain (off-chain), extraídos dos exemplos da Lightning Network no [BIP 112](https://github.com/bitcoin /bips/blob/master/bip-0112.mediawiki).
4
4
5
5
## Bloqueio para a Lightning Network
6
6
7
-
A [Lightning Network](https://rusty.ozlabs.org/?p=450) é um canal de pagamento que permite aos usuários retirar fundos offchain e se envolver em várias micro-transações antes de finalizar o canal de pagamento e trazer os fundos de volta para Bitcoin. Os benefícios incluem taxas mais baixas e velocidades de transação mais rápidas. Iremos discutir com riqueza maior de detalhes, com exemplos de como utilizá-la usando a linha de comando, começando no [Capítulo 18](18_0_Understanding_Your_Lightning_Setup.md).
7
+
A [Lightning Network](https://rusty.ozlabs.org/?p=450) é um canal de pagamento que permite aos usuários retirar fundos off-chain e se envolver em várias micro-transações antes de finalizar o canal de pagamento e trazer os fundos de volta para o Bitcoin. Os benefícios incluem taxas mais baixas e velocidades de transação mais rápidas. Iremos discutir em mais detalhes, com exemplos de como utilizá-la usando a linha de comando, começando no [Capítulo 19](19_0_Understanding_Your_Lightning_Setup.md).
8
8
9
-
O [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) contém alguns exemplos de como essas transações offchain podem ser geradas, usando scripts de bloqueio do Bitcoin.
9
+
O [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) contém alguns exemplos de como essas transações off-chain poderiam ser geradas, usando scripts de bloqueio do Bitcoin.
10
10
11
-
### Bloqueio com transações de compromisso revogáveis
11
+
### Bloqueio com Transações de Compromisso Revogáveis
12
12
13
-
O truque do Lightning é o fato de ele estar fora da blockchain. Para usar a Lightning, os participantes bloqueiam fundos em conjunto na blockchain do Bitcoin com uma transação multisig n-de-n. Em seguida, eles se envolvem em uma série de transações entre si. Cada nova "transação de compromisso" (commitment transaction) divide esses fundos de uma maneira diferente. Essas transações são parcialmente assinadas, mas _não são colocadas na blockchain_.
13
+
O truque com a Lightning é o fato de ela estar off-chain. Para usar a Lightning, os participantes bloqueiam fundos em conjunto na blockchain do Bitcoin com uma transação multisig n-de-n. Em seguida, eles se envolvem em uma série de transações entre si. Cada nova "transação de compromisso" (commitment transaction) divide esses fundos de uma maneira diferente. Essas transações são parcialmente assinadas, mas _não são colocadas na blockchain_.
14
14
15
-
Se temos uma massa de transações não publicadas, qualquer uma delas _pode_ ser colocada na Blockchain, portanto, como evitamos que um dos participantes volte a uma transação antiga que é mais benéfica para eles? A resposta é _revogação_. Um exemplo simplificado no BIP 112, que oferece um dos trampolins para o Lightning, mostra o processo. Nós damos ao participante que seria prejudicado pela reversão de uma transação revogada a capacidade de retirar os fundos ele mesmo se o outro participante tentar usar ilegitimamente a transação revogada.
15
+
Se temos uma massa de transações não publicadas, qualquer uma delas _pode_ ser colocada na Blockchain, portanto, como evitamos que um dos participantes reverta a uma transação antiga que é mais benéfica para eles? A resposta é _revogação_. Um exemplo simplificado no BIP 112, que oferece um dos trampolins para a Lightning, mostra o processo. Nós damos ao participante que seria prejudicado pela reversão de uma transação revogada a capacidade de retirar os fundos ele mesmo se o outro participante tentar usar ilegitimamente a transação revogada.
16
16
17
-
Por exemplo, suponha que Alice e Bob atualizem a transação de compromisso para dar mais fundos a Bob (Ou seja, Alice enviou fundos a Bob por meio da rede Lightning). Eles assinam parcialmente novas transações, mas cada um também oferece seu próprio ```revokeCode``` para as transações anteriores. Isso efetivamente garante que nenhum deles irão publicar as transações anteriores, porque isso permitiria que a contraparte reivindicasse os fundos anteriores.
17
+
Por exemplo, suponha que Alice e Bob atualizem a transação de compromisso para dar mais fundos a Bob (ou seja, Alice enviou fundos a Bob por meio da rede Lightning). Eles assinam parcialmente novas transações, mas cada um também oferece seu próprio ```revokeCode``` para as transações anteriores. Isso efetivamente garante que nenhum deles irão publicar as transações anteriores, porque isso permitiria que a contraparte reivindicasse os fundos anteriores.
18
18
19
19
Então, como se parece a transação antiga? Foi uma transação de compromisso mostrando fundos destinados a Alice, antes que ela os desse a Bob. Ele tinha um script de bloqueio da seguinte maneira:
20
20
```
@@ -31,11 +31,11 @@ ELSE
31
31
ENDIF
32
32
OP_CHECKSIG
33
33
```
34
-
O bloco ```ELSE``` é onde Alice conseguiu os fundos, após um atraso de 24 horas. No entanto, agora foi substituído. Afinal, esse é o ponto principal de um canal de pagamento na Lightning. Nesta situação, esta transação nunca deve ser publicada. Bob não tem incentivo para isso porque ele tem uma transação mais recente, que o beneficia mais porque ele recebeu parte dos fundos de Alice. Alice também não tem incentivo, porque ela perde o dinheiro se tentar retirar mais do que deve, por conta do ```revokeCode```. Assim, ninguém coloca a transação na blockchain e as transações offchain continuam.
34
+
O bloco ```ELSE``` é onde Alice conseguiu os fundos, após um atraso de 24 horas. No entanto, agora foi substituído. Afinal, esse é o ponto principal de um canal de pagamento na Lightning. Nesta situação, esta transação nunca deve ser publicada. Bob não tem incentivo para isso porque ele tem uma transação mais recente, que o beneficia mais porque ele recebeu parte dos fundos de Alice. Alice também não tem incentivo, porque ela perde o dinheiro se tentar retirar mais do que deve, por conta do ```revokeCode```. Assim, ninguém coloca a transação na blockchain e as transações off-chain continuam.
35
35
36
36
Vale a pena explorar como esse script funcionaria em uma variedade de situações, a maioria das quais envolve Alice tentando trapacear, revertendo para a transação mais antiga, que descreve os fundos _antes_ da Alice enviar os satoshis para Bob.
37
37
38
-
#### Executando o script de bloqueio para enganar Alice, com código de revogação
38
+
#### Executando o Script de Bloqueio para a Alice Trapaceira, com Código de Revogação
39
39
40
40
Alice poderia tentar usar o código de revogação que ela deu a Bob para reivindicar imediatamente os fundos. Ela escreve um script de bloqueio de ```<sigAlice> <revokeCode>```:
O ```OP_EQUAL``` alimenta a instrução ```IF```. Como Alice usa o ```revokeCode```, ela entra no caminho que permite gatar os fundos imediatamente, reduzindo o resto do script para ```<pubKeyBob>``` (dentro da condicional) e com o ```OP_CHECKSIG``` (depois).
59
+
O ```OP_EQUAL``` alimenta a instrução ```IF```. Como Alice usa o ```revokeCode```, ela entra no caminho que permite gatar os fundos imediatamente, reduzindo o resto do script para ```<pubKeyBob>``` (dentro do condicional) e com o ```OP_CHECKSIG``` (depois).
60
60
```
61
61
Script: <pubKeyBob> OP_CHECKSIG
62
62
Running: True IF
@@ -71,9 +71,9 @@ Script:
71
71
Running: <sigAlice> <pubKeyBob> OP_CHECKSIG
72
72
Stack: [ False ]
73
73
```
74
-
#### Executando o script de bloqueio para enganar Alice, sem código de revogação
74
+
#### Executando o Script de Bloqueio para a Alice Trapaceira, sem Código de Revogação
75
75
76
-
E daí se Alice tentar usar sua própria assinatura, sem o ```revokeCode```? Ela usa o seguinte script de desbloqueio ```<sigAlice> <notRevokeCode>```.
76
+
E se Alice tentar usar sua própria assinatura, sem o ```revokeCode```? Ela usa um script de desbloqueio de```<sigAlice> <notRevokeCode>```.
#### Executando o script de bloqueio para a vitima, o Bob
110
+
#### Executando o Script de Bloqueio para o Bob Vitimizado
111
111
112
112
O que isso significa é que Bob tem 24 horas para recuperar os fundos se Alice tentar trapacear, usando o ```<revokeCode>``` e a assinatura como script de desbloqueio:
113
113
```
@@ -139,21 +139,21 @@ Script:
139
139
Running: <SigBob> <pubKeyBob> OP_CHECKSIG
140
140
Stack: [ True ]
141
141
```
142
-
#### Executando o Script de Bloqueio para a Virtuosa Alice
142
+
#### Executando o Script de Bloqueio para a Alice Virtuosa
143
143
144
-
Todas as transações de confirmação de Alice são bloqueadas com este mesmo script de bloqueio, quer tenham sido revogadas ou não. Isso significa que a transação de confirmação mais recente, que é a válida atualmente, também está bloqueada com ela. Alice nunca enviou uma transação mais recente para Bob e, portanto, nunca enviou a ele o ```revokeCode``` anterior.
144
+
Todas as transações de confirmação da Alice são bloqueadas com este mesmo script de bloqueio, quer tenham sido revogadas ou não. Isso significa que a transação de confirmação mais recente, que é a válida atualmente, também está bloqueada com ela. Alice nunca enviou uma transação mais recente para Bob e, portanto, nunca enviou a ele o ```revokeCode``` anterior.
145
145
146
-
Nessa situação, ela poderia publicar virtuosamente a transação, fechando o canal. Ela coloca a transação na cadeia e espera 24 horas. Bob não pode fazer nada a respeito porque não possui o código de recuperação. Então, após a espera, Alice recupera os fundos. Bob pode fazer a mesma coisa com sua própria transação final.
146
+
Nessa situação, ela poderia publicar virtuosamente a transação, fechando o canal. Ela coloca a transação na blockchain e espera 24 horas. Bob não pode fazer nada a respeito porque não possui o código de recuperação. Então, após a espera, Alice recupera os fundos. Bob pode fazer a mesma coisa com sua própria transação final.
147
147
148
-
### Bloqueando com Contratos de Bloqueio de Tempo com Hash
148
+
### Bloqueando com Contratos de Bloqueio de Tempo em Hash
149
149
150
-
As Transações de Compromisso Revogável foram apenas um trampolim para a Lightning. A Lightning Network real usa um mecanismo mais complexo chamado [Contrato de Bloqueio de Tempo com Hash (ou no inglês, Hashed TimeLock Contract)](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) ou mais conhecido como HTLC.
150
+
As Transações de Compromisso Revogável foram apenas um trampolim para a Lightning. A Lightning Network real usa um mecanismo mais complexo chamado [Contrato de Bloqueio de Tempo em Hash (ou no inglês, Hashed TimeLock Contract)](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts), mais conhecido como HTLC.
151
151
152
152
O principal objetivo dos HTLCs é criar uma rede abrangente de participantes. As transações não são mais apenas entre um par de participantes que entraram na rede juntos, mas agora podem ser várias pessoas que não estão associadas diretamente. Quando os fundos são enviados, uma string de transações é criada, cada uma delas bloqueada com um ```secretHash```. Quando o ```secretCode``` correspondente é revelado, toda a sequência de transações pode ser gasta. Isso é o que permite que transações singulares realmente se tornem uma rede.
153
153
154
154
Também há um pouco mais de complexidade nos scripts de bloqueio da Lightning Network. Existem bloqueios separados para o remetente e o destinatário de cada transação que são mais amplamente divergentes do que as diferentes transações de compromisso mencionadas na seção anterior. Vamos mostrar os dois, para demonstrar o poder desses scripts de bloqueio, mas não vamos explicar como eles interagem entre si.
155
155
156
-
#### Bloqueando a transação do destinatário
156
+
#### Bloqueando a Transação do Destinatário
157
157
158
158
Mais uma vez, vamos começar a olhar para a transação de compromisso da Alice, que mostra os fundos que ela recebeu:
159
159
```
@@ -182,11 +182,11 @@ A chave para esses novos HTLCs é o ```secretHash```, que dissemos que é o que
182
182
183
183
Após o ```secretCode``` ter sido revelado, o caminho do ```IF``` é utilizado. Alice pode reivindicar os fundos 24 horas após a transação ser colocada na rede Bitcoin.
184
184
185
-
No entanto, também há a oportunidade de Bob recuperar os fundos, que aparecem no caminho do ```ELSE```. Ele pode fazer isso se a transação foi revogada, mas Alice a coloca na blockchain de qualquer maneira, _ou se_ um tempo limite absoluto ocorrer.
185
+
No entanto, também há a oportunidade de Bob recuperar os fundos, que aparecem no caminho do ```ELSE```. Ele pode fazer isso se a transação foi revogada (mas Alice a coloca na blockchain de qualquer maneira), _ou se_ um tempo absoluto se esgotar (timeout).
186
186
187
-
#### Bloqueando a transação do remetente
187
+
#### Bloqueando a Transação do Remetente
188
188
189
-
Este é o script de bloqueio de transação de confirmação alternativo usado pelo remetente:
189
+
Este é o script alternativo de bloqueio da transação de confirmação usado pelo remetente:
A execução do script revela que as verificações iniciais, acima do ```IF```/```ELSE```/```ENDIF```, determinam se o hash era _tanto_ o ```secretCode```_ou_ o ```revokeCode```. Nesse caso, Alice pode pegar os fundos no primeiro bloco. Do contrário, Bob pode pegar os fundos, mas somente depois que Alice tiver sua chance e depois que o tempo limite de 24 horas e o tempo limite absoluto tiverem passado.
249
+
A execução do script revela que as verificações iniciais, acima do ```IF```/```ELSE```/```ENDIF```, determinam se o hash era _tanto_ o ```secretCode```_ou_ o ```revokeCode```. Nesse caso, Alice pode pegar os fundos no primeiro bloco. Do contrário, Bob pode pegar os fundos, mas somente depois que Alice tiver sua chance e depois que o tempo limite de 24 horas e o tempo limite absoluto tiverem se esgotado.
250
250
251
251
#### Compreendendo os HTLCs
252
252
253
-
Os HTLCs são bastante complexos e esta seção não tenta explicar todas as suas complexidades. A [visão geral](https://rusty.ozlabs.org/?p=462) escrita por Rusty Russell explica bem mais, e há ainda mais detalhes no seu artigo [Deployable-lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf). Mas não se preocupe se algumas das complexidades ainda ficarem meio nebulosas para nós, especialmente sobre o funcionamento das inter-relações dos dois scripts.
253
+
Os HTLCs são bastante complexos e esta seção não tenta explicar todas as suas complexidades. A [visão geral](https://rusty.ozlabs.org/?p=462) escrita por Rusty Russell explica bem mais, e há ainda mais detalhes no seu artigo [Deployable-lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf). Mas não se preocupe se algumas das complexidades ainda não ficaram claras para você, especialmente sobre o funcionamento das inter-relações dos dois scripts.
254
254
255
255
Para os fins deste tutorial, existem duas lições importantes em relação aos HTLCs:
256
256
257
-
* Entender que uma estrutura muito complexa como um HTLC pode ser criada usando o Script do Bitcoin;
257
+
* Entender que uma estrutura muito complexa como um HTLC pode ser criada usando o Bitcoin Script;
258
258
* Analisar como executar cada um dos scripts HTLC.
259
259
260
260
Vale a pena executar cada um dos dois scripts HTLC em cada uma de permutações, um item da pilha de cada vez.
261
261
262
-
## Resumo: Expandindo o Bitcoin com os Scripts
262
+
## Resumo: Capacitando o Bitcoin com Scripts
263
263
264
-
Estamos encerrando o exame dos scripts do bitcoin com uma visão de como eles podem ser realmente poderosos. Com 20 opcodes ou menos, um script Bitcoin pode formar a base de todo um canal de pagamento fora da blockchain. Da mesma forma, sidechains com conexões bidirecionais são o produto de menos de vinte opcodes, como também observado brevemente em[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki).
264
+
Estamos encerrando o exame dos scripts do Bitcoin com uma visão de como eles podem ser realmente poderosos. Com 20 opcodes ou menos, um script Bitcoin pode formar a base de todo um canal de pagamento fora da blockchain. Da mesma forma, sidechains com conexões bidirecionais são o produto de menos de vinte opcodes, como também observado brevemente no[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki).
265
265
266
-
Se já vimos a funcionalidade complexa do Bitcoin ou os sistemas adjacentes ao Bitcoin, eles provavelmente foram construídos em scripts Bitcoin. E agora temos todas as ferramentas para fazer o mesmo.
266
+
Se você já viu funcionalidades complexas do Bitcoin ou sistemas adjacentes ao Bitcoin, eles provavelmente foram construídos em Bitcoin Script. E agora temos todas as ferramentas para fazer o mesmo.
267
267
268
268
## O Que Vem Depois?
269
269
270
-
Vamos ficar "Usando o Tor" no [Capítulo 14: Usando o Tor](14_0_Using_Tor.md).
270
+
Vamos ficar "Usando o Tor" no [Capítulo Quatorze: Usando o Tor](14_0_Using_Tor.md).
271
271
272
272
Ou, se preferir, existem dois caminhos alternativos:
273
273
274
-
Se quiser manter o foco no Bitcoin, vá para o "Programando com o RPC" no [Capítulo Quinze: Conversando com Bitcoind usando C](15_0_Talking_to_Bitcoind.md).
274
+
Se quiser manter o foco no Bitcoin, siga em frente para "Programando com o RPC" no [Capítulo Quinze: Conversando com Bitcoind usando C](15_0_Talking_to_Bitcoind.md).
275
275
276
-
Ou, se quisermos manter o foco na linha de comando porque não somos programadores, podemos pular para o [Capítulo Dezoito: Entendendo Nossa Configuração da Lightning](18_0_Understanding_Your_Lightning_Setup.md) para continuar nossa aula usando a linha de comando com a Lightning Network.
276
+
Ou, se quiser manter o foco na linha de comando porque não é um programador, pode pular para o [Capítulo Dezoito: Entendendo Nossa Configuração da Lightning](18_0_Understanding_Your_Lightning_Setup.md) para continuar seus estudos da linha de comando com a Lightning Network.
0 commit comments