Tipos de Endereços Bitcoin Explicados

Resposta Direta

Compare os formatos de endereços legacy, SegWit aninhado, SegWit nativo e Taproot, prefixos, compatibilidade e limites de segurança.

Dois endereços Bitcoin podem ambos receber BTC e ainda assim criar estruturas de transação diferentes por baixo. Um endereço de mainnet começando com 1, um começando com 3, um bc1q endereço e um bc1p endereço podem ser todos destinos válidos, mas não representam necessariamente o mesmo script, codificação ou condição de gasto futuro.

Essa diferença é fácil de perder porque a carteira apresenta um endereço como uma única string. Por baixo, o endereço diz ao software como construir uma saída de transação. Uma vez que essa saída é confirmada, ela se torna um UTXO que deve ser gasto posteriormente de acordo com as regras de script codificadas por essa saída.

A questão prática, portanto, não é simplesmente “Qual prefixo é mais novo?” É se o endereço pertence à rede Bitcoin pretendida, que tipo de saída ele representa, se o software de envio suporta esse formato, e o que o endereço pode—e não pode—dizer antes de você autorizar um pagamento.

O Que um Endereço Bitcoin Representa

Um endereço Bitcoin não é uma conta no sentido bancário. Ele não contém bitcoin, não guarda uma chave privada nem fornece uma visão completa do saldo de uma carteira. É uma codificação legível por humanos que ajuda uma carteira a construir uma saída de transação específica.

A relação simplificada é:

Endereço Bitcoin
        ↓
Decodificação do endereço
        ↓
scriptPubKey
        ↓
Saída de transação
        ↓
UTXO confirmado
        ↓
Condição de gasto futuro

Quando você envia bitcoin, a carteira não move um objeto de uma string de endereço para outra. Ela consome UTXOs existentes como entradas de transação e cria novas saídas. O endereço de destino fornece a informação necessária para construir uma dessas saídas.

É por isso que um formato de endereço importa tecnicamente. Um endereço P2PKH leva a um script de saída diferente de um endereço P2WPKH. Uma saída Taproot P2TR é diferente novamente. Essas saídas podem todas representar bitcoin gastável, mas as condições e a serialização usadas quando são gastas não são idênticas.

O endereço não é a chave privada

A chave privada permanece separada do endereço. Uma carteira usa material de chave privada para criar a assinatura ou dados de testemunha exigidos pela condição de gasto. Publicar um endereço de recebimento não publica a chave privada.

O inverso também é importante: ver um endereço não prova que uma pessoa específica controla a chave correspondente. A análise de blockchain pode observar transações e saídas, mas uma string de endereço sozinha não é evidência de identidade.

Por que vários formatos existem

O Bitcoin tem múltiplos formatos de endereço porque o sistema de transações evoluiu mantendo compatibilidade com saídas mais antigas. Novos formatos não substituíram saídas antigas na blockchain. Em vez disso, introduziram maneiras adicionais de expressar condições de gasto.

Os quatro formatos que a maioria dos usuários encontra na mainnet do Bitcoin são:

• Legado P2PKH, comumente exibido com um endereço começando com 1.
• P2SH, comumente começando com 3; SegWit aninhado é um uso importante de P2SH, mas não o único.
• SegWit nativo, codificado com Bech32 e comumente começando com bc1q para versão de testemunha 0.
• Taproot, codificado com Bech32m e começando com bc1p para saídas P2TR de versão de testemunha 1.

A mudança importante não é a aparência da string. É o que o destino decodificado diz à carteira para colocar na nova saída.

Tipos de endereço Bitcoin comparados

