P2MR: cómo funciona técnicamente la primera dirección cuántica-resistente de Bitcoin

La discusión sobre la potencial amenaza cuántica ya tuvo un primer resultado concreto en el ecosistema Bitcoin: la propuesta de mejora BIP-360, aún en estado de revisión, que define un formato de dirección llamado Pago a Raíz de Merkle (P2MR). Su objetivo poscuántico es cerrar una brecha en los formatos de direcciones de Bitcoin actuales sobre la visibilidad de la clave pública.

Hoy, Taproot es la única actualización de Bitcoin que permite construir árboles de scripts, que son estructuras que organizan distintas condiciones de gasto para una misma dirección, de modo que, al gastar los fondos, alcanza con revelar la condición efectivamente usada y no el resto. Esto permite crear condiciones de gasto más complejas y personalizadas.

No obstante, Taproot también es el único formato activo que, al utilizar ese mecanismo de árbol de scripts, revela en la cadena la clave pública de esa dirección desde el momento en que se crean los fondos. Esa exposición es el vector de ataque cuántico: un hardware suficientemente potente podría derivar la clave privada a partir de la pública expuesta y adueñarse de los fondos.

Asimismo, formatos más simples y anteriores, como P2WPKH (pago a hash de clave pública por testigo) o P2SH (pago a hash de script), ya evitan esa exposición mientras los fondos no se gastan, pero no ofrecen la flexibilidad de un árbol de scripts de Taproot.

De este modo, P2MR busca combinar ambas propiedades: mantener oculta la clave pública hasta que los fondos se gasten y, al mismo tiempo, conservar la flexibilidad que ofrecen los árboles de scripts, algo que hasta ahora no permitía ningún formato de salida nativo de Bitcoin.

La construcción técnica de P2MR

BIP-360 tomó como base el código de Taproot y de Tapscript (BIP-342), el lenguaje utilizado por Bitcoin para definir las condiciones de gasto dentro de los scripts de Taproot, pero eliminó una de las dos formas de gastar los fondos: la vía de clave pública. Por eso, P2MR puede entenderse como Taproot sin gasto por clave.

El funcionamiento de P2MR se basa en una estructura conocida como árbol de Merkle. Cada script se transforma primero en un valor criptográfico de 32 bytes mediante un proceso denominado TapLeaf. Después, esos valores se combinan de a pares mediante la función TapBranch, que unifica los hashes del árbol hasta obtener un único resultado: la raíz de Merkle. Esta raíz es el compromiso criptográfico que identifica el conjunto de condiciones de gasto de la dirección P2MR: alcanza con conocerla para verificar que un script determinado efectivamente formaba parte del árbol original, sin necesidad de conocer el resto de los scripts que lo integran.

P2MR conserva así la posibilidad de reunir distintas condiciones de gasto en un árbol de scripts, pero sin comprometer una clave pública en la dirección: se basa únicamente en la raíz de Merkle. Cuando llega el momento de gastar los fondos, el usuario revela solo el script que contiene la condición que está utilizando (por ejemplo, una regla que permite a un heredero recuperar los fondos después de un plazo determinado) junto con la ruta de hashes TapBranch que demuestra que ese script formaba parte del árbol definido cuando se crearon los fondos. El resto de las condiciones permanece oculto.

La ausencia de la clave pública modifica la estructura que Bitcoin utiliza para identificar los fondos. Una salida P2MR está formada por OP_2 seguido de la raíz de Merkle de 32 bytes, y sus direcciones utilizan el prefijo bc1z, de acuerdo con el documento técnico de BIP-360. A diferencia de Taproot, P2MR no combina esa raíz con ninguna clave interna, y así elimina la vía de gasto que podría exponerla y dejarla vulnerable ante un futuro ordenador cuántico suficientemente potente.

¿Cómo se gasta una salida P2MR?

Para desbloquear una salida P2MR, quien gasta los fondos debe completar el testigo (witness), el campo de la transacción que, desde la actualización SegWit, contiene las pruebas necesarias para autorizar el gasto sin sumar peso a la parte principal de la transacción.

En P2MR, ese testigo se compone de tres partes:

• Los elementos de pila que necesite el script (los datos, como una firma, que se van apilando y usando a medida que el script se ejecuta).

• El script de la hoja correspondiente (TapLeaf, la hoja puntual del árbol que efectivamente se usa para gastar).

• Un bloque de control formado por un byte de control y la ruta de autenticación de Merkle hacia esa hoja, la prueba de que esa hoja pertenece al árbol original.

La diferencia con Taproot es puntual pero central: el bloque de control de P2MR no incluye ninguna clave pública interna, simplemente porque esa clave no existe en este tipo de salida. Esa ausencia se refleja de forma directa en el peso del testigo, y ese peso es precisamente lo que determina cuánta comisión paga cada gasto: cuantos menos bytes ocupe, menor es el costo. Un testigo P2MR de un árbol de una sola hoja pesa 103 bytes, de acuerdo con el documento de BIP-360:

• Frente a un gasto por clave en Taproot (66 bytes), P2MR resulta 56% más pesado.

• Frente al peso promedio de una firma de transacciones de Bitcoin del esquema ECDSA, de unos 72 bytes, según mainnet.observer, el testigo de P2MR resulta 43% más pesado, aunque la comparación no es estrictamente equivalente, ya que el dato de ECDSA corresponde solo a la firma, mientras que el peso de P2MR incluye también el script y el bloque de control.

• Frente a un gasto por script en Taproot con la misma estructura (135 bytes, la suma de los 103 bytes de P2MR más los 32 bytes que ocupa la clave interna en el bloque de control), en cambio, P2MR pesa 24% menos, porque no necesita incluir esa clave.

El desarrollador Anthony Towns calculó, en un intercambio sobre P2MR en la lista de correo de desarrolladores de Bitcoin, que sumar una firma poscuántica a una salida de este tipo representa hoy un sobrecosto cercano al 14% frente a un gasto por clave en Taproot, pero ese número baja a 7% con esquemas como SHRINCS y a apenas 1% con esquemas del tipo Winternitz.

Adicionalmente, P2MR sigue firmándose hoy con el esquema Schnorr (BIP-340), no con ECDSA, y al ser una estructura nativa de Tapscript es compatible con Lightning Network (LN), BitVM, Ark, las configuraciones de multifirma y los bloqueos de tiempo (timelocks), y está diseñado para que, en el futuro, alguna de las hojas de su árbol pueda incorporar una firma poscuántica sin necesidad de cambiar de tipo de salida, tal como describe el sitio especializado Post Quantum.

Lo que P2MR no resuelve y el debate técnico

El documento de BIP-360 delimita con precisión lo que P2MR resuelve y lo que no:

• Protege contra los llamados ataques de exposición prolongada, cuando una clave pública queda expuesta en la cadena durante un tiempo indefinido, pero no contra los ataques de exposición corta, los que ocurren mientras una transacción todavía no fue confirmada y permanece brevemente en el mempool esperando a que una computadora cuántica intente romperla antes de que se confirme.

• Tampoco introduce ninguna firma poscuántica: depende de que el usuario no reutilice direcciones, porque volver a usar la misma dirección expone la clave pública antes de tiempo y reabre el mismo riesgo que P2MR busca evitar.

Finalmente, al cierre de este artículo, BIP-360 figura aún en estado borrador dentro del repositorio oficial, en donde se fusionó en febrero de 2026. Ese estado significa que la propuesta no está activada en la red principal de Bitcoin y que, hasta ahora, no existe un cronograma de activación programado para incorporarla.