135 / 736SP

Silent Payments

Um contato de pagamento, uma saída diferente a cada vez

Bob quer publicar dados para receber contribuições sem expor uma lista de todos os recebimentos. Silent Payments permite compartilhar um contato fixo do qual cada pagamento deriva uma saída diferente. A conveniência tem um custo: sua carteira precisa localizar os fundos recebidos na cadeia.

Silent Payments permite receber bitcoin por um identificador reutilizável sem que todos os pagamentos cheguem ao mesmo endereço rastreável publicamente. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. A carteira do remetente calcula um novo destino para o pagamento, e a do destinatário o reconhece depois na cadeia. A BIP352 descreve o procedimento. O destinatário não precisa estar conectado nem fornecer um novo endereço antes de cada pagamento.

Se Bob publicar um endereço Bitcoin comum, qualquer pessoa poderá acompanhar seus recebimentos em um explorador. Um explorador de blocos é um aplicativo para consultar transações e blocos de uma determinada rede. Fornecer um endereço novo a cada pessoa é melhor, mas alguém precisa distribuí-los. Silent Payments resolve esse problema: Bob publica dados fixos e Alice cria com eles uma saída específica para o pagamento, um registro do valor e da condição para gastá-lo depois. O contato público não se repete como o mesmo endereço de recebimento na cadeia. [1] [3] [9] [7]

Um endereço Silent Payments inclui uma scan key pública e uma spend key pública. Uma chave privada é um valor numérico secreto; a chave pública correspondente pode ser compartilhada com outras pessoas. Os nomes indicam as funções: a scan key está ligada à busca de pagamentos e a spend key ao gasto. As chaves privadas correspondentes ficam com Bob. Na mainnet, a rede principal do Bitcoin, começa com sp1 e usa Bech32m. Não é um endereço Taproot comum iniciado por bc1p nem um backup da carteira. O par público permite a um remetente compatível calcular o destino, mas não concede poder de gasto nem revela uma lista dos recebimentos de Bob. [1] [5] [9]

Para pagar a Bob, a carteira de Alice seleciona valores recebidos anteriormente. As referências a esses valores formam as entradas da nova transação. O cálculo do destino usa as chaves das entradas que atendem às regras da BIP352; nem todo tipo de entrada serve. Alice combina as chaves privadas dessas entradas com a scan key pública de Bob usando ECDH. Esse método criptográfico permite que os dois lados obtenham o mesmo segredo de forma independente, sem trocar chaves privadas. A partir desse segredo e da vinculação às entradas específicas, a carteira ajusta a spend key pública de Bob e obtém a chave da nova saída. A vinculação impede a repetição do destino quando uma chave de entrada é reutilizada. Se Alice usar RBF, ou seja, substituir uma transação ainda não confirmada, por exemplo para aumentar a taxa, e mudar as entradas, a carteira deverá calcular o destino novamente. Não pode apenas reaproveitar o resultado anterior. [1] [4]

A carteira de Bob examina transações elegíveis e calcula possíveis saídas com sua scan key privada e os dados públicos das entradas. Quando encontra uma correspondência, registra a saída entre seus fundos. Na cadeia, é uma saída Taproot sem aviso especial. Bob não precisa estar conectado durante o envio nem responder antes a Alice, mas sua carteira deve processar depois os dados necessários. [1] [6]

A scan key encontra pagamentos; a spend key, junto com os dados derivados, permite gastá-los. A spend key privada pode ficar separada do scanner conectado. O vazamento da scan key privada, por si só, não permite gastar os fundos, mas pode revelar recebimentos em conjunto com dados públicos. Entregá-la a um servidor de escaneamento de terceiros afeta, portanto, a privacidade. A seed e a spend key privada não são enviadas a esse servidor. [1]

