Saltar al contenido
Financial Context Wiki

Ataque de polvo

Un ataque de polvo envía salidas o activos no solicitados de poco valor a direcciones seleccionadas. La transferencia por sí sola no revela una clave privada, pero el gasto o la interacción posterior puede exponer la privacidad o crear riesgo de phishing.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Los activos no solicitados pueden crear riesgos de privacidad, phishing y transacción, y las acciones en cadena pueden ser irreversibles.

Respuesta directa

Un ataque de polvo envía salidas o activos no solicitados de poco valor a direcciones seleccionadas. En una cadena UTXO, el atacante puede observar si una billetera gasta después esas salidas junto con otras monedas y usar esa evidencia para agrupar direcciones. En una cadena basada en cuentas, un token o NFT desconocido suele ser más bien spam o un señuelo para visitar un sitio, aprobar un contrato o copiar una dirección engañosa.

Recibir polvo no revela por sí solo una frase semilla, una clave privada ni la facultad de firmar. La exposición surge de lo que ocurre después: la selección automática de monedas puede crear un vínculo público entre UTXO, mientras que hacer clic, firmar, aprobar, intercambiar o devolver un activo desconocido puede tener consecuencias para la seguridad o la privacidad.

En Bitcoin Core, “polvo” tiene un significado más específico dentro de la política. GetDustThreshold estima si gastar una salida con dustRelayFee costaría más de lo que vale la salida. El resultado depende del script de salida y de la entrada de gasto prevista, por lo que no existe una cantidad universal de monedas que defina el polvo en todas las cadenas o para todos los tipos de salida.

La política de retransmisión y el consenso son capas distintas. Un nodo estándar puede negarse a retransmitir una salida de polvo según su política local, aunque una salida ya incluida en un bloque válido siga formando parte del conjunto UTXO y pueda gastarse si una transacción posterior paga una comisión aceptable.

Cómo funciona

Las transacciones de Bitcoin consumen salidas anteriores como entradas y normalmente crean una salida de cambio. Una heurística de propiedad común de entradas considera que las entradas gastadas juntas son indicio de un control común. Un atacante puede enviar pequeñas salidas a varias direcciones conocidas o sospechosas, vigilar la cadena y reforzar un grupo de direcciones si una transacción posterior selecciona juntas esas salidas.

Esa conclusión es probabilística, no un hecho del protocolo. CoinJoin y otras transacciones colaborativas permiten deliberadamente que distintos participantes aporten entradas a una misma transacción, y los custodios pueden construir transacciones para muchos clientes. Por tanto, una transacción puede debilitar o invalidar la heurística; no demuestra quién es el propietario legal ni la identidad real de cada entrada.

Las cadenas basadas en cuentas no combinan UTXO de esta manera. Aun así, cualquiera puede enviar moneda nativa, transferir un token, acuñar un NFT o hacer que un contrato emita eventos engañosos. Una billetera o un indexador puede mostrar el resultado, pero el nombre, símbolo, icono o saldo mostrado de un token no autentica el contrato ni establece su valor económico. La cuestión defensiva es si el usuario autorizó alguna llamada, firma o asignación posterior.

Utilice este procedimiento de respuesta:

  1. No haga clic en una URL, responda, devuelva, intercambie, queme ni apruebe el elemento desconocido solo para quitarlo de la vista.
  2. Registre la cadena, el hash de la transacción, el índice de salida o el contrato del activo, el remitente, el importe y lo que muestra la billetera antes de cambiar nada.
  3. Distinga entre un UTXO, una transferencia nativa, un token, un NFT, una aprobación o un registro de solo evento; cada uno tiene un estado y una remediación diferentes.
  4. Para un UTXO, revise la selección de monedas y utilice la función de control o bloqueo de monedas de una billetera de confianza para que la salida no se seleccione automáticamente. En Bitcoin Core, lockunspent puede excluir salidas concretas; la persistencia depende de la opción utilizada.
  5. En una billetera basada en cuentas, oculte el spam cuando sea posible y verifique la cadena y la dirección completa del contrato antes de asignarle un precio o realizar cualquier acción.
  6. Si ya se utilizó un sitio, una firma o un contrato, examine los datos exactos firmados y las asignaciones actuales, revoque los permisos peligrosos mediante una interfaz de confianza y mueva los activos restantes solo cuando lo justifique la exposición de la clave o una autorización que siga vigente.
  7. Obtenga cada dirección de pago de una fuente autenticada y compare la dirección completa en una pantalla de confianza; el historial de transacciones no es una libreta de direcciones.

