EL LIBRO DE SATOSHI Estamos tratando de demostrar la ausencia de algo, lo que parece requerir conocerlo todo y verificar que ese algo no esté incluido. R ǃ : No es una sugerencia Publicado por Red, 11 de agosto de 2010, 04:58:50 AM _____________________________________________________________ Satoshi: Sé que sabes la primera parte de lo que estoy escribiendo, pero quiero que otros puedan seguir y corregir cualquier concepto erróneo que pueda tener. Estaba viendo la implementación actual del árbol Merkle tratando de descubrir cuándo se podrían eliminar las transacciones sin perder seguridad. En términos de gráfico de transacción, las transacciones representan los nodos. Los bordes del gráfico de transacción están representados por los puntos de entrada que apuntan a transacciones previas usando una clase de estructura BlockHash->TransHash->OutPoint. Es la existencia de un punto de entrada que marca un punto de salida anterior gastado. Por lo tanto, para que una transacción sea válida, lo más que se muestra por cada punto ingreso de una transacción de AMBOS, un punto de salida anterior existente Y, que no exista un punto de ingreso previo que haga referencia a ese punto de salida. Por lo tanto, para cada punto de salida, hay cero o uno puntos de ingreso haciendo referencia hacia él. cero = no gastado. uno = gastado. Eso también significa que no se puede eliminar ninguna transacción de la lista de bloqueo, hasta que ambos puntos de salida sean gastados. De lo contrario, las monedas desaparecerán. Sin embargo, puede eliminar todas las transacciones de doble enlace tan pronto como esté seguro de que el segundo bloque de enlace se mantendrá. (posibilidad más temprana). Sin embargo, a medida que elimina transacciones y las reemplaza con su hash del árbol de Merkle, pierde la estructura de gráfico presente 227
SOBRE UN TIPO ALTERNATIVO DE CADENA DE BLOQUES CON SÓLO REGISTRO HASH en la lista de bloque. En efecto, todas las transacciones recuperadas de la lista de bloque tienen un valor no utilizado, simplemente porque aún existen. Ya no pueden demostrar su validez por ascendencia ya que esa parte del gráfico fue eliminada. Lo que me hizo pensar, ¿hay alguna forma de probar la validez si nunca se ponen todas las transacciones en el gráfico para empezar? _____________________________________________________________ Cita de: satoshi, 11 de agosto de 2010, 12:14:22 AM El desafío es, ¿cómo se demuestra que no existen otros gastos? Parece que un nodo debe conocer todas las transacciones para poder verificarlo. Si solo conoce el hash de los puntos de entrada/salida, no puede verificar las firmas para ver si un punto de salida había sido gastado antes. ¿Tienes alguna idea sobre esto? _______________________________________________________________ La clave es codificar la información de transacción como parte del hash de punto de salida. Por lo tanto, en lugar de crear un hash de transacción único, representa la transacción como dos hashes de salida. (Originalmente consideré una estructura como un punto de entrada/transacción/punto de salida , usando hashes, pero resultó ser innecesario). Solo los validadores de transacciones necesitan conocer la dirección de bitcoin asociada con un hash de punto de salida grabado. Eso proviene de la transacción antecedente presentada para un punto de ingreso de la transacción actual. La transacción antecedente y el punto de salida son hasheados y se presumen AMBOS válidos y no gastados si ese hash aparece una, y sólo una vez en la lista de bloque. La transacción actual debe estar firmada por la clave de la dirección en las transacciones antecedentes, por supuesto. Si esto resulta válido, se generarán dos nuevos hashes de salida y se insertarán en el bloque actual. Los hashes del punto de ingreso se marcan gastados para incluirlos también en el bloque actual. (Si existe un hash dos veces, se gasta.) Si desea representar la transacción como una unidad (y el gráfico de transacción actualmente visible), los hashes del punto de ingreso y los del punto de salida podrían agruparse. Sin embargo, esto no es estrictamente necesario para probar la validez. 228