flywithu/Learning-Bitcoin-from-the-Command-Line
1
1
Fork 0
mirror of https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git synced 2025-06-07 16:06:26 +00:00
Code Issues Releases Wiki Activity

Merge pull request #400 from KoreaComK/chapter18

Browse Source 
Chapter 18 Translated by @koreacomk need review
This commit is contained in:
Shannon Appelcline 2021-08-31 08:58:24 -10:00 committed by GitHub
commit cfd260fff8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 1165 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
pt/19_0_Understanding_Your_Lightning_Setup.md Normal file
View File

@ -0,0 +1,26 @@
# Capítulo 19: Compreendendo a Configuração da Lightning
> :information_source: **NOTA:** Este é um rascunho que está em andamento. Seu objetivo é que possa obter alguns comentários dos revisores iniciais. Ainda não está pronto para ser produzido.
O capítulo anterior concluiu nosso trabalho com o Bitcoin propriamente dito, por meio do CLI, scripts e linguagens de programação. No entanto, existem muitos outros utilitários dentro do ecossistema Bitcoin. Neste capítulo e no próximo, iremos cobrir o que pode ser o maior e mais importante deles, a Lightning Network. Aqui, começaremos a trabalhar com a interface de linha de comando `lightning-cli`, entendendo a configuração do c-lightning e dos seus recursos, incluindo alguns exemplos e configuração básica.
## Objetivos Deste Capítulo
Depois de trabalhar neste capítulo, um desenvolvedor será capaz de:
* Avaliar se um node c-lightning está instalado e atualizado;
* Executar comandos básicos de uma carteira Lightning;
* Criar um canal na Lightning.
Os objetivos secundários do capítulo incluem a capacidade de:
* Compreender a configuração básica da Lightning;
* Compreender a interação dos canais Lightning;
* Entender como usar a Lightning.
## Tabela de Conteúdo
* [Seção 1: Verificando a Configuração da c-lightning](19_1_Verifying_Your_Lightning_Setup.md)
* [Seção 2: Conhecendo a Configuração da c-lightning](19_2_Knowing_Your_lightning_Setup.md)
* [Adendo: Acessando um Segundo Node Lightning](19_2__Interlude_Accessing_a_Second_Lightning_Node.md)
* [Seção 3: Criando um Canal na Lightning](19_3_Setting_Up_a_Channel.md)

288
pt/19_1_Verifying_Your_Lightning_Setup.md Normal file
View File

