¿Qué es Hashcash? 3f43v

Bitcoin usa la función Proof of Work de hashcash como núcleo de minería de Bitcoin. Todos los mineros bitcoin, ya sea U, GPU, FPGA o ASIC, están gastando su esfuerzo creando pruebas de trabajo hashcash que actúan como un voto en la evolución de blockchain y validan el registro de transacciones blockchain. 483r65

Al igual que muchos algoritmos criptográficos, hashcash usa una función hash como elemento básico, del mismo modo que las firmas HMAC o RSA se definen en una función hash conectable (comúnmente indicada por la convención de nomenclatura de algoritmo-hash: HMAC-SHA1, HMAC- MD5, HMAC-SHA256, RSA-SHA1, etc.), hashcash se puede instanciar con diferentes funciones, hashcash-SHA1 (original), hashcash-SHA256 ^ 2 (bitcoin), hashcash-Scrypt (iter = 1) (litecoin).

Historia 4a4s17

La función de prueba de trabajo de hashcash fue inventada en 1997 por el Dr. Adam Back , y se propuso para usos anti-DoS, incluida la prevención: uso indebido anónimo de puerta de enlace y mail2news, nombre de nym en cuclillas en nymservers (servidores de remansos pseudónimos replicables), así como regulación general contra el correo no deseado y abuso de la red general.

Antes de bitcoin, SpamAssasin usaba hashcash y (con un formato incompatible) de Microsoft (con el nombre de "matasellos de correo electrónico") en hotmail, exchange, outlook, etc. y por la red de anonimato i2p, mixmaster anonymous remailer components y otros sistemas.

Hashcash también fue utilizado por el precursor de bitcoin RPW de Hal Finney como una forma de extraer monedas. La propuesta de dinero B de Wei Dai y los precursores de bitcoin de la propuesta BitGold de Nick Szabo también se propusieron en el contexto de la minería de hashcash.

Opciones de función hash 1161q

En el algoritmo original de 1997, hashcash usó SHA1 porque en ese momento, este era el hash de facto y recomendado por el NIST, y el hash defacto MD5 anterior había comenzado recientemente a mostrar signos de debilidad. Bitcoin que se especifica / lanza en 2008/2009 usa SHA256. En realidad, no existe una razón fuerte por la que SHA1 no haya funcionado, hashcash depende solo de la propiedad de resistencia de preimagen parcial (seguridad hasta el tamaño del hachís, 160 bits con SHA1) y no la dureza por colisión del cumpleaños (seguridad de hasta 80 bits) , por lo que el hash SHA1 es lo suficientemente grande.

Bitcoin está construido de todos modos con seguridad de 128 bits porque se usa ECDSA de 256 bits, que también ofrece seguridad de 128 bits. Sin embargo, SHA256 es la elección correcta y más conservadora porque incluso SHA1 ha comenzado a mostrar algunas debilitaciones, aunque solo en la colisión de cumpleaños, no en la segunda preimagen.{PAGEBREAK}

Double Hash 4y5120

Bitcoin está utilizando dos iteraciones hash (denotadas SHA256 ^ 2, es decir, "SHA256 función al cuadrado") y la razón de esto se relaciona con un ataque parcial en el hash SHA1 más pequeño pero relacionado. La resistencia de SHA1 a los ataques de cumpleaños se ha roto parcialmente a partir de 2005 en O (2 ^ 64) frente al diseño O (2 ^ 80). Si bien hashcash depende de la resistencia a la imagen previa y, por lo tanto, no es vulnerable a los ataques de cumpleaños, un método genérico para endurecer SHA1 contra el ataque de colisión de cumpleaños es iterarlo dos veces.

Hasta el momento, no existe un ataque comparable contra SHA256, sin embargo, como el diseño de SHA256 es similar a SHA1, probablemente sea defensivo para las aplicaciones usar doble SHA256. Y esto es lo que hace Bitcoin, no es necesario dada la confianza de hashcash en la seguridad de la preimagen, pero es un paso defensivo contra futuros desarrollos criptoanalíticos. El ataque a SHA1 y en principio a otros hashes de diseño similar como SHA256, también fue la motivación para la competencia de diseño de NIST SHA3, que todavía está en curso.

Future Hash 4x5q53

Una vez que el concurso NIST SHA3 haya finalizado, Bitcoin podría en el futuro considerar adoptar hashcash-SHA3 como una actualización de seguridad (por ejemplo, una invocación única de SHA3 frente a una invocación doble de SHA256). Parece claro desde el salto SHA1, y SHA256 es un diseño similar, que anteriormente había un malentendido sobre la seguridad de las funciones hash contra colisiones de cumpleaños, y los finalistas SHA3 todos apuntan a solucionar ese problema.

