Vai al contenuto
Financial Context Wiki

Attacco dust

Un attacco dust invia output o asset non richiesti e di basso valore a indirizzi selezionati. Il trasferimento da solo non rivela una chiave privata, ma la spesa o l'interazione successiva può compromettere la privacy o creare un rischio di phishing.

Aggiornato

Solo a scopo didattico; non costituisce consulenza finanziaria. Gli asset non richiesti possono creare rischi per la privacy, di phishing e di transazione, e le azioni on-chain possono essere irreversibili.

Risposta diretta

Un attacco dust invia output o asset non richiesti e di basso valore a indirizzi selezionati. Su una blockchain UTXO, l’attaccante può osservare se un wallet spende in seguito quegli output insieme ad altre monete e usare tale evidenza per raggruppare gli indirizzi. Su una blockchain basata su account, un token o NFT sconosciuto è più spesso spam o un’esca per visitare un sito, approvare un contratto o copiare un indirizzo ingannevole.

Ricevere dust non rivela di per sé una seed phrase, una chiave privata o l’autorità di firma. L’esposizione deriva da ciò che accade dopo: la selezione automatica delle monete può creare un collegamento pubblico tra UTXO, mentre fare clic, firmare, approvare, scambiare o restituire un asset sconosciuto può avere conseguenze per la sicurezza o la privacy.

In Bitcoin Core, “dust” ha un significato più ristretto legato alle policy. GetDustThreshold stima se spendere un output con dustRelayFee costerebbe più del valore dell’output. Il risultato dipende dallo script dell’output e dall’input di spesa previsto, quindi non esiste una quantità universale di monete che definisca il dust su ogni blockchain o per ogni tipo di output.

La policy di inoltro e il consenso sono livelli distinti. Un nodo standard può rifiutarsi di inoltrare un output dust in base alla propria policy locale, anche se un output già incluso in un blocco valido rimane parte del set UTXO e può essere speso se una transazione successiva paga una commissione accettabile.

Come funziona

Le transazioni Bitcoin consumano output precedenti come input e di solito creano un output di resto. Una euristica di proprietà comune degli input considera gli input spesi insieme come indizio di controllo comune. Un attaccante può inviare piccoli output a diversi indirizzi noti o sospetti, monitorare la blockchain e rafforzare un cluster di indirizzi se una transazione successiva seleziona insieme quegli output.

Questa conclusione è probabilistica, non un fatto del protocollo. CoinJoin e altre transazioni collaborative consentono deliberatamente a partecipanti diversi di fornire input a un’unica transazione, mentre i depositari possono creare transazioni per molti clienti. Una transazione può quindi indebolire o invalidare l’euristica; non dimostra il proprietario legale né l’identità reale di ogni input.

Le blockchain basate su account non combinano gli UTXO in questo modo. Chiunque può comunque inviare valuta nativa, trasferire un token, coniare un NFT o fare in modo che un contratto emetta eventi ingannevoli. Un wallet o un indicizzatore può mostrare il risultato, ma nome, simbolo, icona o saldo visualizzato di un token non autenticano il contratto né ne stabiliscono il valore economico. La domanda difensiva è se l’utente abbia autorizzato una chiamata, una firma o un’approvazione successiva.

Segui questa procedura di risposta:

  1. Non fare clic su un URL e non rispondere, restituire, scambiare, bruciare o approvare l’elemento sconosciuto solo per rimuoverlo dalla vista.
  2. Registra la blockchain, l’hash della transazione, l’indice dell’output o il contratto dell’asset, il mittente, l’importo e ciò che mostra il wallet prima di modificare qualsiasi cosa.
  3. Distingui un UTXO da un trasferimento nativo, token, NFT, approvazione o record di solo evento; ciascuno ha uno stato e una procedura di rimedio diversi.
  4. Per un UTXO, controlla la selezione delle monete e usa la funzione di coin control o blocco di un wallet affidabile affinché l’output non venga selezionato automaticamente. In Bitcoin Core, lockunspent può escludere output specifici; la persistenza dipende dall’opzione utilizzata.
  5. In un wallet basato su account, nascondi lo spam quando possibile e verifica la blockchain e l’indirizzo completo del contratto prima di assegnare un prezzo o intraprendere qualsiasi azione.
  6. Se sono già stati usati un sito, una firma o un contratto, esamina i dati esatti firmati e le approvazioni correnti, revoca le autorizzazioni pericolose tramite un’interfaccia affidabile e sposta gli asset rimanenti solo quando la compromissione della chiave o un’autorità ancora attiva lo giustifica.
  7. Ottieni ogni destinazione di pagamento da una fonte autenticata e confronta l’indirizzo completo su un display affidabile; la cronologia delle transazioni non è una rubrica.

