
Uma nota sobre financiamento: o CypherpunkGuide não veicula publicidade de vigilância — nada de redes de anúncios, pixels de rastreamento ou conteúdo patrocinado. O projeto se sustenta com fontes transparentes de receita: doações de leitores agora; assinatura e afiliados alinhados à linha editorial mais adiante. Respondemos aos leitores, não aos anunciantes.
Receber bitcoin esconde uma contradição pequena e silenciosa. Todo guia diz para nunca reutilizar um endereço — a reutilização é um dos sinais mais fáceis de ler para quem analisa a cadeia. Só que, na hora em que você quer ser pago — uma caixinha de gorjetas na bio, uma linha de doação num README, uma fatura que você envia uma vez e esquece —, precisa de um endereço que fique parado. Endereços que giram e identidade fixa puxam para lados opostos.
Os Silent Payments (BIP-352) são o protocolo que resolve isso: você publica um endereço, e cada pessoa que te paga deriva a partir dele um endereço on-chain diferente, de modo que quem observa a cadeia vê outputs sem relação entre si, sem destino em comum. É uma das mudanças mais importantes na privacidade de recebimento em anos. É também muito mal compreendido, entregue pela metade nas carteiras, e carrega um custo real que os artigos entusiasmados costumam passar por cima.
Escrevo sob um pseudônimo e trato cada moeda que guardo como já vigiada, então não quis aceitar o protocolo de olhos fechados. Antes de escrever uma linha deste guia, fiz do zero uma implementação do BIP-352 em Python — com o libsecp256k1 através da biblioteca coincurve — e testei o resultado contra os test vectors oficiais da especificação: 28 de 28 subcasos de envio e 29 de 29 subcasos de recebimento bateram, bit a bit, em menos de 200 milissegundos (registro que acompanha o artigo). O que vem a seguir é o funcionamento real — o que ele protege, quais carteiras o oferecem em 2026 e o custo de escaneamento que você deveria entender antes de depender dele.
| A promessa | A realidade | O porém |
|---|---|---|
| “Um endereço, privacidade total” | Um endereço, privacidade só no recebimento | Os valores e os seus remetentes continuam expostos |
| “Substitui a mistura de moedas” | Resolve um problema diferente do CoinJoin | Não mistura; impede o vínculo de reutilização |
| “É só publicar e esquecer” | Publicar é de graça; receber não é | Alguém precisa escanear a cadeia atrás das suas moedas |
| “Toda carteira já suporta” | Enviar é comum; receber é mais recente | Confira envio e recebimento por carteira e por versão |
O que é um Silent Payment de fato (e o que ele não protege)#
Um Silent Payment é um endereço Bitcoin reutilizável, definido pela BIP-352: a partir de uma única string que você publica uma vez, quem paga consegue derivar para você um endereço on-chain único e não vinculável. Ele protege o vínculo de recebimento — a ligação entre pagamentos distintos para a mesma identidade — e nada mais. Ele não esconde valores, não protege os seus remetentes e nada faz quanto aos registros fora da cadeia que ligam as moedas ao seu nome.
O endereço são duas chaves públicas — uma scan key e uma spend key — codificadas juntas. Na mainnet ele começa com sp1; numa rede de teste, com tsp1 (o prefixo legível é sp / tsp, e o 1 é apenas o separador do bech32m). Quando alguém te paga, a carteira dessa pessoa combina as próprias chaves de input com a sua scan key para calcular um segredo compartilhado e, a partir dele, deriva um novo output Taproot que só você consegue detectar e gastar. Dois pagadores nunca geram o mesmo output, e não existe nenhuma “transação de notificação” anunciando o vínculo — essa é a melhoria decisiva em relação à antiga abordagem de payment code da BIP-47.
Vale dizer com todas as letras o que ele deixa exposto, porque a palavra “privado” carrega aqui um peso que não conquistou. Silent Payments são uma ferramenta de recebimento. O valor que você recebe continua visível on-chain. A privacidade de quem paga é problema dessa pessoa, não seu. E o ataque mais forte contra um pseudônimo público quase nunca é a cadeia — é a escrita, os metadados, a corretora com KYC onde as moedas encontram um passaporte. Esse é o modelo aditivo descrito em como o rastreamento on-chain funciona de verdade e, fora da cadeia, em desanonimização por IA. Os Silent Payments fecham uma brecha específica e valiosa. São necessários, não suficientes.
Quais carteiras suportam Silent Payments em 2026#
O suporte é real, mas irregular, e o hábito mais útil de todos é conferir envio e recebimento separadamente — eles chegaram em momentos diferentes, em carteiras diferentes, às vezes com anos de distância. Enviar para um endereço Silent Payment já é comum; conseguir receber em um deles, o que exige que a carteira escaneie a cadeia, é mais novo e mais raro. A tabela abaixo reflete fontes primárias em 9 de julho de 2026; confira as notas de versão de cada projeto antes de mover dinheiro de verdade, porque essa lista muda.
| Carteira | Envio | Recebimento | Observações (em 9 de julho de 2026) |
|---|---|---|---|
| Sparrow | ✅ v2.3.0 (out. 2025) | ✅ v2.5.0 (mai. 2026) | Implementação de desktop mais completa; assinatura por hardware wallet via BIP-375 adicionada na v2.4.0 (fev. 2026). Mais recente: v2.5.2 |
| Cake Wallet | ✅ | ✅ | Primeira carteira móvel com todos os recursos (v4.18.0, fim de maio de 2024). Usa escaneamento no próprio aparelho — mais pesado para a bateria e para o tempo de sincronização |
| Bitcoin Core | ⏳ não integrado | ⏳ não integrado | O módulo criptográfico do libsecp256k1 já foi integrado (PR #1765); o suporte no nível da carteira ainda está em aberto (PR #35301 / #35302) |
Duas ressalvas que a tabela comprime. Primeira: “receber” é a linha que importa e a que fica para trás — uma carteira pode deixar você pagar o endereço sp1 de um amigo muito antes de conseguir guardar um endereço seu. Segunda: o modo como uma carteira escaneia é uma decisão de privacidade, não só de desempenho, e é o assunto das duas próximas seções. Antes de tudo, para que as moedas que você vai receber por essa via não carreguem um vínculo de identidade plantado na corretora, veja como comprar Bitcoin sem KYC.
Envio: a metade fácil#
Enviar para um endereço Silent Payment é a metade simples do protocolo, porque quem envia faz todo o trabalho localmente e nunca precisa escanear nada. Numa carteira compatível — a Sparrow é a referência no desktop —, você cola o endereço sp1… do destinatário no campo de envio exatamente como faria com qualquer outro, e a carteira faz a derivação de forma invisível.
Nos bastidores, a sua carteira pega as chaves privadas dos inputs que está gastando, combina com a scan key do destinatário para calcular um segredo compartilhado e usa esse segredo para derivar um endereço de output Taproot de uso único para esse pagamento específico. Como a derivação incorpora os seus inputs, o mesmo endereço de destinatário produz um output on-chain diferente a cada vez que uma pessoa diferente — ou um conjunto diferente das suas moedas — o paga. Quem envia não precisa de nada do destinatário além do endereço publicado: nenhuma ida e volta, nenhuma notificação, nenhuma interação. É por isso que o suporte no lado do envio veio primeiro e hoje é o caso comum. A assimetria é toda a história da próxima seção: o custo que o envio evita é exatamente o custo que o recebimento não tem como evitar.
Recebimento: o custo de escaneamento que ninguém menciona#
Para receber Silent Payments, a sua carteira precisa examinar outputs candidatos ao longo da blockchain e testar cada um contra as suas chaves para achar os pagamentos destinados a você — não há um endereço na cadeia para simplesmente “consultar”. Esse custo de escaneamento é a contrapartida central e pouco comentada da BIP-352, e o modo como a sua carteira o resolve determina tanto a sua comodidade quanto a sua privacidade. Publicar o endereço é de graça. Encontrar o que foi enviado para ele não é.
Se você roda o seu próprio full node — o nó completo da rede Bitcoin —, o escaneamento é um cálculo local sobre os dados dos blocos: exigente, mas privado, porque nada sai da sua máquina. O atrito aparece quando você quer receber num celular ou num notebook sem node. É aí que entra um servidor de indexação. No caso da Sparrow, esse servidor é o Frigate (um servidor Electrum de Silent Payments, atualmente na v1.5.3), e existe uma instância pública em frigate.2140.dev. Você não o “acessa” pelo navegador — ele fala o protocolo Electrum, não HTTP. Na Sparrow, você o encontra em Preferences → Server → Public Server e depois testa a conexão.
Esta é a parte que os tutoriais animados pulam — e é uma questão de privacidade, não um detalhe de rodapé. Para deixar um servidor escanear em seu nome, a sua carteira entrega a esse servidor a sua scan private key e a sua spend public key. Mesmo quando o servidor as mantém apenas na memória, como o Frigate foi projetado para fazer, um indexador malicioso ou comprometido pode usá-las para reconstruir exatamente o retrato que os Silent Payments deveriam negar a um observador: a lista completa dos pagamentos que você recebeu. O guia prático do bennet.org diz isso sem rodeios — um servidor mal-intencionado “poderia montar exatamente o retrato do seu histórico de recebimentos que os Silent Payments deveriam impedir”. Então o enquadramento honesto é um espectro: o seu próprio node é totalmente privado e dá mais trabalho; um indexador público é cômodo e pede que você confie o seu histórico de recebimentos ao operador dele. Escolha com consciência, e não deixe que “eu uso Silent Payments” vire uma falsa sensação de segurança quando o servidor de um estranho é quem faz o seu escaneamento.
Reproduzi o BIP-352 na mão#
O jeito mais rápido de confiar em um protocolo de privacidade é fazê-lo rodar e testar o resultado contra os próprios números da especificação — foi o que fiz, em vez de aceitar as afirmações de olhos fechados. A minha implementação feita do zero reproduz com exatidão os 57 subcasos oficiais dos test vectors — 28/28 no envio, 29/29 no recebimento — e o log completo, junto dos scripts, acompanha este artigo (bip352-verification.txt), para que você mesmo os reproduza. Mais útil do que a contagem de acertos, porém, é ver um único pagamento sendo derivado passo a passo.
Pegue um endereço publicado e acompanhe o cálculo de quem envia. Os valores abaixo são reais, tirados dos próprios test vectors da especificação:
| Passo | O que é | Valor (abreviado) |
|---|---|---|
a | Soma das chaves privadas de input de quem envia | 7ed265a6…56345f86 |
A | Soma das chaves públicas correspondentes | 032562c1…dedc4bee |
input_hash | Hash que vincula as moedas específicas gastas | 5bfe5321…b7ad0668 |
ecdh | Segredo compartilhado que os dois lados derivam de forma independente (input_hash · a · B_scan) | 028158af…3e14d80d |
t₀ | Tweak, hash(ecdh‖0) | f438b401…c2e7eef6 |
| output | B_spend + t₀·G (o endereço on-chain) | 3e9fce73…de46e3c1 |
Agora, a propriedade que faz tudo isso valer a pena. Eu mesma construí um segundo remetente independente — outro material de chaves, uma moeda diferente e fictícia — pagando o mesmo endereço publicado (nenhuma transação é transmitida aqui; como no passo a passo acima, isto é pura derivação). O output dele foi 3f1dd702…879b98ad. Dois pagamentos, um endereço, e on-chain os dois outputs não compartilham nada: nenhum endereço em comum, nenhum vínculo visível. Só quem detém a scan key consegue rodar o cálculo inverso e reconhecer os dois como seus. É essa a garantia de privacidade no recebimento, e você pode vê-la se sustentar no passo a passo em vez de aceitá-la como afirmação. Essa é a contrapartida on-chain do problema de reutilização dissecado em privacidade on-chain do Bitcoin — o mesmo agrupamento que a reutilização entrega de graça a um analista de blockchain é exatamente o que esta derivação retém.
As pegadinhas: multisig, labels e o limite K_max#
Além do custo de escaneamento, três detalhes de implementação decidem se os Silent Payments servem para a sua configuração — e cada um é o tipo de coisa que você quer descobrir antes de depender dele, não depois. São os pontos que as explicações de “como funciona” quase nunca abordam.
- Multisig e transações colaborativas são complicadas. Como quem envia deriva o pagamento a partir das chaves privadas dos inputs que estão sendo gastos, enviar de uma carteira multiassinatura (multisig) ou de um CoinJoin — onde as chaves de assinatura estão repartidas entre partes que não podem simplesmente juntá-las — não combina de forma limpa com a BIP-352. Os Silent Payments resolvem o vínculo de reutilização, não o problema de mistura; se você quer privacidade de valor e de grafo, isso ainda é território das transações colaborativas, tratadas em privacidade on-chain. Trate-os como complementares, não como intercambiáveis.
- Labels são comodidade com uma assimetria. A BIP-352 permite que quem recebe derive variantes rotuladas de um mesmo endereço — úteis para distinguir quais outputs vieram de qual fonte. A informação do rótulo só faz sentido para você, que detém o endereço; ela não fica exposta on-chain. Mas é um registro que você mantém, e uma carteira ou um backup comprometido pode vazá-lo. Comodidade, contada com honestidade.
- Existe um limite de destinatários,
K_max = 2323. A especificação (v1.1.0, março de 2026; atual v1.1.1, abril de 2026) limita quantos outputs um único grupo pode derivar, como defesa contra transações forjadas para explodir o trabalho de escaneamento de quem recebe. Como pessoa física, você nunca vai esbarrar nele. Mas é por isso que a ideia ingênua de “pagar 3.000 outputs para um endereço” não funciona — e isso é de propósito. O limite mostra que os autores do protocolo levaram a sério o ataque de custo de escaneamento.
Uma checagem de realidade ligada a isso: os light clients — as carteiras leves que não guardam a blockchain inteira — são justamente onde as pessoas esperam que o problema do escaneamento já esteja resolvido. Mas, em meados de 2026, não existe nenhuma ferramenta de light client pronta para produção e com confiança minimizada que você simplesmente instale. O daemon de carteira blindbitd foi arquivado em agosto de 2025; só o indexador que o acompanha, o blindbit-oracle, segue em manutenção ativa, e a especificação do light client ainda está em andamento. Existem bibliotecas experimentais como a bdk-sp, mas os próprios autores desaconselham o uso em mainnet. Se um guia dá a entender que receber Silent Payments pelo celular é uma experiência resolvida e sem contrapartidas, ele está adiantado em relação ao software.
Conclusão: você já deveria usar Silent Payments?#
Os Silent Payments estão prontos para uma tarefa específica e valiosa — um endereço público e reutilizável de recebimento que não vaza um vínculo de reutilização — e ainda não estão prontos para ser a sua única ferramenta de privacidade nem o padrão móvel sem atrito. Case a ferramenta com a tarefa e rode o seu próprio node se o histórico de recebimentos for sensível. O objetivo honesto aqui é mais privacidade no recebimento, não anonimato.
| A sua situação | Veredito | Como |
|---|---|---|
| Um endereço público de gorjeta/doação (criador, projeto, pseudônimo) | Encaixa muito bem | Publique um endereço sp1…; escaneie com o seu próprio node, se puder |
| Recebimento do dia a dia, você roda um node | Boa escolha | Sparrow + o seu node; escaneamento totalmente privado |
| Recebimento do dia a dia, sem node, primeiro o celular | Parcial | Funciona via um indexador público — aceite a troca de confiança, ou espere os light clients |
| Você quer privacidade de valor ou do grafo de remetentes | Ferramenta errada | Os Silent Payments não fazem isso; veja transações colaborativas e Lightning |
| Enviar de multisig / CoinJoin | Confira com cuidado | A combinação é complicada; verifique antes o suporte da sua carteira |
Seja qual for o seu caso, a sequência é a de sempre: nomeie o adversário, conserte primeiro os elos baratos e irreversíveis — aquisição sem KYC onde for legal, bons hábitos com as suas moedas, nunca reutilizar um endereço comum — e acrescente os Silent Payments onde eles fecham a brecha específica de um endereço publicado que você quer manter não vinculável. É um avanço de verdade. É também uma ferramenta de recebimento com uma conta de escaneamento a pagar, e saber quem paga essa conta — você, ou um servidor em que você confia — é a diferença entre privacidade e a sensação de privacidade.
Perguntas frequentes#
O que é um endereço de silent payment?#
Um endereço de silent payment é um endereço Bitcoin reutilizável, definido pela BIP-352, que você publica uma única vez — na mainnet, ele começa com sp1. Ao contrário de um endereço comum, cada pagador deriva a partir dele um endereço on-chain de uso único diferente, então os pagamentos feitos a você não carregam nenhum destino compartilhado e vinculável. Ele codifica duas chaves públicas (uma scan key e uma spend key), e não um único script.
Os Silent Payments escondem o valor que eu recebo?#
Não. Os Silent Payments protegem o vínculo de recebimento — a ligação entre pagamentos distintos para a mesma identidade — e nada mais. O valor de cada pagamento continua registrado na blockchain pública, a privacidade dos seus remetentes não é afetada e os registros fora da cadeia (como os de uma corretora com KYC) ficam intactos. Para privacidade de valor, as ferramentas certas são a Lightning ou as transações colaborativas.
Quais carteiras suportam Silent Payments em 2026?#
Em 9 de julho de 2026, a Sparrow suporta tanto o envio (desde a v2.3.0, outubro de 2025) quanto o recebimento (desde a v2.5.0, maio de 2026); a Cake Wallet suporta os dois com escaneamento no próprio aparelho (desde a v4.18.0, fim de maio de 2024). O suporte no nível da carteira do Bitcoin Core ainda não foi integrado, embora o módulo criptográfico subjacente já esteja. Confira sempre o suporte de envio e de recebimento separadamente, e confirme nas notas de versão atuais.
Por que receber um Silent Payment é lento?#
Porque não há um endereço na cadeia para consultar. Para achar os pagamentos enviados a você, a sua carteira precisa escanear os outputs candidatos ao longo dos blocos e testar cada um contra as suas chaves. No seu próprio node, isso é um cálculo local e privado; sem um node, você depende de um servidor de indexação, que é mais rápido, mas traz uma troca de confiança. As ferramentas de light client que eliminam ao mesmo tempo o custo e a confiança ainda estão em andamento.
Os Silent Payments continuam privados se eu usar um servidor público?#
Só em parte. Para escanear em seu nome, um indexador público recebe a sua scan private key e a sua spend public key. Mesmo mantidas apenas na memória, essas chaves permitem que um servidor malicioso ou comprometido reconstrua o histórico completo dos pagamentos que você recebeu — justamente o que os Silent Payments deveriam impedir diante de um observador da cadeia. Rodar o seu próprio node evita isso; um servidor público troca essa privacidade por comodidade.
| # | Fonte | URL | Arquivo |
|---|---|---|---|
| 1 | BIP-352 — Silent Payments (especificação, v1.1.1) | https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki | https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki |
| 2 | Bitcoin Optech — tópico Silent Payments | https://bitcoinops.org/en/topics/silent-payments/ | https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/ |
| 3 | Sparrow Wallet — Releases | https://github.com/sparrowwallet/sparrow/releases | https://web.archive.org/web/*/https://github.com/sparrowwallet/sparrow/releases |
| 4 | Frigate — servidor Electrum de Silent Payments | https://github.com/sparrowwallet/frigate | https://web.archive.org/web/*/https://github.com/sparrowwallet/frigate |
| 5 | bennet.org — guia prático de Silent Payments (a troca de privacidade do servidor) | https://bennet.org/learn/silent-payments-bitcoin-privacy/ | https://web.archive.org/web/*/https://bennet.org/learn/silent-payments-bitcoin-privacy/ |
| 6 | libsecp256k1 — módulo Silent Payments (PR #1765, integrado) | https://github.com/bitcoin-core/secp256k1/pull/1765 | https://web.archive.org/web/*/https://github.com/bitcoin-core/secp256k1/pull/1765 |
Três outros textos deste site se conectam aqui. Os Silent Payments respondem à metade de recebimento do problema de reutilização dissecado em Privacidade on-chain do Bitcoin: como o rastreamento funciona — leia esse texto para ver o que o agrupamento enxerga e o que não enxerga. Como o endereço é tão privado quanto as moedas que você recebe nele, combine esta leitura com Como comprar Bitcoin sem KYC, que conserta a âncora de identidade lá na origem. E como a cadeia nunca é a ameaça inteira, Desanonimização por IA cobre a inferência fora da cadeia que corre em paralelo a tudo isso.