Un aspecto de relevancia para hashcash-SHA3 es que hay cierto debate dentro del proceso de comentarios del NIST sobre la propuesta de debilitar la resistencia de SHA3 a los ataques de preimagen de hasta 128 bits (frente al tamaño de hash completo como en los hash anteriores). La motivación es una pequeña ganancia de rendimiento, con la lógica de que algunos algoritmos de enchufable con hash no se basan en la resistencia de imagen completa de longitud completa. La propuesta ha recibido comentarios negativos significativos debido a que crea una suposición de seguridad no estándar (en comparación con todos los valores hash anteriores), y por lo tanto crea riesgo y necesitaría todos los algoritmos conectables mediante hash (como HMAC, RSA, DSA, hashcash, etc.) ser reexaminado caso por caso para ver si SHA3 es seguro de usar con ellos;

Riesgos criptoanalíticos 45165j

Un problema práctico con el cambio a hashcash-SHA3 es que invalidaría todos los [hardware de minería ASIC] (/ bitcoin-mining-hardware /) existente, y también es un cambio poco probable, salvo en caso de riesgo de seguridad; no hay ninguna indicación de que SHA1 o SHA256, o SHA256 ^ 2 sean vulnerables al ataque previo a la imagen, por lo que la motivación no se encuentra en ausencia de nuevos desarrollos criptoanalíticos. Además, incluso si SHA256 ^ 2 se hizo más fácil debido al ataque criptoanalítico, y los mineros comenzaron a usar lo que sea que fuera el nuevo enfoque algorítmico, no necesariamente importa ya que [la dificultad simplemente se adapta a él] (/ what-is-bitcoin-mining-difficulty /). Sin embargo, un posible efecto colateral sería que introduciría más intercambios de memoria o precomputación que podrían hacer que los ASIC no sean rentables, o dar ventajas a las personas con grandes recursos para hacer los pre-cálculos.

De todos modos, esto es toda especulación sobre si y hasta que cualquier preimagen que afecte a los ataques criptoanalíticos se encuentre en SHA256.

Función Hashcash 2r6f5v

El algoritmo hashcash es relativamente simple de entender. La idea se basa en una propiedad de seguridad de valores hash criptográficos, que están diseñados para ser difíciles de invertir (los denominados propiedad unidireccional o resistente a la imagen previa). Puedes calcular y de x a bajo costo y = H (x), pero es muy difícil encontrar x dado solo y. Una inversión de hash completa tiene un tiempo de ejecución de fuerza bruta computacionalmente inviable, siendo O (2 ^ k) donde k es el tamaño de hash p. Ej. SHA256, k = 256, y si se encontró una imagen previa, cualquiera podría verificarla de manera muy eficiente computar un hash, entonces hay una gran asimetría en la minería de imágenes previas (computacionalmente no factible) frente a la verificación (una sola invocación de hash).

Una segunda pre-imagen hash significa dada una preimagen x de hash y donde y = H (x), la tarea es encontrar otra imagen previa de hash y: x 'para que y = H (x'). Esto no debe confundirse con una colisión de cumpleaños que consiste en encontrar dos valores x, x 'para que H (x) = H (x'), esto se puede hacer en un trabajo mucho más bajo O (sqrt (2 ^ k)) = O (2 ^ (k / 2)) porque puede proceder calculando muchos valores H (x) y almacenándolos hasta que encuentre un par coincidente. Se necesita mucha memoria, pero hay compensaciones de tiempo de memoria.

La versión 0 del protocolo hashcash (1997) utilizó una segunda preimagen parcial, sin embargo, la versión posterior 1 (2002) usa preimágenes parciales de una cadena bastante elegida, en lugar de dígitos de pi o algo arbitrario, 0 ^ k (es decir, todos 0 cadena) se utiliza por conveniencia, por lo que el trabajo es encontrar x tal que H (x) = 0. Esto también es equitativo y solo requiere una invocación de hash para verificar contra dos con 2º pre-imágenes parciales. (Esta optimización fue propuesta por Hal Finney e independientemente por Thomas Boschloo).

