EL LIBRO DE SATOSHI La forma en que propuse el sistema, cada vez que se genera un bloque, cada nodo de validación debe aceptar o rechazar ese bloque al validar las transacciones y confirmar los valores hash en el bloque. En efecto, el mismo trabajo que se está haciendo con el sistema actual más los controles de hash de punto de salida. Como los otros validadores ya estaban compitiendo para generar el bloque, ya tienen (al menos la mayoría) las transacciones. Al igual que con el sistema actual, si las transacciones no se validan (más los hashes de punto de salida incluidos) los otros nodos rechazarán el bloque. Si el bloque no obtiene aceptación por al menos el 50% de la potencia de la CPU, no hace la lista de bloque. Entonces, la presencia de los hashes en la lista de bloques significa que al menos el 50% de los validadores existentes en ese momento vieron y validaron todas las transacciones y los hashes de punto de salida que contiene. Por lo tanto (salvo en bloqueos de hashes) si alguien presenta una transacción antecedente que coincide con un punto de salida no gastado, debe ser válida. El antecedente de ese antecedente debe haber sido válido también, de lo contrario el antecedente habría sido rechazado. Y así una y otra vez. Para que ese no sea el caso, debes postular que hubo un período de tiempo en el que los bloques no se validaban contra los hashes del punto de salida. Pero eso es plausiblemente inverosímil con el sistema de competencia de CPU. _____________________________________________________________ Cita de: satoshi, 12 de agosto 2010, 02:46:56 AM Si un cliente no ha estado presente hasta hace poco, las dos formas de convencerlo de que una transacción tiene un pasado válido es: 1) Mostrándole el histórico completo de la moneda original generada. 2) Mostrándole el histórico completo de un bloque extremadamente profundo, entonces confiará en que, si tantos nodos dicen que el histórico hasta ese momento era correcto, entonces debe ser cierto. 235

SOBRE UN TIPO ALTERNATIVO DE CADENA DE BLOQUES CON SÓLO REGISTRO HASH Si un cliente se unió a la red recientemente, lo hizo asumiendo que los validadores anteriores siguieron las reglas y que todos los bloques preexistentes son válidos. (Nadie se uniría a una red con fama de corrupta). Por supuesto, en el sistema actual, si las transacciones nunca se purgaron, un nuevo nodo podría validar todos los bloques anteriores para la auto-consistencia. Pero aún no podrían probar la verdad absoluta. Una red de robots podría haber tomado el relevo y borrado algunas transacciones dejando "una nueva verdad" y usuarios insatisfechos. Equivalente al caso 1) anterior. En el sistema actual, si las transacciones se purgaron del árbol de Merkle, entonces tienes el caso 2) anterior. Los recién llegados deben confiar en el proceso. Falta algo, no tienen por qué preocuparse. Todos deben suponer que fue válido. Lo único que digo es que, si confías en el proceso de la competencia de validación de bitcoins (¡y nosotros lo hacemos!), entonces realmente no necesitas "un 2) bloque extremadamente profundo" para ser muy profundo. Alguien dijo en otro hilo que los clientes rechazan cualquier cambio en los bloques con más de dos horas de antigüedad. Entonces podemos tener absoluta confianza en todos los bloques enterrados a 12 profundidades. Entonces, si una transacción no se gasta y se entierra en profundidad 12, podemos purgar todos sus antepasados. Añaden paños calientes, pero ninguna validación adicional. Tenemos que confiar en ellos. Simplemente no hay forma de retroceder y cambiar el rumbo. Después de eso, cada bloque sucesivo presupone que todos los bloques precedentes son verdaderos. De lo contrario, sería un fork y no un bloque sucesivo. Por lo tanto, para cualquier transacción validada contra puntos de salida en un bloque anterior, si esos puntos de salida existen y no se han gastado, se deben suponer válidos. Si se presume que son válidos, se debe suponer que sus antepasados son válidos, incluso si se purgan. --- 236