Una idea de bifurcación blanda de Bitcoin para ayudar a comprimir la cadena de bloques

¿Por qué no obligamos a los mineros a incrustar la altura del árbol TX Merkle en los primeros dos bytes de la versión del encabezado del bloque de 4 bytes?

Esa sería una bifurcación sensata, pero debería tener en cuenta que, debido a BIP65, la versión del bloque (que es un número entero con signo) debe ser al menos 4, restringiéndola a 2^31-4 valores. Mantener la compatibilidad con BIP9 y posiblemente BIP340, que asignan significado a ciertos bits en el número de versión, complicaría aún más las cosas.

Además, es difícil convencer a los mineros de que utilicen una bifurcación suave en un cambio que les complica las cosas, lo que significa que, en ausencia de una presión exitosa al estilo de la UASF, es poco probable que se adopte.

Solucionaría la debilidad de fuerza bruta del nodo hoja (CVE-2017-12842), que actualmente solo se soluciona mediante reglas de estandarización, pero no mediante reglas de consenso.

¡En efecto! Creo que un cambio de consenso que impone un tamaño de transacción mínimo en su lugar es probablemente mucho menos invasivo.

De manera similar a la descripción en BIP 141, podemos introducir un tipo de nodo que no sea ni un nodo podado ni un nodo completo completo, pero tendrían txindex=1 para transacciones con salidas no gastadas. Esos nodos primero almacenarían bloques completos. Cuando llega el siguiente bloque, utilizando su txindex, buscan el bloque, encuentran la transacción y verifican si se gastaron todas las salidas. Si es así, eliminarían la transacción del almacenamiento de ese bloque pero solo mantendrían su hash. Esto ahorraría mucho espacio ya que me parece que la mayoría de los escenarios de consulta de un nodo habilitado para txindex usarían gettransaction en transacciones con salidas no gastadas.

No veo cómo este cambio está relacionado con este modo potencial de operación. Independientemente de lo que sugiera que los bloques se comprometan en su encabezado, los nodos pueden recordarlo cuando validan un bloque por primera vez, sin un cambio de consenso. A un nodo localmente, si él mismo validó cuántas transacciones hay realmente en el bloque, nunca se convencerá de nada más.

Tampoco creo que este modo tenga ningún beneficio. Comparte la lentitud de la validación del modelo anterior a UTXO (*) con la falta de capacidad para proporcionar bloques completos (como los nodos eliminados actuales) mientras consume mucho más espacio en disco (necesitaría mantener cada transacción completa que tenga al menos una sin gastar). salida, en lugar de mantener solo las salidas no gastadas).

(*) Antes de Bitcoin 0.8, en lugar de un conjunto blockchain + UTXO, había un índice blockchain + en esa cadena para cada transacción + un valor booleano para cada salida, ya sea que se gastara o no. Esto fue lento, porque significaba que el conjunto de trabajo (datos a los que el código accede con frecuencia) era efectivamente toda la cadena de bloques (realizando muchas búsquedas aleatorias para cada entrada que se gastaba). En el modelo UTXO introducido en 0.8, el conjunto UTXO se mantiene independientemente de la cadena de bloques (no contiene punteros a la cadena de bloques; contiene una copia de todos los UTXO), lo que permite el almacenamiento en caché eficiente solo de los UTXO y hace que la cadena de bloques sea bonita. innecesario para el funcionamiento normal (excepto servir bloques a otros pares o volver a escanear). Ese modelo es lo que también permitió la poda, ya que la propia cadena de bloques ya no se usa para la validación.