A fondo · Custodia y privacidad · 15 min
Úsala una sola vez: por qué reutilizar una dirección de Bitcoin es peligroso
Uno de cada cuatro bitcoins está en una dirección desde la que ya se gastó y que después volvió a recibir un pago. Qué revela una dirección reutilizada, a quién, por qué sigue pasando dieciocho años después de que el whitepaper dijera que no se hiciera, y cómo dejar de hacerlo sin prisas.
Traducción hecha con ayuda de IA, pendiente de revisión humana. Lee el original (en inglés).
Adónde vas: Una dirección de Bitcoin es un comprobante de pago de un solo uso, no un número de cuenta. Pagarle dos veces le entrega tu historial a cualquiera que esté mirando, pone todas las monedas de esa dirección detrás de una sola clave y, una vez que esa clave ha firmado, deja las monedas al descubierto. Este capítulo muestra qué revela una sola reutilización, por qué uno de cada cuatro bitcoins está estacionado así, cómo dejar de hacerlo y qué hacer con calma si ya lo hiciste.
Modo búnker
El 7 de octubre de 2026 Justin Drake, investigador de Ethereum, le pidió a la industria blockchain "calmly begin planning" (empezar a planear con calma) el "bunker mode" (modo búnker): "a controlled mass migration of assets to fresh addresses, i.e. addresses whose pubkeys remain hidden behind a hash" (una migración masiva y controlada de activos a direcciones nuevas, es decir, direcciones cuyas claves públicas siguen ocultas detrás de un hash). Quienes tienen bitcoin, "starting with large and sophisticated ones, should consider moving the bulk of their funds to addresses that have never signed a transaction" (empezando por los grandes y sofisticados, deberían considerar mover el grueso de sus fondos a direcciones que nunca hayan firmado una transacción), y "when they do sign one, they should also move remaining funds to a new address" (cuando firmen una, deberían mover también los fondos restantes a una dirección nueva). Y después: "Don't rush" (no te apresures).
Cuatro horas más tarde Juan Galt, reportero de Bitcoin Magazine, respondió: "Only an Ethereum developer would think that not reusing addresses is 'Bunker mode'" (solo a un desarrollador de Ethereum se le ocurriría que no reutilizar direcciones es "modo búnker").
El consejo de Drake es el del whitepaper, sección 10, 2008: "a new key pair should be used for each transaction to keep them from being linked to a common owner" (debería usarse un par de claves nuevo para cada transacción, para que no se vinculen a un dueño común). Y sin embargo, según el conteo de ChainQuery (un sitio hermano cuyo nodo produjo estas cifras), 5,172,596 BTC, más o menos una moneda de cada cuatro (el 25.7% de la oferta), están en una dirección con hash desde la que ya se gastó y que después volvió a recibir un pago (instantánea del 11 de octubre de 2026, bloque 970,878). Eso es la reutilización de direcciones en el sentido de este capítulo; llamemos a esas monedas expuestas por reutilización. Dos tipos de dirección en uso hoy, la P2PK de la era de Satoshi y Taproot, muestran su clave desde el día en que se crean (la multisig sin hash, o bare multisig, también, y casi no guarda nada); llamémoslas siempre expuestas. Súmalas y son 7,105,243 BTC, alrededor del 35%.
Dieciséis días antes de Drake, en el foro de desarrollo Delving Bitcoin, Pieter Wuille, quien abrió ahí la discusión sobre un tipo de salida poscuántico, escribió "Address reuse is entrenched" (la reutilización de direcciones está arraigada). Bitcoin Optech, el boletín de los desarrolladores, lo resumió el 2 de octubre: un tipo de salida propuesto dejaría que cada dueño decidiera cuándo dejar de depender de las claves de hoy, "but Wuille believes address reuse and public key sharing are too entrenched for most users to benefit" (pero Wuille cree que la reutilización de direcciones y el compartir claves públicas están demasiado arraigados como para que la mayoría de los usuarios se beneficie). Quienes construyen la defensa cuántica de Bitcoin dejaron de dar por hecho que vas a portarte bien. Este capítulo trata de mantener tus monedas en los dos tercios cuyas claves siguen ocultas, el grupo que no dieron por perdido.
Ninguna computadora que exista puede derivar una clave privada a partir de una clave pública; las recuperaciones de claves de 2013 que se describen más abajo explotaron software de firma defectuoso, no las matemáticas detrás de ECDSA, el esquema de firma de Bitcoin. Yehuda Lindell, criptógrafo de Coinbase, respondió que hay "no evidence whatsoever pointing to a break of decades old hardness assumptions like elliptic curve cryptography" (ninguna evidencia en absoluto que apunte a una ruptura de supuestos de dificultad con décadas de antigüedad, como la criptografía de curva elíptica). Expuesta en este capítulo quiere decir que la clave pública está en la cadena, no que algo haya sido robado, y no existe ninguna computadora cuántica criptográficamente relevante. El consejo ya era correcto en 2013, por razones que no tienen nada que ver con la IA ni con las computadoras cuánticas (la historia de Android, más abajo).
Una dirección no es una clave
Una clave pública es un número que tu billetera deriva de tu clave privada (técnicamente, un punto sobre una curva elíptica llamada secp256k1). Una dirección no es eso: en la mayoría de los tipos codifica un hash de la clave (o de un script), y la clave pública se queda oculta hasta que gastas; entonces entra en la transacción para que todo el mundo la compruebe, mientras tu clave privada nunca sale de tu billetera. Taproot es la excepción; una dirección bc1p es la propia clave x-only ajustada (tweaked), pública desde su creación.
Un gasto lleva una firma y la clave que la verifica, en un campo público: el scriptSig en las transacciones antiguas, el testigo (witness) en las de SegWit. Hasta entonces, un hash ocupa el lugar de la clave: HASH160 (20 bytes) para las direcciones de clave y para las direcciones de script que empiezan con 3..., SHA256 (32 bytes) para las direcciones de script bc1q, como muestra la tercera columna de la tabla.
| Script | Prefijo | Clave visible al crearla | Clave visible tras el primer gasto | Depósitos posteriores expuestos |
|---|---|---|---|---|
| P2PK | hex en bruto | sí | sí | siempre |
| P2PKH | 1... | no (HASH160) | sí, en el scriptSig | para siempre |
| P2SH | 3... | no (hash de un script) | sí, si el gasto revela una clave (el script de canje de una multisig, o el testigo en SegWit anidado) | para siempre |
| P2WPKH | bc1q (42 caracteres) | no (HASH160) | sí, en el testigo | para siempre |
| P2WSH | bc1q (62 caracteres) | no (SHA256 de un script) | sí, si el script del testigo contiene claves | para siempre |
| P2TR | bc1p | sí (clave x-only ajustada) | no aplica | siempre |
Una misma clave privada también puede escribirse como una dirección 1..., una 3... y una bc1q; revélala a través de cualquiera de las tres y las tres quedan expuestas, así que cambiar de tipo de dirección no es pasar a una clave nueva.
El BIP 341, la especificación de Taproot, plantea la objeción más fuerte a esconder las claves detrás de hashes, en una nota al pie: "While the usage of public key hashes is often said to protect against ECDLP breaks or quantum computers, this protection is very weak at best: transactions are not protected while being confirmed, and a very large portion of the currency's supply is not under such protection regardless" (aunque suele decirse que usar hashes de claves públicas protege contra una ruptura del ECDLP o contra las computadoras cuánticas, esa protección es, en el mejor de los casos, muy débil: las transacciones no están protegidas mientras se confirman, y de todos modos una porción muy grande de la oferta de la moneda no está bajo esa protección). (ECDLP es el problema matemático sobre el que descansa una clave). Las dos mitades son ciertas, y ninguna es un argumento a favor de la reutilización: la primera es la ventana de diez minutos que viene más abajo; la segunda es el montón de monedas reutilizadas del que trata este capítulo. Nuestro capítulo sobre Taproot (en inglés) le concede a la nota sus hechos, y este también; nos separamos de ella en la conclusión: vale la pena conservar los dos tercios de la oferta que están detrás de un hash, y el montón de la reutilización es la parte que un usuario puede achicar.
A qué apuntaba Drake
La razón de Drake era la IA, no lo cuántico. Su "ECDSA breaks before qday ... in months not years" (ECDSA se rompe antes del qday ... en meses, no en años; qday: el día en que una computadora cuántica pueda romper una clave) venía etiquetado como "IMO" (en mi opinión) y "worst case" (el peor de los casos), y su evidencia eran matemáticas nuevas hechas por IA. El 6 de octubre OpenAI publicó un catálogo de manuscritos escritos por IA, 719 después de que tres se retiraran al día siguiente; su índice no lista ningún resultado criptoanalítico clásico, y Scott Aaronson, repitiendo lo que "several people have pointed out" (varias personas han señalado), dijo que la criptografía estaba "extremely conspicuous by its absence" (brillaba por su ausencia). El único supuesto de dificultad roto que Drake citó, un algoritmo más rápido de lo esperado para un problema de libro de texto llamado 3SUM, es un artículo aparte, del 5 de octubre, de Josh Alman y Virginia Vassilevska Williams.
Cerca del final de su resumen (abstract): "Claude, an AI model developed by Anthropic, discovered the algorithm" (Claude, un modelo de IA desarrollado por Anthropic, descubrió el algoritmo); su sección de metodología es más específica: un modelo de investigación interno de Anthropic lo encontró mientras sondeaba un supuesto de dificultad criptográfica, y los autores lo redactaron y se hacen responsables de él. Este sitio se produce con Claude, el modelo público. El resultado no dice nada sobre curvas elípticas. Sus resultados principales están verificados por máquina en Lean 4; lo que nadie ha revisado es "months not years" (meses, no años). Lindell, Charles Guillemet, de Ledger, y Adam Back, de Blockstream, lo rechazaron; Matthew Green, criptógrafo de Johns Hopkins, dio probabilidades en lugar de eso: "a 1% chance" (una probabilidad del 1%) de que la criptografía de clave pública falle por completo y "a 15% chance" (una del 15%) de perder la confianza en "our existing public-key encryption algorithms" (nuestros algoritmos actuales de cifrado de clave pública), "based on vibes, but nobody has better ones" (basadas en sensaciones, pero nadie tiene mejores). Nada de eso cambia la solución, que ya está en tu billetera.
El gasto es la revelación: minutos frente a años
La clave de quien usa direcciones nuevas se hace pública al transmitir la transacción y se queda en la cadena para siempre, pero las monedas que hay detrás se van en cuanto el gasto se confirma, unos diez minutos con una comisión competitiva, más si tiene que esperar; a partir de ahí la clave ya no custodia nada. Una dirección reutilizada mantiene cada depósito posterior detrás de una clave ya pública durante todo el tiempo que las monedas se quedan ahí. El BIP 360, una propuesta en borrador de direcciones a prueba de computación cuántica, llama a esto exposición breve y exposición prolongada, y enuncia la tesis: "Protection from long exposure quantum attacks does not depend on the activation of post-quantum signatures in Bitcoin, but requires that users do not expose their public keys to attackers via public key reuse or other unsafe practices" (la protección contra los ataques cuánticos de exposición prolongada no depende de que se activen firmas poscuánticas en Bitcoin, sino de que los usuarios no expongan sus claves públicas a los atacantes mediante la reutilización de claves públicas u otras prácticas inseguras).
La división por edad hace de esto un asunto de los usuarios de hoy. ChainQuery lista las monedas expuestas por reutilización según cuánto hace que se reveló la clave: alrededor de 1.48 millones de BTC con cinco años o más, 2.62 millones con entre uno y cinco años y 1.07 millones con menos de un año; las monedas siempre expuestas de más de cinco años son la fila P2PK de la era de Satoshi, unos 1.71 millones de BTC. Así que las monedas expuestas por reutilización cuyas claves se hicieron públicas en los últimos cinco años, unos 3.69 millones de BTC, superan a todo el montón P2PK por dos a uno. Son las billeteras de hoy, no las de Satoshi.
Recibir dos veces en una dirección desde la que nunca se gastó filtra privacidad, no la clave; gastar una vez y volver a recibir filtra las dos cosas.
El cortafuegos de Satoshi: lo que ve el analista de cadena
Un año después del whitepaper, en el foro bitcointalk, Satoshi resumió la premisa del diseño en una frase: "If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else" (si no se conocen las identidades de las personas que usan las direcciones de bitcoin y cada dirección se usa una sola vez, entonces esta información solo revela que alguna persona desconocida le transfirió algún monto a alguien más).
Nuestro capítulo sobre privacidad cubre la industria del análisis de cadena. Meiklejohn y sus colegas, que en 2013 enunciaron formalmente las reglas de agrupación y las llamaron heurísticas, formularon así la primera: "If two (or more) addresses are inputs to the same transaction, they are controlled by the same user" (si dos o más direcciones son entradas de la misma transacción, las controla el mismo usuario). Esa regla agrupa a quienes envían. La reutilización alimenta el grupo desde el otro lado: una dirección reutilizada es un destino conocido, así que cada pago que recibe se suma al grupo que el analista ya había construido alrededor de ella. El artículo de 2016 de Harrigan y Fretter sobre por qué la agrupación de direcciones funciona tan bien nombra la reutilización de direcciones en primer lugar entre "the primary reasons behind this effectiveness" (las razones principales de esa eficacia).
En términos cotidianos, según la Bitcoin Wiki. Reutiliza la dirección de una billetera de papel y quien te vendió una recarga pequeña puede seguirla en la cadena y encontrar los ahorros que hay detrás. Cobra en una sola dirección y cada persona que te paga puede leer todos los demás pagos que recibes ahí. La Wiki concluye: "A better name would be something like 'bitcoin invoice'" (un nombre mejor sería algo como "factura de bitcoin").
Una clave, muchas monedas: la advertencia de 2013
La seguridad de las claves es la tercera razón, después de la exposición y la privacidad, y no tiene nada que ver con computadoras cuánticas. Una dirección por pago significa que una clave comprometida cuesta un pago; una dirección reutilizada pone todos los pagos que alguna vez recibió detrás de una sola clave, así que basta con que esa clave caiga una vez para perderlos todos.
El 28 de enero de 2013 un desarrollador, Nils Schneider, encontró dos entradas firmadas por la misma clave cuyas firmas compartían un valor que nunca deben compartir, y recuperó la clave; la culpable era una billetera cuyo generador de números aleatorios "was returning the same 'random' number every time" (devolvía el mismo número "aleatorio" cada vez). La misma clase de error golpeó a Android ese mismo año: el 11 de agosto de 2013 bitcoin.org advirtió que "all Android wallets generated to date" (todas las billeteras de Android generadas hasta la fecha) eran "vulnerable to theft" (vulnerables al robo). La alerta recetó rotación de claves: "key rotation is necessary" (la rotación de claves es necesaria) y "make sure not to send back your bitcoins to your old insecure addresses" (asegúrate de no devolver tus bitcoins a tus viejas direcciones inseguras).
El ataque necesita dos firmas de la misma clave; una clave que firma una sola vez no puede filtrarse así, y la reutilización es lo que le da a una clave su centésima firma. Cada firma necesita un número aleatorio nuevo, de un solo uso, el nonce, y en los dos casos de 2013 la billetera reutilizó uno. Las billeteras ahora lo derivan de la clave y del mensaje en lugar de tirar los dados (RFC 6979; el BIP 340 hace lo mismo para las firmas Schnorr, con aleatoriedad fresca mezclada), lo que volvió rara esta clase de error. La reutilización de nonce es un error de firma que una billetera con nonces RFC 6979 o BIP 340 no debería tener; la reutilización de direcciones es el hábito que convierte un error de firma en una fuga de la clave.
Una xpub es una clave pública extendida, una clave pública padre más su chaincode (código de cadena), una sola cadena de texto que le permite a un servidor o a una app generar todas las direcciones que cuelgan de ella sin poder gastar. El BIP 32 le pone una advertencia propia: cualquiera que tenga tu xpub y una sola clave privada no endurecida (non-hardened) de las que cuelgan de ella, la clase corriente que deriva una cuenta, puede calcular todas las demás. Una xpub también entrega de golpe todas las claves públicas de la cuenta, y por eso el BIP 360 dice que las xpubs "also reveal quantum vulnerable public key information" (también revelan información de clave pública vulnerable a la computación cuántica).
Por qué sigue pasando
La reutilización fue racional alguna vez: antes de las billeteras HD, una dirección nueva podía dejar atrás el último respaldo. El hábito sobrevivió a la razón.
Por qué persiste de todos modos, según el desarrollador de Bitcoin Matt Corallo en la lista de correo bitcoin-dev, el 19 de abril de 2026: "the more I think about the address reuse problem ... the more I don't think its going away" (cuanto más pienso en el problema de la reutilización de direcciones ... menos creo que vaya a desaparecer). Sus tres razones: "wallets get user complaints when their address changes" (las billeteras reciben quejas de los usuarios cuando su dirección cambia); para "funds, family offices, many custodians, and exchange hot wallets, address reuse is an important security feature" (fondos, family offices, muchos custodios y billeteras calientes de exchanges, la reutilización de direcciones es una función de seguridad importante), ya que "much of the large-bitcoin-wallet industry is built around keeping a list of allowed addresses" (buena parte de la industria de las grandes billeteras de bitcoin está construida alrededor de mantener una lista de direcciones permitidas); y usuarios "just reusing an address that was provided to them" (que simplemente reutilizan una dirección que les dieron). Un proveedor de custodia lo confirmó después de Drake. Fireblocks, 8 de octubre de 2026: "By default, change from every spend returns to the permanent address, so once that address has spent it stays exposed" (por defecto, el cambio de cada gasto vuelve a la dirección permanente, así que una vez que esa dirección ha gastado se queda expuesta).
Los grandes saldos reutilizados son institucionales. Las veinte direcciones expuestas más grandes de ChainQuery son, todas, expuestas por reutilización. Dos direcciones de prueba de reservas de Binance, etiquetadas a partir del propio feed de Binance, guardan unos 249,000 y 171,000 BTC, y las cinco direcciones principales suman unos 787,000 BTC, el 11% de todo lo expuesto. Rafael Schultze-Kraft, cofundador de Glassnode, publicó el 8 de octubre las cuotas de exposición por exchange con una salvedad que también aplica a las etiquetas de ChainQuery: "None of it should be read as a risk ranking, solvency signal, or a statement about the security of any exchange or custodian. Entity balances cover labeled addresses only" (nada de esto debe leerse como un ranking de riesgo, una señal de solvencia ni una afirmación sobre la seguridad de ningún exchange o custodio; los saldos por entidad cubren solo las direcciones etiquetadas). Las direcciones de pago de los pools de minería y las direcciones de donación publicadas se reutilizan por diseño.
En el mismo hilo de Delving, Wuille pregunta, sobre los usuarios que ya reutilizaron, cómo "can stop being paid to the same address" (pueden dejar de recibir pagos en la misma dirección). No puedes impedir que otras personas reutilicen tu dirección, y algunas lo hacen a propósito.
Migajas que te siguen: la reutilización forzada de direcciones
El nombre que la Bitcoin Wiki le da al ataque es reutilización forzada de direcciones; la prensa lo llama ataque de polvo, un nombre que la Wiki considera incorrecto. Un adversario paga polvo, una migaja de unos cientos de satoshis, a direcciones que ya se usaron en la cadena, y si tu billetera gasta después la migaja junto con otras monedas, la regla de propiedad común de las entradas de "El cortafuegos de Satoshi", más arriba, las vincula todas.
El consejo se divide en dos. Una migaja en una dirección que ya habías vaciado: no la gastes nunca; congélala con el control de monedas de tu billetera (el lockunspent de Core hace lo mismo). Una migaja en una dirección que todavía guarda tus monedas: gasta todo lo que hay ahí junto, migaja incluida, sin entradas de ningún otro lado. Esas monedas ya estaban vinculadas; lo que no debes hacer es vincularlas con el resto de tu billetera.
Bitcoin Core automatizó esa división por pasos. La versión 0.17.0 (2018) añadió -avoidpartialspends, que gasta juntas todas las monedas de una misma dirección pero, como señalaba su nota de versión, seguía recogiendo las monedas enviadas ahí después; la 0.19.0.1 (2019) respondió con la opción avoid_reuse de la billetera, que omite las monedas enviadas a una dirección después de que se gastó desde ella, porque, como lo expresó la propuesta de julio de 2018 que hay detrás (el PR #13756, de kallewoof), "a payer could otherwise begin tracking a payee's wallet by regularly peppering a known UTXO with dust outputs" (quien paga podría empezar a rastrear la billetera de quien cobra salpicando con regularidad un UTXO conocido con salidas de polvo). Desde la 0.21.0 (2021) la billetera evita los gastos parciales por defecto cuando no cuesta comisión extra; avoid_reuse en sí sigue desactivada por defecto, necesita un rescan en una billetera ya existente y no tiene interruptor en la interfaz gráfica.
Por qué una dirección nueva ya no cuesta nada
"Voy a perder la pista de todas esas direcciones" era cierto antes de las billeteras HD y es falso desde que llegaron. BIP 32 (2012): una semilla, todas las claves futuras. El BIP 44 mantiene el cambio en una rama de direcciones propia, separada de las que entregas, y fija el gap limit, "currently set to 20" (fijado actualmente en 20): una billetera en recuperación escanea hasta encontrar veinte direcciones sin usar seguidas, así que la única forma de perder la pista es acuñar muchas más direcciones sin pagar que el gap, algo sobre lo que el BIP 44 les pide a las billeteras que avisen.
Bitcoin Core es una billetera HD por defecto desde la 0.13.0 (2016) y mantiene 1,000 claves por adelantado en su reserva de claves (keypool). Una propuesta de 2014 para quitar la casilla de reutilizar quedó en pausa hasta que "deterministic wallets are implemented (then there is no excuse left to reuse addresses)" (se implementen las billeteras deterministas; entonces ya no quedará excusa para reutilizar direcciones), se reabrió cuando las billeteras HD llegaron, y la 0.16.0 (2018) anunció: "The option to reuse a previous address has now been removed" (la opción de reutilizar una dirección anterior se ha eliminado). El botón de reutilizar sobrevivió alrededor de un año y medio a la llegada de las billeteras HD.
La trampa que queda es el usuario: la pantalla de recibir muestra la última dirección sin usar hasta que se usa, así que cópiasela a dos personas y la reutilización la fabricaste tú.
Consejo pro: Una dirección por cada persona que te debe dinero. Si dos personas te van a pagar, presiona "nueva dirección" dos veces. Piensa en una factura, no en un número de cuenta.
Cuando de verdad necesitas una sola dirección para siempre
Los frascos de propinas, los pies de factura y las listas de direcciones autorizadas para retiros son necesidades reales; cada solución tiene un costo.
Entrega una xpub. El BIP 32 lo previó en 2012, al llamar a la xpub de la rama de recepción "a sort of 'super address'" (una especie de "superdirección"). La documentación de BTCPay Server (consultada en octubre de 2026) describe el mecanismo: una xpub de solo lectura en el servidor, que "generates a new address for every invoice" (genera una dirección nueva para cada factura). Tres costos. Quien tenga la xpub ve todos los pagos que esa cuenta llegue a recibir. Un servidor que acuña una dirección por factura puede rebasar el gap limit con facturas que nadie pagó; BTCPay advierte que después de "20 consecutive unpaid invoices" (20 facturas sin pagar seguidas) una billetera externa "stops fetching the transactions" (deja de buscar las transacciones). Y la advertencia del BIP 32 de más arriba: esa xpub más una sola clave filtrada de la cuenta son todas las claves de la cuenta. Así que dale al servidor la xpub de una cuenta aparte; una filtración cuesta entonces solo esa cuenta.
Silent Payments, BIP 352. Publicas un solo código; cada remitente deriva de él una dirección nueva que solo tú puedes reconocer, sin contacto entre ustedes. (Los códigos de pago del BIP 47 intentaron esto en 2015, pero necesitaban una transacción de notificación on-chain por cada remitente; los Silent Payments la eliminan). Costos: quien recibe tiene que escanear la cadena, "generally feasible for full nodes but poses a challenge for light clients" (en general factible para los nodos completos, pero un reto para los clientes ligeros), y toda salida es Taproot, así que las monedas que van a quedarse quietas una década conviene barrerlas una vez a una dirección con hash. El soporte en billeteras empezó a llegar en 2024 y todavía se extiende; a octubre de 2026, Bitcoin Core integró la lógica del BIP pero "does not yet enable sending or receiving silent payments" (todavía no permite enviar ni recibir Silent Payments).
Lightning, para el frasco de propinas. Una factura Lightning (invoice, BOLT 11) es para un solo pago. Una oferta de BOLT 12 (Offers), o una Lightning Address (dirección Lightning), puede reutilizarse porque un nodo o un servidor acuña detrás una factura nueva cada vez, lo que hace a una Lightning Address tan privada como quien opera ese servidor.
De las soluciones del tipo "publica un código, no una dirección", las estáticas comparten una falla, señalada por el desarrollador de Bitcoin Peter Todd en 2023: las billeteras se pierden o se ven comprometidas, y un código estático sin vencimiento sigue atrayendo pagos hacia una billetera que ya no existe; en sus palabras, "toxic data: funds sent to those addresses can be easily lost forever" (datos tóxicos: los fondos enviados a esas direcciones pueden perderse fácilmente para siempre). El BIP 352 no tiene campo de vencimiento; una oferta BOLT 12 puede llevar uno.
Si ya reutilizaste: la versión con calma
Nuestro capítulo cuántico dice qué hacer. Aquí va el cómo.
Ten claro qué arregla mover las monedas. La clave está en un bloque para siempre; mover las monedas las pone detrás de un hash nuevo. La regla de ChainQuery: "Coins leave that pool only when they're spent to a non-always-exposed script type" (las monedas salen de ese grupo solo cuando se gastan hacia un tipo de script que no sea de los siempre expuestos), así que barrerlas a una dirección bc1p (Taproot), que muestra su clave desde el primer día, no cuenta.
Un solo gasto, solo desde esa dirección. Todo lo que hay en la dirección reutilizada ya está vinculado, así que gastarlo todo en una sola transacción no añade ningún vínculo nuevo; mezclar monedas de otras direcciones, sí. Entradas solo de esa dirección, hacia una sola dirección nueva con hash que tu billetera nunca mostrará dos veces. Lo mismo vale para una dirección multisig P2SH o P2WSH reutilizada, cuyo primer gasto publica todas las claves. La salvedad de la Wiki: alguien que ya tenga la clave privada todavía puede ganarle la carrera al barrido en los minutos previos a que se confirme, la ventana breve de "El gasto es la revelación", más arriba.
¿Reutilizada una vez y nunca gastada? Todavía no hay nada expuesto; haz que el primer gasto sea el último. La migaja de un desconocido sigue la división de "Migajas que te siguen", más arriba.
Elige un día aburrido. Revisa el indicador de presión de comisiones y espera a un día en que marque Low (baja).
Encuentra las tuyas. listreceivedbyaddress en un nodo lista, para cada una de tus direcciones, las transacciones que le pagaron; dos o más significa que la dirección recibió dos pagos, y si se gastó desde ella entre un pago y otro, eso es reutilización en el sentido de este capítulo. En un explorador de bloques, recuerda la advertencia de Wuille vía Optech, 2019: "looking up your own addresses on a block explorer leaks your privacy to the site operator" (buscar tus propias direcciones en un explorador de bloques filtra tu privacidad a quien opera el sitio). Eso incluye a ChainQuery: primero el nodo, y Tor si no te queda más remedio que usar un explorador.
No te apresures. Drake: "Don't rush" (no te apresures). Vitalik Buterin, cofundador de Ethereum: "I personally have lost more money in botched migrations than I have lost in all hacks combined" (personalmente he perdido más dinero en migraciones mal hechas que en todos los hackeos juntos). Guillemet: una migración masiva "would create operational mistakes that lose funds with higher probability than the scenario being mitigated" (crearía errores operativos que pierden fondos con más probabilidad que el escenario que se intenta mitigar). Nuestro capítulo cuántico, meses antes: "No muevas monedas por pánico". La cadena estuvo de acuerdo: la semana del 7 de octubre no trajo ningún pico de comisiones (una tasa de comisión mediana por bloque de 1 sat/vB todos los días del 6 al 10 de octubre) ni ningún éxodo del grupo expuesto, que se redujo en 12,319 BTC, más o menos un sexto de un punto porcentual, sin nada en la corta historia de ChainQuery que marque la semana como inusual. Al 12 de octubre, los foros de desarrollo y la lista bitcoin-dev no lo habían discutido en absoluto.
Consejo pro: Quien te venda un producto de "modo búnker" te está vendiendo algo que tu billetera ya hace gratis.
Qué ganamos con esto
- Sabes que una dirección es una factura. Un pago, y listo.
- Sabes qué filtra una sola reutilización. El pasado, el futuro, tus contrapartes y, en cuanto gastas, la clave.
- Sabes que las tres razones son independientes. La exposición de la clave pública, la privacidad y la seguridad de las claves se sostienen cada una por su cuenta, y un solo hábito arregla las tres.
- Sabes que la solución ya es el comportamiento por defecto de tu billetera. Las billeteras HD, el gap limit y el botón de reutilizar que se eliminó hicieron el trabajo hace años; la opción
avoid_reusede Core, que es opcional, se encarga de las migajas. No lo deshagas. - Sabes cuál es la secuencia con calma si ya lo hiciste. Un solo gasto, solo desde esa dirección, en un día tranquilo, hacia un hash nuevo, y sin prisas.
Úsala una sola vez.
Más en Custodia y privacidad
Fuentes
- Bitcoin whitepaper, section 10: Privacy (2008)
- Satoshi Nakamoto on bitcointalk, 25 November 2009 - use bitcoin addresses only once
- ChainQuery quantum-exposure report (live, weekly; figures in this chapter from the 2026-10-11 snapshot, block 970,878)
- ChainQuery - top quantum-exposed addresses, with attribution confidence
- ChainQuery x LearnBitcoin Baseline 2026 Q2 PDF
- Project Eleven - Bitcoin Risq List (block 970,566 snapshot)
- Glassnode Research - Measuring Bitcoin's Quantum-Exposed Supply (20 May 2026)
- Rafael Schultze-Kraft (Glassnode co-founder) on X, 8 October 2026 - updated exposure thread with entity shares and disclaimer
- Justin Drake on X, 7 October 2026 - the bunker mode post
- Juan Galt (Bitcoin Magazine) on X, 7 October 2026
- Yehuda Lindell (Coinbase) on X, 8 October 2026 - no evidence of a break
- Charles Guillemet (Ledger) on X, 7 October 2026 - operational mistakes versus the scenario being mitigated
- Vitalik Buterin on X, 7 October 2026 - botched migrations
- Matthew Green (Johns Hopkins) on X, 9 October 2026 - a 1 percent chance and a 15 percent chance, based on vibes but nobody has better ones
- Adam Back (Blockstream) on X, 7 October 2026 - this is AI fear mongering
- Alman and Vassilevska Williams - Truly Subquadratic 3SUM and Truly Subcubic APSP via Triangles in Sparse Lopsided Graphs (arXiv, 5 October 2026; the paper's abstract says, near its end, 'Claude, an AI model developed by Anthropic, discovered the algorithm', and its last paragraph adds that Claude verified the main results in Lean 4, its Acknowledgments and Methodology section says an internal Anthropic research model found it, and the main results are certified in Lean 4; the arXiv listing-page abstract omits the sentence)
- openai/math on GitHub - the 6 October 2026 catalogue of AI-written manuscripts (README: 719 manuscripts in 372 families, after three were withdrawn on 7 October; CONTENTS index read 2026-10-11)
- Scott Aaronson - The Mathocalypse (7 October 2026; the cryptography remark is in an appended update, live by 8 October)
- Delving Bitcoin - PQC output type discussion (Pieter Wuille, July to October 2026)
- Matt Corallo, bitcoin-dev, 19 April 2026 - reply in the thread PQC: What is our Goal, Even? (why reuse persists; dusting attacks), b10c mirror
- The same Matt Corallo message on Google Groups (bitcoindev)
- Bitcoin Optech - Output linking topic
- Bitcoin Optech Newsletter, 15 January 2019 - biased nonces and reused addresses
- Bitcoin Optech Newsletter, 19 March 2019 - looking up your own addresses leaks your privacy
- Bitcoin Optech Newsletter #425, 2 October 2026 - Optech's summary of Wuille on address reuse; Core PR #35301
- BIP-32 - Hierarchical Deterministic Wallets
- BIP-44 - Multi-Account Hierarchy for Deterministic Wallets (gap limit)
- BIP-47 - Reusable Payment Codes (status Deployed; the notification transaction)
- BIP-141 - Segregated Witness (where the key is revealed)
- BIP-340 - Schnorr Signatures (synthetic nonces)
- BIP-341 - Taproot (the public-key-hash footnote)
- BIP-352 - Silent Payments
- BIP-360 - Pay-to-Merkle-Root (draft; long and short exposure attacks)
- BIP-361 - Post-Quantum Migration (draft)
- BOLT 12 - Offers (introduction: invoices are per user; the optional offer_absolute_expiry field)
- Bitcoin Core issue #2429 - old-address list encourages reuse (gmaxwell, 2013)
- Bitcoin Core PR #3716 - remove the reuse-address checkbox (2014 to 2017)
- Bitcoin Core PR #10831 - keypool default raised to 1,000 (2017)
- Bitcoin Core PR #12257 - avoid partial spends (2018)
- Bitcoin Core PR #13756 - the avoid_reuse wallet flag (kallewoof; opened July 2018, merged June 2019; the peppering line is its description)
- Bitcoin Core PR #14582 - avoid partial spends by default when fee-neutral (2020)
- Bitcoin Core PR #23065 - persistent option for lockunspent (2021)
- Bitcoin Core PR #35301 - silent payments BIP logic (merged 23 September 2026)
- Bitcoin Core GUI issue #341 - no toggle for avoid_reuse (open since 2021)
- Bitcoin Core 0.13.0 release notes (HD wallets by default)
- Bitcoin Core 0.16.0 release notes (reuse option removed)
- Bitcoin Core 0.17.0 release notes (-avoidpartialspends)
- Bitcoin Core 0.19.0.1 release notes (avoid_reuse)
- Bitcoin Core 0.21.0 release notes (-maxapsfee)
- bitcoin.org alert, 11 August 2013 - Android security vulnerability
- Mike Hearn, bitcoin-dev, 11 August 2013 - Android key rotation
- Android Developers Blog - Some SecureRandom Thoughts (14 August 2013)
- Nils Schneider - Recovering Bitcoin private keys using weak signatures from the blockchain (28 January 2013, Wayback Machine capture of 21 October 2013)
- Meiklejohn et al. - A Fistful of Bitcoins (IMC 2013)
- Harrigan and Fretter - The Unreasonable Effectiveness of Address Clustering (2016)
- Stuetz et al. - Reuse of Public Keys Across UTXO and Account-Based Cryptocurrencies (2026)
- Bitcoin Wiki - Address reuse
- Bitcoin Wiki - Privacy (forced address reuse)
- Peter Todd, bitcoin-dev, 4 August 2023 - BIP-352 addresses should have an expiration time
- Fireblocks - Bitcoin Bunker Mode and What It Actually Protects (Michael Gutkin, 8 October 2026)
- BTCPay Server docs - Wallet FAQ (one address per invoice, the gap limit)
- mempool.space - mining graphs, block fee rates (a rolling window; the 1 sat/vB daily medians for 6 to 10 October 2026 were read from its data on 2026-10-12)
Publicado el . No hay correcciones registradas para esta página.
Editar esta página en GitHub