¿Se implementa la poda del historial de transacciones en el cliente bitcoin de Satoshi?

El documento original de bitcoin sugiere un método para descartar transacciones antiguas. Se debe calcular el Merkle Tree de todo el historial de transacciones y almacenar solo una parte del árbol.

Sin embargo, no noté este método implementado. BuildMerkleTreelo almacena solo en la memoria, y parece asumir que tiene todo el historial de transacciones, y el método de serialización almacena las transacciones reales y no almacena Merkle Tree.

¿Eso está implementado? ¿Puede darme una referencia de dónde está en el código?

Si no, ¿está planeado para una versión futura específica?

bitcoin.org es donde se aloja el cliente estándar, pero generalmente no se usa para referirse al cliente en sí mismo; generalmente se lo llama cliente estándar o cliente Satoshi. AFAIK, actualmente no implementa transacciones de poda.
@MeniRosenfeld Arreglado, gracias. No estoy seguro de cómo se debe hacer exactamente, y una implementación puede aclarar las cosas. ¿Algún cálculo de qué tan grande será un bloque sin poda, en los próximos años?
Edité su pregunta para incluir la pregunta de cuándo está prevista una característica de este tipo, espero que no le importe. (También se agregó un signo de interrogación de cierre al título)
Estaba seguro de haber hecho una pregunta similar (sobre la planificación) en el pasado, pero no la encontré ahora. Recuerdo vagamente que Gavin dijo que "es lo siguiente en la hoja de ruta después de multisig", pero no tengo una cita, y creo que no se formalizó de todos modos. Para el cordón, la respuesta directa a su pregunta es "No, el cliente actual no poda historia".
Consulte también la discusión y los enlaces en en.bitcoin.it/wiki/Thin_Client_Security

Respuestas (4)

Desde Bitcoin Core v0.8.0, la base de datos de validación ("estado de cadena" o "conjunto UTXO" o "hoja de balance de la cuenta") está separada de la cadena de bloques. Cuando ingresa un nuevo bloque, sus efectos (eliminar entradas gastadas y agregar salidas) se aplican a la base de datos. Esto significa que los bloques aún se descargan y verifican como antes, pero ya no se usan para la validación después. Los bloques aún se almacenan en el disco para enviarlos a otros nodos que se están sincronizando o para volver a escanear transacciones antiguas.

Desde Bitcoin Core v0.11.0, también es posible ejecutarlo en un modo de eliminación real, donde los bloques en el disco se eliminan después de un tiempo. Desde v0.12, es posible usar la billetera mientras se ejecuta en modo de poda. Desde v0.14, es posible podar manualmente (emitiendo un comando RPC en lugar de que la aplicación decida).

Tenga en cuenta que ninguno de estos mecanismos se basa en el mecanismo descrito en el documento técnico de Bitcoin.

Supongo que esto no está implementado debido al problema que mencionó Pieter. Tener un cliente que solo almacena una versión podada de la cadena de bloques no puede ser amigable para otros clientes que no tienen implementada esta función de poda, ya que no podrá recuperar la cadena de bloques original.

Dado que una variedad de clientes todavía están en desarrollo, lo que permite a los clientes alternativos elegir cómo manejar sus datos de cadena de bloques permite nuevas innovaciones. Por ejemplo, permite analizar cómo se ha comportado Bitcoin a lo largo del tiempo. Incluso si no has grabado esto desde el principio.

Aquí hay dos opciones. El primero puede ser un grupo de cadena de bloques que será un almacenamiento similar a un torrente y se puede implementar de forma independiente en las billeteras (la distribución actual de 30 GB a 2000 clientes con un 50 % de redundancia generará solo un tamaño de 30 MB)

En segundo lugar, podría haber algún tipo de desfragmentación, donde se necesita el desarrollo del protocolo. Aquí no habrá ningún problema para agregar un bloque en la parte superior de la cadena de bloques que incluye, digamos, 100k bloques más antiguos como una copia, sin cuentas de saldo cero. La pregunta es solo si aquí habrá una tasa significativa de desfragmentación. suposiciones

  • no necesitamos transacciones que creen cuentas vacías (todo fue enviado)
  • no necesitamos transacciones que no cambien el saldo (todo fue devuelto)
  • podemos establecer un límite de tiempo para las cuentas inactivas (solo una transacción superó nuestra cuenta y la cuenta nunca se usó)

No es una solución simple y la cuenta inactiva no se puede actualizar hasta que no se esté ejecutando, entonces el último elemento no es del todo seguro.

No, requiere todo el historial para verificar nuevas transacciones (debido a que la seguridad de un nuevo bloque en la cadena requiere la seguridad de todos los bloques anteriores).

Es posible que algunos clientes futuros no requieran toda la cadena y no verifiquen completamente las transacciones; sin embargo, no los consideraría seguros para transacciones grandes porque no tengo idea si el "cliente flaco" en el que estoy no está atascado en una bifurcación maliciosa en la cadena. diseñado para permitir gastos dobles y alguien no se ha ido a México con mis Bitcoins.

Esto no es correcto. No necesita todo el historial para verificar las transacciones: las transacciones gastadas y bien enterradas podrían eliminarse de manera segura si se implementaran. Sin embargo, con el protocolo de red actual, dicho nodo podado no puede proporcionar la cadena de bloques a otros nodos completos.
¿Se implementa la poda del historial de transacciones en el cliente bitcoin de Satoshi?
RespuestasAquíPolítica de privacidad1y, 0v