The method
A gate in front of broadcast. Not a new chain.
This system implements the disclosed method, system, and apparatus for verifying identities of participants in blockchain transactions. The ledger continues to validate keys. A trust manager, sitting beside the network, validates people.
01
Hold the transaction
A personal computing device constructs a blockchain transaction that includes a non-verified identifier of the intended participant. It does not send that transaction to the network yet.
02
Ask a third-party trust manager
The device sends a verification request containing the non-verified identifier. The request is typically encrypted with the manager’s public key and digitally signed with the initiator’s private key.
03
Attest, federate, or refuse
The manager decrypts the request, checks the signature, and compares the identifier to a database of pre-verified entities. It may contact the recipient, verify credentials with an issuing authority, or forward the request to a second manager.
04
Broadcast only on a positive response
The device transmits the transaction to the blockchain network only when the verification response indicates that the intended participant’s identity has been verified. Otherwise the construction is cancelled and both parties may be notified.
Embodiments
Pre-registration
Participants open an account or enroll specifically to transact. Identity is proven with a passport, driver’s license, Social Security card, birth certificate, fingerprint, or a cryptographically verifiable credential.
On-the-fly verification
If the recipient is not on file, the manager uses contact details in the request, collects credentials, and verifies them with a public or private authority before answering.
Federation
A manager that cannot match the identifier sends a second verification request to another manager — identified by URL, IP, name, or routing number — and forwards the result.
Status messages
The initiator’s device may notify the intended participant that verification is in progress, and again after the response, stating whether the identity held.
What is signed, what is stored
The verification request is hashed (SHA-256) and signed with the initiator’s private key. The manager decrypts the signature with the corresponding public key and compares digests. A match proves the request was initiated by the holder of that key and that the payload was not changed in transit.
After a successful enrollment, the manager stores a record — name, account, public key — in a database of verified entities. Later lookups are automatic. The blockchain transaction that follows still contains only the public keys of the participants.
Apparatus
Each personal computing device — phone, tablet, laptop — holds a processor, non-transitory memory, network interface, and user interface. After it is programmed with the wallet instructions, it becomes the apparatus that constructs the transaction, sends the verification request, and withholds broadcast on a negative response.
The system is the device plus at least one trust manager, communicating over a wide-area network, independent of any particular chain. Bitcoin and Ethereum are examples, not limits.
Run it against a live directory
The console generates a real ECDSA P-256 key pair, signs the verification request, and will refuse to publish if the intended participant cannot be attested.
Open the console