Cómo nace una transacción de Bitcoin

Sigue el recorrido real de una transacción de Bitcoin: creación, firma, comisión, difusión, mempool y confirmación, con comprobaciones prácticas antes y después del envío.
Antes de pulsar enviar
La transacción empieza en la cartera cuando eliges el activo Bitcoin y abres el flujo Enviar (Send). Ahí se rellenan campos concretos: dirección de destino, importe, unidad BTC o sats, y a veces una nota local que no viaja por la red.
La comprobación crítica ocurre antes de firmar: red Bitcoin correcta, formato de dirección compatible, saldo disponible y comisión separada del importe. En una cuenta custodiada también conviene revisar si aparece comisión de red, comisión de plataforma o plazo interno de procesamiento.
- Verifica que la dirección no pertenezca a otra red o activo distinto; una dirección correcta en la red equivocada no implica recuperación.
- Confirma si el importe se envía como cantidad exacta al destinatario o como total con comisión incluida; la pantalla de vista previa suele indicarlo.
Construcción y firma
La cartera construye la transacción seleccionando entradas o UTXO, creando una salida al destinatario y, normalmente, una salida de cambio. Ese cambio vuelve a una dirección controlada por tu propia cartera, aunque no siempre sea visible con el mismo formato.
La firma se realiza con la clave privada o dentro del hardware wallet mediante Confirmar (Confirm). La dirección sirve para recibir; la clave privada autoriza gastar. Una semilla o seed phrase expuesta compromete toda la cartera y no se corrige cambiando solo la contraseña.
- Revisa en la confirmación final destinatario, importe y comisión; copiar y pegar mal un carácter o aprobar desde una pantalla no verificada puede volver el envío irreversible.
- No compartas clave privada ni seed phrase con soporte, chat o formularios; ningún estado pendiente justifica revelarlas.
Difusión y mempool
La transacción firmada se difunde a nodos de la red y entra en la mempool si supera las validaciones básicas. Desde ese momento suele aparecer como pendiente con un identificador único: hash de transacción o TXID, útil para seguir el estado.
La prioridad depende sobre todo de la comisión por tamaño de datos, no del importe enviado. Si la tarifa elegida es baja para la congestión actual, el estado puede permanecer sin confirmar hasta que un minero la incluya o la cartera permita acelerarla.
- En un explorador busca campos como status, confirmations, fee, inputs, outputs y timestamp para distinguir un problema de interfaz de un problema real de red.
- Si el servicio muestra retirada procesada pero el explorador no encuentra el TXID, verifica primero si la plataforma usa revisión manual, cola de retiros o consolidación interna.
Confirmación y cierre
La primera confirmación llega cuando un bloque incluye la transacción y el explorador cambia el estado de pending a confirmed. Cada bloque posterior añade confirmaciones, pero el número exigido por comercios, carteras o exchanges puede variar según su política de riesgo.
El resultado final no siempre admite marcha atrás. Una transacción ya confirmada no se cancela desde la cadena, y un envío a una dirección equivocada depende únicamente de que el receptor coopere o de que el servicio custodio tenga un proceso excepcional de recuperación.
- Guarda el TXID y compáralo en más de un explorador si el estado parece contradictorio; el dato útil es la confirmación en red, no solo el aviso de la app.
- Ejemplo realista: en autocustodia puedes ver cambio, TXID y comisión exacta; en una cuenta custodiada quizá solo veas retirada, estado y confirmaciones cuando el operador la publique.
