¿Por qué la dirección no contiene un scriptPubKey completo?

Hay varias razones para esto, algunas históricas y otras más recientes:

• Al principio, las direcciones probablemente no tenían la intención de cubrir todo lo que Bitcoin Script podía hacer. Eran una alternativa para el caso en que el destinatario no estaba en línea (estamos llamando a direcciones que siguen siendo direcciones porque originalmente eran direcciones IP a las que se conectaría para solicitar un correo electrónico scriptPubKey). Entonces, en el momento en que se introdujeron, un enfoque en el tamaño probablemente era mucho más relevante que las consideraciones sobre la flexibilidad. Tenga en cuenta que las direcciones tienen un 'byte de versión' (que fue diseñado para actualizar el formato, no para identificar altcoins).
• Más tarde, cuando se introdujo P2SH, la preocupación por la flexibilidad desapareció por completo: P2SH permitió transmitir cualquier problema de gasto en una dirección de tamaño constante. Además, eliminó la preocupación de los remitentes que necesitaban crear salidas más grandes. El hecho de que esté usando una billetera multisig no debería significar que tenga que pagar una tarifa más alta al enviarme.
• Cuando se introdujo SegWit, P2SH ya no era suficiente para codificar ningún resultado, por razones de eficiencia y seguridad. A pesar de la necesidad de un nuevo formato de todos modos, decidimos no proponer algo que pudiera codificar correos electrónicos arbitrarios scriptPubKey. El razonamiento dado en BIP173:
  • ¿Por qué no hacer un formato de dirección que sea genérico para todas las scriptPubKeys? Eso generaría confusión sobre las direcciones de los tipos scriptPubKey existentes. Además, si alguna vez se introducen direcciones que no tienen un mapeo uno a uno con scriptPubKeys (como las direcciones basadas en ECDH), tener disponible un tipo de dirección antiguo totalmente genérico permitiría reinterpretar las scriptPubKeys resultantes usando el formato de dirección antiguo, con perdió fondos como resultado si se les envían bitcoins.

La mayoría de los nodos de bitcoin solo permiten algunos tipos específicos de scriptPubKey, incluidos P2PK, P2PKH, OP_RETURN, P2SH, testigo nativo y multisig. Esos son los 'tipos estándar', otros no están relacionados por defecto (inicialmente por razones de seguridad debido a errores).

Por lo tanto, las direcciones con pubKeyScripts no estándar serían básicamente inutilizables en la red tal como están, y no hay necesidad de incluir el pubKeyScript completo en ese caso; ahorra espacio y es más seguro usar solo la plantilla.

Las direcciones tienen un byte de versión al principio para diferenciar entre tipos.

Es posible crear scripts que hagan lo que quieras, de forma similar a lo que pides, usando P2SH. Aún así, las direcciones P2SH tienen un formato scriptPubKey específico que siempre se usa, pero luego, cuando gasta, puede proporcionar el script de canje

¿Hay tal vez una mezcla de dos cosas en su suposición?

¿Por qué una dirección contiene solo el PublicKeyHash...

Las direcciones no contienen hashes. Las direcciones se derivan de las claves públicas (hexadecimales), que se sha256 y ripemd160'ed, se agregan con un byte de red y algunas sumas de verificación, y luego se codifican en base58.

El script que nos muestra aquí para P2PKH es la condición de gasto. Cuando se crea una transacción de financiación, esta condición está en la salida, de modo que solo la persona que puede crear el pubkeyhash puede gastar los fondos. Para crear el hash de clave pública, necesita la clave pública hexadecimal y sha256/ripemd...

Ahora, ¿por qué no se usa una combinación de OpCodes y Hash como dirección? Le doy una oportunidad especulativa. Me pregunto, ¿cuál es la ganancia? La billetera para rodear el keyhash con 5 OpCodes (incluida la longitud) no requiere mucho esfuerzo. El keyhash se calcula de todos modos (bastante fácil de sumar/multiplicar con números enteros y sin aritmética de punto flotante), para ser utilizado más adelante en la codificación base58. Todos los costos de cálculo están en la(s) máquina(s) del usuario, no en las máquinas de la red bitcoin. Así que no es un gran costo para la maquinaria de la billetera.

Limitar una dirección a un caso de uso específico requeriría tener muchos "tipos" de direcciones en una billetera (un montón para P2PK, P2PKH, P2SH, OP_Return... y más). Creo que en ese momento solo tenías un manojo de llaves en la billetera. Y las direcciones pregeneradas de la billetera (sin reutilización de direcciones), que debían respaldarse correctamente después de cada uso. ¿Agregar diferentes tipos de direcciones para un caso de uso limitado solo complicaría el manejo de la billetera?