Nome comum	Prefixo da mainnet	Codificação	Saída típica	O que o prefixo informa
Legado	1	Base58Check	P2PKH	Família de byte de versão para um endereço de hash de chave pública da mainnet
P2SH (incluindo SegWit aninhado)	3	Base58Check	P2SH; SegWit aninhado é uma construção possível de script de resgate	O destino é P2SH, não o script de resgate exato dentro dele
SegWit nativo	bc1q	Bech32	Testemunha v0, comumente P2WPKH ou P2WSH	Destino Bech32 de versão de testemunha 0 na mainnet
Taproot	bc1p	Bech32m	P2TR	Destino Taproot de versão de testemunha 1 na mainnet

Esta tabela é útil para identificação, mas o prefixo não é uma descrição completa do comportamento de gasto futuro. O exemplo mais claro é um 3... endereço: ele identifica P2SH, mas P2SH pode se comprometer com muitos scripts de resgate. SegWit aninhado é apenas uma possibilidade.

Endereços Legados P2PKH

Pay-to-public-key-hash legado, ou P2PKH, é o formato de endereço mais associado ao software inicial de carteiras Bitcoin. Na mainnet, esses endereços Base58Check normalmente começam com 1.

O endereço representa um hash de uma chave pública. Quando uma carteira paga para esse destino, ela cria um script de bloqueio P2PKH que exige uma assinatura válida e a chave pública correspondente quando a saída é gasta.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

O endereço visível, portanto, não é o script em si. A carteira decodifica o endereço Base58Check, extrai a versão e a carga útil e constrói o scriptPubKey apropriado.

Saídas P2PKH permanecem saídas Bitcoin válidas. “Legado” não significa inválido ou automaticamente inseguro. A distinção se torna relevante ao comparar a estrutura da transação: gastar uma saída P2PKH tradicional coloca os dados de desbloqueio no script de entrada em vez de usar a serialização de testemunha SegWit.

Essa diferença pode aumentar o peso da transação em comparação com gastos de chave SegWit comuns. Isso não significa que um pagamento P2PKH automaticamente tem uma taxa específica. Número de entradas, número de saídas, taxa selecionada e o resto da transação assinada ainda determinam o custo final.

P2SH e SegWit Aninhado

Pay-to-script-hash, ou P2SH, moveu parte da lógica de gasto para trás de um hash. Endereços P2SH na mainnet usam Base58Check e normalmente começam com 3.

Uma saída P2SH padrão coloca o hash do script de resgate no script de bloqueio:

OP_HASH160

OP_EQUAL

O script de resgate completo é fornecido somente quando a saída é gasta. Isso criou uma importante ferramenta de compatibilidade quando o SegWit foi introduzido: um programa de testemunha SegWit poderia ser colocado dentro de um script de resgate P2SH, permitindo que um remetente que entendesse endereços P2SH comuns pagasse uma saída que mais tarde seria gasta usando as regras do SegWit.

Uma construção comum de chave única é chamada P2SH-P2WPKH:

Endereço P2SH
    ↓
hash do redeemScript
    ↓
redeemScript contém um programa de testemunha P2WPKH
    ↓
assinatura e chave pública são fornecidas através de dados de testemunha quando gasto

Um prefixo 3 não prova SegWit

Este é um dos limites mais importantes da identificação visual de endereços. Um endereço que começa com 3 informa que o destino usa a versão de endereço P2SH da mainnet. Não revela o script de resgate completo antes que a saída seja gasta.

P2SH existia antes do SegWit e pode envolver outros scripts. Tratar todo 3... endereço como “um endereço SegWit” é, portanto, muito amplo.

Limite técnico: o prefixo identifica o formato do endereço externo. Não prova o script exato escondido atrás de um hash P2SH.

SegWit nativo e bc1q

SegWit nativo remove o wrapper de compatibilidade P2SH e representa o programa de testemunha diretamente. BIP 173 introduziu a codificação Bech32 para endereços SegWit nativos.

Na mainnet do Bitcoin, a parte legível por humanos é bc. A versão 0 de testemunha produz endereços comumente reconhecíveis pelo início bc1q.

Duas saídas comuns de versão 0 de testemunha são:

