Coin control: gestión de UTXOs

Pagas 200.000 sats y el programa elige por ti

Imagina una billetera (wallet) con tres UTXO: uno de 300.000 sats que retiraste de un exchange con KYC, y dos de 150.000 y 80.000 que te pagaron vecinos en persona. Vas a pagar 200.000 sats con una comisión de 10 sat/vB, y los tres UTXO son de tipo P2WPKH.

Hay dos formas razonables de hacerlo. Con el UTXO de 300.000 solo, la transacción ocupa unos 141 vB (una entrada de unos 68, dos salidas de 31 y unos 11 de cabecera) y la comisión ronda los 1.410 sats. Con los dos de los vecinos, ocupa unos 209 vB y la comisión sube a unos 2.090 sats. Son unos 680 sats de diferencia. Una tercera opción, que la selección automática puede elegir sin avisar, junta los tres, y entonces el exchange que conoce tu nombre queda unido en la cadena a lo que cobraste a tus vecinos.

Los tamaños son un cálculo aproximado con las reglas de peso de BIP-141, no una tabla oficial. El orden de magnitud es el que importa: la diferencia de comisión se paga una vez, y la unión de orígenes no se deshace.

Coin control es poder decidir tú cuál de esas opciones se firma. Este artículo no repite por qué juntar entradas delata a su dueño (eso lo explica consolidación de UTXOs) ni el formato de las etiquetas (etiquetas y BIP-329). Se centra en lo que falta: cómo se detecta el cambio, cómo se practica la selección manual, qué hace la automática, cuánto cuesta cada entrada y cómo se defiende uno del polvo.

La otra salida: cómo se detecta el cambio

Gastar entradas conjuntas ya enlaza a su dueño. Satoshi lo admitía en el whitepaper (§10, 2008): las transacciones con varias entradas revelan por fuerza que sus entradas eran del mismo dueño. Lo que viene después es seguir a ese dueño. Para eso el analista necesita saber cuál de las salidas es el pago y cuál es el cambio que vuelve a la billetera. La Bitcoin Wiki (artículo «Privacy», revisión de abril de 2026, consultado el 7 de octubre de 2026) recoge varias pistas, y ninguna es decisiva por sí sola.

• Dirección reutilizada. Una salida que va a una dirección que ya se había usado es casi seguro el pago, no el cambio. La Wiki la considera probablemente la más fiable de todas. Es el vínculo con reutilización de direcciones.
• Tipo de script distinto. Si se gasta desde P2PKH y salen una salida P2PKH y otra P2SH, la P2SH es el pago y la P2PKH vuelve al remitente.
• Importe redondo. Los pagos suelen ser cifras redondas (0,1 BTC). La salida que no lo es se lee como cambio.
• Entrada innecesaria. Es la que más enseña. Ejemplo de la Wiki: entradas de 2 y 3 BTC, salidas de 4 y 1 BTC. Si el pago fuera el de 1 BTC, la entrada de 2 BTC habría bastado sola, así que la de 3 sobraría. Luego el pago es el de 4 BTC y el cambio es el de 1.
• Huella de la billetera. Tipo de dirección, orden de entradas y salidas, nLockTime, nSequence, firmas de R bajo, forma de elegir monedas. Cada programa deja una huella reconocible.

La consecuencia práctica es incómoda. Estrenar una dirección para el cambio no basta, porque el cambio se delata por el tipo de script, por el importe o por una entrada que no hacía falta. Por eso las dos primeras tareas de coin control son coger solo las entradas necesarias y que el cambio no se distinga del pago.

Selección manual, paso a paso

Un solo origen por transacción. Es la razón de ser de las etiquetas. Si para pagar tienes que elegir entre tres entradas de un mismo origen o dos entradas que mezclan orígenes y ahorran 300 sats, conviene pagar los 300 sats. La comisión de más se paga una vez. La unión en la cadena dura para siempre y ninguna transacción posterior la deshace. Nunca juntes en un mismo pago monedas con KYC y monedas sin KYC (más en KYC y sin KYC).

Ninguna entrada de más. Si una sola moneda cubre el pago, añadir otra encarece la transacción y, además, señala cuál de las salidas es el pago. Con una moneda de 250.000 sats y un pago de 180.000, lo mejor es gastar esa moneda sola.