Para facilitar el trabajo, la definición de una preimagen parcial es encontrar x tal que H (x) / 2 ^ (nk) = 0 donde / es el cociente entero de la división, n es el tamaño de la salida de hash ( n = 256 bits para SHA256) yk es el factor de trabajo, es decir, los primeros k bits de la salida de hash son 0. Entonces, por ejemplo, k = 20 requiere un promedio de 1 millón de intentos. En realidad, es la salida que coincide parcialmente, no la imagen previa, por lo que podría llamarse más exactamente una imagen previa con una coincidencia de salida parcial, sin embargo, la preimagen parcial es efectivamente una mano corta para eso.{PAGEBREAK}

Añadiendo propósito 445w2s

Si la imagen parcial previa x de y = H (x) es aleatoria, es solo una prueba de trabajo desconectada para nada, todos pueden ver que usted hizo el trabajo, pero no saben por qué, por lo que los s podría reutilizar el mismo trabajo para diferentes servicios. Para hacer que la prueba de trabajo se vincule a un servicio o propósito, el hash debe incluir s, una cadena de servicio para que el trabajo se convierta en encontrar H (s, c) / 2 ^ (nk) = 0. El minero varía en el contador c hasta que esto sea cierto. La cadena de servicio podría ser un nombre de dominio de servidor web, una dirección de correo electrónico de destinatarios, o en bitcoin un bloque del ledger blockchain de bitcoin.

Un problema adicional es que si varias personas están extrayendo, usando la misma cadena de servicio, no deben comenzar con la misma x o pueden terminar con la misma prueba, y cualquiera que lo mire no respetará una copia duplicada del mismo trabajo. como podría haber sido copiado sin trabajo, el primero en presentarlo será recompensado, y otros encontrarán su trabajo rechazado. Para evitar el riesgo de perder el trabajo de esta manera, es necesario que haya un punto de partida aleatorio, por lo que el trabajo se convierte en encontrar H (s, x, c) / 2 ^ (nk) = 0 donde x es aleatorio (por ejemplo, 128 bits para que sea estadísticamente inviable que dos s inicien maliciosa o accidentalmente en el mismo punto), y c es el contador que varía, y s es la cadena de servicio.

Esto es lo que tiene la versión 1 de hashcash y bitcoin. De hecho, en bitcoin, la cadena de servicio es la base de monedas y la base de monedas incluye la dirección de recompensa de los destinatarios, así como las transacciones para validar en el bloque. Bitcoin en realidad no incluye un punto de inicio aleatorio x, reutilizando la dirección de recompensa como el factor de aleatorización para evitar colisiones para este propósito de punto de inicio aleatorio, lo que ahorra 16 bytes de espacio en la base de monedas. Para privacidad, bitcoin espera que el minero use una dirección de recompensa diferente en cada bloque exitoso.

Trabajo más preciso 19g2v

Hashcash como se propuso originalmente tiene trabajo 2 ^ k donde k es un número entero, esto significa que la dificultad solo se puede escalar en potencias de 2, esto es un poco más simple ya que puedes ver y medir completamente la dificultad solo contando 0s en hexadecimal / binario y adecuado para usos anteriores. (Muchas de las opciones de diseño de hashcash están motivadas por la simplicidad).

Pero debido a que Bitcoin necesita un control de trabajo más preciso y dinámico (para enfocar con precisión el intervalo de bloque de 10 minutos), cambia k para que sea un punto fraccional (coma flotante), por lo que se vuelve a encontrar H (s, x, c) <2 ^ (nk) que es equivalente si k es un número entero. Bitcoin define target = 2 ^ (nk), por lo que el trabajo se puede escribir de forma más simple para encontrar H (s, x, c) <target. Por supuesto, debido a la suerte, el tiempo de bloqueo en realidad tiene una varianza bastante alta, pero el promedio sigue siendo el blanco más preciso por la introducción de k fraccional.

Trabajo, dificultad y seguridad criptográfica 1x74f

Hashcash expresa margen de seguridad en los términos estándar de seguridad criptográfica O (2 ^ k) donde, para comparación, DES ofrece k = 56 bits de seguridad, ECDSA-256 ofrece k = 128 bits de seguridad, y porque es ampliamente utilizada esta forma log2 de expresar trabajo y seguridad también puede ser útil para hacer comparaciones de seguridad.

La tasa de trabajo de Bitcoin se llama hashrate de red en GH / sec. Como el intervalo del bloque objetivo es de 10 minutos que se puede convertir a seguridad criptográfica como log2 (hashrate * 600), de modo que el hashrate de noviembre de 2013 es 4 petahash / seg y el hashcash de 256 bits de 256 bits de pruebas de trabajo de Bitcoin son 62 bits (incluyendo +1 para doble hash).