Esempio

  • Un utente riceve donazioni pubbliche all’indirizzo A e conserva i risparmi all’indirizzo B. Un osservatore sa già che A appartiene all’utente, ma non sa chi controlla B.
  • Un attaccante invia 600 sats ad A e 600 sats a B. In seguito, il wallet seleziona i 20,000 sats di A, i 50,000 sats di B e i due piccoli output in un’unica transazione che paga 60,000 sats più una commissione.
  • Lo schema degli input condivisi fornisce all’osservatore indizi che A e B possano essere controllati insieme, esponendo la cronologia dei risparmi associata a B. Non dimostra comunque crittograficamente che una sola persona possieda entrambi gli indirizzi.
  • Se il wallet supporta il coin control, l’utente può invece etichettare e bloccare i due output da 600 sats. Congelarli non cancella le transazioni; impedisce la selezione automatica finché il blocco rimane efficace.

Rischi

  • La selezione automatica delle monete collega un indirizzo pubblico a un indirizzo privato di risparmio.
  • Il riutilizzo degli indirizzi facilita il raggruppamento successivo e amplia la cronologia visibile.
  • Restituire il dust conferma che il destinatario può spendere l’output preso di mira.
  • Un utente scambia un cluster probabilistico per un’attribuzione certa dell’identità.
  • Un wallet non dispone di coin control o un blocco temporaneo scompare dopo il riavvio.
  • Una transazione collaborativa o custodial crea un cluster falso positivo.
  • Il nome di un token sconosciuto o l’immagine di un NFT contiene una destinazione di phishing.
  • Un utente concede un’approvazione o firma dati opachi tentando di riscattare, vendere o nascondere spam.
  • Un token contraffatto condivide il nome o il simbolo di un asset riconosciuto.
  • Un indicizzatore attribuisce un prezzo a un contratto sconosciuto e contamina i report di portafoglio o contabili.
  • Una transazione minima inserisce un indirizzo simile che viene poi copiato dalla cronologia.
  • Una risposta affrettata a un incidente sposta fondi e firma un’altra azione dannosa.

Nei sistemi di tesoreria e contabilità, identifica gli asset fungibili tramite blockchain e indirizzo del contratto, non solo tramite ticker. Mantieni gli asset sconosciuti senza prezzo per impostazione predefinita, separa gli eventi osservati dalle variazioni di saldo confermate e richiedi una revisione prima che un nuovo contratto entri nei sistemi di valutazione, instradamento o garanzia.

La sola ricezione passiva non dimostra che un wallet sia compromesso. Procedi in base all’autorità o al comportamento effettivi: una firma, un’approvazione o una chiamata a contratto sconosciuta, un dispositivo modificato, una frase di recupero divulgata o una transazione in uscita non autorizzata sono sostanzialmente diversi da un record in entrata non richiesto.

Errori comuni

  • Ricevere dust sottrae automaticamente il wallet. Un trasferimento in entrata non rivela la chiave privata; la spesa successiva o un’interazione indotta crea l’esposizione rilevante.
  • Ogni piccolo output è sotto la soglia dust di Bitcoin. La soglia è un calcolo della policy di inoltro che varia in base allo script e alle ipotesi sulle commissioni; “attacco dust” è usato anche più in generale per trasferimenti non richiesti di basso valore.
  • Spostare o bruciare un token spam è sempre più sicuro che ignorarlo. Qualsiasi azione può chiamare un contratto non affidabile, creare un’approvazione o rivelare ulteriori collegamenti. Nascondere un elemento è spesso la risposta con meno interazioni.
  • Gli input usati insieme appartengono sempre a una sola persona. La proprietà comune degli input è un’euristica utile, ma CoinJoin e la creazione custodial forniscono chiari controesempi.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...