“Ni tus llaves, ni tus monedas” no es suficiente

Este eslogan (quizás acuñado por el evangelista de Bitcoin Andreas Antonopoulos) ha sido popular entre la comunidad de Bitcoin durante algún tiempo. “Claves” aquí se refiere a las claves privadas, lo que implica que aquellos que están en posesión de las claves privadas poseen los bitcoins controlados por esas claves.

Si bien este eslogan era cierto en los primeros días de Bitcoin, hoy es menos relevante y no cuenta toda la historia. La razón es la creciente sofisticación de la generación de claves y los contratos inteligentes, que incluyen, entre otros, multifirma.

Dado que la misión de Nunchuk es la proliferación de múltiples firmas, es crucial que el primer paso sea aclarar este concepto erróneo. El resto de este artículo explica por qué el eslogan anterior ya no es suficiente.

Volviendo a lo básico: direcciones de Bitcoin

Las direcciones de Bitcoin se construyen utilizando 2 componentes: un componente de datos y un componente de script que explica cómo se deben usar esos datos para bloquear los bitcoins.

En los primeros días de Bitcoin, tanto el componente de datos como el componente de script eran increíblemente simples. Los datos solían ser una única clave pública sin comprimir. El componente del guión fue igualmente sencillo. O bien involucró una sola operación, OP_CHECKSIG (P2PK), o una lista de operaciones un poco más larga (P2PKH), pero aún así altamente predecible. En aquellos días, las direcciones actuaban en última instancia como alias de las claves públicas.

En este contexto, “ni tus llaves, ni tus monedas” tiene sentido. Quien posea las claves privadas puede deducir las claves públicas. Y de las claves públicas, las direcciones.

La posesión de las claves privadas significa que:

BIP16 / BIP32

Las cosas comenzaron a cambiar con la introducción de capacidades de scripting más avanzadas, comenzando con BIP16 (P2SH). Con P2SH, el componente de script puede ser casi cualquier cosa. Un buen ejemplo son las recompensas de Peter Todd por encontrar colisiones de hash criptográficas. Pero un caso de uso más típico de P2SH implica carteras de múltiples firmas, donde los fondos están controlados por más de una clave pública.

Las direcciones de una billetera multifirma habilitada para P2SH ya no son predecibles, porque el orden de las claves públicas incluía cuestiones. Por ejemplo, una dirección multigrado P2SH 2 de 3 podría construirse de 6 formas diferentes, dependiendo de cómo ordenemos las 3 claves públicas. Si no hacemos una copia de seguridad del código redeemScript, que contiene este orden de claves multifirma, es posible que ni siquiera sepamos qué direcciones nos pertenecen. No todo está perdido, ya que podemos “probar” todas las permutaciones. Pero este enfoque de fuerza bruta es costoso y no escalable, como veremos más adelante.

Otro desarrollo ocurrió en el lado del componente clave de la dirección. Algún tiempo después de la creación de P2SH, llegaron las billeteras jerárquicas deterministas (HD), que luego se estandarizaron en BIP32. Antes de las billeteras HD, una billetera es simplemente una colección de claves privadas aleatorias. Los monederos HD crean una jerarquía de claves para que las claves privadas pertenezcan a la misma familia, todas generadas desde la misma raíz llamada clave maestra.

Las billeteras HD también hicieron que las direcciones fueran menos predecibles. Para cada dirección en una billetera HD, necesitamos saber de qué linaje descendió esa clave pública particular de la clave maestra. Esto se denomina ruta de derivación BIP32.

En resumen: la introducción de BIP16 y BIP32 significó que la posesión de las claves privadas ya no es suficiente. También es posible que necesitemos el código redeemScript (para BIP16) y las rutas de derivación (para BIP32) para poder “poseer” completamente bitcoins.

SegWit y Taproot

Las cosas se complicaron aún más con la activación de Segregated Witness, un conjunto de actualizaciones de protocolo muy esperado que solucionó problemas críticos como la maleabilidad de las transacciones.

SegWit introdujo un formato de dirección nuevo y mejorado, llamado Bech32.

El problema es que ahora hay más formas de generar direcciones a partir de una única clave maestra. Para cada tipo de dirección (ahora hay 3: heredado, segwit nativo y un híbrido llamado segwit anidado), nos enfrentamos a los mismos problemas de BIP16 y BIP32. ¡Así que terminamos con permutaciones sobre permutaciones de posibilidades de direcciones!

Niveles de permutaciones:

Aquí es donde estamos hoy. Tanto el componente clave como el componente de secuencia de comandos de la dirección se han vuelto muy complejos y la posesión de las claves privadas constituye solo una pequeña parte de la propiedad.

Durante este período, los proveedores de billeteras hicieron frente a esta creciente complejidad a través de sus propias formas ad-hoc y patentadas, lo que llevó a consecuencias desafortunadas. Primero, las billeteras se volvieron menos compatibles entre sí. Por ejemplo, para recuperar una billetera creada con un proveedor en otro, es necesario buscar “rutas de recuperación” mágicas y ejecutar manualmente scripts de conversión, un proceso que es propenso a errores. Otro efecto secundario negativo es la invención de conceptos deficientes como YPUB / ZPUB que complican aún más el proceso y confunden al usuario. Discutiremos YPUB / ZPUB y por qué deben evitarse por separado en otro artículo.

Pero no se detiene ahí. Pronto, Bitcoin tendrá capacidades de scripting aún más avanzadas, como Taproot. Cuando eso sucede, la cantidad de permutaciones de direcciones aumenta aún más.

Solución: lenguaje descriptor

Tal vez dándose cuenta de la urgencia de este problema, el desarrollador principal Pieter Wuille se propuso resolverlo. Pieter se dio cuenta de que lo que finalmente nos faltaba era un lenguaje de nivel superior para dominar esta monstruosa complejidad. Su solución, el lenguaje del descriptor de salida (descriptor para abreviar), resuelve elegantemente este problema.

El propósito del lenguaje descriptor es expresar con precisión cómo se derivan las claves y cómo se utilizan para crear direcciones.

Con descriptores, el usuario solo necesita hacer una copia de seguridad de 2 cosas para su billetera: las claves maestras (o semillas BIP39) y los descriptores. Ya no habría ninguna ambigüedad, ya sea en saber qué direcciones en la cadena de bloques nos pertenecen, o cómo recuperar la billetera utilizando herramientas de terceros.

En el futuro, es crucial que todas las carteras de Bitcoin pasen a una arquitectura de descriptor primero.

Los días de “ni tus llaves, ni tus monedas” han terminado. Quizás sea más apropiado ahora decir:

“Ni tus claves, ni tus descriptores, ni tus monedas”.

* Acerca de Nunchuk: Nunchuk es un producto de Enigmo, una empresa privada con sede en Singapur. Nuestra misión es llevar la tecnología multifirma al mayor número de personas posible, y Nunchuk es el primer paso. Visite nuestro sitio web en https://nunchuk.io o síganos en Twitter @ nunchuk_io .

* Acerca de Nunchuk Journal: una colección de artículos que tratan sobre todo lo relacionado con Bitcoin. La revista documenta nuestros procesos de pensamiento en la creación de Nunchuk, cómo las cosas impactan al usuario y las observaciones sobre la industria en general.