Consulta el razonamiento que sustenta las guías de BitcoinSafe. Cada amenaza tiene identificadores estables, controles, pruebas esperadas, fuentes y una explicación del riesgo restante.
Un marco público para examinar cómo los fallos operativos y los ataques pueden provocar gastos no autorizados, pérdida de capacidad de recuperación, exposición de privacidad o fallos de continuidad. Cada amenaza se vincula con controles, pruebas esperadas y riesgo restante.
Personas que gestionan su propia custodia de Bitcoin, educadores que explican la autocustodia y desarrolladores que necesitan identificadores públicos estables para sus guías. El modelo no se adapta a una persona, saldo, jurisdicción o adversario concretos.
Esta publicación es un marco de razonamiento, no una puntuación de seguridad, auditoría, garantía, recomendación de producto ni certificación. La documentación pública puede estar incompleta, las implementaciones pueden contener fallos y los controles bien aplicados siguen dejando riesgo residual.
Quien pueda satisfacer la política de la cartera puede autorizar un gasto. Perder todas las vías de recuperación válidas puede volver inaccesibles los fondos aunque la red Bitcoin siga funcionando.
Los teléfonos, ordenadores, sesiones del navegador, cuentas en la nube, plataformas, coordinadores y canales de comunicación se consideran falibles, no fiables por defecto.
El modelo incluye errores al manejar copias, recuperar, revisar transacciones, controlar accesos, documentar y transferir responsabilidades. No presupone un operador perfectamente formado.
Un control se documenta solo hasta el nivel respaldado por especificaciones públicas, documentación del proveedor, registros reproducibles o una revisión identificada. La ausencia de un problema divulgado no demuestra seguridad.
Claves privadas, dispositivos de firma, contraseñas adicionales, políticas y componentes de quórum que pueden autorizar una transacción.
Copias, metadatos de la cartera, información de derivación, instrucciones y procedimientos probados necesarios para restaurar el acceso.
El destinatario, importe, comisión, cambio, entradas y política de firma previstos para un gasto.
Direcciones, claves públicas extendidas, saldos, historial de transacciones, contrapartes y relaciones de propiedad.
La capacidad de una persona autorizada para entender, mantener, recuperar y transferir la configuración con el tiempo.
El modelo sigue una secuencia de alcance, amenaza, respuesta y revisión. Las prioridades describen hasta qué punto una condición puede conducir directamente a una pérdida; no estiman probabilidades. Los controles reducen vías de fallo concretas, pero nunca certifican que una cartera o configuración sea segura.
La condición descrita puede permitir directamente un gasto no autorizado o una pérdida permanente de acceso. La etiqueta no estima la probabilidad del suceso.
La condición puede impedir la recuperación, debilitar la verificación o dificultar considerablemente la contención de otro fallo.
La consecuencia depende mucho del modelo de custodia, el valor en riesgo, el adversario, la jurisdicción o la frecuencia de uso. Aun así exige una decisión explícita.
El modelo separa autoridad de custodia, copias, recuperación, acceso, revisión de transacciones y continuidad para que un control fuerte no oculte otra debilidad.
Quién puede autorizar gastos y qué partes o componentes deben seguir disponibles y actuar correctamente.
Si el material de recuperación sobrevive a una pérdida y permanece fuera del alcance de personas no autorizadas.
Si las claves, el contexto de la cartera, las herramientas y el procedimiento pueden restaurar la cartera antes de una emergencia.
Cómo resisten la apropiación o el compromiso las cuentas de proveedores, los dispositivos, el software y las interfaces de firma.
Si el firmante puede confirmar de forma independiente qué autoriza antes de que una transacción sea irreversible.
Si un sucesor autorizado puede localizar la información no secreta adecuada y seguir un proceso probado sin reunir todos los secretos.
El resumen visual se genera con los mismos registros que las descargas. La lista de texto ofrece la misma información sin depender del color ni de la posición.
La prioridad indica hasta qué punto una condición puede causar una pérdida. No es una probabilidad, valoración de producto ni puntuación personal.
threat-custody-provider-control
threat-custody-signer-compromise
threat-backup-unavailable
threat-backup-secret-exposure
threat-recovery-not-rehearsed
threat-recovery-wallet-context-missing
threat-access-provider-account-takeover
threat-access-signing-environment-compromise
threat-transaction-destination-substitution
threat-transaction-incomplete-signing-context
threat-continuity-operator-unavailability
threat-continuity-secret-concentration
mitigation-define-custody-boundary
mitigation-isolate-signing-keys
mitigation-redundant-offline-backups
mitigation-separate-secret-material
mitigation-rehearse-recovery
mitigation-preserve-wallet-context
mitigation-phishing-resistant-access
mitigation-harden-signing-environment
mitigation-verify-on-trusted-display
mitigation-separate-transaction-roles
mitigation-document-continuity-roles
mitigation-rehearse-continuity
Un inventario actualizado de firmantes, proveedores, políticas, vías de recuperación y dependencias que pueden bloquear. El marketing por sí solo no demuestra control.
Una comprobación fechada de que el material existe, sigue legible, está separado según los límites previstos y no se ha introducido en un sistema no fiable.
Un registro fechado de la vía probada, identificación de cartera, herramientas, política reconstruida, problemas y correcciones. No debe contener el secreto.
Métodos documentados de recuperación de cuentas, tipo de autenticador, procedencia de dispositivos y software, proceso de actualización y eliminación de accesos antiguos.
Un procedimiento repetible que identifica qué campos revisa cada firmante, la fuente independiente de la intención, la validación de la política y cuándo se permite difundir.
Un inventario fechado y no secreto de funciones y lugares, responsable de cada seguimiento, registro del ensayo y revisión tras cambios familiares, legales, de proveedor o cartera.
Claves, dispositivos, personas, proveedores y políticas pueden fallar juntos o actuar de forma distinta a la documentación. Más independencia suele añadir complejidad.
Más copias pueden sobrevivir a más pérdidas, pero crean más oportunidades de descubrimiento, coacción, mal manejo o registros obsoletos.
Dispositivos, compatibilidad, personas, memoria, documentación y estado de la cartera pueden cambiar después de una prueba correcta.
Equipos, soporte, personal del servicio, firmware, acceso físico y cadena de suministro del software siguen siendo posibles vías de fallo.
Un firmante puede omitir información importante, la referencia puede estar comprometida o el operador puede aprobar datos confusos o inesperados.
Un traspaso técnicamente correcto puede entrar en conflicto con la ley, los impuestos, la familia, las reglas del proveedor o la voluntad actual del propietario.
El modelo no predice precio, liquidez, tratamiento fiscal ni la conveniencia de mantener bitcoin.
Los fallos de consenso, ataques de minería, defectos del protocolo y particiones de red quedan fuera de este modelo operativo.
El modelo no certifica carteras físicas o de software, plataformas, custodios, servicios multifirma ni proveedores de recuperación.
Ninguna prioridad tiene en cuenta el saldo, habilidades, adversarios, ubicación, familia o frecuencia de uso del lector.
Los controles de continuidad solo describen operaciones. No crean autoridad legal ni sustituyen asesoramiento cualificado en la jurisdicción correspondiente.
Las fuentes respaldan afirmaciones técnicas o de proceso concretas. Las guías generales de NIST y CISA se identifican como tales, no como pruebas específicas de Bitcoin.
National Institute of Standards and Technology
Se usa para alcance, supuestos, fuentes de amenaza, incertidumbre y revisión. BitcoinSafe no copia las escalas de probabilidad de NIST.
Consultado: 2026-08-28
OWASP Foundation
Se usa para la secuencia de alcance, identificación, respuesta y revisión, y para documentar mitigaciones prácticas.
Consultado: 2026-08-28
Bitcoin Developer Documentation
Se usa para separar distribución de claves, firma y red, y para explicar la función de las claves privadas en el gasto.
Consultado: 2026-08-28
Bitcoin Improvement Proposals
Se usa para la derivación determinista y las consecuencias de exponer o perder el material raíz.
Consultado: 2026-08-28
Bitcoin Improvement Proposals
Se usa solo para describir material mnemónico y contraseña adicional. El modelo no afirma que BIP 39 sea obligatorio para toda cartera.
Consultado: 2026-08-28
Bitcoin Improvement Proposals
Se usa para separar funciones de transacción, firma sin conexión, datos del firmante y límites de metadatos PSBT.
Consultado: 2026-08-28
Bitcoin Improvement Proposals
Se usa para explicar la importancia del tipo de script, rutas, claves y suma de comprobación del descriptor además de las claves privadas.
Consultado: 2026-08-28
Bitcoin Core
Se usa para el objetivo de seguridad y el límite operativo documentados de la firma PSBT sin conexión.
Consultado: 2026-08-28
Bitcoin Core
Se usa para comprobaciones de identidad del firmante externo, coincidencia de descriptores y visualización de direcciones.
Consultado: 2026-08-28
National Institute of Standards and Technology
Se usa para resistencia al phishing, vinculación al verificador, controles de autenticadores y límites de códigos introducidos manualmente.
Consultado: 2026-08-28
Cybersecurity and Infrastructure Security Agency
Se usa para la práctica general de copias sin conexión y pruebas periódicas de restauración. La recuperación de Bitcoin añade requisitos de secreto.
Consultado: 2026-08-28
National Institute of Standards and Technology
Se usa para funciones, recuperación, pruebas, validación, material externo y registros fechados. Es una guía general, no asesoramiento específico de Bitcoin.
Consultado: 2026-08-28
Creative Commons
Define las condiciones de reutilización del texto y los datos de investigación incluidos.
Consultado: 2026-08-28
Semantic Versioning
Define la versión inmutable y las reglas de versiones mayores, menores y de parche usadas por el modelo.
Consultado: 2026-08-28
Los parches corrigen texto o fuentes sin cambiar categorías. Las versiones menores añaden registros compatibles. Las mayores pueden cambiar supuestos o taxonomía. Los archivos anteriores se conservan.
Primera versión pública con seis categorías, 12 amenazas, 12 mitigaciones, pruebas esperadas, riesgos residuales, correspondencias con la evaluación y recursos traducidos.
El texto, la taxonomía, las relaciones y los archivos generados se publican con CC BY 4.0. El código y el resto del sitio quedan fuera de ese aviso.
Los archivos JSON y Markdown contienen los mismos identificadores y relaciones que aparecen abajo. Las versiones publicadas nunca se reescriben.
La impresión se ejecuta en el navegador y no envía datos del modelo ni de la evaluación.
La evaluación revisa seis prácticas en tu navegador. No solicita palabras de recuperación, claves privadas, direcciones, saldos ni archivos de cartera.
Usa el mapa general cuando necesites contexto o abre la guía especializada más cercana para actuar.
Evalúa seis prácticas de forma local y recibe prioridades explicadas sin introducir secretos de la cartera.
Separa los riesgos de red, precio, custodia, estafa, transacción, copia y herencia antes de elegir un control.
Une custodia, copias, control de acceso, verificación de pagos, recuperación y continuidad en un proceso.
Separa descubrimiento, autoridad, instrucciones y acceso a secretos para que los herederos no improvisen.