¿Se puede crear una cadena de bloques que olvide las transacciones cuyos productos se han gastado?

Esto no es posible con los bloques y transacciones actuales, aunque es posible que futuras mejoras nos permitan eliminar algo de espacio de futuros bloques y transacciones.

Pensemos en la idea de eliminar una transacción por un momento. Digamos que tenemos dos transacciones particulares en la cadena de bloques:

1. Alice extrae 50 bitcoins
2. Alice le paga a Bob 50 bitcoins

Ahora eliminamos la transacción de coinbase (minería) de Alice:

1. [PURGADO]
2. Alice le paga a Bob 50 bitcoins

¡Guau! ¡Parece que 50 bitcoins aparecieron de la nada!

¿Qué pasa si esa transacción tiene muchas pruebas de trabajo?

¿Podría confiar en la transacción Alice-pays-Bob si tuviera 50,000 confirmaciones aunque no pueda ver de dónde provienen esos bitcoins? Claro, eso podría ser una compensación razonable de seguridad reducida por una mayor comodidad.

Pero para validar transacciones futuras, los nodos no solo necesitan saber quién tiene bitcoins, también necesitan saber quién no tiene bitcoins. Por ejemplo, imagina que Bob no ha gastado sus 50 bitcoins, por lo que esa transacción debería ser parte de la cadena de bloques; sin embargo, cuando descarga la cadena de bloques del nodo de Mallory, esto es lo que obtiene:

1. [PURGADO]
2. [PURGADO]

En algún momento en el futuro, Bob va a gastar sus 50 bitcoins. Otros nodos que no sincronizaron desde Mallory saben que Bob tiene 50 bitcoins, por lo que aceptan bloques con esa transacción. Su nodo rechaza bloques con esa transacción porque no cree que Bob tenga 50 bitcoins, lo que lo saca permanentemente de la cadena de bloques de consenso. Esto se llama falla de consenso y es una de las cosas que tratamos de evitar con todas nuestras fuerzas en Bitcoin.

¿Por qué no simplemente realizar un seguimiento de las cantidades y purgar el resto?

Una forma de evitar este dilema sería si pudiéramos dividir las transacciones en diferentes partes:

1. Las partes que necesitábamos para construir el conjunto de salida de transacción no gastada (UTXO) que usan los nodos completos para probar si Bob tiene o no 50 bitcoins.
2. Todo lo demás, como las grandes claves públicas y las firmas que usamos para demostrar que Alice estaba autorizada a gastar esos 50 bitcoins.

Aquí nos encontramos con un problema adicional con la poda de transacciones, una limitación de la forma en que Nakamoto diseñó los identificadores de transacciones (txid). El diseño de Nakamoto simplemente procesa toda la transacción y la usa para formar los nodos hoja del árbol merkle cuyo nodo raíz se incluye en el encabezado del bloque y se asegura con la prueba de trabajo.

(Imagen de 21.co , licencia CC-By-SA)

Debido a este diseño, para verificar los datos requeridos por UTXO, también debe descargar la transacción completa , incluidas sus claves públicas y firmas, que constituyen aproximadamente 1/3 a 2/3 de una transacción.

Esto hace que la poda al estilo del libro blanco de Nakamoto en Bitcoin en este momento sea prácticamente imposible. Afortunadamente, algunas personas inteligentes han estado trabajando para mejorar la situación.

Testigo segregado

... que suena como un extraño término policial...

La cadena lateral de testnet de Blockstream, Elements Alpha , incluye una característica ingeniosa llamada testigo segregado . Primero, algunos antecedentes sobre los testigos en criptografía:

Un testigo son los datos necesarios para probar la validez de algunos otros datos. Esto probablemente se deriva del derecho contractual, donde a menudo haces que otras personas sean testigos de tu firma en documentos importantes. En el caso de Bitcoin, el testigo de que un gasto en particular es válido es scriptPubKey de la salida que se gasta y scriptSig de la entrada que hace referencia a ella en la transacción de gasto.

En Elements Alpha y el nuevo Sidechain principal de Liquid , el testigo se "segrega" en una parte diferente del bloque y no está cubierto por el hash txid. Eso significa que los nodos que deseen reducir sus requisitos de descarga pueden omitir la descarga de testigos para transacciones con más de (digamos) 50 000 confirmaciones. Sin embargo, ahora aún pueden usar el encabezado de bloque merkle root para verificar que todos los datos que no sean testigos (incluidas las cantidades transferidas) sean correctos y usarlos para crear un conjunto UTXO correcto.

No puedo encontrar una fuente en este momento, pero creo que escuché a Wuille y Maxwell decir que para las transacciones típicas de la red principal de Bitcoin, esto significaría que aproximadamente 1/3 de los datos de la transacción no tienen que ser descargados por nodos que no No quiero validar firmas antiguas. En Elements Alpha, donde el testigo es más grande para las transacciones que utilizan el valor ciego , esto significaría que no es necesario descargar 2/3 de los datos.

Como beneficio adicional, el testigo segregado también "elimina por completo todas las formas conocidas de maleabilidad de transacciones" ( descripción de Wuille ).

¿Cuándo aparecerá esto en Bitcoin?

Estás de suerte: hace solo unos días, Luke Dashjr presentó una idea sobre cómo se puede bifurcar el testigo segregado en la red principal de Bitcoin. (Anteriormente, se había pensado que sería necesaria una bifurcación dura).

El pagador paga a un scriptPubKey que siempre devuelve verdadero pero que contiene el hash de un script de canje como lo hace P2SH:

<hash_of_redeem_script> OP_TRUE

(Me lo acabo de inventar; no sé cómo será la construcción real).

Cuando la persona que pagó más tarde va a gastar, proporciona un scriptSig vacío en la transacción misma. Esto es válido para los nodos antiguos, pero los nodos actualizados saben que deben buscar en otro lugar del bloque el scriptSig real. El testigo ha sido segregado.

Tanto para los nodos antiguos como para los nuevos, calculan el txid utilizando el scriptSig vacío, por lo que los datos cubiertos por la raíz de merkle aún cubren las referencias y las cantidades de valores importantes.

No sé exactamente qué tan bien se compara esto con el testigo segregado en Elements Alpha (¿eso también cubre el scriptPubKey?), pero hace la mayor parte del trabajo en una construcción bifurcable suave conveniente.

Dado que se trata de ingeniería de hace una semana, puede cambiar mucho o incluso resultar inviable en los próximos meses, así que no espere verlo en el futuro inmediato, pero, a largo plazo, espere comenzar a ver algo nuevo. Aparecen las opciones de eliminación previas a la descarga.

Sí, esto debería ser posible. Pero todavía no hay soporte para esto en bitcoind.

Básicamente, puede ejecutar bitcoind con la opción -prune. En ese caso, eliminará los bloques más antiguos y mantendrá solo las salidas no gastadas (que se requieren para la validación de tx más nueva). Entonces, en teoría, puede simplemente copiar la base de datos utxo de un nodo existente y comenzar a descargar desde el bloque actual.

Ahora mismo no existe una forma descentralizada de construir la base de datos utxo, solo tenéis que empezar a descargar desde el bloque 0 y construirla vosotros mismos. Podría, por ejemplo, descargar toda la base de datos de UTXO. Estaba pensando en una forma de transmitir el conjunto UTXO (como bloques), pero sería muy grande (alrededor de 1,2 GB en este momento). No tengo los conocimientos suficientes para saber exactamente cómo se podría implementar tal cosa, pero me parece teóricamente plausible.