Ejemplo

  • Un usuario recibe donaciones públicas en la dirección A y guarda sus ahorros en la dirección B. Un observador ya sabe que A pertenece al usuario, pero desconoce quién controla B.
  • Un atacante envía 600 sats a A y 600 sats a B. Más tarde, la billetera selecciona los 20,000 sats de A, los 50,000 sats de B y ambas salidas pequeñas en una sola transacción que paga 60,000 sats más una comisión.
  • El patrón de entradas compartidas proporciona al observador indicios de que A y B podrían controlarse conjuntamente, lo que expone el historial de ahorros asociado con B. Aun así, no demuestra criptográficamente que una sola persona sea propietaria de ambas direcciones.
  • Si la billetera admite control de monedas, el usuario puede etiquetar y bloquear en su lugar las dos salidas de 600 sats. Congelarlas no borra las transacciones; impide la selección automática mientras el bloqueo siga vigente.

Riesgos

  • La selección automática de monedas vincula una dirección pública con una dirección privada de ahorros.
  • Reutilizar direcciones facilita la agrupación posterior y amplía el historial visible.
  • Devolver el polvo confirma que el destinatario puede gastar la salida seleccionada.
  • Un usuario confunde un grupo probabilístico con una atribución de identidad cierta.
  • Una billetera carece de control de monedas o un bloqueo temporal desaparece tras reiniciarla.
  • Una transacción colaborativa o de custodia genera un grupo falso positivo.
  • El nombre de un token desconocido o la imagen de un NFT contiene un destino de phishing.
  • Un usuario concede una asignación o firma datos opacos al intentar reclamar, vender u ocultar spam.
  • Un token falsificado comparte el nombre o el símbolo de un activo reconocido.
  • Un indexador asigna precio a un contrato desconocido y contamina los informes de cartera o contabilidad.
  • Una transacción diminuta introduce una dirección parecida que después se copia del historial.
  • Una respuesta apresurada a un incidente mueve fondos y firma otra acción maliciosa.

En los sistemas de tesorería y contabilidad, identifique los activos fungibles por cadena y dirección del contrato, no solo por el ticker. Mantenga los activos desconocidos sin precio de forma predeterminada, separe los eventos observados de los cambios de saldo confirmados y exija una revisión antes de que un contrato nuevo entre en los sistemas de valoración, enrutamiento o garantías.

La recepción pasiva por sí sola no demuestra que una billetera esté comprometida. Escale según la autoridad o el comportamiento reales: una firma desconocida, una asignación, una llamada a un contrato, un dispositivo cambiado, una frase de recuperación filtrada o una transacción saliente no autorizada son hechos sustancialmente distintos de un registro entrante no solicitado.

Errores comunes

  • Recibir polvo roba automáticamente la billetera. Una transferencia entrante no revela la clave privada; el gasto posterior o una interacción inducida crea la exposición relevante.
  • Todas las salidas pequeñas están por debajo del umbral de polvo de Bitcoin. El umbral es un cálculo de la política de retransmisión que varía según el script y las hipótesis de comisión; “ataque de polvo” también se utiliza de manera más amplia para transferencias no solicitadas de poco valor.
  • Mover o quemar un token de spam siempre es más seguro que ignorarlo. Cualquier acción puede llamar a un contrato no fiable, crear una asignación o revelar más vínculos. Ocultar un elemento suele ser la respuesta con menos interacción.
  • Las entradas utilizadas juntas siempre pertenecen a una sola persona. La propiedad común de entradas es una heurística útil, pero CoinJoin y la construcción de transacciones por custodios ofrecen contraejemplos claros.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...