Sigué mirando la votación final de Babylon porque el campo que debería haber parecido aburrido fue el que se negó a cambiar.
nuevo hash de bloque.
misma altura.
misma aleatoriedad pública.
y esa última parte empezó a molestarme más que el conflicto.
un Proveedor de Finalidad de Babylon se compromete con la aleatoriedad pública antes de que exista la elección de bloque. luego, cuando llega el bloque, esa altura recibe su firma EOTS y todo parece normal.
una altura. un bloque. un uso.
entonces aparece otra votación para la misma altura.
hash de bloque diferente.
misma aleatoriedad pública.
¿por qué el campo que no cambió es el peligroso?
pensé que la contradicción vivía en los dos hashes. Babylon podría compararlos, ver que el Proveedor de Finalidad respaldó historias incompatibles y castigarlo.
pero los hashes solo muestran la discrepancia.
la aleatoriedad repetida muestra cómo se hicieron las firmas.
al parecer, eso es lo que el Proveedor de Finalidad nunca tuvo permitido repetir.
la misma aleatoriedad pública apunta a la misma aleatoriedad privada subyacente debajo de ambas firmas EOTS. una vez que ese secreto de un solo uso se usa contra dos hashes de bloque, el par deja de comportarse como dos votos ordinarios.
se vuelve suficiente para extraer la clave privada EOTS del Proveedor de Finalidad.
y eso hizo que la pantalla se sintiera al revés.
lo que cambió muestra la mentira.
lo que se mantuvo igual hace que la mentira sea denunciable (slashable).
Babylon no necesita enviar toda la ofensa a Bitcoin después de eso. la clave extraída aporta lo que faltaba en las transacciones de slashing prefirmadas detrás de las delegaciones BTC.
baja el poder de voto. el Proveedor de Finalidad es tombstoned. el BTC nativo ahora puede entrar en rutas de slashing creadas antes de que existieran cualquiera de las dos votaciones.
y aun así sigo mirando esa aleatoriedad pública.
estaba comprometida antes de que cualquier bloque pareciera peligroso.
la primera votación la usó una vez y no expuso nada.
la segunda votación no la alteró.
ese era el problema.
dos hashes de bloque están discutiendo en la pantalla.
el campo silencioso entre ellos es la pista de que el secreto de un solo uso subyacente se pidió que sobreviviera dos veces.
@BabylonLabs_io #baby $BABY $BLESS $TAKE
nuevo hash de bloque.
misma altura.
misma aleatoriedad pública.
y esa última parte empezó a molestarme más que el conflicto.
un Proveedor de Finalidad de Babylon se compromete con la aleatoriedad pública antes de que exista la elección de bloque. luego, cuando llega el bloque, esa altura recibe su firma EOTS y todo parece normal.
una altura. un bloque. un uso.
entonces aparece otra votación para la misma altura.
hash de bloque diferente.
misma aleatoriedad pública.
¿por qué el campo que no cambió es el peligroso?
pensé que la contradicción vivía en los dos hashes. Babylon podría compararlos, ver que el Proveedor de Finalidad respaldó historias incompatibles y castigarlo.
pero los hashes solo muestran la discrepancia.
la aleatoriedad repetida muestra cómo se hicieron las firmas.
al parecer, eso es lo que el Proveedor de Finalidad nunca tuvo permitido repetir.
la misma aleatoriedad pública apunta a la misma aleatoriedad privada subyacente debajo de ambas firmas EOTS. una vez que ese secreto de un solo uso se usa contra dos hashes de bloque, el par deja de comportarse como dos votos ordinarios.
se vuelve suficiente para extraer la clave privada EOTS del Proveedor de Finalidad.
y eso hizo que la pantalla se sintiera al revés.
lo que cambió muestra la mentira.
lo que se mantuvo igual hace que la mentira sea denunciable (slashable).
Babylon no necesita enviar toda la ofensa a Bitcoin después de eso. la clave extraída aporta lo que faltaba en las transacciones de slashing prefirmadas detrás de las delegaciones BTC.
baja el poder de voto. el Proveedor de Finalidad es tombstoned. el BTC nativo ahora puede entrar en rutas de slashing creadas antes de que existieran cualquiera de las dos votaciones.
y aun así sigo mirando esa aleatoriedad pública.
estaba comprometida antes de que cualquier bloque pareciera peligroso.
la primera votación la usó una vez y no expuso nada.
la segunda votación no la alteró.
ese era el problema.
dos hashes de bloque están discutiendo en la pantalla.
el campo silencioso entre ellos es la pista de que el secreto de un solo uso subyacente se pidió que sobreviviera dos veces.
@BabylonLabs_io #baby $BABY $BLESS $TAKE