¿Podría ser más simple el script estándar de pago por dirección? por ejemplo, no comparar de la HASH160?

¿Qué pasaría si tuviera un scriptPubKey de

<pubKey>OP_CHECKSIG

Y un scriptSig de

<sig>

Pregunta

  1. ¿Funcionaría eso en el cliente estándar?

  2. ¿Por qué necesitamos verificar el hash?

La única razón posible que se me ocurrió es que hace que un DDOS sea mucho más difícil, ya que las personas no inundan la red con firmas no válidas que consumen la CPU, y un hash es relativamente económico.

Si la explicación que tengo es correcta, ¿está documentado en alguna parte?

El wiki dice que el hash de la clave pay to pub es para evitar una ruptura en el algoritmo ECDSA, pero me pregunto cuál podría ser la respuesta real.

Curiosamente, el uso del hash también utiliza espacio adicional en la cadena de bloques, ya que la clave pública tiene que aparecer de todos modos en la transacción de gasto. Por otro lado, sin el hash, usaría la clave pública como su dirección; es un 60% más largo, lo que puede ser un poco inconveniente.
La protección contra un ataque a ECDSA parece una explicación perfectamente razonable; ¿por qué lo dudas?

Respuestas (3)

Exponer su clave pública debilita un poco la seguridad. Por eso es recomendable que no reutilices direcciones ya que tu clave pública queda expuesta cuando firmas la primera transacción gastando dinero desde esa dirección. El uso de Pay-To-PubKey en lugar de Pay-To-Pubkey-Hash expone su clave pública de inmediato.

Esa es una razón, pero no la principal, o la razón por la que se hizo originalmente.

Esta es la secuencia de comandos estándar de pago a pubkey, que fue la "secuencia de comandos estándar" original durante un tiempo, y todavía se usa si realiza una mina en solitario desde bitcoind.

Originalmente, las transacciones de Bitcoin estaban destinadas a usar pago por IP, donde la "dirección" era una dirección IP, y la clave pública para pagar se calculaba sobre la marcha cuando el remitente lo solicitaba. Estas transacciones usaban scripts de pago por clave pública.

Pay-to-IP quedó en desuso y finalmente se eliminó rápidamente, principalmente por razones de seguridad (man-in-the-middle), y la "solución alternativa" (pensada para cuando el destinatario estaba desconectado) pay-to-pubkeyhash se hizo cargo, con varios efectos secundarios desafortunados (reutilización de direcciones, sin comentarios en transacciones, ...). Con suerte, el Protocolo de pago (BIP 70-72) puede recuperarlos.

Hay otras razones para preferir pay-to-pubkeyhash en lugar de pay-to-pubkey, como una ventaja de seguridad muy pequeña (antes de que se revele la clave pública, el atacante primero necesita un ataque de preimagen en el hash, antes de comenzar a atacar el EC clave) y un efecto menor en el conjunto UTXO (la base de datos que mantiene cada nodo completo además de la cadena de bloques).

Esto no es útil porque cualquiera puede canjearlo con una firma ECDSA válida firmada bajo CUALQUIER clave.

Tienes razón, escribí mal el guión. Lo revisé.
Gracias, pero este script solo es útil si las personas publican la clave pública en lugar de la dirección. Incluso después de la compresión, una clave pública sigue siendo un 60 % más larga que una dirección.
¿Podría ser más simple el script estándar de pago por dirección? por ejemplo, no comparar de la HASH160?
RespuestasAquíPolítica de privacidad1y, 0v