¿Por qué los scripts P2PK no tienen su propia dirección?

Uno de los problemas con la codificación de salidas P2PK como una dirección es que pueden ser muy largas. P2PK puede tener claves comprimidas y sin comprimir. Las claves sin comprimir son de 65 bytes, lo que significa que la dirección resultante sería muy larga. De hecho, esta longitud es probablemente la razón por la que P2PKH existe en primer lugar: como una forma de tener cadenas cortas como direcciones. Por lo tanto, las direcciones P2PK pueden ser muy largas y difíciles de manejar, por lo que no son tan útiles.

Pero hoy en día, todo el mundo usa pubkeys comprimidas, por lo que la longitud ya no es un problema.

Dado que Satoshi no le dio a P2PK un tipo de dirección, la razón por la que no se ha creado desde entonces es que a nadie le importa. P2PKH ya hace todo lo que hace P2PK, solo un poco más. Y con otras mejoras por venir, como Taproot (que es un esquema de pago por clave pública y tiene su propio tipo de dirección), no hay una razón convincente para hacer el esfuerzo de definir un estándar e intentar que las billeteras lo implementen.

Creo que hay una combinación de tipo de transacción (p2pk, p2sh, p2pkh...) y claves públicas o direcciones. Las direcciones se generan a partir de la clave pública hexadecimal (un patio de recreo genial aquí: http://gobittest.appspot.com/Address ). Las claves públicas se codifican con hash, se agrega un byte de red, algunas sumas de verificación y se codifican en base58check. Esto me da la dirección bitcoin de una clave pública.

En una transacción puedo usar diferentes métodos para transferir fondos. También te había respondido a tu otra publicación . Entonces, cuando la condición de gasto solo requiere que presente su clave pública y firma, entonces es una transacción p2pk. Su billetera reconocería la clave pública (siguiendo el esquema de codificación mencionado anteriormente) como dirección de "tipo 1".

Si la condición de gasto está configurada para presentar un hash de clave pública, entonces es un tx p2pkh, y tiene la estructura estándar Op_Dup, Op_Hash160,...

Al echar un vistazo a la pila, queda claro lo que sucede. El tx de gasto pone su sig y pubkey en la pila. Luego, el script pubkey se coloca en la pila. El primer comando es OP_Dup, por lo que la clave pública está duplicada. Luego sigue OP_Hash160, aplicando hash a la clave pública. Este hash luego se compara con el hash del script pubkey (en su ejemplo, "1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c"), y con suerte estos dos coinciden (según el siguiente OP_Equal). Esto prueba que usted es la persona legítima para gastar los fondos, porque podría probar que puede convertir su clave pública en el hash de clave pública referenciado. Y hashing es una función unidireccional... nadie más podría hacer esto. En el último paso, se verifica la firma en la transacción, y con su clave pública ahora provista, la transacción se verificará en busca de una firma válida (OP_Checksig).

Espero poder aclarar la confusión sobre las direcciones y las transacciones de "pago a pubkey" o "pago a pubkey hash" :-)