• P2WPKH: um programa de testemunha de 20 bytes comumente usado para pagamentos de carteira de chave única.
• P2WSH: um programa de testemunha de 32 bytes que se compromete com um script de testemunha.

O endereço em si dá à carteira a versão de testemunha e o programa. Para a versão 0 de testemunha, scripts de saída comuns têm estas formas:

P2WPKH: OP_0 
P2WSH:  OP_0

A saída contém diretamente o programa de testemunha em vez de um wrapper P2SH. Quando o UTXO é gasto, a assinatura ou os dados de script exigidos pelo programa de testemunha são fornecidos no testemunho da transação, em vez de em um scriptSig tradicional no estilo P2PKH.

Bech32 também altera a detecção de erros

Bech32 não é meramente um alfabeto diferente. Ele inclui uma soma de verificação projetada para esta família de endereços e separa a parte legível por humanos da rede dos dados de testemunha codificados.

As strings Bech32 não devem misturar caracteres maiúsculos e minúsculos. As carteiras normalmente exibem endereços Bech32 da mainnet do Bitcoin em minúsculas. Uma codificação totalmente em maiúsculas pode ser válida de acordo com a especificação, mas maiúsculas e minúsculas misturadas são inválidas.

Taproot e bc1p

O Taproot introduziu saídas pay-to-Taproot, ou P2TR. O P2TR usa a versão 1 de testemunha com um programa de testemunha de 32 bytes. Na mainnet do Bitcoin, o endereço resultante começa com bc1p.

A versão 1 de testemunha e posteriores usam Bech32m em vez da soma de verificação Bech32 original. O BIP 350 introduziu essa mudança após uma fraqueza ser identificada no uso do comportamento original da soma de verificação Bech32 para versões mais recentes de testemunha.

Isto fornece uma regra de identificação prática:

bc1q... → versão de testemunha 0 → Bech32
bc1p... → versão de testemunha 1 P2TR → Bech32m

O script de bloqueio P2TR correspondente usa versão de testemunha 1 e uma chave de saída Taproot de 32 bytes:

OP_1 <32-byte Taproot output key>

Uma saída P2TR compromete-se com essa chave de saída Taproot. Ela pode posteriormente ser gasta através do caminho de chave ou, se uma árvore de script foi comprometida, através de um caminho de script válido revelado.

O endereço não revela qual caminho será eventualmente usado. Ver bc1p informa que a saída é P2TR. Não informa se o gastador futuro usará uma assinatura de caminho de chave ou revelará um caminho de script.

O que os Prefixos Bitcoin Realmente Dizem a Você

Prefixos são úteis porque permitem que um humano identifique rapidamente a provável família de endereço e rede. Eles devem ser tratados como uma verificação inicial, não como validação completa.

Exemplo de início	Significado provável na mainnet	O que não prova
1...	Endereço P2PKH mainnet	Proprietário, saldo ou identidade do destinatário
3...	Endereço P2SH mainnet	Que o script de resgate é SegWit aninhado
bc1q...	Endereço nativo de versão de testemunha 0	Se é P2WPKH ou P2WSH apenas pelo prefixo
bc1p...	Endereço de versão de testemunha 1 P2TR	Qual caminho de gasto Taproot será usado posteriormente

O prefixo também não pode autenticar a pessoa que lhe deu o endereço. Um endereço perfeitamente codificado e com checksum válido ainda pode pertencer ao destinatário errado.

A Rede Vem Antes do Tipo de Endereço

Antes de escolher entre Legacy, SegWit ou Taproot, confirme que o endereço pertence à rede Bitcoin que você pretende usar.

Endereços da família Bech32 tornam isso visível através de sua parte legível por humanos. O BIP 173 define bc para a mainnet do Bitcoin e tb para endereços de testnet do Bitcoin. A parte legível por humanos é, portanto, parte da validação da rede, não decoração.

