Lowest Priority!!! Not a call for alarm.
Just a request so I can understand… while doing some blockchain archaeology.
Good morning, I suspect that this topic has been discussed plenty in the past, but im having trouble finding it, unless my solution exists somewhere in Duniter utilise une ancienne version buggée de TweetNaCl: que faire? (and Im just too lazy to read through it). A simple RTFM with a pointer would be much appreciated.
Concerning my attempt to audit the genesis block:
- the Innerhash matches.
- the signature is verifiable.
- the block hash matches.
- spot checking some of the 59 newcomers/identities verifies.
- spot checking some of the 59 joiners verifies.
- BUT spot checking many of the 551 certifications where it looks like each of the 59 accounts are certified by around 9 of the others, so far fails every signature verification that Ive tried. If I jump ahead to block 347 (forged the following evening) where the next cert occurs, it verifies.
Did Certification documents have a different format in the genesis block? Or was there a special rule for creating the signatures?
Thanks in advance for your time to point me to an explanation.
Regards,
Spencer971
2 Likes
I’d argue that downloading software and deciding to run it is similar to a tacit agreement to an adherence/adhesion contract… If assuming that the genesis block is/was embedded in each duniter node from day0, then it’s validity is nothing more than academic (just as satoshi’s genesis coinbase is not spendable). every single participant has already accepted the starting point. Still, Id like to be able to explain it for myself. -Spencer971
1 Like
I believe I’ve found my answer!
It was hinting at me right there in the genesis block… among the verifiable compact identities/joiners entries and even the un-compacted certifications pointer to the identity of the account being certified – which dont verify.
A question I hadn’t yet asked myself: « How could any message be verifiably signed if it contains the block hash of the block it is included in? », led me to see what BlockUID the un-compacted Identity and Membership documents used… which is 0-E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 and which is NOT the CertTimestamp of the compact certifications… which is simply 0 without -HASH; but the accounts needed something to use as blockhashes; whatever they were using looks to have used the 0-E3B0… BlockUID when creating/signing Membership, Identity and Certification… but the node that forged the genesis block compacted the certification entries using the ‹ 0 › as BlockUID. Simply editing the CertTimeStamp to use the same value as the IdtyTimestamp creates a Certification document which is verifiable against its given bottom signature and Issuer pubkey. [note: ive edited my conclusions above in the past hour]
[and after a couple of hours of « Where does the hash for the identity/membership docs come from? » I realize… its the sha256 of an empty message. Very clever guys!
[added following morning: compact certs never have a blockhash expressed, only the block-num.]
2 Likes