mirror of
https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git
synced 2025-06-07 16:06:26 +00:00
Revise chapter 5 titles, fix typos
This commit is contained in:
namcios
parent
c4cf1ef060
commit
7ce59c0584
@ -1,8 +1,8 @@
|
||||
# Capítulo 5: Controlando as transações de Bitcoin
|
||||
# Capítulo 5: Controlando Transações no Bitcoin
|
||||
|
||||
O envio de uma transação nem sempre termina com um "viveram felizes para sempre". Usando os protocolos RBF (Replace-By-Fee, ou Substituindo-A -Taxa no português) e CPFP (Child-Pays-For-Parent, ou Filho-Paga-Pelo-Pai), um desenvolvedor pode continuar a controlar a transação após ela ter sido enviada, para melhorar a eficiência ou para recuperar transações que estava presas na _mempool_. Esses métodos irão começar a mostrar o verdadeiro poder do Bitcoin.
|
||||
|
||||
## Objetivos deste capítulo
|
||||
## Objetivos deste Capítulo
|
||||
|
||||
Depois de trabalhar neste capítulo, um desenvolvedor será capaz de:
|
||||
|
||||
@ -16,8 +16,8 @@ Os objetivos secundários do capítulo incluem a capacidade de:
|
||||
* Entender a diferença entre o RBF e o CPFP;
|
||||
* Planejar a taxa do RBF.
|
||||
|
||||
## Tabela de conteúdo
|
||||
## Tabela de Conteúdo
|
||||
|
||||
* [Seção 1: Observando as transações presas na mempool](05_1_Watching_for_Stuck_Transactions.md)
|
||||
* [Seção 2: Reenviando uma transação com o RBF](05_2_Resending_a_Transaction_with_RBF.md)
|
||||
* [Seção 3: Financiando uma transação com o CPFP](05_3_Funding_a_Transaction_with_CPFP.md)
|
||||
* [Seção 1: Atentando-se para Transações Presas](05_1_Watching_for_Stuck_Transactions.md)
|
||||
* [Seção 2: Reenviando uma Transação com RBF](05_2_Resending_a_Transaction_with_RBF.md)
|
||||
* [Seção 3: Financiando uma Transação com CPFP](05_3_Funding_a_Transaction_with_CPFP.md)
|
||||
@ -1,8 +1,8 @@
|
||||
# 5.1: Observando as transações presas na mempool
|
||||
# 5.1: Atentando-se para Transações Presas
|
||||
|
||||
Às vezes, uma transação de Bitcoin pode ficar presa. Isso normalmente ocorre porque não havia taxa de transação suficiente, mas também pode ser devido a uma falha da rede ou do software.
|
||||
|
||||
## Observando as transações enviadas
|
||||
## Observando as Transações Enviadas
|
||||
|
||||
Nós devemos _sempre_ observar as transações para garantir que tenham sido encerradas. O ```bitcoin-cli listtransactions``` mostrará todas as nossas transações de entrada e saída, enquanto o ```bitcoin-cli gettransaction``` juntamente com um txid, irá mostrar uma transação específica.
|
||||
|
||||
@ -50,10 +50,10 @@ Se sua transação ficar paralisada por mais tempo do que esperamos, normalmente
|
||||
|
||||
**4. Use o CPFP como sendo o destinatário.** Se nós formos os recebedores do saldo, podemos usar o CPFP (Child-Pays-For-Parent) para usar a transação não confirmada como um input para uma nova transação. Podemos consultar a sessão [§5.3: Financiando uma transação com o CPFP](05_3_Funding_a_Transaction_with_CPFP.md).
|
||||
|
||||
## Resumo do Observando as transações presas na mempool
|
||||
## Resumo: Atentando-se para Transações Presas
|
||||
|
||||
Esta é uma introdução ao poder das transações do Bitcoin. Se sabemos que uma transação está presa, podemos decidir como liberá-la com recursos como o RBF ou o CPFP.
|
||||
|
||||
## O que vem depois?
|
||||
## O Que Vem Depois?
|
||||
|
||||
Continuemos "Controlando as transações de Bitcoin" com a sessão [§5.2: Reenviando uma transação com o RBF](05_2_Resending_a_Transaction_with_RBF.md).
|
||||
Continuemos "Controlando Transações no Bitcoin" com a sessão [§5.2: Reenviando uma Transação com RBF](05_2_Resending_a_Transaction_with_RBF.md).
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# 5.2: Reenviando uma transação com o RBF
|
||||
# 5.2: Reenviando uma Transação com RBF
|
||||
|
||||
Se a nossa transação Bitcoin travar e formos a parte que está enviando o saldo, podemos reenviá-la usando o RBF (Replace-By-Fee). No entanto, isso não é tudo que o RBF pode fazer: Geralmente é um recurso poderoso que permite aos remetentes do Bitcoin recriar transações por vários motivos.
|
||||
|
||||
> :warning: **AVISO DE VERSÃO:** Esta é uma inovação do Bitcoin Core v0.12.0, que atingiu a maturidade total na carteira do Bitcoin Core na versão 0.14.0. Obviamente, a maioria das pessoas já deveria estar usando-a.
|
||||
|
||||
## Opt-In para o RBF
|
||||
## Optando pelo RBF
|
||||
|
||||
O RBF é um recurso opcional do Bitcoin. As transações só são elegíveis para usar o RBF se tiverem sido criadas com um sinalizador RBF especial. Isso é feito configurando qualquer um dos números de sequência UTXO da transação (que normalmente são configurados automaticamente), de modo que seja maior que 0 e menor que 0xffffffff-1 (4294967294).
|
||||
|
||||
@ -42,19 +42,19 @@ O sinalizador ```bip125-replaceeable``` permanecerá como ```yes``` até que a t
|
||||
|
||||
> :book: ***Devo confiar nas transações que não possuem confirmações?*** Não, nunca. Isso era uma verdade antes do RBF e continua sendo depois do RBF. As transações devem receber confirmações antes de serem determinadas como confiáveis. Isto é especialmente verdadeiro se uma transação for marcada como ```bip125-replaceable```, porque ela pode muito bem ser... substituída.
|
||||
|
||||
> :information_source: **NOTA - SEQUÊNCIA:** Este é o primeiro uso do valor ```nSequence``` no Bitcoin. Podemos configurá-lo entre 1 e 0xffffffff-2 (4294967293) e habilitar o RBF, mas se não tivermos cuidado, poderemos bater de frente com o uso paralelo do ```nSequence``` que serve para _timelocks_ relativos. Sugerimos sempre configurá-lo como "1", que é o que o Bitcoin Core faz, mas a outra opção é configurá-lo com um valor entre 0xf0000000 (4026531840) e 0xffffffff-2 (4294967293). Configurá-lo como sendo "1" efetivamente torna os bloqueios de tempo relativos irrelevantes e configurá-lo para 0xf0000000 ou superior os desativa. Tudo isso é explicado posteriormente na sessão [§11.3: Usando CSV nos Scripts](11_3_Using_CSV_in_Scripts.md). Por enquanto, basta escolhermos um dos valores não conflitantes para o ```nSequence```.
|
||||
> :information_source: **NOTA - SEQUÊNCIA:** Este é o primeiro uso do valor ```nSequence``` no Bitcoin. Podemos configurá-lo entre 1 e 0xffffffff-2 (4294967293) e habilitar o RBF, mas se não tivermos cuidado, poderemos bater de frente com o uso paralelo do ```nSequence``` que serve para _timelocks_ relativos. Sugerimos sempre configurá-lo como "1", que é o que o Bitcoin Core faz, mas a outra opção é configurá-lo com um valor entre 0xf0000000 (4026531840) e 0xffffffff-2 (4294967293). Configurá-lo como sendo "1" efetivamente torna os bloqueios de tempo relativos irrelevantes e configurá-lo para 0xf0000000 ou superior os desativa. Tudo isso é explicado posteriormente na seção [§11.3: Usando CSV nos Scripts](11_3_Using_CSV_in_Scripts.md). Por enquanto, basta escolhermos um dos valores não conflitantes para o ```nSequence```.
|
||||
|
||||
### Opcional: Sempre habilite o RBF
|
||||
### Opcional: Sempre Habilite o RBF
|
||||
|
||||
Se preferirmos, podemos _sempre_ optar por habilitar o RBF. Podemos fazer isso executando nosso ```bitcoind``` com o comando ``` -walletrbf```. Depois de fazermos isso (e reiniciarmos nosso ```bitcoind```), todos os UTXOs devem ter um número de sequência inferior e as transações posteriores devem ser marcadas como ```bip125-replaceable```.
|
||||
Se preferirmos, podemos optar por _sempre_ habilitar o RBF. Podemos fazer isso executando nosso ```bitcoind``` com o comando ``` -walletrbf```. Depois de fazermos isso (e reiniciarmos nosso ```bitcoind```), todos os UTXOs devem ter um número de sequência inferior e as transações posteriores devem ser marcadas como ```bip125-replaceable```.
|
||||
|
||||
> :warning: **AVISO DE VERSÃO:** O sinalizador walletrbf requer o Bitcoin Core v.0.14.0 ou superior.
|
||||
|
||||
## Entendendo o funcionamento do RBF
|
||||
## Entendendo o Funcionamento do RBF
|
||||
|
||||
A funcionalidade RBF é baseada no [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), que lista as seguintes regras para usá-lo:
|
||||
|
||||
> 1. As transações originais sinalizam a possibilidade de serem substituídas de maneira explicita ou por herança, conforme descrito na sessão anterior.
|
||||
> 1. As transações originais sinalizam a possibilidade de serem substituídas de maneira explicita ou por herança, conforme descrito na seção anterior.
|
||||
|
||||
Isso significa que o número de sequência deve ser definido para menos de 0xffffffff-1 (4294967294), ou o mesmo é verdadeiro para transações pai não confirmadas.
|
||||
|
||||
@ -73,7 +73,7 @@ Diante desse conflito, os mineradores saberão usar aquele com a taxa mais alta
|
||||
|
||||
> :warning: **ATENÇÃO:** Algumas discussões anteriores sobre esta política sugeriram que o número ```nSequence``` também fosse aumentado. Na verdade, esse era o uso pretendido do ```nSequence``` em sua forma original. Isso _não_ faz parte da política publicada no BIP 125. Na verdade, aumentar o número da sequência, pode travar acidentalmente nossa transação com um _timelock_ relativo, a menos que usemos números de sequência no intervalo de 0xf0000000 (4026531840) a 0xffffffff-2 (4294967293) .
|
||||
|
||||
## Substituindo uma transação no modo hard: Manualmente
|
||||
## Substituindo uma Transação no Modo Difícil: Manualmente
|
||||
|
||||
Para criar uma transação RBF manual, tudo o que precisamos fazer é criar uma transação bruta que: (1) Substitua uma transação bruta anterior onde o RBF foi habilitado e que não foi confirmada; (2) Reutilizar um ou mais dos mesmos UTXOs; (3) Aumentar as taxas e; (4) Pagar a taxa mínima de ambas as transações [que já podem ser atendidas no item (3)].
|
||||
|
||||
@ -154,7 +154,7 @@ $ bitcoin-cli -named gettransaction txid=5b953a0bdfae0d11d20d195ea43ab7c31a5471d
|
||||
```
|
||||
Nossos destinatários terão nosso saldo, e a transação original que foi falha acabará saindo do mempool.
|
||||
|
||||
## Substituindo uma transação no modo easy: Usando o bumpfee
|
||||
## Substituindo uma Transação no Modo Fácil: Usando o bumpfee
|
||||
|
||||
As transações brutas são muito poderosas e podemos fazer muitas coisas interessantes combinando-as com o RBF. No entanto, às vezes _tudo_ o que desejamos é apenas liberar uma transação que está presa na mempool. Podemos fazer isso com um comando simples, o ```bumpfee```.
|
||||
|
||||
@ -201,7 +201,7 @@ $ bitcoin-cli -named gettransaction txid=75208c5c8cbd83081a0085cd050fc7a4064d87c
|
||||
```
|
||||
> :aviso: **AVISO DE VERSÃO:** O comando ```bumpfee``` no RPC requer o Bitcoin Core v.0.14.0.
|
||||
|
||||
## Resumo do Reenviando uma transação com o RBF
|
||||
## Resumo: Reenviando uma Transação com RBF
|
||||
|
||||
Se uma transação ficar presa na mempool e não quisermos esperar que ela expire, e se habilitamos o RBF nela, podemos fazer um gasto duplo usando o RBF para criar uma transação de substituição (ou apenas usar o comando ```bumpfee```).
|
||||
|
||||
@ -209,6 +209,6 @@ Se uma transação ficar presa na mempool e não quisermos esperar que ela expir
|
||||
|
||||
> Por exemplo, podemos enviar uma transação e, antes de ser confirmada, combiná-la com uma segunda transação. Isso permite que possamos comprimir várias transações em uma única, diminuindo as taxas totais. Também podemos oferecer benefícios à privacidade. Existem outras razões para usarmos o RBF, como por exemplo contratos inteligentes ou transferência de transações, conforme descrito na parte referente a [Perguntas frequentes sobre RBF de opt-in](https://bitcoincore.org/en/faq/optin_rbf/).
|
||||
|
||||
## O que vem depois?
|
||||
## O Que Vem Depois?
|
||||
|
||||
Vamos continuar "Controlando as transações de Bitcoin" na sessão [§5.3: Financiando uma transação com o CPFP](05_3_Funding_a_Transaction_with_CPFP.md).
|
||||
Vamos continuar "Controlando Transações no Bitcoin" na seção [§5.3: Financiando uma Transação com CPFP](05_3_Funding_a_Transaction_with_CPFP.md).
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# 5.3: Financiando uma transação com o CPFP
|
||||
# 5.3: Financiando uma Transação com CPFP
|
||||
|
||||
Se nossa transação do Bitcoin travar e formos os _recebedores_, poderemos aumentar a velocidade usando o CPFP (Child-Pays-For-Parent). Esta é uma alternativa semelhante ao que a parte que _ envia_ o saldo pode fazer usando o RBF.
|
||||
|
||||
> :warning: **AVISO DE VERSÃO:** Esta é uma inovação do Bitcoin Core v0.13.0, o que novamente significa que a maioria das pessoas já deve estar utilizando-a.
|
||||
|
||||
## Entendendo o funcionamento do CPFP
|
||||
## Entendendo o Funcionamento do CPFP
|
||||
|
||||
O RBF é possível caso você seja a parte que está enviando o saldo. O remetente errou e precisou aumentar a taxa, ou queria ser inteligente e combinar transações por diversos motivos. O RBF é um poderoso recurso voltado para o remetente. De certa forma, o CPFP é o oposto do RBF, pois dá poder ao destinatário que sabe que o dinheiro ainda não chegou e quer acelerar o processo. No entanto, também é um recurso muito mais simples, com aplicabilidade não tão ampla quanto a primeira.
|
||||
|
||||
@ -12,7 +12,7 @@ Basicamente, a ideia do CPFP é que um destinatário tenha uma transação que n
|
||||
|
||||
Devemos observar que o CPFP não é um recurso novo no protocolo, assim como o RBF. É apenas um novo esquema de incentivo que pode ser usado para a seleção de transações pelos mineradores. Isso também significa que não é tão confiável quanto uma alteração feita pelo RBF: Pode haver motivos para que o filho não seja selecionado para ser colocado em um bloco e isso impedirá que o pai também seja colocado no bloco.
|
||||
|
||||
## Gastando UTXOs não confirmados
|
||||
## Gastando UTXOs Não Confirmados
|
||||
|
||||
Financiar uma transação com o CPFP é um processo muito simples, usando os métodos com os quais já estamos familiarizados:
|
||||
|
||||
@ -108,7 +108,7 @@ Nossas transações podem ser processadas rapidamente, ou não. Tudo depende se
|
||||
|
||||
E isso realmente é tudo o que podemos fazer.
|
||||
|
||||
### Atenção aos nuances
|
||||
### Atenção aos Nuances
|
||||
|
||||
Embora o CPFP seja geralmente descrito como sendo um destinatário que usa uma nova transação para pagar por uma antiga que não foi confirmada, existem alguns nuances.
|
||||
|
||||
@ -116,12 +116,12 @@ A parte que está _enviando_ poderia usar o CPFP para liberar uma transação se
|
||||
|
||||
A parte que está _recebendo_ pode usar o CPFP mesmo se não estiver planejando gastar o dinheiro imediatamente, por exemplo, se estiver preocupado que os fundos possam não ser reenviados se a transação expirar. Nesse caso, ele apenas cria uma transação secundária que envia todo o dinheiro (menos a taxa de transação) para um endereço de troco. Isso é o que fizemos no nosso exemplo.
|
||||
|
||||
## Resumo do Financiando uma transação com o CPFP
|
||||
## Resumo: Financiando uma Transação com CPFP
|
||||
|
||||
Podemos aproveitar os incentivos do CPFP para liberar fundos que nos foram enviados, mas que não foram confirmados. Basta usar a transação não confirmada como sendo um UTXO e pagar uma taxa de transação acima da média.
|
||||
|
||||
> :fire: ***Qual é o poder do CPFP?*** O seu uso é apenas para liberar fundos quando formos os recebedores dos fundos e o remetente não quer ajudar por qualquer que seja o motivo. Ele não tem as mesmas habilidades que o RBF, mas é uma maneira alternativa de exercer controle sobre uma transação depois que ela foi colocada na mempool, mas antes de ser confirmada em um bloco.
|
||||
|
||||
## O que vem depois?
|
||||
## O Que Vem Depois?
|
||||
|
||||
Vamos avançar para o [Capítulo 6: Expandindo as Transações de Bitcoin com Multisigs](06_0_Expanding_Bitcoin_Transactions_Multisigs.md).
|
||||
Vamos avançar para o [Capítulo 6: Expandindo Transações no Bitcoin com Multisigs](06_0_Expanding_Bitcoin_Transactions_Multisigs.md).
|
||||
Loading…
x
Reference in New Issue
Block a user