De una estrategia de custodia a requisitos concretos para elegir herramientas

Elegir herramientas demasiado pronto suele invertir el proceso: primero aparece un producto atractivo y después intentamos construir la arquitectura alrededor de él. Este artículo propone el orden contrario: partir de tu estrategia de custodia, traducirla en requisitos concretos y verificables y, solo entonces, comprobar qué hardware y qué software los cumplen de verdad.

No vas a encontrar aquí una lista de marcas. Vas a encontrar un método para que cualquier elección se pueda explicar y, sobre todo, comprobar.

Primero la estrategia y el rol

Una estrategia de custodia responde a preguntas que no dependen de ningún producto: de qué te quieres proteger, cómo podrías perder los fondos, quién interviene y durante cuánto tiempo debe funcionar el sistema. Si todavía no lo tienes claro, empieza por entender por qué una wallet no es una arquitectura de custodia y qué cambia entre custodia por terceros, autocustodia y custodia colaborativa.

De esa estrategia salen cuatro bloques de información:

• Amenazas: robo físico, malware en el ordenador, phishing, coacción, errores propios o desaparición de un proveedor.
• Escenarios de pérdida: se rompe un dispositivo, se pierde una copia, la aplicación deja de existir, fallece quien custodia.
• Personas: quién firma, quién coordina, quién recupera y qué nivel técnico tiene cada una.
• Horizonte: no es lo mismo una wallet para pagos de este mes que una reserva que debe poder recuperarse dentro de quince años.

Con eso claro aparece el rol de cada pieza. Una herramienta puede ser excelente como firmante operativo y mediocre como llave de bóveda. El requisito debe describir la función antes de nombrar una marca. Distinguir firmante, coordinador y nodo evita pedirle a un dispositivo lo que en realidad corresponde a otra pieza del sistema.

De la estrategia a requisitos verificables

Las decisiones de estrategia se traducen en condiciones verificables: compatibilidad multisig, pantalla, air-gap, exportación, portabilidad, recuperación o diversidad respecto a otro componente. La clave está en la palabra verificable: «es seguro» no es un requisito; «muestra la dirección completa en su propia pantalla» sí lo es.

• Verificación de dirección en pantalla. Si una amenaza es el malware en el ordenador, el firmante debe poder mostrar la dirección de recepción y los datos del gasto en su propia pantalla, sin depender de lo que enseñe el ordenador.
• Soporte PSBT. Si quieres separar quién prepara la transacción de quién la firma, el coordinador y el firmante deben intercambiar transacciones parcialmente firmadas por el medio que hayas decidido (cable, QR o tarjeta).
• Exportar el descriptor. Si tu recuperación no puede depender de una aplicación concreta, el coordinador debe permitir exportar el descriptor de la wallet, que describe qué claves, qué derivaciones y qué tipo de script la forman.
• Interoperabilidad y recuperación con otro software. Si el escenario «la aplicación desaparece» está en tu lista, la wallet debe poder reconstruirse en un software distinto del original.
• Código abierto o auditable. Si no quieres depender solo de la palabra del fabricante, el código debe estar publicado y la descarga debe poder verificarse.
• Conexión a nodo propio. Si la privacidad o la independencia frente a servidores ajenos forman parte de la estrategia, el coordinador debe permitir configurar tu propio nodo como fuente de datos.
• Soporte multisig. Si la estrategia reparte el poder de firma, todas las piezas deben admitir el quorum y el tipo de script elegidos, y el firmante debe poder comprobar que una dirección pertenece a esa configuración y no a otra.
• Mantenimiento del proyecto. Si el horizonte es largo, importa quién mantiene la herramienta, con qué frecuencia publica versiones y cómo comunica los fallos de seguridad.

Cómo probar cada requisito

Un requisito que no has probado es una suposición. Haz las pruebas con una wallet de laboratorio o con importes pequeños, nunca con la reserva completa.