Bitcoin también define una nueva noción de dificultad (relativa) que es el trabajo requerido para que en el hashrate actual de la red se espere que se encuentre un bloque cada 10 minutos. Se expresa en relación con una unidad mínima de trabajo de 2 ^ 32 iteraciones (aproximadamente, el trabajo técnicamente mínimo es 0xFFFF0000 debido a los detalles del nivel de implementación de bitcoin). La dificultad de Bitcoin es simple para convertir aproximadamente a seguridad criptográfica log2: k = log2 (dificultad) +32 (o para log2 de alta precisión (dificultad * 0xFFFF0000)). La dificultad está relacionada con el objetivo simplemente como dificultad = objetivo / 0xFFFF0000.

Tal vez sea más fácil lidiar con las altas dificultades en la escala log2 (un petahash / segundo es un número de 16 dígitos decimales de hash por segundo), y los hace comparables con otras declaraciones de seguridad criptográfica. Por ejemplo, el proyecto EFF "deepcrack" DES cracker construyó una máquina de fuerza bruta de hardware capaz de romper una clave DES en 56 horas para dejar en claro que el DES de 56 bits era demasiado débil en 1998 a un costo de $ 250,000 (más tiempo de diseño voluntario) ) En comparación, la red de bitcoin hace 62 bits (incluyendo +1 para hash doble) cada 10 minutos y es 537,000 veces más poderosa que deepcrack, o podría si se centrara en DES en lugar de SHA256 descifrar una tecla DES en 9 segundos para deepcracks 56 horas

Privacidad del minero 2f2y1c

En principio, un minero debería, por lo tanto, utilizar de forma privada una dirección de recompensa diferente para cada bloque (y restablecer el contador a 0). El por qué los bitcoins minados de Satoshi se vincularon potencialmente, fue porque mientras él cambiaba las direcciones de recompensa, se olvidó de reiniciar el contador después de cada mina exitosa, que es un error de privacidad de minería de bitcoin. De hecho, con el bitcoin, el contador también debería ocultarse, de lo contrario, revelaría su nivel de esfuerzo, y si tiene mucho poder de minería, eso puede implicar a quién pertenece la moneda. Bitcoin hace esto a través de nonce y extra-nonce. Nonce comienza en 0, pero el nonce extra es aleatorio.

Juntos forman un contador aleatorio que oculta la cantidad de esfuerzo que se incluyó en la prueba, por lo que nadie puede decir si fue un minero poderoso pero desafortunado que trabajó duro, o un minero débil que tuvo mucha suerte.

Además con la [introducción de pools de minería] (/ bitcoin-mining-pools /), si el minero usa la misma dirección de recompensa para todos los s, que es lo que hacen los protocolos de minería actuales, existe el riesgo de que los s puedan rehacer el trabajo. Para evitar que los s rehagan el trabajo, los mineros reparten el trabajo definido para que lo hagan los s. Sin embargo, esto crea una comunicación innecesaria de ida y vuelta y en las primeras versiones del protocolo quizás fue un factor en la decisión de enviar el bloque al mío, lo que significa que los mineros no están validando sus propios bloques, lo que delega la autoridad de validación, aunque no funciona. , al operador de la agrupación, reduciendo la seguridad de la red bitcoin.

{PAGEBREAK}

La versión de protocolo de minería más reciente permite al agregar su propia definición de bloque, pero aún incurre innecesariamente en viajes redondos para distribuir la asignación de trabajo. Como el nuevo protocolo de minería combinada tiene un minero elegido extraNonce, esto actúa como un factor de inicio aleatorio, por lo que no es necesario hablar con el grupo para la asignación de trabajo, un grupo puede tener una dirección estática publicada y los mineros solo pueden hacer un trabajo de cualquiera que sea el tamaño que elijan, y lo envían al grupo como un paquete UDP. (Si el minero requiere privacidad, podría usar el método de derivación pública de BIP 32 para permitir que el nodo le informe al minero a través de un mensaje cifrado con el trabajo de minería, factor para multiplicar la clave pública estática por).

Prueba de trabajo de Scrypt 2f4g3v

Es un malentendido hablar sobre la prueba de trabajo de Scrypt. Scrypt no pretende ser una función de prueba de trabajo, sino una función de derivación de claves estirada, y si bien es costoso para su diseño computar con altas iteraciones, no se puede usar para hacer una prueba de trabajo que sea auditable de manera pública. , como verificar cuesta lo mismo que crear.

