¿Por qué molestarse en verificar tanto la clave pública como la firma en las transacciones P2PKH?

1) Las direcciones quedarían obsoletas después de un uso.

2) Si alguien realiza un ataque Sybil, puede evitar que las transacciones se transmitan (lo que también puede suceder ahora), pero también puede realizar una transacción falsa desde esa dirección y transmitirla, ya que el atacante sabe cuál es la preimagen. es.

3) Incluso sin un ataque de Sybil, alguien podría aprovechar los eventuales bloques huérfanos y tomar el dinero de todas las transacciones en ellos, haciendo una transacción falsa para cada uno.

Hay condición de gasto y condición de propiedad. La condición de gasto la establece el remitente anterior de los fondos en el script de pubkey: "prueba de que puede crear el hash que pertenece a esta dirección". Con la función hash de una vía, esto demuestra que solo "usted" puede ser el individuo, para gastar más los fondos. Lo explicaste correctamente con la dependencia hash.

La firma se utiliza para probar que usted es el propietario legítimo de los fondos. Checksig verificaría la lógica ECDSA, y solo su clave privada puede generar el resultado correcto.

En su último comentario, indicó que las firmas (multisig) no se verifican en absoluto. Esto es ligeramente incorrecto. El script de redención tiene el OP_Code 0xAE al final, que verifica las firmas para un número específico de claves públicas.

Ver también la respuesta aquí

Existe investigación en el campo y se ha propuesto una solución similar en la literatura; se llama Fawkescoin y sugiere reemplazar ECDSA con una función hash y un servicio de línea de tiempo seguro, como una cadena de bloques.

Hay algunas desventajas (problemas de practicidad) a considerar, como ya lo mencionaron MCCCS y pebwindkraft , y la mayoría de ellas, si no todas, están relacionadas con las firmas únicas, como menciona MCCCS.

las direcciones quedarían obsoletas después de un uso

Algunos ejemplos de lo que puede salir mal incluyen:

1. La transacción no se realiza, por ejemplo, debido a tarifas bajas o a una parte malintencionada que impide que las transacciones se transmitan y luego crea una transacción falsa desde esa dirección y la transmite a su propia clave (gracias a MCCCS)
2. Una bifurcación, luego se debe usar la misma clave para cada versión bifurcada.
3. Bloques huérfanos (gracias a MCCCS)
4. La situación es más complicada en las transacciones multi-sig. No existe una solución obvia usando solo hashes en los casos en que las direcciones multi-sig son propiedad de partes que no son de confianza (los servicios como CoinJoin no pueden funcionar).
5. Anuncie la misma dirección para recibir fondos, es decir, un sitio web que acepte donaciones en una sola dirección. Luego, deberá gastar todo en una transacción (para firmar solo una vez) e incluso si puede tolerar esto (poco probable), aún es propenso a los ataques antes mencionados.
6. Si se requiere una prueba de solvencia (o prueba de propiedad de la clave/activos), entonces una forma es firmar un desafío y demostrar que posee la clave. Como ya se mencionó, desea evitar volver a firmar por cualquier medio, por lo que lo anterior revelará su imagen previa.
7. Si un script falla por cualquier motivo durante la verificación, destruye efectivamente el valor asociado con cualquier dirección de entrada, ya que se revelará su imagen previa.

Porque esa es la única forma de saber que el gastador es el destinatario previsto. El conocimiento de la clave pública por sí solo es susceptible al ataque del hombre en el medio. Si no se verificaron las firmas, cuando transmita una transacción a la red, no habría nada que impida que el primer destinatario de su transacción simplemente copie su clave pública, arroje su transacción a la basura y transmita su propia transacción nueva gastando su monedas para ellos mismos. Las firmas son necesarias para la autenticación.