mirror of
https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git
synced 2025-06-07 16:06:26 +00:00
Chapter 10 full translated
This commit is contained in:
KoreaComK
parent
bb6dd6cfde
commit
b630588e1d
26
pt/10_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md
Normal file
26
pt/10_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md
Normal file
@ -0,0 +1,26 @@
|
||||
# Capítulo 10: Incorporando Scripts em Transações P2SH no Bitcoin
|
||||
|
||||
O Script do Bitcoin desce vários níveis de abstração, permitindo que controlemos minuciosamente as condições de resgate dos fundos. Mas, como realmente incorporamos esses scripts do Bitcoin nas transações que construímos até agora? A resposta é um novo tipo de transação de Bitcoin, o P2SH.
|
||||
|
||||
## Objetivos deste capítulo
|
||||
|
||||
Depois de trabalhar neste capítulo, um desenvolvedor será capaz de:
|
||||
|
||||
* Projetar uma transação P2SH;
|
||||
* Aplicar um script P2SH Bitcoin.
|
||||
|
||||
Os objetivos secundários do capítulo incluem a capacidade de:
|
||||
|
||||
* Compreender o script P2SH;
|
||||
* Compreender o Script Multisig;
|
||||
* Compreender as várias variações dos scripts Segwit;
|
||||
* Entender como gastar fundos enviados a um P2SH.
|
||||
|
||||
## Tabela de conteúdo
|
||||
|
||||
* [Seção 1: Entendendo a Fundação do P2SH](10_1_Understanding_the_Foundation_of_P2SH.md)
|
||||
* [Seção 2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md)
|
||||
* [Seção 3: Executando um script Bitcoin com P2SH](10_3_Running_a_Bitcoin_Script_with_P2SH.md)
|
||||
* [Seção 4: Criando scripts multisig](10_4_Scripting_a_Multisig.md)
|
||||
* [Seção 5: Criando um script Segwit](10_5_Scripting_a_Segwit_Script.md)
|
||||
* [Seção 6: Gastando uma Transação P2SH](10_6_Spending_a_P2SH_Transaction.md)
|
||||
100
pt/10_1_Understanding_the_Foundation_of_P2SH.md
Normal file
100
pt/10_1_Understanding_the_Foundation_of_P2SH.md
Normal file
@ -0,0 +1,100 @@
|
||||
# 10.1: Entendendo a Fundação do P2SH
|
||||
|
||||
Sabemos que os scripts do Bitcoin podem ser usados para controlar o resgate dos UTXOs. A próxima etapa é criar os nossos próprios scripts... Mas isso requer uma técnica muito específica.
|
||||
|
||||
## Conhecendo os Padrões do Bitcoin
|
||||
|
||||
Aqui está a pegadinha sobre como usar scripts do Bitcoin: Por razões de segurança, a maioria dos nós do Bitcoin aceitará apenas seis tipos de transações de Bitcoin, ditas como "padrão".
|
||||
|
||||
* __Pay to Public Key (P2PK)__ - O tipo de transação mais antiga e obsoleta (```<pubKey> OP_CHECKSIG```) que foi substituída por uma mais segura, a P2PKH.
|
||||
* __Pay to Public Key Hash (P2PKH)__ - Uma transação padrão (```OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG```) que paga para o hash de uma chave pública.
|
||||
* __Pay to Witness Public Key Hash (P2WPKH)__ - O tipo mais novo de transação de chave pública. Usa apenas (```OP_0 <pubKeyHash>```) porque depende do consenso do minerador para funcionar, conforme descrito na seção [§9.5](09_5_Scripting_a_P2WPKH.md).
|
||||
* __Multisig__ - Uma transação para um grupo de chaves, conforme explicado mais detalhadamente na seção [§8.4](08_4_Scripting_a_Multisig.md).
|
||||
* __Null Data__ - Uma transação que não pode ser gasta (`OP_RETURN Data`).
|
||||
* __Pay to Script Hash (P2SH)__ - Uma transação que paga a um script específico, conforme explicado mais detalhadamente neste capítulo.
|
||||
|
||||
Então, como podemos descrever um script mais complexo do Bitcoin? A resposta está nesse último tipo de transação padrão, o P2SH. Podemos colocar qualquer tipo de script mais longo e complexo em uma transação P2SH e, contanto que sigamos as regras padrões para incorporar nosso script e resgatar os fundos, obteremos todos os benefícios do Script do Bitcoin.
|
||||
|
||||
> :warning: **AVISO DE VERSÃO:** Os Scripts P2SH somente se tornaram padrão à partir do Bitcoin Core 0.10.0. Antes disso, apenas os scripts do tipo P2SH Multisigs eram permitidos.
|
||||
|
||||
## Compreendendo o script P2SH
|
||||
|
||||
Você já viu uma transação P2SH quando criou uma multisig na seção [§6.1: Enviando uma Transação com Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md). Embora o multisig seja um dos tipos de transação padrão, o ```bitcoin-cli``` simplifica o uso dos multisigs, incorporando-os às transações P2SH, conforme descrito mais detalhadamente na seção [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
|
||||
|
||||
Então, vamos olhar mais uma vez para o ```scriptPubKey``` daquela transação multisig P2SH:
|
||||
```
|
||||
"scriptPubKey": {
|
||||
"asm": "OP_HASH160 a5d106eb8ee51b23cf60d8bd98bc285695f233f3 OP_EQUAL",
|
||||
"hex": "a914a5d106eb8ee51b23cf60d8bd98bc285695f233f387",
|
||||
"reqSigs": 1,
|
||||
"type": "scripthash",
|
||||
"addresses": [
|
||||
"2N8MytPW2ih27LctLjn6LfLFZZb1PFSsqBr"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
O script de bloqueio tem uma aparência bastante simples: ```OP_HASH160 a5d106eb8ee51b23cf60d8bd98bc285695f233f3 OP_EQUAL```. Como de costume, há um grande bloco de dados no meio. Este é um hash de outro script de bloqueio que está oculto (```redeemScript```) que só será revelado quando os fundos forem resgatados. Em outras palavras, o script de bloqueio padrão para um endereço P2SH é: ```OP_HASH160 <redeemScriptHash> OP_EQUAL```.
|
||||
|
||||
> :book: *** O que é um redemScript? *** Cada transação P2SH carrega a impressão digital de um script de bloqueio que fica oculto como um hash de 20 bytes. Quando uma transação P2SH é resgatada, o ```redeemScript``` completo (sem o hash) é incluído como parte do ```scriptSig```. O Bitcoin garantirá que o ```redeemScript``` corresponda ao hash. Então, ele realmente executa o ```redeemScript``` para ver se os fundos podem ser gastos (ou não).
|
||||
|
||||
Um dos elementos interessantes das transações P2SH é que nem o remetente nem o Blockchain sabem realmente o que é o ```redemScript```! Um remetente simplesmente envia para um endereço P2SH padronizado que é marcado com um prefixo "2" e, não se preocupa com a forma como o destinatário irá recuperar os fundos.
|
||||
|
||||
> :link: **TESTNET vs MAINNET:** Na testnet, o prefixo para endereços P2SH é ```2```, enquanto na mainnet, é ```3```.
|
||||
|
||||
## Entendendo como construir um script P2SH
|
||||
|
||||
Como o script de bloqueio está visível para uma transação P2SH e é bem simples, criar uma transação desse tipo também é um tanto quanto fácil. Em teoria. Tudo o que precisamos fazer é criar uma transação cujo script de bloqueio inclua um hash de 20 bytes do ```redeemScript```. Esse hash é feito com o padrão ```OP_HASH160``` do Bitcoin.
|
||||
|
||||
> :book: ***O que é OP_HASH160?*** Uma operação padrão do hash para o Bitcoin executar um hash SHA-256 e, em seguida, um hash RIPEMD-160.
|
||||
|
||||
No geral, quatro etapas são necessárias:
|
||||
|
||||
1. Criar um script de bloqueio arbitrário com o script do Bitcoin;
|
||||
2. Criar uma versão serializada desse script de bloqueio;
|
||||
3. Executar um hash SHA-256 nesses bytes serializados;
|
||||
4. Executar um hash RIPEMD-160 nos resultados desse hash SHA-256.
|
||||
|
||||
Cada uma dessas etapas exige algum trabalho e, algumas delas podem ser bastante complexas. A boa notícia é que realmente não precisamos se preocupar com elas, porque são complexas o suficiente para que tenhamos uma API que faz o serviço para nós, normalmente.
|
||||
|
||||
Por enquanto, forneceremos apenas uma visão geral, para que entendamos o contexto da metodologia. Na seção [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md), forneceremos uma visão mais aprofundada da criação do script, caso queiramos entender a essência desse processo.
|
||||
|
||||
## Entendendo como enviar uma transação do tipo P2SH
|
||||
|
||||
Então, como enviamos nossa transação P2SH? Novamente, a teoria é muito simples:
|
||||
|
||||
1. Incorporamos o hash em um script ```OP_HASH160 <redeemScriptHash> OP_EQUAL```;
|
||||
2. Traduzimos isso para um código hexadecimal;
|
||||
3. Usamos esse hex como nosso ```scriptPubKey```;
|
||||
4. Criamos o resto da transação.
|
||||
|
||||
Infelizmente, este é lugar momento em que precisaremos usar às APIs, em grande parte porque o ```bitcoin-cli``` não fornece nenhum suporte para a criação de transações P2SH. Mas, podemos resgatá-las sem problema.
|
||||
|
||||
## Entendendo como desbloquear uma transação do tipo P2SH
|
||||
|
||||
O truque para resgatar uma transação P2SH é que o destinatário deve ter salvo o script secreto de bloqueio serializado que foi codificado para criar o endereço P2SH. Isso se chama ```redeemScript``` porque é o que o destinatário precisa para resgatar os fundos.
|
||||
|
||||
Um ```scriptSig``` de desbloqueio para uma transação P2SH tem o seguinte formato:``` ... dados ... <redeemScript>```. Os ```dados``` devem ser _somente_ dados que são colocados na pilha, não operadores. O [BIP 16](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) os chama de assinaturas, mas isso não é um requisito real.
|
||||
|
||||
> :warning: **AVISO:** Embora assinaturas não sejam um requisito, um script P2SH na verdade não é muito seguro se não exigir pelo menos uma assinatura nas entradas. As razões para isso estão descritas na seção [§13.1: Escrevendo scripts de quebra-cabeças](13_1_Writing_Puzzle_Scripts.md).
|
||||
|
||||
Quando um UTXO é resgatado, ele é executado em duas rodadas de verificação:
|
||||
|
||||
1. Primeiro, o ```redeemScript``` no ```scriptSig``` está em hash e é comparado ao hash do script no ```scriptPubKey```;
|
||||
2. Se eles corresponderem, uma segunda rodada de verificação será iniciada;
|
||||
3. Em segundo lugar, o ```redeemScript``` é executado usando os dados anteriores que foram colocados na pilha;
|
||||
4. Se a segunda rodada de verificação _também_ for bem-sucedida, o UTXO é desbloqueado.
|
||||
|
||||
Considerando que não podemos criar facilmente uma transação P2SH sem uma API, devemos ser capazes de resgatar facilmente uma transação P2SH com o ```bitcoin-cli```. Na verdade, já fizemos isso na seção [§6.2: Gastando uma Transação com Multsig] (06_2_Spending_a_Transaction_to_a_Multisig.md). O processo exato é descrito na seção [§10.6: Gastando uma transação P2SH](10_6_Spending_a_P2SH_Transaction.md), após terminarmos com todas as complexidades da criação de uma transação P2SH.
|
||||
|
||||
> :warning: **AVISO:** Podemos criar uma transação perfeitamente válida com um redemScript com o hash correto, mas se o redemScript não funcionar, ou não funcionar corretamente, os fundos serão perdidos para sempre. É por isso que é importantíssimo testar os Scripts, conforme discutido na seção [§9.3: Testando um Script no Bitcoin](09_3_Testing_a_Bitcoin_Script.md).
|
||||
|
||||
## Resumo: Entendendo a Fundação do P2SH
|
||||
|
||||
Os scripts arbitrários do Bitcoin não são o padrão neste sistema. No entanto, podemos incorporá-los em transações padrão usando o tipo de endereço P2SH. Precisamos apenas fazer um hash do nosso script como parte do script de bloqueio, então o revelamos e executamos como parte do script de desbloqueio. Contanto que também possamos satisfazer o ```redeemScript```, o UTXO poderá ser gasto.
|
||||
|
||||
> :fire: ***Qual é o poder do P2SH?*** Já sabemos o poder do script do Bitcoin, que nos permite criar Contratos Inteligentes mais complexos de todos os tipos. O P2SH é o que realmente libera esse poder, nos permitindo que incluamos o Script arbitrário do Bitcoin em transações padrão.
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos continuar "Incorporando Scripts em Transações P2SH no Bitcoin" na seção [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md).
|
||||
182
pt/10_2_Building_the_Structure_of_P2SH.md
Normal file
182
pt/10_2_Building_the_Structure_of_P2SH.md
Normal file
@ -0,0 +1,182 @@
|
||||
# 10.2: Construindo a Estrutura de P2SH
|
||||
|
||||
Na seção anterior, apresentamos uma visão geral da teoria de como criar as transações P2SH para armazenar os scripts de Bitcoin. Na prática, fazer isso é _muito mais difícil_, mas por uma questão de integridade, vamos examinar minuciosamente todos os pontos. Provavelmente, isso não é algo que faríamos sem uma API, então, se ficar muito complicado, esteja ciente de que retornaremos aos scripts originais de alto nível mais pra frente.
|
||||
|
||||
## Criando um Script de Bloqueio
|
||||
|
||||
Qualquer transação P2SH começa com um script de bloqueio. Esse é o assunto dos capítulos 9, 11 e 12. Podemos usar qualquer um dos métodos de script do Bitcoin descritos nestes capítulos para criar qualquer tipo de script de bloqueio, desde que o ```redeemScript``` serializado resultante tenha 520 bytes ou menos.
|
||||
|
||||
> :book: ***Por que os scripts P2SH são limitados a 520 bytes?*** Como muitas coisas no Bitcoin, a resposta é a compatibilidade com as versões anteriores: Novas funcionalidades devem ser constantemente criadas dentro das antigas restrições do sistema. Nesse caso, 520 bytes é o máximo que pode ser colocado na pilha de uma vez. Como todo o redemScript é colocado na pilha como parte do processo de resgate, ele está limitado a essa quantidade.
|
||||
|
||||
## Serializando um script de bloqueio da maneira mais difícil
|
||||
|
||||
Depois de criar um script de bloqueio, precisamos serializá-lo antes que possamos ser inseridos no Bitcoin. Este é um processo de duas partes. Primeiro, devemos transformá-lo em um hexcode, para então transformar esse hex em binário.
|
||||
|
||||
### Criando o código hexadecimal
|
||||
|
||||
Criar o hexcode necessário para serializar um script é uma simples tradução, mas ao mesmo tempo, algo complexo o suficiente para ir além de qualquer script shell que provavelmente escreveremos. Esta etapa é um dos principais motivos pelos quais precisamos de uma API para criar as transações P2SH.
|
||||
|
||||
Podemos criar um hexcode percorrendo nosso script de bloqueio e transformando cada elemento em um comando hexadecimal de um byte, possivelmente seguido por dados adicionais. De acordo com o guia da [página Bitcoin Wiki Script](https://en.bitcoin.it/wiki/ Roteiro):
|
||||
|
||||
* Os operadores são traduzidos para o byte correspondente para esse opcode;
|
||||
* As constantes 1-16 são convertidas para opcodes 0x51 a 0x61 (OP_1 a OP_16);
|
||||
* A constante -1 é traduzida para opcode 0x4f (OP_1NEGATE);
|
||||
* Outras constantes são precedidas por opcodes 0x01 a 0x4e (OP_PUSHDATA, com o número especificando de quantos bytes adicionar);
|
||||
* Os inteiros são traduzidos em hexadecimal usando a notação de magnitude com sinal _little-endian_.
|
||||
|
||||
### Traduzindo os tipos inteiros
|
||||
|
||||
Os inteiros são a parte mais problemática de uma tradução de script de bloqueio.
|
||||
|
||||
Primeiro, devemos verificar se o nosso número está entre -2147483647 e 2147483647, o intervalo de inteiros de quatro bytes quando o byte mais significativo é usado para assinatura.
|
||||
|
||||
Em segundo lugar, precisamos traduzir o valor decimal em hexadecimal e preenchê-lo com um número par de dígitos. Isso pode ser feito com o comando ```printf```:
|
||||
```
|
||||
$ integer=1546288031
|
||||
$ hex=$(printf '%08x\n' $integer | sed 's/^\(00\)*//')
|
||||
$ echo $hex
|
||||
5c2a7b9f
|
||||
```
|
||||
Terceiro, precisamos adicionar um byte inicial adicional de ```00``` se o dígito superior for "8" ou maior, para que o número não seja interpretado como negativo.
|
||||
```
|
||||
$ hexfirst=$(echo $hex | cut -c1)
|
||||
$ [[ 0x$hexfirst -gt 0x7 ]] && hex="00"$hex
|
||||
```
|
||||
Quarto, precisamos traduzir o hexa em _big-endian_ (byte menos significativo por último) para _little-endian_ (byte menos significativo primeiro). Podemos fazer isso com o comando ```tac```:
|
||||
```
|
||||
$ lehex=$(echo $hex | tac -rs .. | echo "$(tr -d '\n')")
|
||||
$ echo $lehex
|
||||
9f7b2a5c
|
||||
```
|
||||
Além disso, sempre precisaremos saber o tamanho dos dados que colocamos na pilha, para que possa precedê-los com o opcode adequado. Podemos apenas lembrar que cada dois caracteres hexadecimais é um byte. Ou podemos usar o comando ```echo -n``` com o pipe para ```wc -c``` e dividi-lo ao meio:
|
||||
```
|
||||
$ echo -n $lehex | wc -c | awk '{print $1/2}'
|
||||
4
|
||||
```
|
||||
Com todo esse trabalho, iríamos saber que poderíamos traduzir o número inteiro 1546288031 em um opcode ```04``` (para colocar quatro bytes na pilha) seguido por ```9f7b2a5c``` (a representação hexadecimal do tipo _little-endian_ de 1546288031).
|
||||
|
||||
Se, ao invés disso, tivéssemos um número negativo, precisaríamos (1) fazer os cálculos no valor absoluto do número e, em seguida, (2) bit a bit - ou colocar 0x80 para nosso resultado _little-endian_ final. Por exemplo, ```9f7b2a5c```, que é 1546288031, se tornaria ```9f7b2adc```, que é -1546288031:
|
||||
```
|
||||
$ neglehex=$(printf '%x\n' $((0x$lehex | 0x80)))
|
||||
$ echo $neglehex
|
||||
9f7b2adc
|
||||
```
|
||||
|
||||
### Transformando o Hex em Binário
|
||||
|
||||
Para completar nossa serialização, traduzimos o código hexadecimal em binário. Na linha de comando, isso requer apenas uma invocação simples do ```xxd -r -p```. No entanto, provavelmente desejamos fazer isso tudo junto, para também fazer o hash do script...
|
||||
|
||||
## Executando o script de conversão de tipos inteiros
|
||||
|
||||
Um script completo para alterar um número inteiro entre -2147483647 e 2147483647 para uma representação de magnitude assinada do tipo _little-endian_ em hexadecimal pode ser encontrado no [diretório de código src](src/10_2_integer2lehex.sh). Podemos baixar o ```integeer2lehex.sh```.
|
||||
|
||||
> :warning: **AVISO:** Este script não foi verificado de forma consistente. Se formos utilizá-lo para criar scripts de bloqueio reais, precisamos nos certificar de verificar e testar os resultados.
|
||||
|
||||
Precisamos nos certificar de que as permissões no script estão corretas:
|
||||
```
|
||||
$ chmod 755 integer2lehex.sh
|
||||
```
|
||||
Podemos então executar o script da seguinte maneira:
|
||||
```
|
||||
$ ./integer2lehex.sh 1546288031
|
||||
Integer: 1546288031
|
||||
LE Hex: 9f7b2a5c
|
||||
Length: 4 bytes
|
||||
Hexcode: 049f7b2a5c
|
||||
|
||||
$ ./integer2lehex.sh -1546288031
|
||||
Integer: -1546288031
|
||||
LE Hex: 9f7b2adc
|
||||
Length: 4 bytes
|
||||
Hexcode: 049f7b2adc
|
||||
```
|
||||
|
||||
## Analisando um P2SH Multisig
|
||||
|
||||
Para entender melhor o processo, faremos a engenharia reversa do multisig P2SH que criamos na seção [§6.1: Enviando uma Transação com Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md). Dê uma olhada no ```redeemScript``` que usamos, que agora sabemos que é a versão hexadecimal do script de bloqueio:
|
||||
```
|
||||
522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa352ae
|
||||
```
|
||||
Podemos traduzir isso de volta para o script manualmente usando a [página do Bitcoin Wiki Script](https://en.bitcoin.it/wiki/Script) como uma referência. Basta olhar para um byte (dois caracteres hexadecimais) de dados por vez, a menos que nos seja dito para olhar pra mais bytes usando OP_PUSHDATA (um opcode no intervalo de 0x01 a 0x4e).
|
||||
|
||||
Todo o Script será dividido da seguinte forma:
|
||||
```
|
||||
52 / 21 / 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 / 21 / 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 / 52 / ae
|
||||
```
|
||||
Aqui está o que as partes individuais significam:
|
||||
|
||||
* 0x52 = OP_2
|
||||
* 0x21 = OP_PUSHDATA 33 bytes (hex: 0x21)
|
||||
* 0x02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 = os próximos 33 bytes (hash de chave pública)
|
||||
* 0x21 = OP_PUSHDATA 33 bytes (hex: 0x21)
|
||||
* 0x02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 = os próximos 33 bytes (hash de chave pública)
|
||||
* 0x52 = OP_2
|
||||
* 0xae = OP_CHECKMULTISIG
|
||||
|
||||
Em outras palavras, esse ```redeemScript``` era uma tradução de ```2 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 2 OP_CHECKMULTISIG``` Voltaremos a este script na seção [§10.4: Criando scripts multisig](10_4_Scripting_a_Multisig.md) quando detalharmos exatamente como os multisigs funcionam dentro do paradigma P2SH.
|
||||
|
||||
Se gostarmos de fazer o trabalho manual com esse tipo de tradução no futuro, podemos usar o ```decodescript bitcoin-cli```:
|
||||
```
|
||||
$ bitcoin-cli -named decodescript hexstring=522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa352ae
|
||||
{
|
||||
"asm": "2 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 2 OP_CHECKMULTISIG",
|
||||
"reqSigs": 2,
|
||||
"type": "multisig",
|
||||
"addresses": [
|
||||
"mmC2x2FoYwBnVHMPRUAzPYg6WDA31F1ot2",
|
||||
"mhwZFJUnWqTqy4Y7pXVum88qFtUnVG1keM"
|
||||
],
|
||||
"p2sh": "2N8MytPW2ih27LctLjn6LfLFZZb1PFSsqBr",
|
||||
"segwit": {
|
||||
"asm": "0 6fe9f451ccedb8e4090b822dcad973d0388a37b4c89fd1aed485110adecab2a9",
|
||||
"hex": "00206fe9f451ccedb8e4090b822dcad973d0388a37b4c89fd1aed485110adecab2a9",
|
||||
"reqSigs": 1,
|
||||
"type": "witness_v0_scripthash",
|
||||
"addresses": [
|
||||
"tb1qdl5lg5wvakuwgzgtsgku4ktn6qug5da5ez0artk5s5gs4hk2k25szvjky9"
|
||||
],
|
||||
"p2sh-segwit": "2NByn92W1vH5oQC1daY69F5sU7PEStKKQBR"
|
||||
}
|
||||
}
|
||||
```
|
||||
É especialmente útil para verificar nosso trabalho durante a serialização.
|
||||
|
||||
## Serializando um script de bloqueio da maneira mais fácil
|
||||
|
||||
Quando instalamos o ```btcdeb``` na seção [§9.3](09_3_Testing_a_Bitcoin_Script.md) também instalamos o ```btcc``` que pode ser usado para serializar scripts do Bitcoin:
|
||||
```
|
||||
$ btcc 2 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 2 OP_CHECKMULTISIG
|
||||
warning: ambiguous input 2 is interpreted as a numeric value; use OP_2 to force into opcode
|
||||
warning: ambiguous input 2 is interpreted as a numeric value; use OP_2 to force into opcode
|
||||
522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa352ae
|
||||
```
|
||||
Isso é muito mais fácil do que fazer tudo na mão!
|
||||
|
||||
Considere também o compilador em Python, [Transaction Script Compiler](https://github.com/Kefkius/txsc), que traduz de trás pra frente também.
|
||||
|
||||
## Fazendo o hash de um script serializado
|
||||
|
||||
Depois de criar um script de bloqueio e serializá-lo, a terceira etapa na criação de uma transação P2SH é fazer o hash do script de bloqueio. Conforme observado anteriormente, um hash OP_HASH160 de 20 bytes é criado por meio de uma combinação de um hash SHA-256 e um hash RIPEMD-160. O hash de um script serializado, portanto, requer dois comandos: ```openssl dgst -sha256 -binary``` que faz o hash SHA-256 e produz um binário a ser enviado no pipe, então o ```openssl dgst -rmd160``` pega o fluxo do binário, faz um RIPEMD- 160 hash e, finalmente, gera um código hexadecimal legível.
|
||||
|
||||
Aqui está todo o processo, incluindo a transformação anterior do script hexadecimal em binário:
|
||||
```
|
||||
$ redeemScript="522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa352ae"
|
||||
$ echo -n $redeemScript | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -rmd160
|
||||
(stdin)= a5d106eb8ee51b23cf60d8bd98bc285695f233f3
|
||||
```
|
||||
|
||||
## Criando uma transação P2SH
|
||||
|
||||
Criar o hash de 20 bytes apenas fornece o hash no centro de um script de bloqueio P2SH. Ainda precisamos colocá-lo junto com os outros opcodes que criam uma transação P2SH padrão: ```OP_HASH160 a5d106eb8ee51b23cf60d8bd98bc285695f233f3 OP_EQUAL```.
|
||||
|
||||
Dependendo de nossa API, podemos inserir isso como um ```scriptPubKey``` no estilo ```asm``` para nossa transação, ou podemos ter que traduzi-lo para o código ```hex``` também. Se tivermos que traduzir, podemos usar os mesmos métodos descritos acima para "Criar o código hexadecimal" (ou usar o ```btcc```), resultando em ```a914a5d106eb8ee51b23cf60d8bd98bc285695f233f387```.
|
||||
|
||||
Podemos observar que o ```hex scriptPubKey``` para a transação P2SH Script irá _sempre_ começar com um ```a914```, que é o ```OP_HASH160``` seguido por um ```OP_PUSHDATA``` de 20 bytes (hex: ```0x14```); e _sempre_ terminará com um ```87```, que é um ```OP_EQUAL```. Portanto, tudo o que precisamos fazer é colocar o script de resgate em hash entre esses números.
|
||||
|
||||
## Resumo: Construindo a Estrutura de P2SH
|
||||
|
||||
Na verdade, a criação do script de bloqueio P2SH entra ainda mais nas entranhas do Bitcoin. Embora seja útil saber como tudo isso funciona em um nível muito baixo, é mais provável que tenhamos uma API cuidando de todo o trabalho pesado para nós. Nossa tarefa será simplesmente criar o Script Bitcoin para fazer o bloqueio... Que é o tópico principal dos capítulos 9, 11 e 12.
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos continuar "Incorporando Scripts em Transações P2SH no Bitcoin" na seção [§10.3: Executando um script Bitcoin com P2SH](10_3_Running_a_Bitcoin_Script_with_P2SH.md).
|
||||
99
pt/10_3_Running_a_Bitcoin_Script_with_P2SH.md
Normal file
99
pt/10_3_Running_a_Bitcoin_Script_with_P2SH.md
Normal file
@ -0,0 +1,99 @@
|
||||
# 10.3: Executando um script Bitcoin com P2SH
|
||||
|
||||
Agora que conhecemos a teoria e a prática por trás dos endereços P2SH, estamos prontos para transformar um script de Bitcoin não padrão em uma transação real. Vamos utilizar o script de bloqueio simples da seção [§9.2: Executando um Script no Bitcoin](09_2_Running_a_Bitcoin_Script.md), `OP_ADD 99 OP_EQUAL`.
|
||||
|
||||
## Criando uma transação P2SH
|
||||
|
||||
Para bloquear uma transação com este script, precisamos fazer o seguinte:
|
||||
|
||||
1. Serializar o `OP_ADD 99 OP_EQUAL`:
|
||||
1. OP_ADD = 0x93 - uma tradução simples do opcode;
|
||||
2. 99 = 0x01, 0x63 - este opcode coloca um byte na pilha, 99 (hex: 0x63);
|
||||
* Não se preocupe com a conversão porque é apenas um byte.
|
||||
3. OP_EQUAL = 0x87 - uma tradução simples do opcode;
|
||||
4. ```<serialized99Equal>``` = "93016387".
|
||||
|
||||
```
|
||||
$ btcc OP_ADD 99 OP_EQUAL
|
||||
93016387
|
||||
```
|
||||
2. Vamos salvar o ```<serialized99Equal>``` para referência futura como ```redeemScript```;
|
||||
1. `<redeemScript>` = "93016387".
|
||||
3. SHA-256 e RIPEMD-160 do hash do script serializado;
|
||||
1. ```<hashed99Equal>``` = "3f58b4f7b14847a9083694b9b3b52a4cea2569ed".
|
||||
4. Produzir um script de bloqueio P2SH que inclua o ```<hashed99Equal>```;
|
||||
1. ```scriptPubKey``` ="a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed87".
|
||||
|
||||
Podemos então criar uma transação usando o ```scriptPubKey```, provavelmente através de uma API.
|
||||
|
||||
## Desbloqueando a transação P2SH
|
||||
|
||||
Para desbloquear essa transação, é necessário que o destinatário produza um ```scriptSig``` que acrescente duas constantes, totalizando noventa e nove, ao script serializado:```1 98 <serialized99Equal>```.
|
||||
|
||||
### Executando a primeira rodada de validação
|
||||
|
||||
O processo de desbloqueio da transação P2SH começa com uma primeira rodada de validação, que nada mais é que a verificação se o script de resgate corresponde ao valor hash no script de bloqueio.
|
||||
|
||||
Vamos concatenar o ```scriptSig``` e o ```scriptPubKey``` e executá-los, normalmente:
|
||||
```
|
||||
Script: 1 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
|
||||
Stack: []
|
||||
|
||||
Script: 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
|
||||
Stack: [ 1 ]
|
||||
|
||||
Script: <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
|
||||
Stack: [ 1 98 ]
|
||||
|
||||
Script: OP_HASH160 <hashed99Equal> OP_EQUAL
|
||||
Stack: [ 1 98 <serialized99Equal> ]
|
||||
|
||||
Script: <hashed99Equal> OP_EQUAL
|
||||
Running: <serialized99Equal> OP_HASH160
|
||||
Stack: [ 1 98 <hashed99Equal> ]
|
||||
|
||||
Script: OP_EQUAL
|
||||
Stack: [ 1 98 <hashed99Equal> <hashed99Equal> ]
|
||||
|
||||
Script:
|
||||
Running: <hashed99Equal> <hashed99Equal> OP_EQUAL
|
||||
Stack: [ 1 98 True ]
|
||||
```
|
||||
O script termina com um ```True``` no topo da pilha e, portanto, foi bem-sucedido... Embora haja outro fragmento abaixo dele.
|
||||
|
||||
Porém, por se tratar de um script P2SH, a execução não está concluída.
|
||||
|
||||
### Executando a segunda rodada de validação
|
||||
|
||||
Para a segunda rodada de validação, vamos verificar se os valores no script de desbloqueio satisfazem o ```redeemScript```: Desserializando o ```redeemScript``` ("93016387" = "OP_ADD 99 OP_EQUAL") e executando-o usando os itens no ```scriptSig``` anterior para o script serializado:
|
||||
|
||||
```
|
||||
Script: 1 98 OP_ADD 99 OP_EQUAL
|
||||
Stack: [ ]
|
||||
|
||||
Script: 98 OP_ADD 99 OP_EQUAL
|
||||
Stack: [ 1 ]
|
||||
|
||||
Script: OP_ADD 99 OP_EQUAL
|
||||
Stack: [ 1 98 ]
|
||||
|
||||
Script: 99 OP_EQUAL
|
||||
Running: 1 98 OP_ADD
|
||||
Stack: [ 99 ]
|
||||
|
||||
Script: OP_EQUAL
|
||||
Stack: [ 99 99 ]
|
||||
|
||||
Script:
|
||||
Running: 99 99 OP_EQUAL
|
||||
Stack: [ True ]
|
||||
```
|
||||
Com essa segunda validação _também_ verdadeira, o UTXO agora pode ser gasto!
|
||||
|
||||
## Resumo: Executando um script Bitcoin com P2SH
|
||||
|
||||
Depois de conhecer a técnica de construção dos P2SH, qualquer script pode ser embutido em uma transação Bitcoin, e depois de entender a técnica de validação do P2SH, é fácil executar os scripts em duas fases.
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos continuar "Incorporando Scripts em Transações P2SH no Bitcoin" na seção [§10.4: Criando scripts multisig](10_4_Scripting_a_Multisig.md).
|
||||
149
pt/10_4_Scripting_a_Multisig.md
Normal file
149
pt/10_4_Scripting_a_Multisig.md
Normal file
@ -0,0 +1,149 @@
|
||||
# 10.4: Criando scripts multisig
|
||||
|
||||
Antes de encerrarmos esta introdução ao script P2SH, vale a pena examinar um exemplo mais realista. Desde a seção [§6.1](06_1_Sending_a_Transaction_to_a_Multisig.md), dissemos casualmente que a interface ```bitcoin-cli``` envolve nossa transação multisig em uma transação P2SH. Na verdade, esta é a metodologia padrão para a criação dos multisigs na Blockchain do Bitcoin. Veja como isso funciona, com mais detalhes.
|
||||
|
||||
## Compreendendo o Código Multisig
|
||||
|
||||
As transações multisig são criadas no Bitcoin usando o código ```OP_CHECKMULTISIG```. O ```OP_CHECKMULTISIG``` espera uma longa sequência de argumentos que se parece com isto: ```0 ... sigs ... <m> ... endereços ... <n> OP_CHECKMULTISIG```. Quando o ```OP_CHECKMULTISIG``` é executado, ele faz o seguinte:
|
||||
|
||||
1. Retira o primeiro valor da pilha (```<n>```);
|
||||
2. Retira os valores "n" da pilha como endereços Bitcoin (chaves públicas com hash);
|
||||
3. Retira o próximo valor da pilha (```<m>```);
|
||||
4. Retira os valores "m" da pilha como assinaturas potenciais;
|
||||
5. Retire um `0` da pilha devido a um erro na codificação original;
|
||||
6. Compara as assinaturas com os endereços de Bitcoin;
|
||||
7. Coloca ```True``` ou ```False``` dependendo do resultado.
|
||||
|
||||
Os operandos do ```OP_MULTISIG``` são tipicamente divididos, com o ```0``` e as assinaturas vindo do script de desbloqueio e o "m", "n" e endereços sendo detalhados pelo script de bloqueio.
|
||||
|
||||
O requisito para que o ```0``` seja o primeiro operando para o ```OP_CHECKMULTISIG``` é uma regra de consenso. Como a versão original do ```OP_CHECKMULTISIG``` acidentalmente retirou um item extra da pilha, o Bitcoin deve seguir esse padrão para sempre, para que os scripts de resgate complexos daquele período de tempo não sejam acidentalmente quebrados, tornando fundos antigos irrecuperáveis.
|
||||
|
||||
> :book: ***O que é uma regra de consenso?*** Estas são as regras que os nodes do Bitcoin seguem para trabalharem juntos. Em grande parte, eles são definidos pelo código do Bitcoin Core. Essas regras incluem muitas regras óbvias, como o limite de quantos Bitcoins são criados para cada bloco e as regras de como as transações podem ser respondidas. No entanto, eles também incluem correções para bugs que apareceram ao longo dos anos, porque uma vez que um bug foi introduzido na base de código do Bitcoin, ele deve ser continuamente suportado, para que os antigos Bitcoins não se tornem impossíveis de serem gastos.
|
||||
|
||||
## Criando uma Transação Multisig Bruta
|
||||
|
||||
Conforme discutido na seção [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md), os multisigs são um dos tipos de transação padrão do Bitcoin. Uma transação pode ser criada com um script de bloqueio que usa o comando ```OP_CHECKMULTISIG``` bruto e será aceito em um bloco. Esta é a metodologia clássica para usar multisigs no Bitcoin.
|
||||
|
||||
Como exemplo, iremos revisitar o multisig criado na seção [§8.1](08_1_Sending_a_Transaction_with_a_Locktime.md) uma última vez e construir um novo script de bloqueio para ele usando esta metodologia. Como devemos nos lembrar, essa transação era uma multisig 2 de 2 construída a partir do ```$address1``` e ```$address2```.
|
||||
|
||||
Como o script de bloqueio ```OP_CHECKMULTISIG``` requer o "m"(```2```), os endereços, e o "n"(```2```), poderíamos escrever o seguinte ```scriptPubKey```:
|
||||
```
|
||||
2 $address1 $address2 2 OP_CHECKMULTISIG
|
||||
```
|
||||
Se isso parece familiar, é porque é o multisig que desserializamos no [§10.2: Construindo a Estrutura de P2SH](10_2_Building_the_Structure_of_P2SH.md).
|
||||
```
|
||||
2 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 2 OP_CHECKMULTISIG
|
||||
```
|
||||
> **AVISO:** Para assinaturas `OP_CHECKMULTISIG` clássicas, o "n"deve ser ≤ 3 para que a transação seja padrão.
|
||||
|
||||
## Desbloqueando uma Transação Multisig Bruta
|
||||
|
||||
O ```scriptSig``` para um endereço multisig padrão deve então enviar os operandos ausentes para o ```OP_CHECKMULTISIG```: Um ```0``` seguido por assinaturas "m". Por exemplo:
|
||||
```
|
||||
0 $signature1 $signature2
|
||||
```
|
||||
|
||||
### Executando um Script Multisig Bruto
|
||||
|
||||
Para gastar um UTXO multisig, executamos o ```scriptSig``` e o ```scriptPubKey``` da seguinte maneira:
|
||||
```
|
||||
Script: 0 $signature1 $signature2 2 $address1 $address2 2 OP_CHECKMULTISIG
|
||||
Stack: [ ]
|
||||
```
|
||||
Primeiro, colocamos todas as constantes na pilha:
|
||||
```
|
||||
Script: OP_CHECKMULTISIG
|
||||
Stack: [ 0 $signature1 $signature2 2 $address1 $address2 2 ]
|
||||
```
|
||||
Então, o ```OP_CHECKMULTISIG``` começa a rodar. Primeiro, o "2" é retirado:
|
||||
```
|
||||
Running: OP_CHECKMULTISIG
|
||||
Stack: [ 0 $signature1 $signature2 2 $address1 $address2 ]
|
||||
```
|
||||
Então, o "2" diz ao ```OP_CHECKMULTISIG``` para retirar dois endereços:
|
||||
```
|
||||
Running: OP_CHECKMULTISIG
|
||||
Stack: [ 0 $signature1 $signature2 2 ]
|
||||
```
|
||||
Então, o próximo "2" é retirado:
|
||||
```
|
||||
Running: OP_CHECKMULTISIG
|
||||
Stack: [ 0 $signature1 $signature2 ]
|
||||
```
|
||||
Então, o "2" diz ao ```OP_CHECKMULTISIG``` para retirar duas assinaturas:
|
||||
```
|
||||
Running: OP_CHECKMULTISIG
|
||||
Stack: [ 0 ]
|
||||
```
|
||||
Então, mais um item é retirado por engano:
|
||||
```
|
||||
Running: OP_CHECKMULTISIG
|
||||
Stack: [ ]
|
||||
```
|
||||
Depois, o ```OP_CHECKMULTISIG``` completa a operação comparando as assinaturas "m" aos endereços "n":
|
||||
```
|
||||
Script:
|
||||
Stack: [ True ]
|
||||
```
|
||||
## Compreendendo as limitações de scripts multisig brutos
|
||||
|
||||
Infelizmente, a técnica de incorporar um multisig bruto em uma transação tem algumas desvantagens notáveis:
|
||||
|
||||
1. Como não há formato de endereço padrão para as multisigs, cada remetente deve: inserir um script multisig longo e complicado; ter um software que permite fazer isso e; ser confiável para não bagunçar nada.
|
||||
2. Como os multisigs podem ser muito mais longos do que os scripts padrão de bloqueio, isso significa mais custos. Isso requer taxas de transação mais altas para o remetente e cria mais incômodo para cada node.
|
||||
|
||||
Geralmente eram problemas com qualquer tipo de script complexo do Bitcoin, mas rapidamente se tornaram problemas muito reais quando aplicados as multisigs, que foram alguns dos primeiros scripts complexos a serem amplamente usados na rede Bitcoin. As transações P2SH foram criadas para resolver esses problemas, começando em 2012.
|
||||
|
||||
> :book: ***O que é um multisig P2SH?*** As Multisigs P2SH foram a primeira implementação de transações P2SH. Elas simplesmente empacotam uma transação multisig padrão em uma transação P2SH padrão. Isso permite a padronização de endereços, reduz o armazenamento de dados e, aumenta as contagens "m" e "n".
|
||||
|
||||
## Criando um P2SH Multisig
|
||||
|
||||
As Multisigs P2SH são a metodologia moderna para a criação de multisigs na Blockchain. Elas podem ser criadas de forma muito simples, usando o mesmo processo visto nas seções anteriores.
|
||||
|
||||
### Criando a Bloqueio para o P2SH Multisig
|
||||
|
||||
Para criar uma multisig P2SH, siga as etapas padrão para criar um script de bloqueio P2SH:
|
||||
|
||||
1. Serializar ```2 $ address1 $ address2 2 OP_CHECKMULTISIG```;
|
||||
1. ```<serializedMultiSig>``` = "522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98dfaed8d287f76c570e98dfaed8d287f76c570123582e38ed8287fab56c570123582e38ed8287fab56.
|
||||
2. Salvar o ```<serializedMultiSig>``` para referência futura como o redemScript;
|
||||
1. ```<redeemScript>``` = "522102da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d1912102bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa352ae".
|
||||
3. Fazer o hash SHA-256 e RIPEMD-160 do script serializado;
|
||||
1. `<hashedMultiSig>` = "a5d106eb8ee51b23cf60d8bd98bc285695f233f3".
|
||||
4. Produzir um script de bloqueio P2SH Multisig que inclua o hash do script (```OP_HASH160 <hashedMultisig> OP_EQUAL```).
|
||||
1. ```scriptPubKey``` =" a914a5d106eb8ee51b23cf60d8bd98bc285695f233f387 ".
|
||||
|
||||
Você pode criar uma transação usando o ```scriptPubKey```.
|
||||
|
||||
## Desbloqueando o P2SH Multisig
|
||||
|
||||
Para desbloquear essa transação multisig, é necessário que o destinatário produza um scriptSig que inclua as duas assinaturas e o ```redeemScript```.
|
||||
|
||||
### Executando a primeira rodada de validação do P2SH
|
||||
|
||||
Para desbloquear o multisig P2SH, primeiro vamos confirmar o script:
|
||||
|
||||
1. Produzir um script de desbloqueio de ```0 $ signature1 $ signature2 <serializedMultiSig>```;
|
||||
2. Concatenar isso com o script de bloqueio ```OP_HASH160 <hashedMultisig> OP_EQUAL```;
|
||||
3. Validar o ```0 $ assinatura1 $ assinatura2 <serializedMultiSig> OP_HASH160 <hashedMultisig> OP_EQUAL```;
|
||||
4. Teremos êxito se o ```<serializedMultisig>``` corresponder ao ```<hashedMultisig>```.
|
||||
|
||||
### Executando a segunda rodada de validação do P2SH
|
||||
|
||||
Em seguida, vamos executar o script multisig:
|
||||
|
||||
|
||||
1. Desserializar o ```<serializedMultiSig>``` para ```2 $ address1 $ address2 2 OP_CHECKMULTISIG```;
|
||||
2. Concatenar isso com os operandos anteriores no script de desbloqueio, ```0 $ assinatura1 $ assinatura2```;
|
||||
3. Validar o ```0 $ assinatura1 $ assinatura2 2 $ endereço1 $ endereço2 2 OP_CHECKMULTISIG```;
|
||||
4. Teremos sucesso se os operandos cumprirem o ```redemScript``` desserializado.
|
||||
|
||||
Agora sabemos como a transação multisig da seção [§6.1](06_1_Sending_a_Transaction_to_a_Multisig.md) foi realmente criada, como foi validada para ser gasta e o motivo pelo qual o ```redeemScript``` foi tão importante.
|
||||
|
||||
## Resumo: Criando scripts multisig
|
||||
|
||||
As multisigs são um tipo de transação padrão, mas são um pouco complicadas de serem usadas. Então, eles são regularmente incorporadas em transações P2SH, como foi o caso na seção [§6.1](06_1_Sending_a_Transaction_to_a_Multisig.md) quando criamos nossas primeiras multisigs. O resultado é mais limpo, menor e mais padronizado, porém, o mais importante, é um ótimo exemplo do mundo real de como os scripts P2SH realmente funcionam.
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos continuar "Incorporando Scripts em Transações P2SH no Bitcoin" na seção [§10.5: Crigando um script Segwit](10_5_Scripting_a_Segwit_Script.md).
|
||||
127
pt/10_5_Scripting_a_Segwit_Script.md
Normal file
127
pt/10_5_Scripting_a_Segwit_Script.md
Normal file
@ -0,0 +1,127 @@
|
||||
# 10.5: Criando um script Segwit
|
||||
> :information_source: * NOTA:** Esta seção foi adicionada recentemente ao curso e é um rascunho inicial que ainda pode estar aguardando revisão.
|
||||
|
||||
O segwit introduziu uma série de novas opções para tipos de endereço e também de scripts. Na seção [§9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md) explicamos como o novo tipo de endereço Bech32 variou os scripts padrão encontrados na maioria das transações tradicionais. Este capítulo examina os três outros tipos de scripts introduzidos pela atualização do Segwit: O P2SH-Segwit (que era o endereço "Segwit aninhado" de transição, quando o Segwit passou a ser usado), o P2WSH (que é o Segwit equivalente ao endereço P2SH , assim como P2WPKH é o Segwit equivalente ao endereço P2PKH) e o endereço P2WSH aninhado.
|
||||
|
||||
Esta é outra situação onde realmente não teremos que nos preocupar com os nuances ao trabalhar com o ```bitcoin-cli```, mas é útil saber como tudo funciona.
|
||||
|
||||
## Compreendendo um script P2SH-Segwit
|
||||
|
||||
O endereço P2SH-Segwit é uma tipo em extinção. Foi basicamente uma medida paliativa enquanto o Bitcoin fazia a transição para o Segwit que permitia a um usuário criar um endereço Segwit e, em seguida, alguém como uma exchange que ainda não habilitou o Segwit ou carteira antiga financiasse esse endereço.
|
||||
|
||||
Se precisarmos usar um, há uma opção para criar um endereço P2SH-Segwit usando ```getnewaddress```:
|
||||
```
|
||||
$ bitcoin-cli getnewaddress -addresstype p2sh-segwit
|
||||
2NEzBvokxh4ME4ahdT18NuSSoYvvhS7EnMU
|
||||
```
|
||||
O endereço começa com um ```2``` (ou ```3```) revelando-o como um script.
|
||||
|
||||
> :book: ***Por que os nodes antigos não podem enviar para endereços Segwit nativos?*** Na seção [§10.1](10_1_Understanding_the_Foundation_of_P2SH.md) observamos que havia um número definido de transações padrão no Bitcoin. Na verdade, não podemos bloquear uma transação com um script que não seja um desses tipos padrão. O Segwit agora é reconhecido como um desses padrões, mas um node antigo não saberá disso e, portanto, se recusará a enviar tal transação para a proteção daquele que o está enviando. Encapsular um endereço Segwit dentro de um script padrão em hash resolve o problema.
|
||||
|
||||
Quando você olha para um UTXO enviado para esse endereço, pode ver que o ```desc``` é diferente, revelando um endereço WPKH envolto em um script:
|
||||
```
|
||||
$ bitcoin-cli listunspent
|
||||
{
|
||||
"txid": "ed752673bfd4338ccf0995983086da846ad652ae0f28280baf87f9fd44b3c45f",
|
||||
"vout": 1,
|
||||
"address": "2NEzBvokxh4ME4ahdT18NuSSoYvvhS7EnMU",
|
||||
"redeemScript": "001443ab2a09a1a5f2feb6c799b5ab345069a96e1a0a",
|
||||
"scriptPubKey": "a914ee7aceea0865a05a29a28d379cf438ac5b6cd9c687",
|
||||
"amount": 0.00095000,
|
||||
"confirmations": 1,
|
||||
"spendable": true,
|
||||
"solvable": true,
|
||||
"desc": "sh(wpkh([f004311c/0'/0'/3']03bb469e961e9a9cd4c23db8442d640d9b0b11702dc0126462ac9eb88b64a4dd48))#p29e839h",
|
||||
"safe": true
|
||||
}
|
||||
```
|
||||
Mais importante ainda, é a presença de um ```redeemScript```, que decodifica para ```OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a```. Isso deve parecer familiar, porque é um ```OP_0``` seguido por um hexcode de 20 bytes de um hash de chave pública. Em outras palavras, um P2SH-SegWit é apenas um SegWit ```scriptPubKey``` preso em um script. Isso é tudo que há para fazer. Corresponde precisamente ao modo como os multisigs modernos são um multsig preso em um P2SH, conforme discutido na seção [§10.4: Criando scripts multisig](10_4_Scripting_a_Multisig.md).
|
||||
|
||||
A transação bruta revela um pouco mais de detalhes quando olhamos para o ```vout``` ```1```:
|
||||
```
|
||||
$ hex=$(bitcoin-cli gettransaction "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa" | jq -r '.hex')
|
||||
$ bitcoin-cli decoderawtransaction $hex
|
||||
{
|
||||
"txid": "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa",
|
||||
"hash": "6866490b16a92d68179e1cf04380fd08f16ec80bf66469af8d5e78ae624ff202",
|
||||
"version": 2,
|
||||
"size": 249,
|
||||
"vsize": 168,
|
||||
"weight": 669,
|
||||
"locktime": 1780788,
|
||||
"vin": [
|
||||
{
|
||||
"txid": "4779bb137ddbcaf796f905e264554b1ec28c0f3ab4538ca02eac5099bfc3fc1e",
|
||||
"vout": 0,
|
||||
"scriptSig": {
|
||||
"asm": "0014c4ea10874ae77d957e170bd43f2ee828a8e3bc71",
|
||||
"hex": "160014c4ea10874ae77d957e170bd43f2ee828a8e3bc71"
|
||||
},
|
||||
"txinwitness": [
|
||||
"3044022025ee4fd38e6865125f7c315406c0b3a8139d482e3be333727d38868baa656d3d02204b35d9b5812cb85894541da611d5cec14c374ae7a7b8ba14bb44495747b5715301",
|
||||
"033cae26cb3fa063c95e2c55a94bd04ab9cf173104555efe448b1bfc3a68c8f873"
|
||||
],
|
||||
"sequence": 4294967294
|
||||
}
|
||||
],
|
||||
"vout": [
|
||||
{
|
||||
"value": 0.00095000,
|
||||
"n": 0,
|
||||
"scriptPubKey": {
|
||||
"asm": "OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG",
|
||||
"hex": "76a91441d83eaffbf80f82dee4c152de59a38ffd0b602188ac",
|
||||
"reqSigs": 1,
|
||||
"type": "pubkeyhash",
|
||||
"addresses": [
|
||||
"mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"value": 0.01063793,
|
||||
"n": 1,
|
||||
"scriptPubKey": {
|
||||
"asm": "OP_HASH160 b780fc2e945bea71b9ee2d8d2901f00914a25fbd OP_EQUAL",
|
||||
"hex": "a914b780fc2e945bea71b9ee2d8d2901f00914a25fbd87",
|
||||
"reqSigs": 1,
|
||||
"type": "scripthash",
|
||||
"addresses": [
|
||||
"2N9yWARt5E3TQsX2RjsauxSZaEZVhinAS4h"
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Isso confirma que este é apenas um P2SH normal, bloqueado por ```" OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG "```. É quando o script de resgate é executado que a mágica ocorre. Assim como com um P2WPKH, um node antigo verá ```OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a``` e verificará automaticamente, enquanto um novo node verá isso, saberá que é um P2WPKH e, assim, irá verificar o ```witness```. Podemos consultar isso na seção [§9.5: Programando um P2WPKH](09_5_Scripting_a_P2WPKH.md).
|
||||
|
||||
> :book: ***Quais são as desvantagens das transações Segwit aninhadas?*** Elas são maiores do que as transações Segwit nativas, então temos algumas das vantagens do Segwit, mas não todas.
|
||||
|
||||
## Compreendendo um script P2WSH
|
||||
|
||||
Ao contrário, as transações P2WSH devem ser cada vez mais utilizadas, uma vez que são a substituição do Segwit nativa para o P2SH, oferecendo todas as mesmas vantagens de tamanho de bloco que foram criadas com transações Segwit P2WPKH nativas.
|
||||
|
||||
Este é um exemplo de endereço P2WSH:
|
||||
[https://mempool.space/pt/testnet/address/tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7](https://blockstream.info/testnet/address/tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7).
|
||||
|
||||
Os detalhes mostram que um UTXO enviado para este endereço está bloqueado com um ```scriptPubKey``` como este:
|
||||
```
|
||||
OP_0 OP_PUSHDATA (32 bytes) 1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262
|
||||
```
|
||||
|
||||
O funcionamento é exatamente como um endereço P2WPKH, a única diferença é que ao invés de um hash de chave pública de 20 bytes, o UTXO inclui um hash de script de 32 bytes. Assim como com um P2WPKH, os nodes antigos apenas verificam isso, enquanto os novos nodes reconhecem que se trata de um P2WSH e verificam internamente o script conforme descrito nas seções anteriores, mas usando os dados da ```witness```, que agora incluem o script de resgate.
|
||||
|
||||
Há também mais uma variante, um script P2WSH embutido em um script P2SH, que funciona muito como o P2SH-Segwit descrito acima, mas para scripts P2WSH aninhados.
|
||||
|
||||
## Resumo: Criando um script Segwit
|
||||
|
||||
Existem dois tipos de scripts P2SH relacionados ao Segwit.
|
||||
|
||||
O endereço P2SH-Segwit é um endereço Segwit aninhado que incorpora o Segwit ```scriptPubkey``` simples dentro de um Script, assim como multisigs são incorporados nos scripts hoje em dia: A chave do tipo Segwit é desenrolada e então analisada normalmente em uma máquina que entende o Segwit . O objetivo é a compatibilidade com versões anteriores dos nodes antigos que, de outra forma, não seriam capazes de enviar saldos para endereços Segwit nativos.
|
||||
|
||||
O endereço P2WSH é uma variante Segwit de P2SH, assim como P2WPKH é uma variante Segwit de P2WSH. Ele funciona com a mesma lógica e é identificado por ter um hash de 32 bytes em vez de um hash de 20 bytes. O objetivo é estender as vantagens do Segwit a outros tipos de scripts.
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos continuar "Incorporando Scripts em Transações P2SH no Bitcoin" na seção [§10.6:Gastando uma Transação P2SH](10_6_Spending_a_P2SH_Transaction.md).
|
||||
42
pt/10_6_Spending_a_P2SH_Transaction.md
Normal file
42
pt/10_6_Spending_a_P2SH_Transaction.md
Normal file
@ -0,0 +1,42 @@
|
||||
# 10.6: Gastando uma Transação P2SH
|
||||
|
||||
Antes de encerrarmos esta visão geral das transações P2SH, vamos abordar como gastá-las. Esta seção é principalmente uma visão geral, referindo-se a uma seção anterior onde _já_ gastamos uma transação P2SH.
|
||||
|
||||
## Usando o script de resgate
|
||||
|
||||
Como vimos na seção [§6.2: Gastando uma Transação com Multsig](06_2_Spending_a_Transaction_to_a_Multisig.md), gastar uma transação P2SH tem tudo a ver com ter aquela versão serializada do script de bloqueio, o chamado _redeemScript_. Portanto, o primeiro passo para poder gastar uma transação P2SH é ter certeza de salvar o _redeemScript_ antes de fornecer o endereço P2SH para todos.
|
||||
|
||||
### Coletando as variáveis
|
||||
|
||||
Como os endereços P2SH são diferentes dos endereços multisig especiais e Segwit aninhados não estão integrados no ```bitcoin-cli```, não haverá atalhos para gastarmos o P2SH como vimos na seção [§6.3: Enviando e Gastando um Multisig de Maneira Automatizada](6_3_Sending_an_Automated_Multisig.md) . Vamos precisar coletar todas as variáveis mais complexas por conta própria!
|
||||
|
||||
Isso significa que precisaremos coletar:
|
||||
|
||||
* O ```hex``` do ```scriptPubKey``` para a transação que estamos gastando;
|
||||
* O ```redeemScript``` serializado;
|
||||
* Quaisquer chaves privadas, já que assinaremos manualmente;
|
||||
* Todos os ```txids```,```vouts``` e ```endereços``` regulares que precisarmos.
|
||||
|
||||
## Criando a transação
|
||||
|
||||
Como vimos na seção §6.2, a criação de uma transação é bem padrão:
|
||||
```
|
||||
$ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' outputs='''{ "'$recipient'": 0.00005}''')
|
||||
$ echo $rawtxhex
|
||||
020000000121654fa95d5a268abf96427e3292baed6c9f6d16ed9e80511070f954883864b10000000000ffffffff0188130000000000001600142c48d3401f6abed74f52df3f795c644b4398844600000000
|
||||
```
|
||||
No entanto, a assinatura requer a inserção de informações extras para o (1) ```scriptPubKey```; (2) o ```redeemScript``` e; (3) quaisquer chaves privadas necessárias.
|
||||
|
||||
Aqui está o exemplo de como fazer isso para aquele multisig P2SH integrado da seção §6.2:
|
||||
```
|
||||
$ bitcoin-cli -named signrawtransactionwithkey hexstring=$rawtxhex prevtxs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "scriptPubKey": "'$utxo_spk'", "redeemScript": "'$redeem_script'" } ]''' privkeys='["cNPhhGjatADfhLD5gLfrR2JZKDE99Mn26NCbERsvnr24B3PcSbtR"]'
|
||||
```
|
||||
Com qualquer outro tipo de P2SH, incluiremos um ```redeemscript``` diferente, mas, fora isso, a prática é exatamente a mesma. A única diferença é que depois de dois capítulos de trabalho com scripts agora entendemos o que é o ```scriptPubKey``` e o que é o ```redeemScript```, então, esperançosamente, o que eram elementos misteriosos a quatro capítulos atrás, agora não são tão misteriosos assim.
|
||||
|
||||
## Resumo: Gastando uma Transação P2SH
|
||||
|
||||
Já gastamos um P2SH no Capítulo 6, quando reenviamos uma transação multsig da maneira mais difícil, que exigia alinhar as informações do ```scriptPubKey``` e do ```redeemScript```. Agora sabemos que o ```scriptPubKey``` é um script de bloqueio P2SH padronizado, enquanto o ```redeemScript``` corresponde a um hash nesse script de bloqueio e que precisamos ser capazes de executá-lo com as variáveis adequadas para receber um resultado ```True```. Mas além disso, não há nada de novo ao gastar uma transação P2SH, porque já fizemos isso!
|
||||
|
||||
## O que vem depois?
|
||||
|
||||
Vamos avançar com os "Script do Bitcoin" no [Capítulo 11: Aumentando o poder do timelock com scripts do Bitcoin](11_0_Empowering_Timelock_with_Bitcoin_Scripts.md).
|
||||
Loading…
x
Reference in New Issue
Block a user