Hashcash con la función hash interna de Scrypt se puede denominar hashcash-Scrypt (1). Scrypt, de Colin Percival, es una función de derivación de claves para convertir las frases clave elegidas por el en claves. Está salado (para evitar los ataques de precomputación / tabla de arcoíris), y el hash se itera muchas veces para ralentizar la rectificación de frase de contraseña. Scrypt tiene un propósito similar al de la función de derivación de clave de contraseña estándar PBKDF2 (que usa HMAC-SHA1 internamente).

El diferenciador y por qué la gente puede elegir Scrypt en lugar de PBDF2 es que el hash interno de Scrypt usa más memoria, por lo que la ventaja de la GPU (o Scrypt ASIC / FPGA teórica) en la trituración de contraseñas es reducida en comparación con las U.

Esto no usa la característica de extensión de la clave de Scrypt, por lo que la extracción no utiliza Scrypt directamente, sino solo el algoritmo hash de Scrypt (al que se accede configurando el parámetro de iteración en una iteración). Por lo tanto, la función de estiramiento de la tecla de Scrypt no se utiliza en absoluto para contribuir a la dureza, a diferencia de su uso normal para la protección de claves, por ejemplo, al derivar la clave de cifrado de la frase de contraseña del para encriptar billeteras de bitcoin.

La razón por la cual el estiramiento de las teclas de Scrypt no puede usarse para la minería es porque a la vez hace que sea más costoso verificarlo por el mismo factor. Esta variante de hashcash se puede denominar hashcash-Scrypt (iter = 1, mem = 128KB) o acortada a hashcash-Scrypt (1). El otro parámetro principal de scrypt denota la cantidad de memoria utilizada (generalmente 128kB).

{PAGEBREAK}

Descentralización: hashcash-Scrypt vs hashcash-SHA256 63301n

La huella de la memoria Scrypt de 128kB hace que litecoin sea menos vulnerable a la centralización de la potencia minera que surge del limitado o la propiedad de los equipos ASIC por parte de los s. Es discutible y poco claro, porque hay argumentos opuestos: que hashcash-SHA256 ^ 2 es muy simple, por lo que un individuo capacitado con sus ahorros personales o un pequeño proyecto de Kickstarter podría diseñar y realizar un pedido con un fabricante de chips.

Esta simplicidad asegura que muchas personas lo hagan y los ASIC estén disponibles. Por el contrario, es un poco más difícil en comparación con hacer un ASHASH-Scrypt (1) ASIC así que tal vez litecoin resultará en el medio plazo peor para la centralización, si una entidad comercial bien financiada arrincona el mercado teniendo más rápido, pero de propiedad, no disponible en el mercado, ASHC hashcash-Scrypt (1) que hacen rentable la minería de la GPU litecoin.

Tenga en cuenta también que un factor atenuante es que se considera que hashcash-Scrypt (1) debería ofrecer una menor velocidad de implementación de ASIC frente a GPU que hashcash-SHA256 ^ 2. Esto se reclama debido al argumento de que el área del dado ocupada por 128kB de RAM, que podría pensarse que debe dedicarse a cada núcleo Scrypt (1), reduciría la cantidad de núcleos Scrypt (1) que caben por chip. Sin embargo, tenga en cuenta que Scrypt (1) no es realmente resistente a la memoria de forma segura, ya que no intenta evitar las compensaciones de tiempo y memoria, por lo que es posible repetir el cálculo de las rondas internas para reducir los requisitos de memoria.

En teoría, por lo tanto, sería posible realizar cálculos más costosos para implementar Scrypt (iter = 1, mem = 128kB) con memoria mínima, solo con más trabajo. En el hardware, la compensación de tiempo-memoria se optimizaría para encontrar la cantidad óptima de memoria para usar, y es bastante posible que la cantidad óptima sea inferior a 128kB.

Hashcash-Scrypt (1) también tiene una desventaja con respecto a hashcash-SHA256 ^ 2 ya que es significativamente más lento de verificar, ya que el costo de verificación de una iteración de Scrypt (mem = 128kB) es mucho mayor que dos hashes SHA256. Esto hace que la validación del blockchain litecoin requiera más U y memoria para todos los nodos completos.

Sin embargo, tenga en cuenta que el trabajo dominante de validación de la U es la verificación de las firmas por transacción ECDSA de las múltiples transacciones en un bloque. Incluso una firma ECDSA es más lenta que una verificación Scrypt (1) que se realiza una vez por bloque, y hay muchas transacciones (y, por lo tanto, verificaciones de firma ECDSA) para verificar dentro de un bloque... Escrito por Bitcoin Mining...