• Dirección en pantalla: genera una dirección de recepción en el coordinador y compárala carácter a carácter con la que muestra el dispositivo, como se explica en comprueba una dirección Bitcoin en la pantalla de tu hardware wallet.
• PSBT: prepara un gasto pequeño, fírmalo en el firmante y revisa en su pantalla destino, importe, comisión y cambio antes de transmitir. El recorrido completo está en PSBT completa: prepara, firma offline y transmite con seguridad.
• Descriptor: expórtalo, impórtalo en otro software como wallet de solo lectura y comprueba que las primeras direcciones coinciden.
• Recuperación con otro software: reconstruye la wallet de prueba en una aplicación distinta y confirma direcciones y saldo. Es la idea de recuperar una wallet sin la aplicación original.
• Código y descargas: localiza el repositorio público, revisa que las versiones publicadas tengan firmas o hashes y verifica al menos una descarga tú mismo.
• Nodo propio: configura tu nodo en el coordinador y comprueba en sus ajustes que no queda ningún servidor público como alternativa automática.
• Multisig: crea un quorum de prueba con los dispositivos reales, recibe una cantidad pequeña y gasta usando exactamente las firmas mínimas.
• Mantenimiento: revisa la fecha de la última versión, las notas de cambios y si existe un canal público para avisos de seguridad.

El conjunto también debe funcionar

Elegir buenos componentes por separado no garantiza que el sistema completo sea interoperable y recuperable. La última prueba es siempre del conjunto: recibir, gastar y recuperar con las piezas reales, en el orden real y siguiendo el procedimiento escrito que usaría otra persona.

Obligatorio, importante y deseable

No todo criterio debe excluir. Separar niveles evita descartar una herramienta por una preferencia secundaria o aceptar otra que falla en una condición esencial.

• Obligatorio: si no se cumple, la herramienta queda fuera. Por ejemplo, verificar direcciones en pantalla para un firmante de bóveda.
• Importante: pesa mucho, pero puede compensarse con otra pieza o con un procedimiento.
• Deseable: comodidad o preferencia; desempata, pero no decide.

Además, cada requisito necesita evidencia y fecha. Una característica técnica puede cambiar con firmware o software. Por eso la comparación debe registrar fuente, fecha de verificación y momento de revisión. «Lo leí en un foro» no es evidencia; «lo probé el día tal con la versión tal» sí lo es.

Checklist de requisitos antes de elegir herramientas

• He escrito mis amenazas, escenarios de pérdida, personas y horizonte.
• Cada pieza tiene un rol definido: firmante, coordinador, nodo o copia.
• Cada requisito está marcado como obligatorio, importante o deseable.
• El firmante muestra en su pantalla direcciones, importes y cambio.
• Firmante y coordinador intercambian PSBT por el medio que he elegido.
• Puedo exportar el descriptor y guardarlo junto a mi plan de recuperación.
• He recuperado la wallet de prueba en otro software.
• El código está publicado y he verificado al menos una descarga.
• El coordinador funciona con mi propio nodo, si la estrategia lo exige.
• Si uso multisig, todas las piezas admiten mi quorum y he gastado con él.
• He revisado el mantenimiento del proyecto y he anotado fuente y fecha de cada comprobación.
• He probado el conjunto completo, no solo cada componente.

Errores habituales

• Elegir por marca. Una marca conocida no te dice si cumple tus requisitos; solo te dice que es conocida.
• Elegir por popularidad. Que mucha gente use una herramienta no significa que encaje en tu rol ni en tu horizonte. Lo popular para pagos puede ser inadecuado para una reserva.
• Confiar en la ficha técnica. «Compatible con multisig» o «exporta descriptor» en una web no sustituye a hacer la prueba con tu configuración y tu versión.
• Probar solo con la app original. Si nunca has recuperado fuera de ella, tu interoperabilidad es teórica.
• Tratar todos los criterios igual. Sin niveles, una preferencia estética puede pesar tanto como la verificación en pantalla.
• No volver a revisar. Las herramientas cambian; una comprobación sin fecha envejece sin que lo notes.

Idea clave: una recomendación defendible puede explicar qué requisito cumple cada herramienta y con qué evidencia.

Qué debes llevarte

• Antes de elegir herramientas, escribe tu estrategia: amenazas, escenarios de pérdida, personas y horizonte.
• Define el rol de cada pieza antes de mirar productos.
• Convierte cada decisión en un requisito verificable y clasifícalo como obligatorio, importante o deseable.
• Prueba cada requisito con importes pequeños y anota fuente, versión y fecha.
• La prueba final es del conjunto: recibir, gastar y recuperar con otro software.
• No confíes en la marca ni en la popularidad. Comprueba.

⌕