As famílias de endereços Base58Check também usam bytes de versão diferentes entre mainnet e testnets, embora a diferença seja menos óbvia para um usuário que apenas olha a string.

Uma carteira deve rejeitar uma combinação de rede/endereço não suportada, mas a responsabilidade final ainda é confirmar a rede exibida pelo aplicativo de envio. O reconhecimento do formato do endereço não substitui a verificação da rede.

Para o contexto mais amplo da transação—entradas, saídas, confirmações e a camada base do Bitcoin—use o referência de rede Bitcoin.

Tipo de Endereço e Taxas de Transação

É comum ouvir que um endereço Bitcoin mais novo é “mais barato”. Essa afirmação é direcionalmente útil em algumas comparações, mas simples demais para ser usada como regra de taxa.

O endereço escolhido por um destinatário afeta o tipo e o tamanho serializado da saída criada hoje. Mais importante, quando essa saída é gasta posteriormente, seu tipo de script afeta a estrutura da entrada de transação correspondente.

SegWit também altera a contabilidade de Weight da transação porque os bytes de testemunha são ponderados de forma diferente dos bytes não-testemunha. Um gasto de chave Native SegWit comum, portanto, tem um perfil de Weight diferente de um gasto Legacy P2PKH comparável. Isso afeta o tamanho virtual quando o UTXO é gasto, mas ainda não fixa a taxa total antecipadamente.

A mesma quantidade de BTC pode levar a custos futuros diferentes

Considere dois usuários que recebem a mesma quantidade de bitcoin. Um recebe uma saída P2PKH e o outro recebe uma saída P2WPKH. O valor é idêntico. A estrutura de entrada futura não é.

Quando esses UTXOs são gastos posteriormente, seus dados de desbloqueio são serializados de forma diferente. Isso altera o Weight da transação e, portanto, o tamanho virtual. Na mesma taxa sat/vB, um vSize diferente significa uma taxa total diferente.

Este é um cenário técnico ilustrativo, não um registro de transação de usuário ou uma afirmação sobre uma carteira específica.

O tipo de endereço ainda não determina a taxa final por si só. Uma transação com muitos inputs SegWit eficientes pode ser maior do que uma com um único input Legacy. A quantidade de outputs, assinaturas, caminhos de script e a taxa escolhida também importam.

Para a relação completa entre Weight, tamanho virtual e sat/vB, leia como funcionam as taxas de transação Bitcoin. Quando você precisa de uma estimativa específica para a transação em vez de uma comparação conceitual, use a Calculadora de Taxas de Transação de Bitcoin.

Compatibilidade é uma Verificação do Remetente

Um endereço Bitcoin válido não é útil para um fluxo de pagamento se a carteira de envio ou o serviço de retirada não entender o formato.

Essa distinção foi especialmente importante durante a adoção do Native SegWit e, posteriormente, do Taproot. A rede Bitcoin podia reconhecer o tipo de output enquanto aplicativos mais antigos não tinham suporte para criar esse destino.

Quando um serviço rejeita um bc1q ou bc1p endereço, não altere o endereço manualmente. Não remova caracteres, mude o prefixo ou converta-o através de um site arbitrário. Use um formato de endereço que sua carteira receptora realmente gerou e que o remetente suporte explicitamente.

Enviar entre formatos não é conversão

Você não precisa de uma carteira Legacy para pagar um endereço Legacy ou uma carteira Taproot para pagar um endereço Taproot no sentido de combinar os formatos de origem e destino. A transação de envio consome quaisquer UTXOs suportados que a carteira seleciona e cria uma nova saída para o script de destino.

A questão relevante é se o software de envio pode decodificar e construir a saída de destino solicitada.

Um Endereço Válido Ainda Pode Estar Errado

Checksums detectam certos erros de transcrição. Eles não autenticam o destinatário pretendido.