Enviar sin cambio. Si no hay cambio, no hay cambio que detectar y la transacción es más pequeña. Hay dos vías. Una es elegir monedas cuya suma, menos la comisión, iguale el pago, que es lo que el algoritmo Branch and Bound busca solo. El destinatario cobra lo acordado y el pequeño sobrante, si lo hay, se va a la comisión. Bitcoin Core hace algo parecido con -discardfee: si gastar un cambio costaría más de lo que vale, lo suma a la comisión. La otra es barrer las monedas seleccionadas con la opción «Max»: todo lo que sumen, menos la comisión, llega al destinatario. Liana lo documenta así (CHANGELOG, v5.0). Sirve para mover monedas a otra billetera tuya o cuando el importe exacto da igual, no para pagar una deuda concreta, porque pagarías de más. Además, el importe deja de ser redondo.

Cambio del mismo tipo que el destino. Si pagas a una dirección bech32m y el cambio sale en bech32, el cambio queda señalado. Bitcoin Core iguala el tipo del cambio al del destinatario desde la PR #23789 (Optech, 5 de enero de 2022): si algún destinatario es P2TR, el cambio es bech32m, y si es P2WPKH, bech32. Sparrow lo exige en su modo de privacidad: la dirección de destino debe ser del mismo tipo que la billetera para que las salidas parezcan iguales (documentación «Spending privately», consultada el 7 de octubre de 2026). Si tu billetera solo maneja un tipo de dirección, pide al destinatario una dirección de ese mismo tipo cuando puedas. Si no puedes, asume que el cambio queda señalado.

Congelar. Una moneda congelada no entra en la selección automática. En Sparrow se hace desde la pestaña UTXOs con «Freeze UTXO». Electrum congela direcciones y, desde la 3.3.5 (9 de mayo de 2019), UTXO sueltos. Bitcoin Core usa lockunspent. Ojo con el detalle: sin el parámetro persistent, el bloqueo vive solo en memoria y se pierde al reiniciar el nodo. Desde la 23.0 se puede guardar en la base de datos de la billetera, y los bloqueos hechos desde la interfaz gráfica ya son persistentes (notas de la 23.0).

En Bitcoin Core la interfaz gráfica oculta estas funciones hasta que las activas en Opciones con «Enable coin control features». Si eliges monedas a mano, Core no añade otras. En el RPC send, add_inputs vale false por defecto cuando das inputs (documentación RPC 30.0.0). Con fundrawtransaction es al revés: add_inputs vale true por defecto y Core puede añadir monedas a las que elegiste si no bastan.

Cuánto cuesta cada entrada

La comisión depende del tamaño de la transacción en vbytes, y cada entrada añade el suyo. Los tamaños siguientes son aproximados: salen de aplicar el peso de BIP-141 (peso = bytes sin testigo × 4 + bytes de testigo, vB = peso / 4) con firmas ECDSA de 72 bytes. No son cifras de una tabla oficial.

• P2PKH: unos 148 vB por entrada (el código de Core habla de «at least 148 bytes»).
• P2SH-P2WPKH: unos 91 vB.
• P2WPKH: unos 68 vB.
• P2TR, gasto por la clave: unos 57,5 vB (firma Schnorr de 64 bytes).
• P2WSH multifirma 2 de 3: unos 104,5 vB.

Las salidas pesan menos: unos 31 vB en P2WPKH, 43 en P2TR, 34 en P2PKH. Por eso, con comisión alta, conviene elegir pocas entradas y grandes. Una entrada P2WPKH cuesta unos 68 sats a 1 sat/vB y unos 6.800 a 100 sat/vB. Cuándo deja de compensar gastar una moneda pequeña lo explica consolidación de UTXOs.

Más entradas siempre suben la comisión del pago actual. La pregunta es si compensa pagar más ahora para tener menos monedas después, y eso depende de cuánto crees que subirá la comisión.

El simulador UTXO Lab, del curso, permite elegir qué salidas gastas en un pago y ver al momento la comisión (con 68 vB por entrada P2WPKH), el cambio y lo que revelas.

Qué hace la selección automática (y qué no sabe)

