@SignOfficial
`attestTimestamp` coincidió con `revokeTimestamp`.
No hay brecha.
Eso no debería suceder.
Lo descubrí mientras revisaba las marcas de tiempo.
Revisé otro.
Mismo patrón.
Emisor diferente.
Mismo resultado.
Al principio parecía un problema de tiempo.
Como si la revocación llegara justo después de la emisión.
No fue así.
No hubo un “después”.
Los registros SIGN documentan ambos eventos de manera independiente.
Simplemente se resolvieron en el mismo momento.
Lo que significa que esta credencial nunca tuvo un estado válido.
No brevemente.
No incluso por un bloque.
Lo que significa que nunca hubo un estado para que cualquier sistema pudiera leer.
Ahí es donde cambió.
Esta no era una credencial revocada.
Era una que omitió la validez por completo.
Vacío instantáneo.
Una credencial que existe en estructura, pero nunca existió en el tiempo.
Siguí cómo lo trata el sistema.
Se resuelve.
El esquema se carga.
El emisor es válido.
Todo pasa a nivel superficial.
Excepto que nunca hubo un punto donde realmente pudiera ser utilizado.
Eso solo aparece si lees las marcas de tiempo directamente.
Aquí es donde $SIGN empieza a importar.
$SIGN solo importa si el protocolo puede distinguir entre una atestación donde `attestTimestamp == revokeTimestamp` y una que se volvió inválida más tarde.
Porque en este momento ambos se resuelven de la misma manera, aunque solo uno fue válido.
Así que la pregunta se convierte en esto.
Si la emisión puede producir algo que nunca fue válido ni siquiera por un segundo, ¿qué significa exactamente “emitido” dentro del sistema?
#SignDigitalSovereignInfra #Sign