Silent Payments não exige uma transação especial de notificação, mas cálculos e transferência de dados não são gratuitos. O destinatário examina transações elegíveis e realiza os cálculos criptográficos descritos. No celular, importam a indexação, a fonte dos dados e o tempo desde a última varredura. Uma lista comum de endereços não basta. Um nó é um programa que verifica transações e blocos e se comunica com outros participantes da rede. Um nó próprio e um provedor externo têm exigências e efeitos diferentes sobre privacidade e disponibilidade. [1] [2] [8]

Bob pode usar labels, variantes de pagamento derivadas, por exemplo para projetos diferentes. Não precisa realizar uma varredura totalmente independente para cada variante. Porém, as variantes públicas compartilham a scan key, permitindo reconhecer o proprietário comum. O rótulo ajuda Bob a classificar um recebimento; não cria uma identidade anônima separada. O rótulo especial de troco identifica o restante de um pagamento feito pelo próprio Bob. Se ele gastar um valor recebido anteriormente que exceda o pagamento mais a taxa, o restante volta para sua carteira. Não se trata de reembolso de um comerciante. A BIP352 reserva o rótulo m = 0 para esse fim. A carteira sempre o procura durante a recuperação e não deve publicá-lo como contato para pagamentos de outras pessoas. [1] [4]

Imagine que Bob perca o celular, mas ainda tenha o backup. A seed é o valor secreto inicial do qual a carteira deriva suas chaves; o usuário costuma guardá-lo por meio de uma Seed Phrase, palavras de recuperação em uma ordem definida. Essas palavras, sozinhas, não significam que qualquer aplicativo encontre os Silent Payments. Ele precisa admitir a mesma derivação de chaves e saber localizar esses pagamentos. Guardar as labels usadas e a data de início de uso da carteira facilita a recuperação. Para recuperar os fundos atuais, é possível examinar os dados necessários das transações com UTXO restantes: valores recebidos individualmente que ainda não foram gastos. Recuperar todo o histórico exige uma varredura mais ampla da cadeia. Uma tela vazia antes do fim da varredura, portanto, não significa necessariamente que o dinheiro foi perdido. [1]

Silent Payments reduz vínculos causados pela reutilização de endereços, mas não esconde valores, momento de confirmação ou histórico das entradas gastas. Alice conhece seu pagamento a Bob, e um pedido pode conter dados pessoais. Se Bob depois juntar vários UTXO em uma transação, pode revelar a relação entre eles. Silent Payments não é CoinJoin, e combiná-los não é automaticamente seguro: a BIP352 aponta a falta de prova formal para remetentes independentes que colaboram. [1] [3]

A BIP352 lista josibake, Ruben Somsen e Sebastian Falbesoner como autores; recebeu seu número em 2023. Na verificação de 17 de outubro de 2026, seu status é Complete. Isso não significa suporte em todas as carteiras: envio, recebimento, varredura e recuperação precisam ser conferidos separadamente. O protocolo usa Taproot existente e não exige um novo Soft Fork, isto é, um endurecimento das regras de validade adotado pela rede. Aplicativos antigos sem suporte não processam corretamente um endereço sp1. [1] [2]

Para ter uma visão mais completa, leia este verbete junto com Privacidade no Bitcoin, Pseudonimidade, Taproot, CoinJoin, Replace-by-Fee (RBF), UTXO. Também há referências a este verbete em Privacidade no Bitcoin, Transaction Labeling.

DOC · 001BIP 352 — Silent PaymentsEspecificação DOC · 002Bitcoin Optech — Silent paymentsDocumentação DOC · 003Silent Payments referenceFonte primária DOC · 004BIP352 — reference implementationFonte primária DOC · 005BIP350 — Bech32mEspecificação DOC · 006BIP341 — TaprootEspecificação DOC · 007Bitcoin Developer Guide — WalletsDocumentação DOC · 008Bitcoin Developer Guide — Block ChainDocumentação DOC · 009Bitcoin Developer Reference — TransactionsDocumentação
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento