Clave pública comprimida

Todo punto de secp256k1 tiene dos valores posibles de la y para una x dada, así que registrar cuál de ellos es cuesta un solo byte en lugar de 32. Las billeteras generan claves comprimidas de forma predeterminada desde Bitcoin Core 0.6, publicada en marzo de 2012, y los bytes ahorrados se restan del tamaño de cada entrada que usted gaste después. Gastar más barato es toda la ventaja, y el formato es invisible en el uso diario.

Cómo funciona

La compresión de claves públicas es álgebra y no compresión de datos. La ecuación de la curva, en la que la y al cuadrado es igual a la x al cubo más 7, tiene como máximo dos soluciones para la y en cualquier x dada, y esas dos soluciones son siempre un número par y un número impar. Por tanto, guardar la x más un bit de información sobre qué solución corresponde basta para que cualquiera recupere el punto con exactitud, resolviendo la ecuación y eligiendo la raíz que tiene la paridad correcta.

La codificación coloca ese bit en el byte inicial. Un prefijo 0x02 significa que el valor de la y es par, 0x03 que es impar, y los 32 bytes que siguen son la coordenada x. Longitud total: 33 bytes. El formato antiguo se identifica con un prefijo 0x04 y lleva ambas coordenadas completas, 65 bytes en total. Cualquier software que lea una clave puede distinguir los dos formatos solo por el primer byte, y así es como las billeteras siguieron siendo compatibles durante la transición.

Los 32 bytes ahorrados recaen en lugares distintos según el tipo de salida. En una entrada heredada (legacy), la clave está en el script de desbloqueo y se cobra con el peso completo de sus bytes, así que 32 bytes cuestan 32 vbytes, alrededor de 640 satoshis con una comisión por vB de 20 sat/vB. En una entrada SegWit, la clave está en el testigo, que se descuenta por un factor de cuatro, así que los mismos 32 bytes cuestan 8 vbytes. Ninguna de las dos cifras es llamativa por sí sola, y ambas se repiten en cada entrada de cada transacción que usted llegue a firmar.

Dónde aparece

Las claves comprimidas se ven en los datos de transacciones en bruto. Abra cualquier gasto reciente en un explorador de bloques y la clave pública del testigo o del script empezará por 02 o 03, seguida de 64 caracteres hexadecimales. Las claves que empiezan por 04 son reliquias.

El formato también decide qué aspecto tiene una dirección. Calcular el hash de una clave comprimida da un resultado distinto del que se obtiene al calcular el hash de la versión sin comprimir de la misma clave, así que una clave privada puede corresponder a dos direcciones heredadas completamente distintas, con saldos separados. Las billeteras lo resuelven por convención y no por ingenio: todo lo que se deriva mediante BIP-32, que abarca todas las billeteras con frase semilla de uso habitual, está comprimido de principio a fin, y una cadena de caracteres en formato de importación de billetera que empieza por K o L anuncia que la clave pertenece al lado comprimido de esa bifurcación.

SegWit eliminó la ambigüedad para siempre. BIP-143 prohíbe las claves sin comprimir dentro de los programas de testigo de versión 0, así que, por esa regla, toda dirección bc1q está comprimida, y Taproot fue más allá al definir claves x-only (solo coordenada x) de 32 bytes que prescinden por completo del byte de paridad.

Clave pública comprimida frente a clave pública sin comprimir

La forma comprimida y la forma sin comprimir codifican el mismo punto, y la diferencia está solo en lo que hay que anotar. La forma comprimida guarda la x; cuando hace falta, deriva la y, lo que cuesta unos pocos microsegundos de aritmética y ahorra 32 bytes para siempre. La forma sin comprimir almacena la y directamente, lo que ahorraba cálculo en el hardware de 2009 y hoy no aporta nada. Como las dos cadenas de bytes difieren, al calcular su hash se obtienen direcciones distintas, y es esa discrepancia, más que el número de bytes, lo que de vez en cuando deja atrapados fondos de billeteras muy antiguas.