Se um malware substituir um endereço copiado por outro endereço Bitcoin válido, a substituição pode passar na validação de checksum perfeitamente. O formato técnico é válido; o destino está errado.

É por isso que “a carteira aceitou o endereço” não é a verificação final de segurança. A aceitação informa que o software reconheceu um destino válido ou suportado. Não prova de onde o endereço veio.

Verifique Antes de Enviar

Um processo de verificação útil separa a validação de formato da validação do destinatário.

1. Confirme a rede. Certifique-se de que a carteira ou serviço está enviando Bitcoin na rede Bitcoin pretendida, em vez de outro ativo ou ambiente de teste.
2. Leia a família do endereço. A 1, 3, bc1q ou bc1p prefixo dá uma pista inicial de formato.
3. Confirme o suporte do remetente. O serviço de retirada ou carteira deve aceitar explicitamente o formato de destino.
4. Verifique o destino através de um canal confiável. Compare o endereço completo em uma tela confiável quando prático, em vez de confiar apenas em alguns caracteres iniciais e finais.
5. Revise a tela final da transação na carteira. Confirme o destinatário, o valor, a taxa de rede e qualquer troco antes de assinar.
6. Proteja material privado. A verificação de endereço de recebimento nunca exige que você insira uma frase-semente ou chave privada em um site.

Para transferências grandes ou operacionalmente sensíveis, as organizações frequentemente adicionam procedimentos independentes de verificação de destino. Esses procedimentos são um controle operacional, não uma propriedade de um formato de endereço Bitcoin específico.

Reutilização de Endereço é uma Questão Separada

Um endereço Bitcoin não expira no nível do protocolo simplesmente por ter sido usado uma vez. Se a condição de gasto correspondente permanecer controlável, pagamentos futuros para o mesmo endereço ainda podem criar saídas válidas.

Isso não torna a reutilização de endereço desejável. Reutilizar um endereço de recebimento pode facilitar a associação de transações na blockchain pública e pode reduzir a privacidade.

Esta questão de privacidade é separada de saber se o endereço é P2PKH, P2SH, P2WPKH ou P2TR. Um formato de endereço moderno não torna o uso repetido do mesmo destino visível privado.

Os Limites da Validação de Endereço

A validação de formato responde a uma questão restrita: se a string pode ser decodificada como o tipo esperado de destino Bitcoin sob as regras de endereço relevantes. Ela não autentica a pessoa que a forneceu, não prova a propriedade de uma chave privada, não prova o saldo total de uma carteira, não garante que um serviço suporte o formato, nem determina a taxa final da transação.

Ela também não pode revelar informações deliberadamente ocultas pela construção da saída. Um endereço P2SH não expõe o script de resgate completo antes do gasto, e um endereço P2TR não informa antecipadamente se o gasto futuro usará o caminho de chave ou revelará um caminho de script. Trate a decodificação bem-sucedida como uma verificação no processo de pagamento, não como prova de que todas as suposições ao redor estão corretas.

Escolhendo um Formato de Recebimento

O padrão mais seguro é usar um endereço gerado pela carteira que você realmente controla, em vez de construir ou converter um endereço manualmente.

Se a carteira receptora oferecer mais de um tipo de endereço, use o tipo que corresponda à política de script pretendida da carteira e que o remetente possa decodificar. Um endereço P2WPKH é apropriado quando a carteira gera intencionalmente um destino de hash de chave de versão de testemunha 0. Um endereço P2TR é apropriado quando a carteira gera intencionalmente um destino Taproot e o remetente o suporta. Destinos mais antigos P2PKH ou P2SH permanecem válidos quando um fluxo de trabalho exige esses formatos.

Não selecione um formato apenas porque alguém afirma que é “o mais barato.” A saída que você cria hoje torna-se uma entrada apenas quando for gasta mais tarde, e o custo final dessa transação futura depende da estrutura completa da transação e da taxa.

