---
title: "Ataque de poeira"
description: "Um ataque de poeira envia saídas ou ativos não solicitados e de baixo valor a endereços selecionados. A transferência, por si só, não revela uma chave privada, mas o gasto ou a interação posterior pode expor a privacidade ou criar risco de phishing."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Ataque de poeira
> Somente para fins educacionais; não constitui aconselhamento de investimento. Ativos não solicitados podem criar riscos de privacidade, phishing e transação, e ações on-chain podem ser irreversíveis.
## Resposta direta
Um ataque de poeira envia saídas ou ativos não solicitados e de baixo valor a endereços selecionados. Em uma cadeia UTXO, o invasor pode observar se uma carteira depois gasta essas saídas junto com outras moedas e usar essa evidência para agrupar endereços. Em uma cadeia baseada em contas, um token ou NFT desconhecido costuma ser spam ou uma isca para visitar um site, aprovar um contrato ou copiar um endereço enganoso.
Receber poeira não revela, por si só, uma frase-semente, uma chave privada nem a autoridade para assinar. A exposição decorre do que acontece depois: a seleção automática de moedas pode criar um vínculo público entre UTXOs, enquanto clicar, assinar, aprovar, trocar ou devolver um ativo desconhecido pode gerar consequências de segurança ou privacidade.
"Poeira" tem um significado mais restrito na política do Bitcoin Core. `GetDustThreshold` estima se gastar uma saída com `dustRelayFee` custaria mais do que o valor da saída. O resultado depende do script de saída e da entrada de gasto prevista, portanto não existe uma quantidade universal de moedas que defina poeira em todas as cadeias ou para todo tipo de saída.
Política de retransmissão e consenso são camadas diferentes. Um nó padrão pode se recusar a retransmitir uma saída de poeira conforme sua política local, embora uma saída já incluída em um bloco válido continue fazendo parte do conjunto UTXO e possa ser gasta se uma transação posterior pagar uma taxa aceitável.
## Como funciona
As transações de Bitcoin consomem saídas anteriores como entradas e normalmente criam uma saída de troco. Uma heurística de propriedade comum das entradas considera entradas gastas juntas como evidência de controle comum. Um invasor pode enviar pequenas saídas a vários endereços conhecidos ou suspeitos, monitorar a cadeia e reforçar um agrupamento de endereços caso uma transação posterior selecione essas saídas em conjunto.
Essa conclusão é probabilística, não um fato do protocolo. CoinJoin e outras transações colaborativas permitem deliberadamente que diferentes participantes forneçam entradas para uma só transação, e custodiantes podem construir transações para muitos clientes. Portanto, uma transação pode enfraquecer ou invalidar a heurística; ela não comprova o proprietário legal nem a identidade real de cada entrada.
Cadeias baseadas em contas não combinam UTXOs dessa forma. Ainda assim, qualquer pessoa pode enviar moeda nativa, transferir um token, cunhar um NFT ou fazer um contrato emitir eventos enganosos. Uma carteira ou um indexador pode exibir o resultado, mas o nome, símbolo, ícone ou saldo exibido de um token não autentica o contrato nem estabelece valor econômico. A questão defensiva é se o usuário autorizou alguma chamada, assinatura ou permissão posterior.
Use este fluxo de resposta:
1. Não clique em uma URL, responda, devolva, troque, queime nem aprove o item desconhecido apenas para removê-lo da visualização.
2. Registre a cadeia, o hash da transação, o índice da saída ou o contrato do ativo, o remetente, o valor e a exibição da carteira antes de alterar qualquer coisa.
3. Diferencie um UTXO de uma transferência nativa, token, NFT, aprovação ou registro somente de evento; cada um tem estado e remediação diferentes.
4. Para um UTXO, examine a seleção de moedas e use o recurso de controle ou bloqueio de moedas de uma carteira confiável para que a saída não seja selecionada automaticamente. No Bitcoin Core, `lockunspent` pode excluir saídas específicas; a persistência depende da opção utilizada.
5. Em uma carteira baseada em contas, oculte spam quando possível e verifique a cadeia e o endereço completo do contrato antes de atribuir um preço ou tomar qualquer medida.
6. Se um site, assinatura ou contrato já tiver sido usado, examine os dados exatos assinados e as permissões atuais, revogue permissões perigosas por uma interface confiável e mova os ativos restantes somente quando o comprometimento da chave ou uma autoridade ainda vigente justificar a medida.
7. Obtenha cada endereço de pagamento de uma fonte autenticada e compare o endereço completo em uma tela confiável; o histórico de transações não é um catálogo de endereços.
## Exemplo
- Um usuário recebe doações públicas no endereço A e guarda economias no endereço B. Um observador já sabe que A pertence ao usuário, mas não sabe quem controla B.
- Um invasor envia `600 sats` para A e `600 sats` para B. Mais tarde, a carteira seleciona os `20,000 sats` de A, os `50,000 sats` de B e ambas as pequenas saídas em uma única transação que paga `60,000 sats` mais uma taxa.
- O padrão de entradas compartilhadas fornece ao observador evidência de que A e B talvez sejam controlados em conjunto, expondo o histórico de economias associado a B. Ainda assim, não prova criptograficamente que uma pessoa seja dona dos dois endereços.
- Se a carteira oferecer controle de moedas, o usuário pode rotular e bloquear as duas saídas de `600 sats`. Congelá-las não apaga as transações; impede a seleção automática enquanto o bloqueio permanecer efetivo.
## Riscos
- A seleção automática de moedas vincula um endereço público a um endereço privado de economias.
- Reutilizar endereços facilita agrupamentos posteriores e amplia o histórico visível.
- Devolver a poeira confirma que o destinatário consegue gastar a saída visada.
- Um usuário confunde um agrupamento probabilístico com uma atribuição de identidade certa.
- Uma carteira não oferece controle de moedas ou um bloqueio temporário desaparece após a reinicialização.
- Uma transação colaborativa ou custodial cria um agrupamento falso positivo.
- O nome de um token desconhecido ou a imagem de um NFT contém um destino de phishing.
- Um usuário concede uma permissão ou assina dados opacos ao tentar reivindicar, vender ou ocultar spam.
- Um token falsificado compartilha o nome ou o símbolo de um ativo reconhecido.
- Um indexador atribui preço a um contrato desconhecido e contamina relatórios de portfólio ou contabilidade.
- Uma transação minúscula insere um endereço parecido que depois é copiado do histórico.
- Uma resposta apressada a um incidente movimenta fundos e assina outra ação maliciosa.
Para sistemas de tesouraria e contabilidade, identifique ativos fungíveis pela cadeia e pelo endereço do contrato, não apenas pelo ticker. Mantenha ativos desconhecidos sem preço por padrão, separe eventos observados de alterações de saldo confirmadas e exija revisão antes que um novo contrato entre em sistemas de avaliação, roteamento ou garantias.
O recebimento passivo, por si só, não é evidência de que uma carteira esteja comprometida. Escalone conforme a autoridade ou o comportamento real: uma assinatura desconhecida, uma permissão, uma chamada de contrato, um dispositivo alterado, uma frase de recuperação vazada ou uma transação de saída não autorizada são materialmente diferentes de um registro de entrada não solicitado.
## Erros comuns
- **Receber poeira rouba automaticamente a carteira.** Uma transferência recebida não revela a chave privada; o gasto posterior ou uma interação induzida cria a exposição relevante.
- **Toda saída pequena está abaixo do limite de poeira do Bitcoin.** O limite é um cálculo da política de retransmissão que varia conforme o script e as premissas de taxa; "ataque de poeira" também é usado de forma mais ampla para transferências não solicitadas de baixo valor.
- **Mover ou queimar um token de spam é sempre mais seguro do que ignorá-lo.** Qualquer ação pode chamar um contrato não confiável, criar uma permissão ou revelar mais vínculos. Ocultar um item costuma ser a resposta com menos interação.
- **Entradas usadas juntas sempre pertencem a uma pessoa.** A propriedade comum das entradas é uma heurística útil, mas CoinJoin e a construção custodial oferecem contraexemplos claros.
## Tópicos relacionados
- [Envenenamento de endereço](/pt-br/crypto/address-poisoning/)
- [Moeda de privacidade](/pt-br/crypto/privacy-coin/)
- [Carteira de criptomoedas](/pt-br/crypto/wallet/)
- [Token encapsulado](/pt-br/crypto/wrapped-token/)
## Fontes
- [Bitcoin Core dust policy](https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp) - Bitcoin Core (acessado em: 2026-08-20)
- [Transactions](https://developer.bitcoin.org/devguide/transactions.html) - Bitcoin Developer Guide (acessado em: 2026-08-20)
- [A Fistful of Bitcoins: Characterizing Payments Among Men with No Names](https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf) - Internet Measurement Conference (acessado em: 2026-08-20)
- [Contracts: CoinJoin](https://developer.bitcoin.org/devguide/contracts.html#coinjoin) - Bitcoin Developer Guide (acessado em: 2026-08-20)
- [lockunspent (30.0.0 RPC)](https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/lockunspent/) - Bitcoin Core (acessado em: 2026-08-20)
- [Some tricks used by scam tokens and how to detect them](https://ethereum.org/developers/tutorials/scam-token-tricks/) - ethereum.org (acessado em: 2026-08-20)
- [Ethereum security and scam prevention](https://ethereum.org/security/) - ethereum.org (acessado em: 2026-08-20)
Source: https://wiki.fcontext.com/pt-br/crypto/dust-attack/index.mdx