Endereço Bitcoin

Alice quer pagar a Bob. Bob abre Receber na carteira, verifica o endereço e envia-o como texto ou código QR. Alice carrega-o na sua carteira e confirma o destinatário e o montante antes de enviar. Não precisa de interpretar cada carácter: a aplicação trata disso. A partir do endereço, a carteira constrói a condição que permitirá gastar o dinheiro mais tarde, normalmente uma assinatura com a chave privada certa. A transação regista essa condição num script chamado scriptPubKey. Guarda o montante e o script, não o texto habitual do endereço. O endereço é, portanto, uma forma prática de transmitir dados de pagamento, não um recipiente com moedas lá dentro. [1] [3]

Copie o endereço comprido ou leia o QR, em vez de o escrever à mão. Mas a verificação não acaba aí: software malicioso pode substituir um endereço na área de transferência. Compare o endereço completo com os dados obtidos do destinatário por um canal fiável. Se utiliza uma Hardware Wallet, confira também o ecrã do próprio dispositivo. O início e o fim não bastam, pois um endereço fraudulento pode imitá-los. Os endereços incluem uma soma de verificação que ajuda a detetar erros de escrita, mas não confirma que um endereço bem escrito pertence à pessoa pretendida. A carteira também tem de suportar o formato e a rede. Um pequeno pagamento de teste pode ajudar, mas não substitui a verificação no envio seguinte. O protocolo não permite simplesmente cancelar um pagamento confirmado para um endereço errado, embora válido. [2] [7] [8] [18]

Na próxima vez que Bob abrir Receber, poderá surgir outro endereço. Isso não significa que o dinheiro desapareceu. Um endereço novo ajuda a proteger a privacidade: quem conhece um endereço publicado pode acompanhar os pagamentos para ele na blockchain, mas não deverá obter automaticamente uma visão de todos os recebimentos da carteira. Reutilizá-lo facilita essa associação. Endereços novos também não garantem anonimato; transações posteriores podem revelar outras ligações. Pode partilhar um endereço para receber, mas convém pensar antes de o publicar por todo o lado. Um endereço também não equivale a uma pessoa: várias pessoas podem gerir fundos em conjunto, ou um serviço pode geri-los para clientes. [1] [14]

A carteira gere chaves, encontra pagamentos que consegue gastar e apresenta o total. O saldo pode, por isso, provir de muitos endereços. Uma HD Wallet comum gera famílias de chaves a partir de uma base partilhada: um novo endereço não significa abrir outra carteira. Ao pagar, a aplicação pode também devolver o valor sobrante para um endereço próprio, chamado Change Address. Os endereços, por si só, não chegam para recuperar a carteira. A cópia de segurança deve permitir recuperar as chaves necessárias e as regras da sua utilização. Muitas carteiras usam uma Seed Phrase, um conjunto de palavras de recuperação; configurações mais complexas podem exigir informações adicionais. Quem paga nunca precisa dessas palavras nem das suas chaves privadas. [10] [14]

Um código QR é apenas uma representação de dados. Pode conter um endereço ou um pedido que comece por bitcoin:, com montante, identificação do destinatário ou mensagem. BIP21 descrevia este mecanismo, que BIP321 amplia. Antes de confirmar, verifique o que a carteira leu realmente. Os pedidos da Lightning Network, como uma invoice para um pagamento ou um offer que permite pedir novas invoices a cada utilização, usam outro processo; Lightning Address facilita obter esse pedido. Alguns pedidos oferecem várias formas de pagar. Do mesmo modo, uma assinatura digital de mensagem não confirma automaticamente uma identidade: BIP322 permite demonstrar que as condições de um script podem ser cumpridas, mas não prova, por si só, identidade legal ou aprovação de uma fatura qualquer. [15] [16] [17]

Base58Check junta um byte de versão aos dados chamados payload. Acrescenta os primeiros quatro bytes de SHA256(SHA256(version || payload)) e codifica o resultado em Base58. Na mainnet, 0x00 indica P2PKH e 0x05 P2SH, dando os inícios habituais 1 ou 3. As redes de teste usam outras versões. O alfabeto omite os caracteres confundíveis 0, O, I e l. Este checksum de 32 bits deteta muitos erros de escrita, mas não autentica o destinatário. [2] [3]

A representação SegWit nativa inclui o prefixo bc para mainnet ou tb para testnet, o separador 1, a versão witness e dados em grupos de 5 bits. Termina com 6 caracteres de verificação. O BIP173 introduziu Bech32; após a descoberta de uma fraqueza em certas inserções e eliminações, o BIP350 manteve Bech32 para a versão 0 e estabeleceu Bech32m para as versões 1–16. As letras podem ser todas minúsculas ou todas maiúsculas, nunca misturadas. O limite da codificação é 90 caracteres. Mesmo uma representação válida pode pertencer a outra rede ou a uma versão não suportada. [7] [8]

P2PKH e P2WPKH remetem para o HASH160 de 20 bytes de uma chave pública. P2SH usa HASH160 de redeemScript, enquanto P2WSH usa SHA256 de witnessScript. SegWit v0 reconhece assim P2WPKH de 20 bytes e P2WSH de 32 bytes. P2TR segundo o BIP341 é diferente: o seu programa da versão 1 contém uma chave de saída Q ajustada, x-only, de 32 bytes, não o hash de uma chave recetora comum. Q pode também incorporar a raiz de uma árvore de scripts adicionais, ligando criptograficamente a chave a essas condições de gasto. O endereço sozinho não revela todas as possibilidades de gasto. [6] [9]

As primeiras saídas Bitcoin pagavam frequentemente diretamente a uma chave pública. P2PKH adiou a sua revelação até ao gasto. BIP13 e BIP16 permitiram transmitir com P2SH o hash de um script mais complexo. BIP141 acrescentou programas witness versionados, BIP173 Bech32, e BIP341 com BIP350 o formato Taproot com Bech32m. O aspeto diferente corresponde a condições de verificação diferentes. Não «converta» um endereço trocando manualmente o prefixo: pode criar uma saída diferente ou impossível de gastar. Alguns scripts não convencionais e as primeiras saídas pay-to-pubkey não têm um endereço canónico habitual. [4] [5] [6] [7] [8] [9] [3]

Uma HD Wallet segundo BIP32 deriva muitas chaves de uma raiz comum. Os caminhos distinguem os tipos de saída: BIP44 usa o propósito 44' para P2PKH, BIP84 o 84' para P2WPKH e BIP86 o 86' para P2TR de chave única. Seguem-se o tipo de moeda (coin type), a conta, o ramo de receção ou change e o índice do endereço. A Seed Phrase sozinha pode não indicar todos os caminhos, contas e regras Multisig. Um Output Descriptor guarda também a origem das chaves e a construção do script. Recuperar exige encontrar os fundos reais, não apenas voltar a mostrar um endereço conhecido. [10] [11] [12] [13] [14]

Em P2PKH e P2WPKH, vê-se normalmente primeiro o hash da chave; o gasto revela a chave pública. P2SH e P2WSH revelam o redeemScript ou witnessScript utilizado. Taproot já contém uma chave pública ajustada na saída. Um key-path spend normalmente acrescenta uma Schnorr Signature, enquanto um script-path spend revela o script escolhido, o control block e o caminho Merkle; os ramos não usados podem permanecer ocultos. Não é, portanto, verdade que todos os endereços escondem a chave pública. [6] [9]