O endereço deve vir da carteira receptora. O remetente deve suportá-lo. A rede deve corresponder. Essas três verificações importam mais do que perseguir um prefixo por si só.

FAQ do Endereço Bitcoin

Qual é a diferença entre bc1q e bc1p?

bc1q é comumente o início de um endereço Bitcoin mainnet de versão de testemunha 0 codificado com Bech32, como P2WPKH ou P2WSH. bc1p identifica um endereço P2TR mainnet de versão de testemunha 1 codificado com Bech32m.

Todo endereço Bitcoin que começa com 3 usa SegWit?

Não. Um endereço de mainnet que começa com 3 é um endereço P2SH. SegWit aninhado pode usar P2SH, mas P2SH pode se comprometer com outros scripts de resgate, então o prefixo sozinho não prova que a saída é SegWit aninhado.

Os endereços Bitcoin diferenciam maiúsculas de minúsculas?

Os endereços Base58Check usam um alfabeto que diferencia maiúsculas de minúsculas. As codificações Bech32 e Bech32m não devem misturar caracteres maiúsculos e minúsculos; as carteiras Bitcoin normalmente os exibem em minúsculas. Não altere manualmente a caixa de um endereço.

Posso enviar Bitcoin de um tipo de endereço para outro?

Sim, quando a carteira de envio suporta o formato de destino. Uma transação pode gastar um tipo de entrada suportado e criar um tipo de saída suportado diferente. Os prefixos de origem e destino não precisam corresponder.

Um endereço Bitcoin expira?

Nenhuma regra de protocolo faz um endereço Bitcoin normal expirar após uma data definida ou após um pagamento. As carteiras geralmente geram novos endereços de recebimento porque a reutilização de endereços pode reduzir a privacidade, não porque endereços gerados anteriormente se tornam automaticamente inválidos.

Qual tipo de endereço Bitcoin devo usar?

Use um endereço gerado pela carteira de recebimento para a rede Bitcoin e o tipo de script que você pretende usar, e confirme que o remetente suporta esse formato. SegWit nativo é comum para pagamentos modernos, enquanto Taproot é apropriado quando ambos os lados suportam P2TR. Não transforme manualmente um formato de endereço em outro.

Fontes Técnicas

As descrições de formato de endereço acima são baseadas em Propostas de Melhoria do Bitcoin e documentação Bitcoin Core. Essas referências definem codificações de endereço, programas de testemunha e comportamento de script; elas não provam a identidade ou segurança de um endereço de recebimento específico. A abordagem mais ampla de fontes do BitcoinToolkit é descrita na Fontes de dados page.

• BIP 13: Formato de endereço para pay-to-script-hash — especifica o formato de endereço P2SH Base58Check.
• BIP 16: Pagar para Script Hash — define o modelo de gasto P2SH e a avaliação do script de resgate.
• BIP 49: Esquema de derivação para P2WPKH-aninhado-em-P2SH — documenta a construção comum de SegWit aninhado de chave única discutida neste guia.
• BIP 141: Testemunha Segregada — define programas de testemunha, Weight de transação e semântica de saída SegWit.
• BIP 173: Formato de endereço Base32 para saídas de testemunha nativas v0-16 — introduziu a codificação de endereço SegWit nativa Bech32.
• BIP 350: Formato Bech32m para endereços de testemunha v1+ — define Bech32m e a regra de soma de verificação para versões de testemunha mais recentes.
• BIP 341: Taproot — define regras de saída e gasto Taproot, incluindo versão de testemunha P2TR 1.
• Descritores de Saída Bitcoin Core — documenta descrições estruturadas de scripts de saída Bitcoin comuns e expressões de chave.

Fontes

1. BIP 13: Formato de endereço P2SH
2. BIP 141: Testemunha Segregada
3. BIP 173: Endereços SegWit nativos Bech32
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. descritores de saída Bitcoin Core

Encontrou um erro? Relate um problema de conteúdo ou leia nosso Política de correções.