An attacker who wants to fake DOI's, could easily bypass the the fallback server mechanism while
overwriting the responsible (fallback) PUBLIC-KEY in his Send-dApp to another dApp he own's personally.
As it looks for now, it is possible to store faked DOI's in the blockchain but the verification on other nodes would fail, which makes this problem less problematic as it sounds.
Question must be raced, if it is possible to check the SOI signature inside name_doi inside the consensus (e.g. tx_veryify.cpp or validation.cpp).
Problem: Checking the signature with a public key requires also the knowledge of the sender email and recipient email address, which is not available on all nodes. Otherwise the signature could be checked with the correct public key which could be queried through an DNS TXT request.
An attacker who wants to fake DOI's, could easily bypass the the fallback server mechanism while overwriting the responsible (fallback) PUBLIC-KEY in his Send-dApp to another dApp he own's personally.
As it looks for now, it is possible to store faked DOI's in the blockchain but the verification on other nodes would fail, which makes this problem less problematic as it sounds.
Question must be raced, if it is possible to check the SOI signature inside name_doi inside the consensus (e.g. tx_veryify.cpp or validation.cpp).
Problem: Checking the signature with a public key requires also the knowledge of the sender email and recipient email address, which is not available on all nodes. Otherwise the signature could be checked with the correct public key which could be queried through an DNS TXT request.