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