La longitud de tx ya fue mencionada por MeshCollider. Sorprendentemente, un P2PK es más corto con claves comprimidas que P2PKH (pero no tan anónimo como P2PKH). El script de bloqueo es solo OP_CHECKSIG. Aquí la dirección sería pubkey + 1 OpCode.

Llego a esta conclusión: al crear un software para transferir valores, necesito objetivos (también conocidos como direcciones) y lógica. Los objetivos serían "estables", y la lógica me da toda la flexibilidad. Se podría hacer vinculando el objetivo a la lógica, pero no se puede ver el beneficio inmediato de ello.

Si hiciera lo que propone, la 'dirección' sería menos parecida a 'dirección' y más una combinación de información de tipo 'dirección' e información de tipo 'mecanismo de gasto', siendo esta última el código de secuencia de comandos de bloqueo.

'Dirección' significa 'ubicación' de algún tipo, ya sea la dirección de Bitcoin, la dirección de memoria, la dirección IP o la dirección de la casa de una persona. En Bitcoin, esta ubicación es la fuente o el destino de los fondos, y es conveniente tener una noción de 'dirección' de esta manera, y creo que ayuda a las personas sin conocimientos técnicos a comprender el concepto básico de Bitcoin.

Cuando comenzamos con las salidas de tipo P2PK, la 'dirección' simplemente encapsulaba la clave pública, que 'ubica' a la persona (o grupo de personas o máquina, etc.) con la clave privada única correspondiente.

Luego, con P2PKH vino un nivel de indirección con un hash de la clave pública que ahora se usa, pero nuevamente la 'dirección' así formada era muy parecida a la 'ubicación' y se identificaba de manera única como 'alguien' (o alguna otra entidad que puede tener fondos) .

Sin embargo, cuando se trataba de P2SH, la información del tipo 'mecanismo de gasto' ingresaba en la 'dirección' porque la dirección contenía un hash del script de bloqueo requerido. Es otro nivel más de indirección: la 'ubicación' de los fondos, es decir, el hash de clave pública, ahora se almacena en ese script de bloqueo implícito. Por lo tanto, la dirección ahora incluye información de tipo 'dirección' e información de tipo 'mecanismo de gasto', como en su propuesta. Por lo tanto, tiene razón: una dirección de Bitcoin YA puede incluir información de tipo de secuencia de comandos que pertenece al 'mecanismo de gasto', además de contener información de tipo 'ubicación'. Por lo tanto, la 'ortogonalidad' de estos dos tipos de información se ha perdido hasta cierto punto con P2SH.

Además, P2SH pierde algo de 'ortogonalidad' en el sentido de que ya no existe la distinción clara entre scriptPubKey que contiene solo el script de bloqueo y scriptSig que contiene solo el script de desbloqueo. El scriptSig ahora toma la forma del script de desbloqueo SEGUIDO POR el script de bloqueo serializado. Y el 'mecanismo de gasto' se cambia a un proceso de 2 etapas que consiste en verificar primero que el script de bloqueo tenga el hash correcto y luego ejecutar el script de desbloqueo concatenado con el script de bloqueo deserializado.

PERO en el caso de P2SH, este es un compromiso que vale la pena porque P2SH es un mecanismo poderoso de gran conveniencia que permite que cualquier persona envíe fácilmente a una "ubicación" de este tipo que usa un script de bloqueo complejo, usando solo una dirección de Bitcoin de tamaño estándar que comienza con un ' 3' y no tener que incluir ese largo script de bloqueo en la transacción (lo que aumentaría la tarifa).

Entonces, P2SH dobla un poco los ángulos ortogonales hacia abajo, aunque por una razón que vale la pena. En todos los diseños hay compensación y compromiso: perder alguna propiedad deseable en un sentido puede valer la pena para obtener un gran beneficio.

En su propuesta, el ángulo ortogonal se está inclinando bastante hacia abajo: las 'direcciones' que son encapsulaciones de 'ubicación', y que se usan no solo dentro de Bitcoin, sino en todas partes donde se realizan transacciones de Bitcoin, ahora llevan consigo este adicional código de secuencias de comandos, que es el detalle del 'mecanismo de gasto' en lugar de la 'ubicación'.

Este no es un argumento lógico a prueba de agua, pero me parece la "solución más elegante" para mantener las direcciones de Bitcoin almacenando la menor cantidad de información de "ubicación" y dejar que los creadores de transacciones se ocupen de los detalles reales del código de secuencias de comandos.