@ -0,0 +1,288 @@
# 19.1: Verificando a Configuração da c-lightning
>: information_source: **NOTA:** Esta seção foi adicionada recentemente ao curso e é um rascunho inicial que ainda pode estar aguardando revisão.
Nesta seção, instalaremos e verificaremos a c-lightning, nosso utilitário para acessar a Lightning Network.
> :book: ***O que é a Lightning Network?*** A Rede Lightning é uma rede descentralizada que usa a funcionalidade de contrato inteligente da blockchain do Bitcoin para permitir pagamentos instantâneos em uma rede de participantes. A Lightning é construída como um protocolo de segunda camada que interage com o Bitcoin para permitir que os usuários troquem seus bitcoins "fora da blockchain" (ou o jargão em inglês, "off-chain").
> :book: ***O que é um protocolo de segunda camada?*** A segunda camada refere-se a um protocolo secundário criado em cima do sistema de blockchain do Bitcoin. O objetivo principal desses protocolos é resolver a velocidade de transação e as dificuldades de escala que estão presentes no Bitcoin. O Bitcoin não é capaz de processar milhares de transações por segundo (TPS), então protocolos de segunda camada foram criados para resolver o problema de escalabilidade da blockchain. Essas soluções também são conhecidas como soluções de dimensionamento "off-chain".
## Instalando a c-lightning
Se já usamos os [Bitcoin Standup Scripts](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts), talvez já o tenhamos instalado no início deste curso. Podemos testar isto verificando se o `lightningd` está em execução:
```
$ ps auxww | grep -i lightning
standup 31213 0.0 0.2 24144 10424 pts/0 S 15:38 0:00 lightningd --testnet
standup 31214 0.0 0.1 22716 7444 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/autoclean
standup 31215 0.0 0.2 22992 8248 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/bcli
standup 31216 0.0 0.1 22756 7604 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/keysend
standup 31217 0.0 0.1 22776 7648 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/pay
standup 31218 0.0 0.1 22720 7652 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/txprepare
standup 31219 0.0 0.1 22744 7716 pts/0 S 15:38 0:00 /usr/local/bin/../libexec/c-lightning/plugins/spenderp
standup 31227 0.0 0.1 22748 7384 pts/0 SL 15:38 0:00 /usr/local/libexec/c-lightning/lightning_hsmd
standup 31228 0.0 0.2 23044 8192 pts/0 S 15:38 0:00 /usr/local/libexec/c-lightning/lightning_connectd
standup 31229 0.0 0.1 22860 7556 pts/0 S 15:38 0:00 /usr/local/libexec/c-lightning/lightning_gossipd
standup 32072 0.0 0.0 6208 888 pts/0 S+ 15:50 0:00 grep -i lightning
```
Caso contrário, precisaremos instalá-lo agora. Infelizmente, se estivermos usando o Debian, precisaremos instalá-lo manualmente, compilando o código-fonte, mas ainda assim deve ser muito simples se seguirmos estas instruções. Se acontecer de estarmos em um sistema Ubuntu padrão, podemos tentar [Instalar a partir do Ubuntu ppa](#variant-install-from-ubuntu-ppa), e sempre podemos tentar [Instalar os binários pré-compilados](#variant-install-pre-compiled-binaries).
> :book: ***O que é a c-lightning?*** Existem três implementações diferentes da Lightning no momento: C-lightning, LND e Eclair. Todos devem ser funcionalmente compatíveis, com base nas mesmas [RFCs do BOLT](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md), mas os detalhes de implementação podem ser diferentes. Escolhemos a c-lightning como base do curso porque ela também faz parte do [projeto Elements](https://github.com/ElementsProject), que contém a Libwally.
### Compilando o Código-Fonte da c-lightning
A instalação da Lightning a partir do código-fonte deve ser bem simples se seguirmos estas instruções.
_Provavelmente_ desejaremos fazer isso em um node não prunado, pois trabalhar com nodes prunados na Lightning pode causar problemas de instalação e uso. Se, no início deste curso, configuramos nosso node para ser prunado, podemos querer substituí-lo por um full node agora. Se estivermos usando a testnet, provavelmente conseguiremos usar o mesmo tipo de máquina que usamos para o node prunado.
> :warning: **AVISO:** Realmente podemos executar a c-lightning em um node prunado. No entanto, conforme observamos no [repositório Lightning](https://github.com/ElementsProject/lightning#pruning), pode haver uma série de problemas. Para fazer isso funcionar, devemos garantir que o node da Lightning sempre tente atualizar informações sobre os blocos que o node do Bitcoin não excluiu. Para fazermos isso, devemos nos certificar de que (1) nosso node de Bitcoin está totalmente atualizado antes de iniciar nosso node da Lightning pela primeira vez e; (2) nosso node Lightning nunca fique defasado do node do Bitcoin (para um node prunado em 550 blocos padrão, ele nunca pode ser desligado por 4 dias ou mais). Portanto, podemos usar o node assim, mas apresenta algum perigo, o que não é uma boa ideia se estivermos executando um serviço em produção.
Dito isso, estamos prontos para instalar a Lightning:
Primeiro, vamos instalar as dependências, incluindo requisitos de desenvolvimento.
```
$ sudo apt-get install -y \
autoconf automake build-essential git libtool libgmp-dev \
libsqlite3-dev python3 python3-mako net-tools zlib1g-dev libsodium-dev \
gettext
$ sudo apt-get install -y valgrind python3-pip libpq-dev
```
Isso pode demorar um pouco, porque há várias dependências e algumas são bem grandes.
Em segundo lugar, vamos clonar o repositório Lightning:
```
$ cd ~
$ git clone https://github.com/ElementsProject/lightning.git
$ cd lightning
```
Agora podemos usar o `pip3` que instalamos para instalar requisitos adicionais para a compilação e posteriomente configurar tudo:
```
$ pip3 install -r requirements.txt
$ ./configure
```
Agora, vamos compilar. Isso pode levar algum tempo também, dependendo do processamento da nossa máquina.
```
$ make
```
Depois disso, o que precisamos fazer é instalar:
```
$ sudo make install
```
## Verificando Nossa Instalação
Podemos confirmar que o lightningd foi instalado corretamente usando o parâmetro `help`:
```
$ lightningd --help
lightningd: WARNING: default network changing in 2020: please set network=testnet in config!
Usage: lightningd
A bitcoin lightning daemon (default values shown for network: testnet).
--conf=<file> Specify configuration file
--lightning-dir=<dir> Set base directory: network-specific
subdirectory is under here
(default: "/home/javier/.lightning")
--network <arg> Select the network parameters (bitcoin,
testnet, regtest, litecoin or
litecoin-testnet) (default: testnet)
--testnet Alias for --network=testnet
--signet Alias for --network=signet
--mainnet Alias for --network=bitcoin
```
## Executando lightningd
Começaremos a explorar a Lightning Network com o comando `lightning-cli`. No entanto, `lightningd` _deve_ estar rodando para podermos usar o `lightning-cli`, já que `lightning-cli` envia comandos JSON-RPC para o `lightningd` (tudo exatamente como o `bitcoin-cli` e o `bitcoind`).
Se instalamos a `c-lightning` manualmente, precisaremos iniciá-la:
```
$ nohup lightningd --testnet &
```
### Executando o lightningd como um serviço
Se preferirmos, podemos instalar o `lightningd` como um serviço que será executado toda vez que reiniciarmos nossa máquina. Os comandos seguintes farão isso e ele começará a funcionar imediatamente:
```
$ cat > ~/lightningd.service << EOF
# It is not recommended to modify this file in-place, because it will
# be overwritten during package upgrades. If you want to add further
# options or overwrite existing ones then use
# $ systemctl edit bitcoind.service
# See "man systemd.service" for details.
# Note that almost all daemon options could be specified in
# /etc/lightning/config, except for those explicitly specified as arguments
# in ExecStart=
[Unit]
Description=c-lightning daemon
[Service]
ExecStart=/usr/local/bin/lightningd --testnet
# Process management
####################
Type=simple
PIDFile=/run/lightning/lightningd.pid
Restart=on-failure
# Directory creation and permissions
####################################
# Run as standup
User=standup
# /run/lightningd
RuntimeDirectory=lightningd
RuntimeDirectoryMode=0710
# Hardening measures
####################
# Provide a private /tmp and /var/tmp.
PrivateTmp=true
# Mount /usr, /boot/ and /etc read-only for the process.
ProtectSystem=full
# Disallow the process and all of its children to gain
# new privileges through execve().
NoNewPrivileges=true
# Use a new /dev namespace only populated with API pseudo devices
# such as /dev/null, /dev/zero and /dev/random.
PrivateDevices=true
# Deny the creation of writable and executable memory mappings.
MemoryDenyWriteExecute=true
[Install]
WantedBy=multi-user.target
EOF
$ sudo cp ~/lightningd.service /etc/systemd/system
$ sudo systemctl enable lightningd.service
$ sudo systemctl start lightningd.service
```
### Habilitando Conexões Remotas
Se tivermos algum tipo de firewall, precisaremos abrir a porta 9735 para permitir que outros nodes da Lightning interajam conosco.
Se usarmos o `ufw` do Bitcoin Standup, podemos fazer da seguinte maneira:
```
$ sudo ufw allow 9735
```
## Verificando o Nosso Node
Podemos verificar se o nosso node Lightning está pronto para funcionar comparando a saída de `bitcoin-cli getblockcount` com o resultado de `blockheight` do `lightning-cli getinfo`.
```
$ bitcoin-cli -testnet getblockcount
1838587
$ lightning-cli --testnet getinfo
{
"id": "03d4592f1244cd6b5a8bb7fba6a55f8a91591d79d3ea29bf8e3c3a405d15db7bf9",
"alias": "HOPPINGNET",
"color": "03d459",
"num_peers": 0,
"num_pending_channels": 0,
"num_active_channels": 0,
"num_inactive_channels": 0,
"address": [
{
"type": "ipv4",
"address": "74.207.240.32",
"port": 9735
},
{
"type": "ipv6",
"address": "2600:3c01::f03c:92ff:fe48:9ddd",
"port": 9735
}
],
"binding": [
{
"type": "ipv6",
"address": "::",
"port": 9735
},
{
"type": "ipv4",
"address": "0.0.0.0",
"port": 9735
}
],
"version": "v0.9.1-96-g6f870df",
"blockheight": 1838587,
"network": "testnet",
"msatoshi_fees_collected": 0,
"fees_collected_msat": "0msat",
"lightning-dir": "/home/standup/.lightning/testnet"
}
```
Neste caso, o `blockheight` é mostrado como `1838587` por ambos os comandos.
Em vez disso, podemos obter um erro, dependendo da situação.
Se o node Bitcoin ainda estiver sincronizando com a rede, devemos ver uma mensagem como esta:
```
"warning_bitcoind_sync": "Bitcoind is not up-to-date with network."
```
Se o nosso node Lightning não estiver atualizado, receberemos uma mensagem como esta:
```
"warning_lightningd_sync": "Still loading latest blocks from bitcoind."
```
Se tentarmos executar em uma blockchain prunada cujo node Bitcoin não estava atualizado quando iniciamos o node Lightning, receberemos mensagens de erro em nosso log parecidas com esta:
```
bitcoin-cli -testnet getblock 0000000000000559febee77ab6e0be1b8d0bef0f971c7a4bee9785393ecef451 0 exited with status 1
```
## Criando Aliases
Sugerimos a criação de alguns aliases (apelidos de comandos) para facilitar o uso da c-lightning.
Podemos fazer isso colocando-os em nosso arquivo `.bash_profile`.
```
cat >> ~/.bash_profile <<EOF
alias lndir="cd ~/.lightning/" #linux default c-lightning path
alias lnc="lightning-cli"
alias lnd="lightningd"
alias lninfo='lightning-cli getinfo'
EOF
```
Depois de inserir esses aliases, podemos executar o comando `source ~/.bash_profile` para inseri-los, ou apenas efetuar logout e login novamente.
Podemos observar que esses aliases incluem atalhos para executar o `lightning-cli`, para executar o `lightningd` e para ir para o diretório c-lightning. Esses aliases têm como objetivo principal tornar nossa vida mais fácil. Sugerimos criar outros apelidos para facilitar o uso de comandos frequentes (e seus argumentos) e para minimizar erros. Os aliases desse tipo podem ser ainda mais úteis se tivermos uma configuração complexa onde regularmente executamos comandos associados a Mainnet, com Testnet _e_ com a Regtest, conforme explicado mais adiante.
Dito isso, o uso desses aliases _neste_ livro pode acidentalmente obscurecer as lições principais que estão sendo ensinadas sobre a c-lightning, portanto, continuaremos a mostrar os comandos completos. Podemos ajustá-los para nosso próprio uso conforme apropriado.
## Opcional: Modificando Nossos Tipos de Servidor
> :link: **TESTNET vs MAINNET:** Ao configurar nosso node, escolhemos criá-lo como um node Mainnet, Testnet ou Regtest. Embora este documento presuma uma configuração no Testenet, vale a pena entender como podemos acessar e usar os outros tipos de configuração, mesmo todos estando na mesma máquina! Mas, se você for um usuário iniciante, pode pular esta parte, pois não é necessária para uma configuração básica.
Quando o lightningd é inicializado, geralmente ele lê um arquivo de configuração cuja localização depende da rede que estamos usando (o padrão é `~/.lightning/testnet/config`). Isso pode ser alterado com os sinalizadores `–conf` e `–lightning-dir`.
```
~/.lightning/testnet$ ls -la config
-rw-rw-r-- 1 user user 267 jul 12 17:08 config
```
Também existe um arquivo de configuração geral (o padrão é `~/.lightning/config`). Se desejarmos executar vários tipos diferentes de nodes simultaneamente, devemos deixar o sinalizador testnet (ou regtest) fora deste arquivo de configuração. Devemos então escolher se estamos usando a mainnet, a testnet ou a regtest toda vez que executarmos o `lightningd` ou o `lightning-cli`.
Nossa configuração pode não ter nenhum arquivo de configuração: a c-lightning será executada com uma boa configuração padrão, sem eles.
## Resumo: Verificando a Configuração da c-lightning
Antes de começar a brincar com a lightning, devemos nos certificar de que nossos aliases estão configurados, nosso `lightningd` está rodando e nosso node está sincronizado. Também podemos querer configurar algum acesso a configurações alternativas da Lightning, em outras redes.
## O Que Vem Depois?
Vamos continuar "Compreendendo a Configuração da Lightning" na seção [§19.2: Conhecendo a Configuração da c-lightning](19_2_Knowing_Your_lightning_Setup.md).
## Variante: Instalando do Ubuntu ppa
Se estivermos usando uma versão do Ubuntu diferente do Debian, podemos instalar a c-lightning usando [Ubuntu ppa](https://launchpad.net/~lightningnetwork/+archive/ubuntu/ppa):
```
$ sudo apt-get install -y software-properties-common
$ sudo add-apt-repository -u ppa:lightningnetwork/ppa
$ sudo apt-get install lightningd
```
## Variante: Instalando Binários Pré-Compilados
Outro método para instalar a Lightning é usar os binários pré-compilados no [repositório Github](https://github.com/ElementsProject/lightning/releases). Vamos escolher o arquivo mais recente, como `clightning-v0.9.1-Ubuntu-20.04.tar.xz`.
Depois de baixá-lo, precisaremos ir para o diretório raiz e descompactá-lo:
```
$ cd /
$ sudo tar xf ~/clightning-v0.9.1-Ubuntu-20.04.tar.xz
```
Aviso: Isso exigirá que tenhamos exatamente as mesmas bibliotecas que foram usadas para criar o binário. Geralmente é mais fácil apenas recompilar.

340
pt/19_2_Knowing_Your_lightning_Setup.md Normal file
View File

@ -0,0 +1,340 @@
# 19.2: Conhecendo a Configuração da c-lightning
> :information_source: **NOTA:** Esta seção foi adicionada recentemente ao curso e é um rascunho inicial que ainda pode estar aguardando revisão.
Antes de começar a acessar a Lightning Network, devemos compreender melhor a nossa configuração.
## Conhecendo o Diretório da c-lightning
Ao usar a c-lightning, tudo será mantindo dentro do diretório `~/.lightning`.
O diretório principal contém apenas os diretórios para as redes configuradas, neste caso da Testnet:
```
$ ls ~/.lightning
testnet
```
O diretório `~/.lightning/testnet` irá então conter a essência da nossa configuração:
```
$ ls ~/.lightning/testnet3
config gossip_store hsm_secret lightningd.sqlite3 lightningd.sqlite3-journal lightning-rpc
```
> :link: **TESTNET vs MAINNET:** Se estivermos usando a Mainnet, então _tudo_ será colocado no diretório principal `~/.lightning/bitcoin`. Essas várias configurações _empilham-se_ elegantemente, então se estivermos usando a Mainnet, Testnet e Regtest, descobriremos que `~/.lightning/bitcoin` contém os arquivos de configuração e os dados da Mainnet, o diretório `~/.lightning/testnet` contém os dados da Testnet, e o diretório `~/.lightning/regtest` contém os dados Regtest.
## Conhecendo os Comandos lightning-cli
A maior parte do nosso trabalho inicial será feito com o comando `lightning-cli`, que oferece uma interface fácil para o `lightningd`, assim como o `bitcoin-cli`.
Já vimos que o comando `help` nos dará uma lista de outros comandos:
```
$ lightning-cli help
lightning-cli: WARNING: default network changing in 2020: please set network=testnet in config!
=== bitcoin ===
feerates style
Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb).
newaddr [addresstype]
Get a new {bech32, p2sh-segwit} (or all) address to fund a channel (default is bech32)
reserveinputs outputs [feerate] [minconf] [utxos]
Reserve inputs and pass back the resulting psbt
sendpsbt psbt
Finalize, extract and send a PSBT.
signpsbt psbt
Sign this wallet's inputs on a provided PSBT.
txdiscard txid
Abandon a transaction created by txprepare
txprepare outputs [feerate] [minconf] [utxos]
Create a transaction, with option to spend in future (either txsend and txdiscard)
txsend txid
Sign and broadcast a transaction created by txprepare
unreserveinputs psbt
Unreserve inputs, freeing them up to be reused
withdraw destination satoshi [feerate] [minconf] [utxos]
Send to {destination} address {satoshi} (or 'all') amount via Bitcoin transaction, at optional {feerate}
=== channels ===
close id [unilateraltimeout] [destination] [fee_negotiation_step]
Close the channel with {id} (either peer ID, channel ID, or short channel ID). Force a unilateral close after {unilateraltimeout} seconds (default 48h). If {destination} address is provided, will be used as output address.
fundchannel_cancel id
Cancel inflight channel establishment with peer {id}.
fundchannel_complete id txid txout
Complete channel establishment with peer {id} for funding transactionwith {txid}. Returns true on success, false otherwise.
fundchannel_start id amount [feerate] [announce] [close_to] [push_msat]
Start fund channel with {id} using {amount} satoshis. Returns a bech32 address to use as an output for a funding transaction.
getroute id msatoshi riskfactor [cltv] [fromid] [fuzzpercent] [exclude] [maxhops]
Show route to {id} for {msatoshi}, using {riskfactor} and optional {cltv} (default 9). If specified search from {fromid} otherwise use this node as source. Randomize the route with up to {fuzzpercent} (default 5.0). {exclude} an array of short-channel-id/direction (e.g. [ '564334x877x1/0', '564195x1292x0/1' ]) or node-id from consideration. Set the {maxhops} the route can take (default 20).
listchannels [short_channel_id] [source]
Show channel {short_channel_id} or {source} (or all known channels, if not specified)
listforwards
List all forwarded payments and their information
setchannelfee id [base] [ppm]
Sets specific routing fees for channel with {id} (either peer ID, channel ID, short channel ID or 'all'). Routing fees are defined by a fixed {base} (msat) and a {ppm} (proportional per millionth) value. If values for {base} or {ppm} are left out, defaults will be used. {base} can also be defined in other units, for example '1sat'. If {id} is 'all', the fees will be applied for all channels.
=== network ===
connect id [host] [port]
Connect to {id} at {host} (which can end in ':port' if not default). {id} can also be of the form id@host
disconnect id [force]
Disconnect from {id} that has previously been connected to using connect; with {force} set, even if it has a current channel
listnodes [id]
Show node {id} (or all, if no {id}), in our local network view
listpeers [id] [level]
Show current peers, if {level} is set, include logs for {id}
ping id [len] [pongbytes]
Send peer {id} a ping of length {len} (default 128) asking for {pongbytes} (default 128)
=== payment ===
createonion hops assocdata [session_key]
Create an onion going through the provided nodes, each with its own payload
decodepay bolt11 [description]
Decode {bolt11}, using {description} if necessary
delexpiredinvoice [maxexpirytime]
Delete all expired invoices that expired as of given {maxexpirytime} (a UNIX epoch time), or all expired invoices if not specified
delinvoice label status
Delete unpaid invoice {label} with {status}
invoice msatoshi label description [expiry] [fallbacks] [preimage] [exposeprivatechannels]
Create an invoice for {msatoshi} with {label} and {description} with optional {expiry} seconds (default 1 week), optional {fallbacks} address list(default empty list) and optional {preimage} (default autogenerated)
listinvoices [label]
Show invoice {label} (or all, if no {label})
listsendpays [bolt11] [payment_hash]
Show sendpay, old and current, optionally limiting to {bolt11} or {payment_hash}.
listtransactions
List transactions that we stored in the wallet
sendonion onion first_hop payment_hash [label] [shared_secrets] [partid]
Send a payment with a pre-computed onion.
sendpay route payment_hash [label] [msatoshi] [bolt11] [payment_secret] [partid]
Send along {route} in return for preimage of {payment_hash}
waitanyinvoice [lastpay_index] [timeout]
Wait for the next invoice to be paid, after {lastpay_index} (if supplied). If {timeout} seconds is reached while waiting, fail with an error.
waitinvoice label
Wait for an incoming payment matching the invoice with {label}, or if the invoice expires
waitsendpay payment_hash [timeout] [partid]
Wait for payment attempt on {payment_hash} to succeed or fail, but only up to {timeout} seconds.
=== plugin ===
autocleaninvoice [cycle_seconds] [expired_by]
Set up autoclean of expired invoices.
estimatefees
Get the urgent, normal and slow Bitcoin feerates as sat/kVB.
fundchannel id amount [feerate] [announce] [minconf] [utxos] [push_msat]
Fund channel with {id} using {amount} (or 'all'), at optional {feerate}. Only use outputs that have {minconf} confirmations.
getchaininfo
Get the chain id, the header count, the block count, and whether this is IBD.
getrawblockbyheight height
Get the bitcoin block at a given height
getutxout txid vout
Get informations about an output, identified by a {txid} an a {vout}
listpays [bolt11]
List result of payment {bolt11}, or all
pay bolt11 [msatoshi] [label] [riskfactor] [maxfeepercent] [retry_for] [maxdelay] [exemptfee]
Send payment specified by {bolt11} with {amount}
paystatus [bolt11]
Detail status of attempts to pay {bolt11}, or all
plugin subcommand=start|stop|startdir|rescan|list
Control plugins (start, stop, startdir, rescan, list)
sendrawtransaction tx
Send a raw transaction to the Bitcoin network.
=== utility ===
check command_to_check
Don't run {command_to_check}, just verify parameters.
checkmessage message zbase [pubkey]
Verify a digital signature {zbase} of {message} signed with {pubkey}
getinfo
Show information about this node
getlog [level]
Show logs, with optional log {level} (info|unusual|debug|io)
getsharedsecret point
Compute the hash of the Elliptic Curve Diffie Hellman shared secret point from this node private key and an input {point}.
help [command]
List available commands, or give verbose help on one {command}.
listconfigs [config]
List all configuration options, or with [config], just that one.
listfunds
Show available funds from the internal wallet
signmessage message
Create a digital signature of {message}
stop
Shut down the lightningd process
waitblockheight blockheight [timeout]
Wait for the blockchain to reach {blockheight}, up to {timeout} seconds.
=== developer ===
dev-listaddrs [bip32_max_index]
Show addresses list up to derivation {index} (default is the last bip32 index)
dev-rescan-outputs
Synchronize the state of our funds with bitcoind
---
run `lightning-cli help <command>` for more information on a specific command
```
## Conhecendo Informações da Lightning
Uma variedade de comandos `lightning-cli` podem fornecer informações adicionais sobre nosso node Lightning. Os mais comuns são:
```
$ lightning-cli --testnet listconfigs
$ lightning-cli --testnet listfunds
$ lightning-cli --testnet listtransactions
$ lightning-cli --testnet listinvoices
$ lightning-cli --testnet listnodes
```
* listconfigs: O comando RPC `listconfigs` lista todas as opções de configuração;
* listfunds: O comando RPC `listfunds` exibe todos os fundos disponíveis, seja em saídas não gastas (UTXOs) na carteira interna ou fundos bloqueados em canais abertos no momento;
* listtransactions: O comando RPC `listtransactions` retorna as transações rastreadas na carteira. Isso inclui depósitos, retiradas e transações relacionadas a canais;
* listinvoices: O comando RPC `listinvoices` recupera o status de um invoice específico, se houver, ou o status de todos os invoices, se não houver nenhum argumento;
* listnodes: O comando RPC `listnodes` retorna nodes que nosso servidor aprendeu através da comunicação com outros nodes, ou um específico se o id do node foi informado.
Por exemplo, `lightning-cli listconfigs` fornece uma variedade de informações sobre nossa configuração:
```
c$ lightning-cli --testnet listconfigs
{
"# version": "v0.8.2-398-g869fa08",
"lightning-dir": "/home/standup/.lightning",
"network": "testnet",
"allow-deprecated-apis": true,
"rpc-file": "lightning-rpc",
"plugin": "/usr/local/bin/../libexec/c-lightning/plugins/fundchannel",
"plugin": "/usr/local/bin/../libexec/c-lightning/plugins/autoclean",
"plugin": "/usr/local/bin/../libexec/c-lightning/plugins/bcli",
"plugin": "/usr/local/bin/../libexec/c-lightning/plugins/pay",
"plugin": "/usr/local/bin/../libexec/c-lightning/plugins/keysend",
"plugins": [
{
"path": "/usr/local/bin/../libexec/c-lightning/plugins/fundchannel",
"name": "fundchannel"
},
{
"path": "/usr/local/bin/../libexec/c-lightning/plugins/autoclean",
"name": "autoclean",
"options": {
"autocleaninvoice-cycle": null,
"autocleaninvoice-expired-by": null
}
},
{
"path": "/usr/local/bin/../libexec/c-lightning/plugins/bcli",
"name": "bcli",
"options": {
"bitcoin-datadir": null,
"bitcoin-cli": null,
"bitcoin-rpcuser": null,
"bitcoin-rpcpassword": null,
"bitcoin-rpcconnect": null,
"bitcoin-rpcport": null,
"bitcoin-retry-timeout": null,
"commit-fee": "500"
}
},
{
"path": "/usr/local/bin/../libexec/c-lightning/plugins/pay",
"name": "pay"
},
{
"path": "/usr/local/bin/../libexec/c-lightning/plugins/keysend",
"name": "keysend"
}
],
"disable-plugin": [],
"always-use-proxy": false,
"daemon": "false",
"wallet": "sqlite3:///home/user/.lightning/testnet/lightningd.sqlite3",
"wumbo": false,
"wumbo": false,
"rgb": "03fce2",
"alias": "learningBitcoin",
"pid-file": "/home/user/.lightning/lightningd-testnet.pid",
"ignore-fee-limits": false,
"watchtime-blocks": 144,
"max-locktime-blocks": 720,
"funding-confirms": 3,
"commit-fee-min": 200,
"commit-fee-max": 2000,
"cltv-delta": 6,
"cltv-final": 10,
"commit-time": 10,
"fee-base": 1,
"rescan": 15,
"fee-per-satoshi": 10,
"max-concurrent-htlcs": 483,
"min-capacity-sat": 10000,
"offline": "false",
"autolisten": true,
"disable-dns": "false",
"enable-autotor-v2-mode": "false",
"encrypted-hsm": false,
"rpc-file-mode": "0600",
"log-level": "DEBUG",
"log-prefix": "lightningd"
}
```
## Resumo: Conhecendo a Configuração da c-lightning
O diretório `~/.lightning` contém todos os arquivos, enquanto o comando `lightning-cli help` mostra uma variedade de informações dos comandos que podem ser usados para obter mais informações sobre a configuração e o funcionamento da Lightning Network.
## O Que Vem Depois?
Precisaremos de um segundo node para testar o pagamento dos invoices. Se precisarmos de suporte para configurar um, podemos ler o [Adendo: Acessando um Segundo Node Lightning](19_2__Interlude_Accessing_a_Second_Lightning_Node.md).
Caso contrário, vamos continuar "Compreendendo a Configuração da Lightning" na seção [§19.3: Criando um Canal na Lightning](19_3_Setting_Up_a_Channel.md).

326
pt/19_2__Interlude_Accessing_a_Second_Lightning_Node.md Normal file
View File

@ -0,0 +1,326 @@
# Adendo: Acessando um Segundo Node Lightning
> :information_source: **NOTA:** Esta seção foi adicionada recentemente ao curso e é um rascunho inicial que ainda pode estar aguardando revisão.
Quando estávamos brincando com o Bitcoin, estávamos acessando uma rede existente, e isso torna tudo relativamente fácil para se trabalhar. Apenas ligávamos o `bitcoind` e estávamos imediatamente interagindo com a rede. Agora, a Lightning funciona da seguinte maneira: é fundamentalmente uma rede ponto a ponto, construída a partir das conexões entre dois nodes individuais. Em outras palavras, para interagir com a Lightning Network, precisaremos primeiro encontrar um node ao qual podemos nos conectar.
Existem quatro maneiras de fazermos isso (das quais as três primeiras são possíveis para a nossa primeira conexão):
## Pedindo Informações Sobre um Node
Se outra pessoa já tiver um node da Lightning Network na rede que escolhemos, podemos pedir o ID dele.
Se estiverem executando a c-lightning, eles só precisam usar o comando `getinfo`:
```
$ lightning-cli getinfo
lightning-cli: WARNING: default network changing in 2020: please set network=testnet in config!
"id": "03240a4878a9a64aea6c3921a434e573845267b86e89ab19003b0c910a86d17687",
"alias": "VIOLETGLEE",
"color": "03240a",
"num_peers": 0,
"num_pending_channels": 0,
"num_active_channels": 0,
"num_inactive_channels": 0,
"address": [
{
"type": "ipv4",
"address": "74.207.240.32",
"port": 9735
}
],
"binding": [
{
"type": "ipv6",
"address": "::",
"port": 9735
},
{
"type": "ipv4",
"address": "0.0.0.0",
"port": 9735
}
],
"version": "v0.9.1-96-g6f870df",
"blockheight": 1862854,
"network": "testnet",
"msatoshi_fees_collected": 0,
"fees_collected_msat": "0msat",
"lightning-dir": "/home/standup/.lightning/testnet"
}
```
Eles poderão então nos dizer o `ID` deles (`03240a4878a9a64aea6c3921a434e573845267b86e89ab19003b0c910a86d17687`). Eles também precisarão informar o endereço IP (`74.207.240.32`) e porta (`9735`).
## Criando um Novo Node c-lightning
No entanto, para fins de teste, provavelmente iremos desejar ter um segundo node sob nosso próprio controle. A maneira mais fácil de fazer isso é criar um segundo node c-lightning em uma nova máquina, usando Bitcoin Standup, de acordo com a seção [§2.1](02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md) ou compilando-o manualmente, de acordo com a seção [§19.1](19_1_Verifying_Your_Lightning_Setup.md).
Depois de ter nosso node em execução, podemos executar o `getinfo` para recuperar nossas informações, como mostrado acima.
## Criando um Novo Node LND
No entanto, para os exemplos do próximo capítulo, vamos criar um node LND. Isso nos permitirá demonstrar um pouco da profundidade do ecossistema Lightning, mostrando como comandos semelhantes funcionam nas duas plataformas diferentes.
Uma maneira de criar um node LND é executar os scripts Bitcoin Standup novamente em uma nova máquina, mas desta vez escolher a LND, de acordo com a seção [§2.1](2_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md).
Outra forma é compilar o LND a partir do código-fonte em uma máquina em que já estejamos executando um node Bitcoin, como falaremos abaixo.
### Compilando o Código-Fonte do LND
Primeiro, precisaremos baixar e instalar o Go:
```
$ wget --progress=bar:force https://dl.google.com/go/"go1.14.4"."linux"-"amd64".tar.gz -O ~standup/"go1.14.4"."linux"-"amd64".tar.gz
$ /bin/tar xzf ~standup/"go1.14.4"."linux"-"amd64".tar.gz -C ~standup
$ sudo mv ~standup/go /usr/local
```
Depois, precisamos nos certificar de que a versão Go é a mais atualizada (atualmente é a `go1.14.4`), e que a plataforma e arquitetura são adequadas para nossa máquina. O item acima funcionará para o Debian.
Vamos atualizar nosso PATH:
```
$ export GOPATH=~standup/gocode
$ export PATH="$PATH":/usr/local/go/bin:"$GOPATH"/bin
```
Em seguida, vamos nos certificar de que o `go` funciona:
```
$ go version
go version go1.14.4 linux/amd64
```
Também precisaremos do `git` e do `make`:
```
$ sudo apt-get install git
$ sudo apt-get install build-essential
```
Agora estamos prontos para recuperar o LND. Certifique-se de obter a versão atual (no momento, é a `v0.11.0-beta.rc4`).
```
$ go get -d github.com/lightningnetwork/lnd
```
E agora podemos compilar:
```
$ cd "$GOPATH"/src/github.com/lightningnetwork/lnd
$ git checkout v0.11.0-beta.rc4
$ make
$ make install
```
Os comandos acima irão instalar o Go na pasta `~/gocode/bin`, que é o `$GOPATH/bin`.
Devemos alterá-la para os diretórios globais:
```
$ sudo cp $GOPATH/bin/lnd $GOPATH/bin/lncli /usr/bin
```
### Criando um Arquivo de Configuração do LND
Ao contrário da c-lightning, precisaremos criar um arquivo de configuração padrão para o LND.
No entanto, primeiro, iremos precisar habilitar o ZMQ em nosso Bitcoind, se ainda não o fizemos na seção [§16.3](16_3_Receiving_Bitcoind_Notifications_with_C.md).
Isso requer adicionar o seguinte ao nosso arquivo `~/.bitcoin/bitcoin.conf`, se ainda não estiver lá:
```
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
```
Se estivermos usando um arquivo de configuração Bitcoin do Standup ou algum outro `conf` especializado, precisamos nos certificar de colocar nossos novos comandos na seção correta. Idealmente, devemos chegar perto do topo do arquivo, caso contrário, na seção `[test]` (assumindo, como de costume, que estamos usando a testnet).
Devemos então reiniciar o Bitcoin (ou apenas reiniciar nossa máquina). Podemos testar se está tudo funcionando da seguinte maneira:
```
$ bitcoin-cli getzmqnotifications
[
{
"type": "pubrawblock",
"address": "tcp://127.0.0.1:28332",
"hwm": 1000
},
{
"type": "pubrawtx",
"address": "tcp://127.0.0.1:28333",
"hwm": 1000
}
]
```
Agora estamos prontos para criar um arquivo de configuração.
Primeiro, precisamos recuperar nosso rpcuser e rpcpassword. A seguinte é uma maneira automatizada de fazer isso:
```
$ BITCOINRPC_USER=$(cat ~standup/.bitcoin/bitcoin.conf | grep rpcuser | awk -F = '{print $2}')
$ BITCOINRPC_PASS=$(cat ~standup/.bitcoin/bitcoin.conf | grep rpcpassword | awk -F = '{print $2}')
```
> :warning: **AVISO:** Obviamente, nunca iremos armazenar nossa senha RPC em uma variável shell em um ambiente de produção.
Em seguida, podemos gravar o arquivo:
```
$ mkdir ~/.lnd
$ cat > ~/.lnd/lnd.conf << EOF
[Application Options]
maxlogfiles=3
maxlogfilesize=10
#externalip=1.1.1.1 # change to your public IP address if required.
alias=StandUp
listen=0.0.0.0:9735
debuglevel=debug
[Bitcoin]
bitcoin.active=1
bitcoin.node=bitcoind
bitcoin.testnet=true
[Bitcoind]
bitcoind.rpchost=localhost
bitcoind.rpcuser=$BITCOINRPC_USER
bitcoind.rpcpass=$BITCOINRPC_PASS
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333
EOF
```
### Criando um Serviço LND
Finalmente, podemos criar um serviço LND para executar automaticamente o `lnd`:
```
$ cat > ~/lnd.service << EOF
# It is not recommended to modify this file in-place, because it will
# be overwritten during package upgrades. If you want to add further
# options or overwrite existing ones then use
# $ systemctl edit lnd.service
# See "man systemd.service" for details.
# Note that almost all daemon options could be specified in
# /etc/lnd/lnd.conf, except for those explicitly specified as arguments
# in ExecStart=
[Unit]
Description=LND Lightning Network Daemon
Requires=bitcoind.service
After=bitcoind.service
[Service]
ExecStart=/usr/bin/lnd
ExecStop=/usr/bin/lncli --lnddir /var/lib/lnd stop
PIDFile=/run/lnd/lnd.pid
User=standup
Type=simple
KillMode=process
TimeoutStartSec=60
TimeoutStopSec=60
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
EOF
```
Em seguida, precisaremos instalar aquilo e iniciar as coisas:
```
$ sudo cp ~/lnd.service /etc/systemd/system
$ sudo systemctl enable lnd
$ sudo systemctl start lnd
```
(É esperado que a primeira vez leve um certo tempo.)
### Habilitando Conexões Remotas
Assim como na c-lightning, precisaremos tornar o LND acessível a outros nodes. Veja como fazer isso se usarmos o `ufw`, de acordo com as configurações do Bitcoin Standup:
```
$ sudo ufw allow 9735
```
### Criando uma Carteira
Na primeira vez que executamos o LND, devemos criar uma carteira:
```
$ lncli --network=testnet create
```
O LND pedirá uma senha e, em seguida, nos perguntará se desejaremos inserir um mnemônico existente (basta pressionar `n` para o último).
Agora devemos ter um `lnd` funcionando, que pode ser verificado com o comando `getinfo`:
```
$ lncli --network=testnet getinfo
{
"version": "0.11.0-beta.rc4 commit=v0.11.0-beta.rc4",
"commit_hash": "fc12656a1a62e5d69430bba6e4feb8cfbaf21542",
"identity_pubkey": "032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543",
"alias": "StandUp",
"color": "#3399ff",
"num_pending_channels": 0,
"num_active_channels": 0,
"num_inactive_channels": 0,
"num_peers": 2,
"block_height": 1862848,
"block_hash": "000000000000000ecb6fd95e1f486283d48683aa3111b6c23144a2056f5a1532",
"best_header_timestamp": "1602632294",
"synced_to_chain": true,
"synced_to_graph": false,
"testnet": true,
"chains": [
{
"chain": "bitcoin",
"network": "testnet"
}
],
"uris": [
],
"features": {
"0": {
"name": "data-loss-protect",
"is_required": true,
"is_known": true
},
"5": {
"name": "upfront-shutdown-script",
"is_required": false,
"is_known": true
},
"7": {
"name": "gossip-queries",
"is_required": false,
"is_known": true
},
"9": {
"name": "tlv-onion",
"is_required": false,
"is_known": true
},
"13": {
"name": "static-remote-key",
"is_required": false,
"is_known": true
},
"15": {
"name": "payment-addr",
"is_required": false,
"is_known": true
},
"17": {
"name": "multi-path-payments",
"is_required": false,
"is_known": true
}
}
}
```
O ID deste node é `032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543`. Embora este comando não nos mostre o endereço IP e a porta, eles devem ser o endereço IP da nossa máquina e a porta `9735`.
## Escute a Fofoca
Se já estivéssemos conectados à Lightning Network, e nosso node já estivesse "fofocando" com seus pares, também poderíamos ser capazes de encontrar informações sobre os pares automaticamente, por meio do comando `listpeers`:
```
c$ lightning-cli --network=testnet listpeers
{
"peers": [
{
"id": "0302d48972ba7eef8b40696102ad114090fd4c146e381f18c7932a2a1d73566f84",
"connected": true,
"netaddr": [
"127.0.0.1:9736"
],
"features": "02a2a1",
"channels": []
}
]
}
```
No entanto, este definitivamente não será o caso na nossa primeira interação com a Lightning Network.
## Resumo: Adendo: Acessando um Segundo Node Lightning
Sempre precisaremos de dois nodes Lightning para formar um canal. Se não tivermos outra pessoa que está testando as coisas conosco, precisaremos criar um segundo node, usanda c-lightning ou (como faremos em nossos exemplos) usando a LND.
## O Que Vem Depois?
Embora possivelmente tenhamos criado um LND, a c-lightning permanecerá no centro dos nossos exemplos até que precisemos começar a usar os dois, no [Capítulo 19](19_0_Understanding_Your_Lightning_Setup.md).
Vamos continuar "Compreendendo a Configuração da Lightning" na seção [§19.3: Criando um Canal na Lightning](19_3_Setting_Up_a_Channel.md).

185
pt/19_3_Setting_Up_a_Channel.md Normal file
View File

@ -0,0 +1,185 @@
# 19.3: Criando um Canal na Lightning
> :information_source: **NOTA:** Esta seção foi adicionada recentemente ao curso e é um rascunho inicial que ainda pode estar aguardando revisão.
Agora que entendemos o básico da configuração da Lightning e, com sorte, já criamos ou recebemos informações sobre um segundo node Lightning, estamos prontos para criar nosso primeiro canal na Lightning Network. Claro, precisaremos entender o que ele é e como é criado usando a c-lightning.
> :book: ***O que é um canal Lightning?*** De maneira simples, um canal Lightning é um tubo de dinheiro que permite transferências rápidas, baratas e privadas sem enviar transações para a blockchain. Mais tecnicamente, um canal é uma transação multisig 2-de-2 no Bitcoin que estabelece um relacionamento financeiro sem confiança entre duas pessoas ou dois agentes. Uma certa quantia de dinheiro é depositada no canal, quando então se mantém um banco de dados local com saldo em bitcoins para ambas as partes, mantendo o registro de qual é o saldo de cada parte. Os dois usuários podem então trocar bitcoins por meio do canal Lightning sem nunca escrever na blockchain do Bitcoin. Somente quando desejam fechar o canal é que eles dividem os bitcoins na blockchain, com base na divisão final das moedas para cada um.
> :book: ***Como os canais Lightning criam uma rede Lightning?*** Embora um canal Lightning só permita o pagamento entre dois usuários, os canais podem ser conectados para formar uma rede que permite pagamentos entre membros que não têm um canal direto entre eles. Isso cria uma rede entre várias pessoas, construída a partir de conexões em pares.
Nesta seção, continuaremos usando nossa configuraçãa c-lightning como nosso node principal.
## Criando um Canal
A criação de um canal Lightning requer as seguintes etapas:
* Financiar nossa carteira c-lightning com alguns satoshis;
* Conectar-se a um node remoto como um par;
* Abrir um canal.
### Financiando Nossa Carteira c-lightning
Para mover fundos para um canal Lightning, primeiro é necessário financiar nossa carteira c-lightning.
> :book: ***O que é uma carteira c-lightning?*** A implementação padrão da c-lightning vem com uma carteira Bitcoin integrada que permite enviar e receber transações de bitcoin na blockchain. Esta carteira será usada para criar novos canais.
A primeira coisa que precisamos fazer é enviar alguns satoshis para nossa carteira c-lightning. Podemos criar um novo endereço usando o comando `lightning-cli newaddr`. Isto gera um novo endereço que pode ser subsequentemente usado para financiar canais gerenciados pelo node c-lightning. Podemos especificar o tipo de endereço desejado; se não for especificado, o endereço gerado será um bech32.
```
$ lightning-cli --testnet newaddr
{
"address": "tb1qefule33u7ukfuzkmxpz02kwejl8j8dt5jpgtu6",
"bech32": "tb1qefule33u7ukfuzkmxpz02kwejl8j8dt5jpgtu6"
}
```
Podemos então enviar fundos para este endereço usando `bitcoin-cli sendtoaddress` (ou qualquer outro método de preferência). Para este exemplo, fizemos o envio que pode ser observado na transação [11094bb9ac29ce5af9f1e5a0e4aac2066ae132f25b72bff90fcddf64bf2feb02](https://mempool.space/pt/testnet/tx/11094bb9ac29ce5af9f1e5a0e4aac2066ae132f25b72bff90fcddf64bf2feb02).
Esta transação é chamada de [transação de financiamento](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#funding-transaction-output) e precisa ser confirmada antes que os fundos possam ser utilizados.
> :book: ***O que é uma transação de financiamento?*** Uma transação de financiamento é uma transação de bitcoin que coloca dinheiro em um canal Lightning. Pode ser de financiamento único (por um participante) ou de financiamento duplo (por ambos). A partir daí, as transações da Lightning tratam de realocar a propriedade da transação de financiamento, mas só se ajustam na blockchain quando o canal é fechado.
Para verificar nosso saldo local, devemos usar o comando `lightning-cli listfunds`:
```
c$ lightning-cli --testnet listfunds
{
"outputs": [],
"channels": []
}
```
Como os fundos ainda não têm seis confirmações, não há saldo disponível. Após seis confirmações, devemos ver o saldo alterado:
```
c$ lightning-cli --testnet listfunds
{
"outputs": [
{
"txid": "11094bb9ac29ce5af9f1e5a0e4aac2066ae132f25b72bff90fcddf64bf2feb02",
"output": 0,
"value": 300000,
"amount_msat": "300000000msat",
"scriptpubkey": "0014ca79fcc63cf72c9e0adb3044f559d997cf23b574",
"address": "tb1qefule33u7ukfuzkmxpz02kwejl8j8dt5jpgtu6",
"status": "confirmed",
"blockheight": 1780680,
"reserved": false
}
],
"channels": []
}
```
Observe que o valor está listado em satoshis ou microsatoshis, não em Bitcoin!
> :book: ***O que são satoshis e msats?*** Já conhecemos os satoshis na seção [§3.4](03_4_Receiving_a_Transaction.md). Um satoshi é o centésimo milionésimo de um bitcoin, então 300.000 satoshis equivalem a 0,003 BTC. Um satoshi é a menor unidade monetária na rede Bitcoin. Mas, a rede Lightning pode ser menor, então 1.000 msat, ou milisatoshis, equivalem a um satoshi. Isso significa que 1 msat é o centésimo bilionésimo de um bitcoin e 300.000.000 msat equivalem a 0,003 BTC.
Agora que financiamos nossa carteira c-lightning, precisaremos de informações sobre um node remoto para começar a criar o processo do canal.
### Conectando a um Node Remoto
A próxima coisa que precisaremos fazer é conectar nosso node a um par. Isso é feito com o comando `lightning-cli connect`. Lembre-se que se quisermos mais informações sobre este comando, devemos digitar `lightning-cli help connect`.
Para conectar nosso node a um par remoto, precisaremos do nosso id, que representa a chave pública do node de destino. Por conveniência, o `ID` pode ter a forma `id@host` ou `id@host:port`. Podemos já ter pego esta informação com o `lightning-cli getinfo` (na c-lightning) ou `lncli --network=testnet getinfo` (no LND) conforme discutido no [adendo anterior](19_2__Interlude_Accessing_a_Second_Lightning_Node.md).
Selecionamos o node LND, `032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543`, que está localizado no endereço IP `45.33.35.151`, ao qual vamos nos conectar a partir de nosso node c-lightning:
```
$ lightning-cli --network=testnet connect 032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543@45.33.35.151
{
"id": "032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543",
"features": "02a2a1"
}
```
### Abrindo um Canal
O comando fundchannel do RPC abre um canal de pagamento com um par ao comprometer uma transação de financiamento para a blockchain. Devemos usar o comando `lightning-cli fundchannel` para fazer isso, com os seguintes parâmetros:
* **id** é o retorno do id do peer da conexão;
* **amount** é o valor em satoshis retirado da carteira interna para financiar o canal. O valor não pode ser inferior ao limite mínimo, atualmente definido como 546 satoshis, nem superior a 16.777.215 satoshis (a menos que grandes canais tenham sido negociados com o par).
* **feerate** é o feerate opcional usado para a transação de abertura e como feerate inicial para transações de confirmação e HTLC.
* **announce** é um sinalizador opcional que aciona o anúncio deste canal ou não. O padrão é verdadeiro. Se desejarmos criar um canal privado, precisamos definí-lo como falso.
* **minconf** especifica o número mínimo de confirmações que saídas usadas no processo de abertura do canal devem ter. O padrão é 1.
* **utxos** especifica os utxos a serem usados ​​para financiar o canal, como uma matriz de “txid:vout”.
Agora podemos abrir o canal assim:
```
$ lightning-cli --testnet fundchannel 032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543 100000 urgent true 1
{
"tx": "0200000000010193dc3337837f091718f47b71f2eae8b745ec307231471f6a6aab953c3ea0e3b50100000000fdffffff02a0860100000000002200202e30365fe321a435e5f66962492163302f118c13e215ea8928de88cc46666c1d07860100000000001600142fe02e5be9283e8c5bcb93ae61421baf8cb64f9c024730440220668a7c253c9fd83fc1b45e4a52823fb6bc5fad30da36240d4604f0d6981a6f4502202aeb1da5fbbc8790791ef72b3378005fe98d485d22ffeb35e54a6fbc73178fb2012103b3efe051712e9fa6d90008186e96320491cfe1ef1922d74af5bc6d3307843327c76c1c00",
"txid": "66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d",
"channel_id": "1d3cf2126ae36e12be3aee893b385ed6a2e19b1da7f4e579e3ef15ca234d6966",
"outnum": 0
}
```
Para confirmar o status do canal, vamos usar o comando `lightning-cli listfunds`:
```
c$ lightning-cli --testnet listfunds
{
"outputs": [
{
"txid": "66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d",
"output": 1,
"value": 99847,
"amount_msat": "99847000msat",
"scriptpubkey": "00142fe02e5be9283e8c5bcb93ae61421baf8cb64f9c",
"address": "tb1q9lszuklf9qlgck7tjwhxzssm47xtvnuu4jslf8",
"status": "unconfirmed",
"reserved": false
},
{
"txid": "b5e3a03e3c95ab6a6a1f47317230ec45b7e8eaf2717bf41817097f833733dc93",
"output": 1,
"value": 200000,
"amount_msat": "200000000msat",
"scriptpubkey": "0014ed54b65eae3da99b23a48bf8827c9acd78079469",
"address": "tb1qa42tvh4w8k5ekgay30ugyly6e4uq09rfpqf9md",
"status": "confirmed",
"blockheight": 1862831,
"reserved": true
}
],
"channels": [
{
"peer_id": "032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543",
"connected": true,
"state": "CHANNELD_AWAITING_LOCKIN",
"channel_sat": 100000,
"our_amount_msat": "100000000msat",
"channel_total_sat": 100000,
"amount_msat": "100000000msat",
"funding_txid": "66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d",
"funding_output": 0
}
]
}
```
Embora este novo canal com 100.000 satoshis não esteja confirmado, nosso estado será `CHANNELD_AWAITING_LOCKIN`. Observe que a alteração não confirmada de `99847` satoshis também está aparecendo como uma nova transação na carteira. Depois que todas as seis confirmações forem concluídas, o canal mudará para o estado `CHANNELD_NORMAL`, que será o estado permanente. Nesse momento, um `short_channel_id` também aparecerá, por exemplo:
```
"short_channel_id": "1862856x29x0",
```
Esses valores indicam onde a transação de financiamento pode ser encontrada na blockchain. Ela aparece na forma `bloco x txid x vout`.
Neste caso, `1862856x29x0` significa:
* Criado no bloco 1862856;
* Com um `txid` de 29 e;
* Um `vout` de 0.
Podemos precisar usar este `short_channel_id` para certos comandos na Lightning.
Esta transação de financiamento também pode ser encontrada onchain pelo TXID [66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d] (https://mempool.space/pt/testnet/tx/66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d)
> :book: ***O que é a capacidade do canal?*** Em um canal Lightning, ambos os lados do canal possuem uma parte da capacidade. O valor do seu lado do canal é chamado de *saldo local (local balance)* e o valor do outro lado é chamado de *saldo remoto (remote balance)*. Ambos os saldos podem ser atualizados muitas vezes sem fechar o canal (quando o saldo final é enviado para a blockchain), mas a capacidade do canal não pode mudar sem fechá-lo. A capacidade total de um canal é a soma do saldo de cada participante do canal.
## Resumo: Criando um Canal na Lightning
Precisaremos criar um canal com um node remoto para poder receber e enviar dinheiro pela Lightning Network.
## O Que Vem Depois?
Você está pronto para passar para o [Capítulo 20: Usando Lightning](20_0_Using_Lightning.md).