Bitcoin Core no usa un único algoritmo. Prueba varios y se queda con el de menor desperdicio (waste). Si empatan, elige el que gasta más entradas (spend.cpp, master, consultado el 7 de octubre de 2026).

• Branch and Bound. Busca un conjunto de entradas que cubra el pago sin crear cambio, con una tolerancia igual al coste del cambio. Una reescritura de su búsqueda, para probar más candidatos distintos, se fusionó en junio de 2026 (Bitcoin Core #32150, Optech, 12 de junio de 2026).
• Knapsack. El algoritmo original. Sigue compitiendo en cada pago y, por herencia, puede incluir monedas que cuestan más de gastar de lo que valen, como el polvo que te hayan enviado.
• Single Random Draw. Baraja las monedas y toma hasta cubrir el pago más un cambio mínimo. Entró con la PR #17526. En unos 8.000 pagos simulados bajó las comisiones un 6 % y subió las transacciones sin cambio del 5,4 % al 9,0 % (Optech, 6 de octubre de 2021).
• CoinGrinder. Llegó con la 27.0 (PR #27877). Busca el conjunto de entradas de menor peso y siempre produce cambio. Solo se activa con comisiones altas: cuando la comisión efectiva supera tres veces -consolidatefeerate, que con el valor por defecto son unos 30 sat/vB (notas de la 27.0).

El desperdicio mezcla dos cosas. Si hay cambio, es el coste de crearlo y de gastarlo más adelante, más el tamaño de las entradas multiplicado por la diferencia entre la comisión de ahora y una comisión a largo plazo. Si no hay cambio, el excedente que se va a comisión ocupa el lugar del coste del cambio (coinselection.h, RecalculateWaste). Ese «largo plazo» es una suposición: -consolidatefeerate vale por defecto 10 sat/vB (10.000 sat/kvB), es decir, la billetera supone que cada entrada se gastará algún día a 10 sat/vB.

La consecuencia es que, con comisiones por debajo de ese umbral, Core prefiere a propósito usar más entradas de las necesarias, para reducir el número de monedas de la billetera. Gastar entradas es barato ahora. Para las comisiones es una decisión sensata. Para la privacidad no lo es si esas entradas vienen de orígenes distintos. Y por encima de unos 30 sat/vB entra CoinGrinder y minimiza el peso, también sin mirar el origen.

Esta es la limitación de fondo: ningún algoritmo sabe de dónde viene una moneda. Core mira el tipo de script y la dirección, no si salió de un exchange con KYC o de un vecino. Eso solo lo sabe quien etiquetó la entrada. Sí hace algo por la privacidad:

• Prefiere conjuntos de entradas de un solo tipo de salida, porque mezclar tipos delataba el cambio de transacciones anteriores (PR #24584, Optech, 10 de agosto de 2022).
• -avoidpartialspends agrupa las salidas por dirección y gasta todas o ninguna de cada dirección. La ayuda dice que mejora la privacidad, pero puede subir la comisión. Por defecto está desactivada, aunque Core prueba también la versión agrupada y la usa si no sale más cara. Siempre está activa en billeteras con avoid_reuse.
• La bandera avoid_reuse (PR #13756, Optech, 26 de junio de 2019) deja fuera de la selección las monedas que llegan a una dirección desde la que ya gastaste. Viene desactivada.

Electrum tiene su propio selector, CoinChooserPrivacy, que es el único que ofrece. Según su código, gasta todas las monedas de una dirección si gasta una y penaliza los cambios muy distintos del pago o demasiado grandes. Sus límites son 0,75 veces la salida menor y 1,33 veces la mayor (coinchooser.py, master, consultado el 7 de octubre de 2026). Sparrow usa dos de los algoritmos de Core, Branch and Bound y Knapsack. Su conmutador Efficiency/Privacy, en modo Privacy, construye una falsa CoinJoin al estilo Stonewall. Requiere fondos de más del doble del pago y un destino del mismo tipo de script, según su documentación. Ojo: para fingir dos participantes gasta más monedas tuyas, y si no las eliges a mano puede juntar orígenes que querías separados.

Ninguna de estas heurísticas sustituye a elegir tú. Y ninguna rompe la heurística de entrada común: coin control solo decide qué se junta. Romperla es cosa de PayJoin o de CoinJoin. El marco general está en pseudonimato y anonimato.

El ataque de polvo

Alguien te envía una cantidad minúscula, a una dirección tuya que ya conoce. Si luego gastas ese UTXO junto con otros, la heurística de entrada común une las direcciones nuevas con las viejas y el atacante gana una pista sobre tu billetera. Funciona porque el gasto del polvo parece inofensivo («son pocos sats») y es justo lo que busca quien lo envía.

La política de Bitcoin Core considera polvo una salida que vale menos de lo que costaría crearla y luego gastarla a 3 sat/vB. Los comentarios del código dan 546 sats para P2PKH y 294 para P2WPKH. Es política de retransmisión de los nodos, no regla de consenso: una transacción con salidas por debajo de ese umbral no se retransmite con la política por defecto (salvo la excepción del polvo efímero, que no viene al caso), pero un minero puede incluirla. Por eso el «polvo» de un ataque no suele ser polvo en el sentido de la política: para que la transacción se retransmita, el atacante tiene que enviar al menos ese umbral. La Bitcoin Wiki prefiere llamarlo reutilización forzada de direcciones.

Las defensas de cada billetera, a 7 de octubre de 2026:

• Sparrow marca «Possible dust attack» en salidas de 1.000 sats o menos (umbral configurable) recibidas en una dirección ya usada y que no proceden de la propia billetera. En el aviso ofrece «Freeze?» (commits de mayo de 2022).
• Electrum añadió en la 4.6.0 (16 de julio de 2025) la opción «Avoid spending from used addresses», que congela sola las monedas que llegan a direcciones desde las que ya gastaste. Viene desactivada: hay que activarla.
• Bitcoin Core ofrece avoid_reuse, descrita arriba.

En Bitcoin Core, sin congelar, nada impide que la selección automática gaste ese polvo junto a otras monedas. avoid_reuse y la opción de Electrum solo actúan si ya gastaste desde esa dirección: el polvo que llega a una dirección que solo ha recibido sigue siendo gastable. Y si activas avoid_reuse en una billetera que ya existe, hay que reescanear para que marque los gastos anteriores.

El consejo seguro es congelar ese UTXO y no gastarlo nunca junto a otros. Ten en cuenta que la marca de congelado no está en la cadena ni en la seed phrase. Si restauras la billetera, aunque sea en el mismo programa, el polvo vuelve a aparecer como gastable. Para conservarla, exporta las etiquetas con el campo spendable de BIP-329, si tu billetera lo admite, y comprueba después de importarlas que esas monedas siguen congeladas.

A finales de enero de 2026 se propuso en Delving Bitcoin gastar el polvo entero hacia una salida OP_RETURN, algo viable desde que Bitcoin Core 29.1 (septiembre de 2025) bajó el mínimo de retransmisión a 0,1 sat/vB. Hay una herramienta experimental («ddust»). Optech (6 de febrero de 2026) recoge los riesgos: una huella reconocible si pocas billeteras lo hacen, la correlación si emites a la vez varias de esas transacciones, tener que retransmitir si suben las comisiones y lo confuso de firmarlas en multifirma y con dispositivos de hardware. No es una práctica asentada.

Dónde está disponible

Coin control existe en Sparrow (pestaña UTXOs, con «Send Selected»), en Electrum (pestaña Coins) y en Bitcoin Core, activándolo en Opciones. También lo tienen Liana (selección manual o automática al crear un gasto) y Nunchuk (desde 2023). No todas las billeteras lo incluyen. Antes de elegir una, comprueba que lo ofrezca y que permita congelar.

Qué significa esto para ti

Tres hábitos bastan para empezar. Etiqueta cada moneda en cuanto llega. Al pagar, elige a mano las monedas de un solo origen, con las menos entradas posibles, y procura que el destino sea del mismo tipo de dirección que tu cambio. Y congela lo que no quieras gastar, sobre todo el polvo que no esperabas.

Coin control no te vuelve anónimo ni deshace lo ya unido, y tiene un coste: a veces pagas unos cientos de sats de más. Es una forma de decidir qué datos le das a un observador, no de ocultarlos todos. Si necesitas romper la heurística de entrada común, mira PayJoin y CoinJoin. Si vas a aprender a usarlo, practica primero con el UTXO Lab.