RPC

Tudo o que automatiza o bitcoin conversa com um nó dessa forma. O Bitcoin Core escuta na porta 8332 solicitações HTTP que carregam JSON, responde a uma chamada por vez e, por padrão, aceita conexões apenas da máquina em que é executado. Se algum serviço já lhe deu uma estimativa de taxa ou disse que um saque foi confirmado, alguma chamada RPC produziu essa resposta.

Como funciona

Uma chamada RPC é uma solicitação HTTP POST cujo corpo nomeia um método e lista seus argumentos.

Peça getblockchaininfo e voltam o nome da cadeia, a altura atual, o progresso da verificação e o tamanho em disco. Peça listunspent ou sendtoaddress e você estará operando a carteira do nó. Peça getrawtransaction e você recebe bytes. O programa bitcoin-cli incluído é uma camada fina que monta o JSON, o envia e imprime a resposta, então tudo o que você pode digitar em uma linha de comando um programa pode fazer por um socket.

A autenticação tem uma história que vale a pena conhecer. O Bitcoin Core abandonou seu suporte integrado a SSL na versão 0.12.0, então a interface fala HTTP sem criptografia e nada mais. Essa mesma versão introduziu o arquivo de cookie, uma credencial aleatória gravada no diretório de dados na inicialização e substituída a cada reinício, e é por isso que o bitcoin-cli funciona na sua própria máquina sem que você precise definir uma senha. Para clientes remotos existe o rpcauth, que guarda no arquivo de configuração um hash com sal em vez de um segredo em texto simples. Ainda não há criptografia de transporte, então alcançar um nó pela rede exige um túnel SSH, uma VPN ou um serviço oculto do Tor, e nada mais serve.

Cada rede tem sua própria porta para que vários daemons possam compartilhar uma mesma máquina: 8332 na mainnet, 18332 na testnet3, 48332 na testnet4, 38332 na signet e 18443 na regtest. A porta RPC da mainnet fica logo abaixo da porta ponto a ponto 8333, e confundir as duas é um erro comum de principiante.

O dialeto evoluiu devagar. O Bitcoin Core respondeu com uma variante frouxa de JSON-RPC 1.0 por bem mais de uma década, e a versão 28.0 ensinou o servidor a reconhecer solicitações JSON-RPC 2.0 e a responder em estrita conformidade com essa especificação, sem deixar de aceitar o estilo antigo. As chamadas específicas de carteira são endereçadas por caminho, então um nó com várias carteiras as encaminha por /wallet/ seguido do nome da carteira.

Onde você vê isso

RPC é a costura entre o bitcoin em si e todo produto construído sobre ele.

Uma implementação Lightning pede blocos a um nó e transmite por ele as transações de fechamento. Exploradores de blocos, painéis da mempool e processadores de pagamento como o BTCPay Server ficam sobre uma instância do bitcoind e a envolvem em algo mais amigável. O sistema de saques de uma corretora é, na base da pilha, uma fila de chamadas sendrawtransaction. Quando nossas análises de corretoras observam que uma plataforma agrupa saques em lotes, esse agrupamento acontece em código que acaba aqui.

É também aqui que instalações auto-hospedadas são comprometidas. A porta 8332 é escaneada constantemente, e um nó publicado na internet aberta com uma senha fácil de adivinhar e uma carteira carregada é uma carteira que será esvaziada. Mantenha a interface limitada à máquina local e acesse por túnel se precisar dela de outro lugar.

RPC vs ordem de bytes RPC

RPC e ordem de bytes RPC compartilham uma sigla e nada mais, o que causa erros reais. RPC é a interface. A ordem de bytes RPC é uma convenção de exibição: hashes de bloco e de transação são calculados e transmitidos em uma direção e impressos pela camada RPC na direção inversa, e é por isso que um txid copiado de um explorador de blocos aparece invertido em comparação com os mesmos 32 bytes dentro de uma transação bruta. Passe um txid copiado diretamente para um analisador de bytes sem invertê-lo e a busca simplesmente nunca corresponderá.