Hashcash

Anna quiere enviar un correo a Pavel. Mandar otra copia apenas le cuesta nada, pero quien envía millones de anuncios disfruta de la misma ventaja. Hashcash introduce un pequeño obstáculo: el ordenador del remitente debe generar primero un sello informático. El coste consiste en tiempo y energía, no en pagar a una empresa postal. Adam Back anunció su implementación el 28 de marzo de 1997 y publicó su descripción técnica en 2002. Cynthia Dwork y Moni Naor ya habían estudiado una idea similar en 1992. Hashcash forma parte de esta búsqueda de formas de limitar los abusos de la red. [1] [12]

Un hash es una huella de longitud fija calculada a partir de unos datos. El programa de Anna modifica un valor del sello y calcula de nuevo su huella hasta que empieza por suficientes bits a cero. Un bit es un dígito binario: cero o uno. Si se exigen b ceros, cada intento tiene una probabilidad aproximada de éxito de 2^-b y hacen falta, de media, 2^b intentos. Para b = 20 son 1048576 cálculos de media, no una cantidad exacta obligatoria. A veces hay suerte enseguida y otras se tarda más. Pavel comprueba el sello terminado con un solo cálculo de hash, aunque también debe revisar sus datos y las condiciones de aceptación. [10] [11]

Si Anna pudiera adjuntar un sello a un millón de mensajes, el obstáculo perdería su sentido. Por eso el sello identifica al destinatario o servicio e incluye una fecha. El receptor comprueba su validez y registra los sellos aceptados para rechazar su reutilización, llamada replay. Ni una fecha ni la vinculación al contenido impiden por sí solas reenviar exactamente el mismo mensaje. Hashcash no dispone de un registro global compartido de sellos gastados: el servicio receptor se encarga de esa comprobación. Que el hash sea correcto no basta para aceptar otra vez el sello. [11] [12]

El servicio receptor decide la dificultad. Cada bit adicional a cero duplica aproximadamente el trabajo medio. Una exigencia baja apenas frena al remitente de spam; una alta también perjudica al usuario corriente. El número 20 es un ejemplo, no un estándar de seguridad eterno. Además, los mismos intentos llevan distinto tiempo en un teléfono antiguo y en un ordenador rápido. El servicio debe considerar los dispositivos, la caducidad y su propia capacidad. Hashcash no impone a todo el mundo una cantidad universal de segundos. [10] [11]

El trabajo informático no distingue a una persona respetuosa de un atacante. Quien disponga de muchos ordenadores o de una botnet, una red de dispositivos comprometidos, puede repartir el trabajo y cargar parte del coste a otras personas. Entretanto, el usuario normal consume batería. Hashcash pretende cambiar los costes del ataque, no garantizar que desaparezca el spam. Tampoco cifra el mensaje, acredita la identidad civil ni asegura la entrega. Es una condición de aceptación que el servicio puede combinar con otras defensas. [10]

La versión 1 utiliza el formato 1:bits:date:resource:ext:rand:counter. Sus campos indican versión, dificultad declarada, fecha, destinatario o servicio, extensiones, un valor aleatorio y un contador que cambia. El campo bits indica cuántos bits iniciales a cero afirma el remitente que tiene la huella, no cuántos intentos hizo realmente el ordenador. Estos nombres pertenecen al formato técnico y no se traducen. La implementación clásica aplica SHA-1 a toda la cadena. Debe cumplir la condición la huella real, no solo el número escrito en bits. Describimos un formato histórico, no una recomendación de SHA-1 para diseños de seguridad nuevos. Bitcoin emplea otro formato de datos y otra función hash. [11] [13]

Aquí se busca una entrada cuya huella tenga un comienzo determinado. Esa entrada se denomina partial preimage: su huella coincide con la parte exigida, mientras que el resto puede ser cualquiera. Una colisión consiste, en cambio, en dos entradas distintas con la misma huella. Algunos textos históricos usan la expresión menos precisa partial collision, pero la distinción es importante. Un ataque que encuentre colisiones de SHA-1 no resuelve automáticamente la búsqueda del prefijo exigido. Eso tampoco convierte SHA-1 en una opción general adecuada para la seguridad actual. [10] [11] [13]

En 2004, Hal Finney presentó RPOW, Reusable Proofs of Work. El usuario podía entregar una prueba de trabajo y recibir un token nuevo; una transferencia posterior invalidaba el anterior y lo sustituía por otro. Reutilizar no significaba copiar libremente el mismo sello. El sistema dependía de un servidor con un módulo seguro IBM 4758 y de la verificación remota del programa ejecutado. Reducía la confianza necesaria en el operador, pero mantenía supuestos sobre el hardware y su fabricante. RPOW fue un precursor experimental, no el consenso descentralizado de Bitcoin. [7] [15]

Bitcoin Whitepaper cita expresamente el Hashcash de Back. Satoshi aprovechó la misma diferencia: encontrar un resultado exige probar una y otra vez, pero los demás pueden comprobarlo fácilmente. Los mineros de Bitcoin buscan una cabecera de bloque válida, que resume un bloque de transacciones y hace referencia al anterior. Utilizan double SHA-256, dos aplicaciones consecutivas de SHA-256, y comparan el resultado con un límite numérico llamado target. No es un sello de correo SHA-1 colocado en una cartera. Comparten el principio, no el sistema completo. [8] [14]

El franqueo pone precio a una solicitud. El dinero necesita resolver además cuál de dos transferencias incompatibles es válida. Bitcoin enlaza bloques y sus nodos eligen, entre las ramas válidas, la cadena con mayor trabajo acumulado. Los nodos, los ordenadores que comprueban las reglas, también verifican las transacciones y la emisión permitida. Ni una cantidad enorme de trabajo vuelve válida una transacción inválida. Hashcash aportó una pieza importante; su combinación con otras reglas permitió una historia monetaria compartida sin administrador central. [8] [9]