Decentralized use of zero knowledge proof with enhanced identity credentials to lower external counter party risks, for example to combat money laundering

Abstract

A cryptographic secure transaction system comprising first and second cryptographic storage devices, each having a master key pair and a public key. A computer server maintains a list of globally unique names and associated public keys. The devices communicate via various signaling pathways, including centralized, decentralized, and broadcast-based pathways, using notification addresses derived from their public keys. A shared secret key generation algorithm generates a shared secret key using the devices' keys, and a distributed ledger records transactions using an address derived from the shared secret key. The system includes methods for managing verified credentials, recovering signals, and reconstructing transaction history using the shared secret keys and distributed ledger. The signaling pathways enable secure communication between devices, facilitating efficient credential management and transaction history reconstruction.

Description

DECENTRALIZED USE OF ZERO KNOWLEDGE PROOF WITH ENHANCED IDENTITY CREDENTIALS TO LOWER EXTERNAL COUNTER PARTY RISKS, FOR EXAMPLE TO COMBAT MONEY LAUNDERING CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Patent Application No.18 / 815,394, filed on August 26, 2024, entitled "Decentralized Use of Zero Knowledge Proof with Enhanced Identity Credentials to Lower External Counter Party Risks, for Example to Combat Money Laundering," which claims priority to U.S. Provisional Patent Application No.63 / 578,658, filed on August 24, 2023, entitled "Decentralized Use of Zero Knowledge Proof with Enhanced Identity Credentials to Lower External Counter Party Risks, for Example to Combat Money Laundering," the contents of which are hereby incorporated by reference in their entirety. Incorporation by reference of any document is limited such that no subject matter is incorporated that is contrary to the explicit disclosure of this document. BACKGROUND Field

[0002] This disclosure relates generally to blockchain-based systems and decentralized finance (DeFi), particularly in relation to identity verification and transaction security. More specifically, the invention provides enhanced identity wallets that utilize cryptographic methods, such as Zero- Knowledge Proof (ZKP), to help ensure transparency and security in cryptocurrency transactions. Background

[0003] One of the persistent problems in blockchain and cryptocurrency systems is the inherent anonymity of wallet addresses. While transactions are transparent and traceable on the blockchain, the identity of the person or entity controlling a specific address remains hidden unless voluntarily disclosed. This anonymity creates opportunities for misuse, as bad actors can exploit the system to conduct illicit activities such as money laundering, fraud, or financing criminal enterprises. Despite knowing the source address of a transaction, there is no mechanism to reliably verify who is behind that address. Thus, even if funds are transferred from a legitimate wallet, the lack of identity validation introduces vulnerabilities that allow bad actors to obfuscate their true identities.

[0004] These risks are particularly problematic in custodial systems like banks or exchanges, which receive funds from external addresses without certainty regarding the originator's identity. Without knowing who controls the sending address, these systems become susceptible to attacks by individuals using stolen or tainted funds to mix with legitimate deposits. For example, a user could deposit funds into a legitimate account but then leverage the same receiving address to funnel illicit gains through another wallet, creating an avenue for laundering money.

[0005] Existing identity verification systems, including KYC (Know Your Customer) protocols, attempt to mitigate these risks but often fail to integrate directly with decentralized blockchain transactions. This disconnection between identity and blockchain activity leaves gaps that badactors can exploit. Thus, there is a need for a system that securely links identity to blockchain transactions without sacrificing the privacy and security of legitimate users. BRIEF SUMMARY

[0006] A cryptocurrency system with a communication channel, a wallet, where the wallet has a paycode and associated private key and the paycode is associated to enhanced identity. The wallet can send a zero knowledge proof on the communication channel to prove ownership of the private key and thus proof of the enhanced identity information. The wallet may include a blockchain address (a payment address) and associated private key. The wallet may send a zero knowledge proof on the communication channel to prove ownership of the source and thus provide proof of funds.

[0007] The cryptocurrency system may include a communication channel, a wallet with a private key, where the wallet can send a zero knowledge proof via the communication channel to prove control of the private key. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a block diagram illustrating the overall system architecture of the privacy- preserving cryptocurrency transaction system.

[0009] FIG. 2 is a flowchart depicting the process of initial onboarding of a new private cryptographic security key.

[0010] FIG.3 is a diagram showing the process of generating and managing verified credentials.

[0011] FIG. 4 is a schematic representation of the multimodal pathway configuration for off- blockchain paycode signaling and backup.

[0012] FIG.5 is a diagram illustrating the system for paycode signal quantity masking

[0013] FIG. 6 illustrates a high-level diagram of the process that may be used to establish a transaction between two parties that includes a Zero Knowledge Proof. DETAILED DESCRIPTION Using BIP-47 / OBPP-5 payment codes (also known as paycodes) combined with enhanced identity credentials and the use of a ZK proof allows the parties in a crypto transaction to know that the source funds address is spendable by the private key that generated a sending wallet paycode (and associated name and identity) and a counterparty’s receive address. In addition, the use of the paycode with enhanced identity enables users to send / receive by using names, instead of long and complex cryptographic addresses. In the sending wallet, the master private key (and corresponding child derived keys) are used to compute a receiving address for paycode transactions. The sending wallet’s child private keys are cryptographically tied to the sending wallet paycode, and the paycode – by the enhanced identity– is associated with the name and identity of the person sending the crypto asset. Further, the master private key is used to generate the paycode.

[0014] It would be useful to prove that the source of funds that arrive at the receive address are controlled by a private key that was derived from the master private key, the same master private key used to generate the paycode associated to the name and identity (the enhanced identity).

[0015] The useful proof noted above helps avoid the system being vulnerable to having a computed receive address used in a nefarious manner. Knowing the computed receive address may allow a 3rdparty or bad-actor to send funds to the computed receive address from sources that are not controlled by a sender. Since the calculated address does not require the funds to be sent from the sender’s wallet, i.e. does not require the sender to prove control of the private key of the source payment address (but rather a receiving address will accept funds from any payment address), crypto assets from any address (even a bad actor’s address) could be the source of the funds, which means that an innocent person thinking they are receiving money from the identified person could unknowingly be receiving funds from a different, potentially malicious, wallet. This vulnerability creates a potential avenue for money laundering or other deceptive practices.

[0016] For a bad actor to identify the calculated receive address, they do not need access to the private keys for the sending wallet. Merely eavesdropping on a transaction can provide insight into funds being sent to a receive address. This knowledge can be obtained in various ways, such as analyzing the blockchain, intercepting communication, colluding with a malicious node, phishing attacks, or other means.

[0017] Analyzing the Blockchain: Given the transparent nature of most blockchain transactions, an attacker can monitor and analyze transaction data to identify receive addresses.

[0018] Intercepting Communication: If two parties are communicating about a transaction through insecure channels, a bad actor might intercept this communication and learn about the receive address.

[0019] Colluding with Malicious Nodes: In decentralized networks, if an attacker has control over a significant number of nodes, they can potentially gain insights into specific transaction details that are otherwise obfuscated to individual nodes.

[0020] Phishing Attacks: By pretending to be a legitimate entity, attackers can deceive users into revealing details about their transactions, including the receive address.

[0021] For example, say there is a user that has a verified KYC (Know Your Customer) identity called “innocent_grandma_A” with a wallet A having a private key A controlling payment address A on the blockchain and grandma A uses address A to transfer assets on the blockchain into a crypto address under control of custody system B (for example, bank B) using a receive address known as B-receive-from-A address. All the funds moving from address A to B-receive-from-A address are legitimate and normally untainted and therefore after a bit of time the custody system B may assume that all money deposited into B-receive-from-A address are funds that are coming from sources controlled by private key A. However, a bad-actor could determine the B-receive- from-A address, for example by examining the transactions being performed by wallet A. Then with that B-receive-from-A address a bad-actor could take another wallet Z that the bad-actorcontrols, one that is filled with stolen funds, and then send assets from Z wallet to the B-receive- for-A address. The bad actor may also give the B-receive-from-A receive address to criminal third parties for them to send funds to B-receive-from-A address. In this scenario B would not be able to tell the difference in the source of funds and thus money laundering may occur if the funds are then exchanged in the custody system upon deposit. If the bad actor and “innocent_grandma_A” are colluding or are the same person then now wallet A could withdraw the exchanged funds thus potentially successfully performing money laundering.

[0022] To thwart this attack, a non-interactive Zero Knowledge proof can prove that the funds sent for payment source address are in fact controlled by a private key of sender A and that same private key is cryptographically proven to be tied to the sender A paycode and associated to the identity through the enhanced identity.

[0023] In Bitcoin and many other cryptocurrencies, a cryptographic technique called Elliptic Curve Digital Signature Algorithm (ECDSA) is used to generate public-private key pairs and verify signatures. When funds are at a certain address, there is a private key corresponding to that public address. A recipient of funds after receiving the funds at a receive address computed by the OBPP-5 / BIP-47 protocol can inspect the on-chain transactions and see the address or addresses that the funds originated from. The zero-knowledge-proof proof when sent via a side channel (also known as a multimodal pathway or signaling pathway) would further prove not only that the receive address was computed by a specific paycode (which is linked through enhanced identity to the sender, i.e., enhanced credentials) but that also the funds sent to the receiving address came from a private key known to the sender that can spend those funds and that same private key is a child private key derived from the master key used to compute the senders paycode.

[0024] In the context of this specification, the term "blockchain" is used as an example of a distributed ledger system. However, it should be understood that the methods and systems described herein are not limited to blockchain specifically but may apply to any form of distributed ledger technology (DLT). Distributed ledger technology encompasses a wide variety of implementations where data is maintained across multiple nodes, typically with decentralized control, ensuring security, transparency, and resistance to tampering. Blockchain is one example of such a system, but the methods described may be implemented in other distributed ledger systems, such as directed acyclic graphs (DAGs), hashgraph, or other consensus-based, decentralized data structures that maintain a verifiable record of transactions.

[0025] Definitions:

[0026] A master private key is the root key of a wallet from which all other keys in the wallet may be derived.

[0027] A paycode private key is the private portion of a paycode public / private key pair where the public portion is presented as a paycode and used as a paycode. The paycode private key may be derived from a master private key, for example derived following BIP-47 at the “m / 47' / coin_type' / identity'” path.

[0028] A payment address private key is the private portion of a payment public / private key pair where the public portion is presented as payment addresses and used as a payment address. Thepayment address may be used, for example, on a distributed ledger. The public / private key pair may be derived according to the BIP-47 specification.

[0029] zkSNARK: Zero-Knowledge Succinct Non-Interactive Argument of Knowledge refers to a proof construction where one can prove possession of certain information, e.g., a secret key, without revealing that information, and without any interaction between the prover and verifier. In this case the prover is the sender aka payor and the verifier is the receiver also known as the payee.

[0030] Here is a step-by-step implementation of the zkSNARK version of the Schnorr protocol to prove control of a private key corresponding to a known public key P and that the same private key is derived from a master private key that created the sender paycode PC. The public key P may be a payment address, either a source payment address Ps, a Source Address, or a destination payment address Pd, a destination address.

[0031] Zero Knowledge Proof 1: Proof of control over both the payment sending address Ps and sender Paycode PC thus providing proof the funds come from sender (e.g. a payor’s wallet) that controls the private key for Ps and the private key for PC, where the paycode PC may be associate to enhanced identity information that identifies the Payor.

[0032] 1. Commitment Phase: • The sender (e.g. the payor’s wallet) selects two random numbers: r1and r2. • The sender then calculate: R1 = r1*G and R2 = r2*G (Where In cryptographic contexts, G represents a predetermined point on an elliptic curve. This point is universally known by participants in a specific blockchain system. In the case of Bitcoin, this predetermined point is referred to as 'secp256k1'.).

[0033] 2. Challenge Phase: The sender challenge is computed as: e = H(R1 || R2 || P || PC). Where: H is a hash function, || denotes concatenation, R1 is a first commitment point related to proving control over the private key linked with payment address P, P is the payment address (payment source address), R2 is a second commitment point associated with proving control over the private key of the payment code PC, and PC is the sender’s payment code. This binds the challenge to the specific public key and the payment code.

[0034] 3. Response Phase: The sender calculates: s1= r1+ e*kPwhere: kPis the private key of the payment public / private key pair where the public portion is the payment source address P, for example where P= kP*G. kPCis the private key of the paycode public / private key pair, where the public portion is the paycode PC, for example where PC= kPC*G.

[0035] 4. Proof: The sender provides the proof date (R1, R2, s1, s2) to the receiver (payee’s wallet).

[0036] 5. Verification: The receiver can verify the proof. The receiver knows the source address P, the paycode PC and receives the proof data (R1, R2, s1, s2), so they can run the proof by verifying these equations balance when all the known information is substituted s1*G = R1 + e*P s2*G = R2 + e*PC

[0037] Ifreceiver can be confident about the sender controls the private keys of both the payment source address P and the sender paycode PC. This is all done without learning anything about the private keys themselves, that is the "zero-knowledge" property. And since the verifier (sender) generates the challenge themselves rather than receiving it from the receiver, the proof is also non-interactive, as required by a zkSNARK.

[0038] Zero Knowledge Proof 2: Proof of control of sender Payment Code (this proof maybe used to prove information contained in the enhanced Identity).

[0039] ZK Proof 2 Step 1 Commitment The sender generates a random number r and calculates a commitment point R, where R = r*G.

[0040] ZK Proof 2 Step 2 Challenge: The sender (payor’s wallet) computes e = H(R || PC), where: H is a hash function, || denotes concatenation, R is the commitment point, and PC is payment code. This binds the challenge to the payment code.

[0041] ZK Proof 2 Step 3 Response: The sender calculates s = r + e*kPC, where:kPCis the private key associated with the payment code PC, that is the public Payment code PC = (kPC)*G

[0042] ZK Proof 2 Step 4 Proof: The sender sends the proof data, which consists of (R, s) to the receiving user (the verifier).

[0043] ZK Proof 2 Step 5 Verification: The verifier (payment recipient’s wallet) knows the sender’s payment source address P, the sender’s payment code PC and has received the proof data (R, s), can verify the proof by computing e = H(R || PC) and checking that s*G = R + e*PC.

[0044] Note this Proof may be used to show control over the sender paycode, and proof over the sending address will come when the transaction come across on the blockchain.

[0045] Zero Knowledge Proof 3: Proof of control over an address (i.e. a sending address), and this proof may be used for proof of funds.

[0046] ZK Proof 3 Step 1 Commitment The sender generates a random number r and calculate R = r*G. (Where In cryptographic contexts, G represents a predetermined point on an elliptic curve. This point is universally known by participants in a specific blockchain system. In the case of Bitcoin, this predetermined point is referred to as 'secp256k1'.)

[0047] ZK Proof 3 Step 2 Challenge: The sender computes e = H(R || P), where H is a hash function, || denotes concatenation, R is the commitment, P is the public key (source address SA). This binds the challenge to the source address.

[0048] ZK Proof 3 Step 3 Response: The sender calculates s = r + e*k, where k is the private key associated with the source address P.

[0049] ZK Proof 3 Step 4 Proof: The sender sends the proof, which consists of (R, s) to the verifier.

[0050] ZK Proof 3 Step 5 Verification: The verifier (receiver), who knows the source address P and receives (R, s), verifies the proof by computing e = H(R || P) and checking that s*G = R + e*P.

[0051] To tie this in to the diagram in Fig. 6, the zkSNARK verifies that Alice’s source “wallet address” (not depicted in diagram) is in fact controlled by a private key known to Alice. A side- channel communication may provide the zkSNARK proof – for example proof (R1, R2, s1, s2) – and this proof may be used by the receiver to verify that sending wallet has control over the paycode, PC, and the address P.

[0052] Zero Knowledge Proof 4: Other mechanisms of proof may show that the sender Address P and the Paycode PC and the master public-key, thus providing proof the funds come from sender that controls the private key for P, the private key for PC, and the private key for the master public key where the paycode PC may be associated to enhanced identity information that identifies the payor.

[0053] ZK Proof 3 Step 1 Commitment Phase: - The sender selects three random numbers: r₁, r₂, and r₃ - The sender then calculates: R₁ = r₁*G and R₂ = r₂*G and R₃ = r₃*G (Where in cryptographic contexts, G represents a predetermined point on an elliptic curve. This point is universally known by participants in a specific blockchain system. In the case of Bitcoin, this predetermined point is referred to as 'secp256k1').

[0054] ZK Proof 3 Step 2 Challenge Phase: The sender challenge is computed as: e = H(R₁ || R₂ || R₃ || PC) Where: H is a hash function, || denotes concatenation, R₁ is a first commitment point related to proving control over the master private key, R₂ is a second commitment point associated with proving control over the private key used in deriving the paycode PC, R₃ is a third commitment point associated with proving control over the private key used in deriving receiving addresses, PC is the sender's payment code.

[0055] ZK Proof 3 Step 3 Response Phase: The sender calculates: s₁ = r₁ + e*k_m s₂ = r₂ + e*k_pc s₃ = r₃ + e*k_base where: k_m is the master private key, k_pc is the private key derived from k_m using the path m / 47' / 0' / 0', k_base is the private key derived from k_m using the path m / 47' / 0' / 0' / 0'.

[0056] ZK Proof 3 Step 4 Proof: The sender provides proof (R₁, R₂, R₃, s₁, s₂, s₃) to the receiver.

[0057] ZK Proof 3 Step 5 Verification: The receiver can verify the proof. The receiver knows the master public key P_m, the paycode PC and receives (R₁, R₂, R₃, s₁, s₂, s₃), so they can verify these equations balance when all the known information is substituted:s₁*G = R₁ + e*P_m s₂*G = R₂ + e*P_pc

[0058] If all can be confident the sender controls of the master private key, the

[0059] Zero Knoledge proof 5: The system may implement a zero-knowledge proof of the relationship between a master private key and derived public keys through a zkSNARK (Zero- Knowledge Succinct Non-Interactive Argument of Knowledge). The zkSNARK system comprises a one-time setup phase that generates a private proving key and a public verification key; a proving phase that uses the proving key to generate proofs; and a verification phase that uses the verification key to validate proofs. This zkSNARK implementation may be accomplished using existing cryptographic frameworks such as circom for circuit development, the Groth16 proving system for efficient verification, or more recent frameworks like PLONK which offer universal setup. Other available tools include the arkworks libraries for zkSNARK implementations, or the gnark framework for Go implementations.

[0060] The one-time setup phase may: a) Create an arithmetic circuit encoding the constraints that must be satisfied to prove key relationships b) Generate a proving key (PK) used by the prover to create proofs c) Generate a verification key (VK) used by verifiers to check proofs d) Make the verification key public while keeping the proving key private

[0061] The arithmetic circuit may encode the following constraints: a) Relationships between the master private key and master public key: P_m = k_m * G, where: - k_m is the master private key (kept private as a witness input) - P_m is the master public key (provided as a public input) - G is the generator point of the secp256k1 curve b) Relationships demonstrating proper BIP-47 key derivation: - Knowledge of the master private key k_m - Knowledge of derived child keys - Proper mathematical relationships between parent and child keys

[0062] The prover (e.g., a wallet demonstrating proper key derivation) may: a) Input secret witness values into the circuit, including: - The master private key k_m - Any intermediate private keys and chaincodes b) Input public values, including: - The master public key P_m - The child public key P_child c) Generate a zero-knowledge proof π using the proving key PK d) Publish the proof π along with the public inputs

[0063] Any verifier may validate the proof by: a) Taking as input: - The verification key VK - The proof π - The public inputs (P_m and P_child) b) Running the zkSNARK verification algorithm c) Receiving a binary output indicating whether the proof is valid

[0064] The proof system may provide the following security properties: a) Zero-knowledge: No information about private keys or intermediate values is revealed beyond what is implied by the public inputs b) Soundness: A valid proof can only be generated by a prover who knows the actual private keys and relationships c) Completeness: Honest provers with valid key relationships can always generate accepted proofs d) Succinctness: Proofs are small and verification is efficient relative to the computation being proved

[0065] The system may specifically prove: a) The prover knows the master private key k_m corresponding to the public master key P_m b) The prover knows child private keys properly derived from k_m c) The mathematical relationships between master and child keys satisfy the cryptographic requirements of BIP-47

[0066] An implementation or a ZK Proof for the system may consist of two steps: 1. When a TX is sent using the BIP-47 / OBPP-5 scheme, simultaneously the above zkSNARK protocol would be used by the sender, Alice, to generate a proof, for example proof (R1, R2, s1, s2) that would be sent, for example via a side channel such as chat to the recipient, Bob. 2.Upon receiving the funds, the recipient Bob may know the sending paycode (PC) from the OBPP-5 signaling system and the source address P from examining the TX performed in step 1 on-chain. With P and PC known, the recipient may then perform verification step of the zkSNARK protocol (for example check that s1*G = R1+ e*P and s2*G = R2+ e*GPC) to confirm that the sender has control over to the private keys associated with PC and P. And further from doing the OBPP-5 calculations that the receive address was uniquely computed by the sending paycode PC.

[0067] If the funds came from multiple source addresses, then the proof / verification would be completed for each of the source addresses.

[0068] In a variant of the above two step process the sending wallet constructs and transmits a set of zkproofs verifying that all the sending-addresses the sending wallet would use to send funds, so that the receiver would know that those sending-addresses were controlled by the private keys of the sending wallet. Then any subsequent transactions, sent from all the different sending-addresses,could be verified even if a specific proof for a particular subset of source addresses was not sent along with each transaction.

[0069] Additionally, the paycode may have enhanced credentials as described in the patent titled “PRIVACY-PRESERVING CRYPTOCURRENCY TRANSACTIONS WITH ENHANCED CREDENTIALS AND USER-FRIENDLY PAYCODE INFRASTRUCTURE.”

[0070] This application reproduces content from Provisional Patent Application Serial No. US63 / 507,085, filed on June 8, 2023; and U.S. Provisional Patent Application No. 63 / 512,052, filed on July 5, 2023 and PCT Application No. PCT / US24 / 33224, filed on June 10, 2024, each titled "PRIVACY-PRESERVING CRYPTOCURRENCY TRANSACTIONS WITH ENHANCED CREDENTIALS AND USER-FRIENDLY PAYCODE INFRASTRUCTURE." The following paragraphs reflect subject matter originally disclosed in those applications.

[0071] FIG. 1 provides an overview 100 of three parts of a system for secure cryptographic transactions, specifically initial onboarding of a new cryptographic storage device like a cryptocurrency wallet. The process starts at an onboarding box 120, where a global unique name is established with an associated public key, also known as a paycode. Next, the process may continue at an optional validate and store identity box 130, where KYC / AML information may be collected, verified by a third-party validator, and signed by a recognized signing authority, such as a wallet provider. Finally, at an off blockchain paycode signaling box 140 cryptographic storage device can notify other cryptographic storage devices of incoming paycode transactions.

[0072] FIG. 2 provides details for initial onboarding process flow 200 of a new public key. Bringing a new user onto the system may comprise the following steps in the onboarding process flow 200.

[0073] Initially, the user may submit a request for "Global Unique Name(s)" 204 to use to create cryptocurrency transactions. The registrar 208 (e.g., Wallet Provider) may verify the availability of a chosen name, and if it is not available, the user may be prompted to select a different name, or the user may be presented a list of related available names. Once this initial step is completed, the registrar 208 establishes a global unique name 206 for the wallet of the user.

[0074] Once the global unique name 206 is established, the registrar 208 may generate a public paycode and corresponding public and private key pair 214. A cryptocurrency hardware or software wallet 210 may generate a public key, for example a paycode, and a private key pair 214. The system may use the previously described methods, for example entropy-based methods, as specified in the Patent applications titled 'Secure Cryptographic Server Card', and 'Crypto Currency Hardware Wallet' for generating the private key.

[0075] This application incorporates by reference Patent Application Serial No. US17 / 732,511, filed on April 28, 2022, titled 'Secure Cryptographic Server Card,' that claims priority to Provisional Application Serial No. US202163181221P filed on April 28, 2021. The contents of these applications, are hereby incorporated by reference in their entirety into the specification of the present application. Incorporation by reference of document is limited such that no subject matter is incorporated that is contrary to the explicit disclosure of this document.

[0076] This application incorporates by reference Patent Application Serial No. US17 / 300,944, filed on December 15, 2021, titled 'Crypto Currency Hardware Wallet,' which claims priority to Provisional Patent Application Serial No. US202163181221P filed on April 28, 2021, and also claims priority to Provisional Patent Application Serial No. US202063125947P filed on December 15, 2020. The contents of these applications, are hereby incorporated by reference in their entirety into the specification of the present application. Incorporation by reference of documents is limited such that no subject matter is incorporated that is contrary to the explicit disclosure of this document.

[0077] The generated public paycode and private key pair 214 may be stored securely by the system in the global name list 212 along with the corresponding global unique name 206. The global name list 212 contains entries for each cryptographic storage device, such as Name1 - Paycode1, Name2 - Paycode2, and so on. The storage may be implemented through various means, for example server-based storage, cloud storage, on-chain smart contract storage (e.g., Ethereum Name Service - ENS), or an on-chain crypto-powered storage system such as Filecoin. The storage may be encrypted or may be stored in plain text, either individually or using a combination of these methods.

[0078] Once the onboarding process flow 200 is complete, the user's wallet 210 may be configured to allow transactions to be made using the global unique name 206, and the wallet 210 may be configured to exclusively use the global unique name 206. In the "exclusive globally unique name mode," the wallet 210 functions under the hood with both paycodes and legacy addresses, but the UI only exposes plain language names and legacy addresses. As such, the wallet 210 is universally compatible with all other non-custodial crypto wallets but allows for far greater ease of use. The user interface of the wallet 210 may not display the public paycode, meaning a user does not need to be aware of the public paycode and other related cryptographic technology to conduct transactions. This feature enables the system to be a global payment platform with an experience similar to modern payment platforms from a user experience perspective but technologically – under the covers – utilizing decentralized and cryptographically secured systems. Modern payment platforms are, for example, PayPal, Venmo, Cash App, or others. The cryptographically secure system may include systems like decentralized blockchain networks and off-blockchain cryptographically secure custody systems as mediums for transacting with cryptocurrency or other crypto assets. Due to the inherent nature of public paycodes, only the transacting parties that have access to the paycode's related private key have visibility and therefore awareness of the transactions. The transactions may be performed on blockchain or off-blockchain. For example, if Alice transacts with Bob's global unique name 206, observers unrelated to the transaction cannot determine if there was a transaction between the wallet 210 of Alice and the wallet 210 of Bob. Consequently, the transaction remains untraceable to third-party observers, but with the convenient and familiar experience provided by modern financial services, while only being visible to the involved parties.

[0079] FIG. 3 provides details for adding enhanced credentials to the user's wallet. The system may provide enhanced credentials, allowing users 302 to obtain enhanced identity credentials for their global unique names. To acquire these credentials, a user 302 may submit specific KYC / AML ("Know Your Customer" / "Anti-Money Laundering") credentials 304, such as a driver's license or passport. The credentials 304 may be submitted through the wallet to a signing authority 306 (e.g.,wallet provider like Swiss Fortress). The signing authority 306 may send the submitted credentials 304 to a verification service provider 310 to undergo a KYC / AML check 308. The verification service provider 310 may conduct the check 308 using dedicated processing servers. In the event of a positive check result (i.e., user credentials are verified), a recognized Signing Authority 306(e.g., Wallet Provider like Swiss Fortress) may provide verified credentials 312. The signing authority 306, having a key pair with a published public key, may execute a private key signature on a payload to create the verified credentials 312. The verification service provider 310 and the signing authority 306 may be the same entity.

[0080] Verified credentials 312 may comprise a digitally signed payload and an unsigned payload that allows the payload to be verified. The signing process may create a cryptographic hash of the unsigned payload, then encrypt the hash using the signing authority's private key to produce the signed payload. The user wallet and the counterparty wallet can confirm the validity of the signature by decrypting the signed payload using the signing authority's public key. This reveals the original hash value, which will match the hash of the unsigned payload if the signature is valid.

[0081] The payload may include the globally unique name, public paycode, blind claims, unblinded claims and other data. The signing authority 306 may return the verified credentials 312 to the user's wallet. These verified credentials 312 may be stored, either centrally for universal access or in the wallet itself. The verified credentials 312 may be shared with selected counterparties.

[0082] The verification of these credentials by counterparties may be used by the counterparty to ensure that they are indeed transacting with the credentialed user.

[0083] Only the corresponding credentialed user’s private key can control the crypto currency or crypto assets associated with the paycode’s blockchain addresses / transactions. The nature of public paycodes ensures that only the transacting parties are aware of their specific transactions, be the transaction on-blockchain or off-blockchain. For example, if Alice transacts with Bob’s global unique name, which is credentialed, third-party observers cannot determine if Alice or Bob conducted a transaction nor even what blockchain (e.g. Bitcoin, Ethereum, Cardono. Etc.) let alone the block containing such a transaction. This creates a transaction experience similar to modern financial services applications for the involved parties, while remaining untraceable to others. The distribution of credentials can be achieved through any number of means for example an encrypted Distributed Hash Table (DHT) messaging system, such as Bitmessage.

[0084] When exchanging credentials, the system may store the credentials centrally or decentralized in an encrypted state, and the wallet may share an encryption key, not the credentials themselves, and let the receiving wallet access and decrypt the centrally stored credentials 312. This may allow efficiency in the exchange of credentials, saving bandwidth and local storage on the wallet.

[0085] For sending enhanced credentials, the credentials may be securely stored, and encrypted using a user's key (which may be a derived symmetric key), either in a centralized or decentralized manner. When a user shares the credentials with a counterparty, they do not need to transmit the entire credential, but instead, they may send a key to decrypt it. The counterparty may downloadthe encrypted credentials from storage and decrypt the credentials. This way, instead of the enhanced identity being transmitted, all that is sent is a key to unlock it.

[0086] This application incorporates by reference Patent Application Serial No. US17 / 583,189, filed on January 24, 2022, titled ‘Cryptographically Secured Hybrid (On and Off Blockchain) Cryptocurrency System,’ which claims priority to Provisional Patent Application Serial No. US202163140270P filed on January 22, 2021. The contents of these applications, are hereby incorporated by reference in their entirety into the specification of the present application. Incorporation by reference the documents is limited such that no subject matter is incorporated that is contrary to the explicit disclosure of this document.

[0087] FIG. 4 shows a privacy-preserving signaling system 400 of an example wallet provider. The system 400 includes a request 404 to initiate transaction with NameB. The request 404 is sent to a cryptographic storage device A 406 that stores public key (Paycode A) and private key A. The cryptographic storage device 406 sends an request 408 to the Privacy-Preserving Signaling System 410 (example: wallet provider). The request is for the Paycode for Name B that is retrieved from the global name list 412 and returned to the cryptographic storage device 406. The global name list 412 includes for example pairs like Name1 - Paycode1, Name2 - Paycode2, and NameB - PaycodeB. The cryptographic storage device 406 can then send a notification request

[0088] The system 400 also includes an off blockchain Paycode Signaling Inbox 416 (multimodal pathways). The off blockchain Paycode Signaling Inbox 416 communicates with the global name list 412 to authenticate to access Inbox of PaycodeB and retrieve and decrypt signal from PaycodeA 418. The signal from PaycodeA 418 is sent to a PaycodeB - private keyB module 420. The PaycodeB - private keyB module 420 outputs a transaction notification 422 indicating the transaction is ready with the correct shared secret address 422.

[0089] System 400 shows one possible multimodal pathway configuration that include off- blockchain paycode signaling and backup.

[0090] For the paycode (i.e. payment code) transactions to function (for example, as per BIP- 47 / OBPP-5) the sending wallet must signal the receiving wallet with the paycode of the sending wallet. This sending of the paycode and subsequent receiving of the paycode by the receiving wallet is know as a paycode signal. The paycode signal provides the destination wallet the paycode of the sender wallet. This is necessary for the destination, i.e. receiving wallet, to derive the unique shared blockchain addresses to watch and use for subsequent transactions with the sending wallet.

[0091] So long as the wallet retains these signals the wallet can determine all the assets under the control of the wallet’s private keys and can know the balance of the transactions conducted with the other paycodes. But if the wallet needs to be reconstructed from the private key (for example, restoring using BIP-39 mnemonic phrase) the wallet will not have the list of paycode signals to be able to know what assets the wallet has. That is, the wallet will lack the list of blockchain shared secret addresses derived from the paycode holding assets under the wallets control. Lacking this information, the restored wallet would be ignorant of the crypto assets it controls. The restored wallet needs to recovery these paycode signals to be able to know all the assets under the wallets control.

[0092] The multimodal pathway will have multiple ways to simultaneously sent paycode signals and provide a persistent backup of the paycode signals.

[0093] Paycode signaling may occur on-blockchain through encrypted paycode signals sent to a fixed address on a blockchain. The paycode signal may be sent on an alternate blockchain. An alternate blockchain may be used because it offers some advantage over the transacting blockchain were the money or crypto asset, will be transferred. For example the alternate blockchain may have lower fees, lower latency, better privacy or other advantages.

[0094] To enhance the security, speed and recovery, the system may include, multimodal signaling pathways.

[0095] The multimodal signaling may use improvements to the paycode signaling process for example using off blockchain paycode signaling.

[0096] The multimodal signaling pathways may include dual / triple redundant paycode signal paths.

[0097] The system may include paycode signal quantity masking.

[0098] The system may include dual / triple redundant paycode signal paths.

[0099] Paycode signals may be sent and stored through the multimodal pathways. Pathways may be centralized or decentralized. In a multimodal pathway an inbox may be setup for a particular paycode (for example, paycodeB) and wallets desiring to transact with paycodeB send signals to the inbox where the signal consists of the wallet’s own paycode (for example PaycodeA) encrypted so only paycodeB may decrypt the message to access the Paycode (for example, PaycodeA) . These paycode inboxes may exist simultaneously and be implemented on several multimodal pathways.

[0100] Decentralized signal pathways may use a DHT messaging system (e.g., Bitmessage), smart contracts, decentralized storage systems (for example, Filecoin), or other decentralized infrastructure.

[0101] Centralized signal pathways may include private servers to hold data or to run a private blockchain.

[0102] The multimodal pathways may be via private server messaging or with a blockchain backup like Filecoin. The blockchain backup may offer both speed and redundancy.

[0103] A signal pathway may be an alternate blockchain, either a dedicated blockchain, existing blockchain, or a smart contract running on an existing blockchain. The blockchain maybe proof of work or proof of stake.

[0104] The signaling pathway may be decentralized on blockchain signaling for example with signaling as specified in BIP-47 / OBPP-5. The signaling pathway may include messaging signaling like bitmessage.

[0105] The signaling pathway may be a backup for example a cloud backup of all paycode signals.

[0106] The signaling pathway may be a failsafe on blockchain backup. The failesaft on blockchain backup may include additional extra or random data, i.e. noise. If the paycode signal fails to reach the destination wallet in another pathway the destination wallet signal may be sent on the same blockchain that is conducting the transaction (for example this may be done in the Unspent Transaction Output chains, by sending a small amount of value to the receiver notification address with the paycode signal as embedded metadata). As a failsafe every paycode sent to or received by a wallet may be recorded by sending a small amount of value on a chain as metadata embedded in the transaction. If all the paycodes that the wallet transacted are already recorded, then the wallet may just record a random paycode to add ‘noise’ in the failsafe backup to make it more difficult for a bad actor to use any leaked data to infer information about the wallet’s transactions.

[0107] An alternate way to reconstruct the paycode signals, and thus the share secret addresses that may hold crypto assets would be a list of all paycodes, this list may be all paycode registered in the system. For the list of all paycodes the system may have each stored paycode be signed cryptographically by the wallet. The paycode may be stored associated with identity information and that association and data may be signed by the wallet, so paycode and identity associated with the wallet cannot be spoofed. Additionally, storing the list of all paycodes and their names on a substantial part of the system creates robust decentralization. A wallet may if it is trying to obtain a list of users on the system and cannot get it from the centralized servers or decentralized blockchains may contact other wallets via peer messaging protocol to obtain a copy of paycodes and names currently registered on the system.

[0108] The multimodal Signal Process in the system may use all or some these methods. For example, if the wallet is sending to a new payment code or chatting with a new payment code then notify may be done via centralized signaling and an alternate chain and the system may also use noise protocol on the ‘Alternate Chain.” The wallet signals may be backed-up to a cloud backup.

[0109] If a wallet is sending a payment code or chatting with a paycode (or if someone is added to the contacts list on the wallet or a wallet received a chat request or signal - "preemptive notification"), and if this payment code has never been notified before (check for the signal on the “alternate chain”), then construct a notification via the centralized signaling pathway (such as the messaging system - which could alternately be implemented decentralized) and main alternate chain decentralized way (which blockchain is used may be configurable, for example a private blockchain and CSPR smart contract for Cerrus). The systems may also (optional, configurable) add noise protocol as detailed below to the "alternate chain" if its cheap (presently that is not the case for Cerrus but is fine on Swiss Fortress). The signals received by a wallet may also be backedup to cloud backup storage only accessible by the wallet. The signal may be optional or be configurable to be receive by the wallet.

[0110] The centralized signaling may be optionally configurable

[0111] The system may be configued to send on chain signal backup with failsafe and noise. If the blockchain that the transaction is being conducted is a UTXO (Unspent Transaction Output) concept then the system may add a notification transaction by adding an algorithm, for example like this one:

[0112] If the alternate blockchain is up and running and the wallet has not yet backed up all the paycode signals it received then the wallet may use a deterministic identifier only known to the wallet (ex, a hash of the private key) and the wallet may signal to that identifier (which externally appears as a regular signal inbox) a signal or signals. The wallet may have signaled itself with encryption such that these paycode signals are only recoverable by the wallet and different then the encryption used on the incoming signals (so they cannot be correlated to the incoming signals on the alternate chain). If possible, the wallet should backup multiple or all unbacked up signals as long as the transaction fee is not significantly increased. If all incoming signals are backed up then proceed to noise protocol.

[0113] If the alternate blockchain is down then try the failsafe. If the alternate blockchain is down and the recipient paycode is new to the wallet, then notify the recipient paycode inside or alongside of the blockchain transaction. This is ok as when the alternate blockchain is up for a while and the random notification protocol is running, it is likely that the recipient has been notified before on this chain. (Optional, configurable) the wallet may assign a random probability (say 50%) of doing this real notification to decrease reliability but increase noise. This can be a table such that on first attempt its 50% chance of real notification, on second attempt 75%, on third 100% etc. If the paycode is already written in the blockchain using a failsafe method transaction there is no need to backup the paycode signal to the failsafe, since it is unnecessary (due to previous signaling of said recipient on this blockchain) and all incoming signals backed up then go to noise protocol.

[0114] In noise protocol when the alternate blockchain is up or the wallet has randomly chosen to not do a real notification, but instead sends a fake notification, to make noise about the transactions signals to hide actual volume of signals going to any particular paycode notification address.

[0115] The wallet may check the wallet’s contact list for any known payment codes that have not been notified on this blockchain yet and notify paycode from the contact list but do not notify the recipient paycode that is being paid.

[0116] If the wallet, cryptographic storage device, find all known paycodes from the wallet’s contact list are already notified on this blockchain then the cryptographic storage device may randomly pick a paycode from the global list of known paycodes and notify, this will add noise to the overall system. These ‘extra noise’ records or fake signals are optional and may be configurable.

[0117] If the wallet is out of contacts to notify, then the paycode signal may notify a made- up random paycode. For a failsafe running on a non-UTXO, like the Ethereum blockchain, Ethereum Virtual Machine (EVM) chain or other non-UTXO for example CSPR and ETH there may be a mechanism to provide notification at low cost, for example gas-efficient smart contracts or event logs.

[0118] The overall system may eliminate the privacy leak of a 3rd party knowing that there is some significant chance that a first-time notification to a paycode combined with money transfer means that that specific paycode received the money. However, if the alternate chain is down, and a user has not been signaled before the failsafe ensures that a signal is sent along with the funds being sent and thus the funds cannot be lost.

[0119] A list of all paycodes being maintained and backed up provides an additional mechanism the system has available to restore all paycode signals from. The list allows all funds to be recovered by checking each shared secret derived address for transaction on all blockchains the wallet can transact on. Recovery using the list allows recovery but it may be computationally expense if there is a large number of paycodes on the list. Some of the computation may be off- loaded from the wallet to a server, be it a private server or a cloud server computer. The cloud backup may be on satellites.

[0120] Some of the full nodes of the alternate chain may be strongly secured and not possible to shut down like in space or at hardened facilities. Desktop wallets may be nodes with a full or partial copy of one or more alternate chains. The system may provide a coordination protocol such that every group of X (for example, 100) desktop wallets always maintains the latest copy of the alternate chain.

[0121] The alternate chain may be merge-mined NameCoin. The alternate chain may be merge-mined fork or clone of NameCoin. Both the fork / clone and NameCoin may be signaled for redundancy, and both may be signaled simultaneously.

[0122] Every wallet may also keep a copy of the current list of all registered paycode and optionally their associated names.

[0123] Received address computation via List of all registered paycodes may be GPU accelerated (which will make recovery faster, for example 100x faster)

[0124] APPROXIMATE SIGNAL INDEXING. Signal notifications in BIP-47 / OBPP-5 (and as presently embodied in Open Transactions, OT) consist of index-from paycode signal (I,FPCS) pairs. The index is computed deterministically for each recipient paycode and the FPCS is an encrypted sender’s paycode signal that indicates the senders paycode and can only be correctly decrypted by the intended recipient. When combined with a public signaling infrastructure such as the alternate chain scheme described above there can be a privacy leak whereby 3rdparty observers can estimate how busy a particular paycode is by seeing how many encrypted paycode messages it receives from senders.

[0125] To resolve this privacy leak while still using highly reliable alternate chain signaling the system may alter the algorithm for the index and FPCS computation when sending a signal. The system may have the signal consist of a “beacon index – from paycode signal” (BI,FPCS) pair. The intention is that a set of wallets will map to a single BI. By having a BI used for multiple wallets an observer cannot tell which particular wallet these paycode signals are targeting. This may be implemented by any number of known algorithms including consistent hashing or prefix filters.

[0126] Consistent hashing employs a function δ(k1, k2) that defines an abstract notion of the distance between keys k1 and k2, which is unrelated to geographical distance or network latency. Each node is assigned a single key called its identifier (ID). A node with ID ix owns all the keys km for which ix is the closest ID, measured according to δ(km, ix). In the system each BI may own all the I for a particular “distance.” A simple example would be that BI “1” receives signals for paycode indexes 1-999, BI “2” receives signals for paycode indexes 1000-1999, and so forth.

[0127] In this scheme a recipient wallet may compute its own incoming BI value and then process all the paycode signals in that inbox for that BI value. Similarly, a sending wallet given a particular I can compute which BI to send the outgoing paycode signal too. Thus, at the expense of processing signals that are not intended for the wallet, there is increased privacy. To make the signal processing easier and eliminate computing erroneous on-chain receive addresses, a checksum may be added to the FPCS such that a wallet can instantly know if it decoded a paycode signal for this wallet because the checksum is valid and the wallet may compute the shared secret receiving addresses across all its blockchains. Alternatively, if the paycode signal is intended for another wallets the checksum would be invalid and that paycode signal should not be processed by this wallet.

[0128] An example of how the system may work would be the alternate single chain using NameCoin or a fork of NameCoin (maybe called FortressCoin), with approximate signa indexing. The system may have desktop wallets contain an automated backup of the entire paycode signal data by either copying or just being nodes in the alternate chains. The system may use on chain backup and failsafe with noise. The system may have a list of all registered paycodes that is backed up in decentralized manor, for example on filecoin.

[0129] Have the list of all registered paycodes being maintained decentralized may be technically easier than having the backup centrally on the cloud. And having the backup decentralized may be more reliable being that it lacks a central single point of failure. The privacy that the system loses by not employing centralized paycode signaling is made up for by the approximate signal indexing. The dual alternate signal chains with the wallets acting as a 3rdbackup on top of individual wallets backing up their signals on UTXO chains and the list of registered paycodes on many nodes in the system provides a multimodal pathway with 5-way redundancy and full decentralization.,

[0130] Paycode signal quantity masking avoids on-chain paycode signaling that reveals the number of paycode signals received by a particular paycode. On-blockchain paycode signaling reveals to any 3rdparty how many paycode signals a particular paycode received (although they can’t compute the paycode shared address or decrypt which paycodes signaled a particularpaycode). The possible security leak is that a 3rdparty can theorize that a wallet that received 100 paycode signals is busier than one that has received 1 paycode signal. The 3rdparty attacker cannot determine where the paycode signaled transactions are on-blockchain but it is preferred to eliminate this possible privacy leak.

[0131] The system may address this vulnerability by the use of multimodal pathways that are off-blockchain.

[0132] Fig.5 shows a system 500 for off blockchain paycode signaling using multimodal pathways 416. The system comprises a private server 502, which receives and stores paycode signals privately, ensuring secure handling of signals. It includes a paycode signal backup 504, where paycode signals are backed up in encrypted bundles for added security and redundancy. Additionally, the system features a messaging server 506 for broadcasting paycode signals, utilizing services such as BitMessage for secure and efficient signal transmission.

[0133] The system may use a private server-based approach for paycode signal storage. The private server receives and securely stores all paycode signals, allowing only authenticated wallets to access and thus no longer can anyone but the user with wallet’s private key, determine the amount of paycode signals received.

[0134] The multimodal pathways may include having the paycode signals backed up. For example, backups may be done to a smart contract or Filecoin-style storage as encrypted bundles. These bundles may be indexed using a hash of the wallet’s private key (or a hash of the private key + salt) generated by the wallet, ensuring that third-party observers cannot determine the number of paycode signals a specific wallet has received.

[0135] The multimodal pathways may also be used to transmit the verified credentials. So, either the verified credentials may be sent along with paycode signal or the verified credentials may be sent in a separate transaction between wallets using the same mechanisms and pathways used to transmit paycode signals. Additionally, the multimodal pathways may be used to send a verified credential request, for example the sending wallet may request that the receiving wallet provide its verified credentials prior to a transaction.

[0136] From a third party's perspective, the backed-up paycode signals appear as an amorphous blob of data, making it impossible to correlate a specific bundle of paycode signals with a particular public paycode without knowledge of that paycode's private key. By contrast the user with their wallet’s private key can find the correct hash and pull the encrypted bundle and with the private key the encrypted bundle can be decoded to access the paycode signals and from that and the public blockchain, the entire wallet history can be quickly reconstructed. If the backup also contains verified credentials, then not only can the wallet history be reconstructed regarding the transactions but also the identity of who those transactions were with may reconstructed form the verified credentials.

[0137] The wallet may utilize a DHT-based messaging server or establish a direct connection to the private server to send and receive paycode signal data, enhancing privacy. In cases where a server is unavailable, the wallet may retrieve paycode signals from the backupmedium described above. To optimize storage space and reduce spam risks, the wallet may delete paycode signals from the wallet that have remained unused for a certain period of time.

[0138] The system diverges from existing systems, such as the Ethereum Name System (ENS), which relies on a fully public mapping of names to attributes. In the case of ENS, if an attribute represents a receive address, third-party observers have the ability to examine the blockchain and determine the balance associated with a particular name. However, the system introduces substantial differences that address these concerns and offers advantages.

[0139] ENS lacks a public paycode infrastructure and associated paycode signal infrastructure, which are integral components of the system. By incorporating public paycodes, user privacy remains intact even if credential and identity information associated with public paycodes becomes publicly accessible. This ensures that only the transacting parties possess knowledge of each other's identities, maintaining a high level of privacy.

[0140] The system may employ encrypted storage for paycode signal data, which may be stored on public networks. This encryption guarantees that only the specific wallet associated with the paycode signals can find and decrypt a paycode signal intended for a wallet. This robust security measure ensures the privacy and integrity of the paycode signal data is protected from unauthorized access.

[0141] The system may allow for the private storage of the mapping between names and paycodes. By maintaining this mapping privately, external entities are unable to ascertain the number of users on the system further preserving the anonymity and confidentiality of user information.

[0142] The system may use a private server with or / without DHT messaging for paycode signal storage.

[0143] The system may be blockchain agnostic, meaning it can operate on various blockchain networks, for example Ethereum, Bitcoin, Cardono, Dogecoin etc.. This flexibility enables cost-effective operation and eliminates the requirement for payments in ETH, thereby increasing accessibility for users.

[0144] The system may offer integration with other systems, for example ENS. This integration may enable globally unique name to paycode lookup via the Ethereum blockchain, providing additional redundancy and functionality to the overall system.

[0145] The system presents substantial differences from ENS by incorporating a paycode infrastructure, ensuring user privacy even with public access to credential and identity information, employing encrypted paycode signal data storage, enabling private name-to-paycode mapping, supporting blockchain agnosticism, offering low operational costs, and providing optional integration with systems like ENS for enhanced functionality and redundancy.

[0146] The above protocol would prove to the recipient that the received funds only came from sources controlled by a particular private key and to an address that was under the same sender control. Thus, any attempted money launderer would have to first deposit all suspect funds into the same wallet that would subsequently be used to send the funds to a third party. Therefore, any attempted money laundering could be easily identified. The point is to prove the addresses are controlled by the same key, for example the private key of the public paycode private / public key pair with the public key is the paycode. There is no need to tie the proof to the transaction itself, just to its source address or addresses. When a transaction comes in from that address the proof can be used to verify the association to the identity that is the source of the funds.

[0147] The ZKP (Zero Knowledge Proof) can be combined with any Crypto transaction, it can be sent on a communication channel. The ZKP can be used to provide proof of funds by conveying the identity is tied to the paycode is also tied to the same wallet master private key and then the counter party can check the balance on those addresses to verify control over those funds without the controlling address having to conduct a transaction on the blockchain to prove it thus avoiding time for transaction to take place on the blockchain and avoiding the cost of the transaction.

Claims

CLAIMS: What is claimed is:

1. A cryptographic secure transaction system comprising: a first cryptographic storage device having a first master key pair, where the first master key pair has a first master private key and a first master public key, and where the first cryptographic storage device has a first public key; a computer server configured to: maintain a list of pairs, each pair comprising a globally unique name and an associated public key, receive a request from the first cryptographic storage device, the request comprising the first public key and a proposed name, verify if the proposed name is available for assignment, and upon verifying availability of the proposed name, add the proposed name and the first public key as a new pair to the list of pairs; and a second cryptographic storage device having a second master key pair, where the second master key pair has a second master private key and a second master public key, and where the second cryptographic storage device has a second public key; where the second cryptographic storage device sends a signal consisting of the second public key to the first cryptographic storage device using a notification address derived from the first public key; a shared secret key generation algorithm that generates a shared secret key using the first private key and the second public key; and a distributed ledger records a transaction that uses an address derived from the shared secret key.

2. The cryptographic secure transaction system of claim 1, where: the first cryptographic storage device is configured to generate the first public key from the first master private key using a derived key algorithm; and the second cryptographic storage device is configured to generate the second public key from the second master private key using the derived key algorithm.

3. The cryptographic secure transaction system of claim 2, where the derived key algorithm uses SHA-512 encryption.

4. The cryptographic secure transaction system of claim 1, where: the first master public key is the first public key; and the second master key is the second public key.

5. The cryptographic secure transaction system of claim 1, where a second distributed ledger uses an address derived from the shared secret key.

6. The cryptographic secure transaction system of claim 1, where the shared secret key generation algorithm uses a Diffie-Hellman algorithm.

7. A cryptographic secure transaction system comprising: a first cryptographic storage device having a first public key; a second cryptographic storage device having a second public key; a distributed ledger;a signaling pathway off of the distributed ledger for transmitting the second public key to a notification address, where the notification address is derived from the first public key; a shared-secret key algorithm that generates a shared-secret key using the second public key and the first private key; and where the distributed ledger has a transaction that utilizes an address derived from the shared-secret key.

8. The cryptographic secure transaction system of claim 7 where the notification address is a beacon address, where the beacon address receives signals destine for more than one public key.

9. The cryptographic secure transaction system of claim 7, where the signaling pathway comprises one or more of the following: a centralized signaling pathway using a central server; a decentralized signaling pathway; or a broadcast-based signaling pathway.

10. The cryptographic secure transaction system of claim 9, where: the centralized signaling pathway using a private central server; the decentralized signaling pathway uses an alternative blockchain; or the broadcast-based signaling pathway includes a DHT-based messaging server.

11. The cryptographic secure transaction system of claim 10, where the decentralized signaling pathway using an alternative blockchain that stores signals as encrypted bundles on a decentralized storage system, where the encrypted bundles are indexed using a hash derived from the first private key.

12. The cryptographic secure transaction system of claim 10, where the decentralized signaling pathway using an alternative blockchain and further comprises a group of cryptographic devices that stores information from the alternative blockchain and where the group collectively maintains a distributed copy of the alternative blockchain.

13. The cryptographic secure transaction system of claim 10, where: the first cryptographic storage device further has a first master key pair, where the first master key pair has a first master private key and a first master public key, and where the first cryptographic storage device is configured to generate the first key pair from the first master private key using a derived key algorithm; the second cryptographic storage device further has a second master key pair, where the second master key pair has a second master private key and a second master public key and where the second cryptographic storage device is configured to generate the second key pair from the second master private key using the derived key algorithm; and the first cryptographic storage device is further configured to generate an additional first public key from the first master private key using a second derived key algorithm, where either the first public key or additional first public key is used to generate the notification address for receiving signals.

14. The cryptographic secure transaction system of claim 7, further comprising a backup mechanism for backing up signals, where the backup mechanism is configured to: embed the signals in transaction metadata of on-blockchain transactions; or embed the signals in unspent transaction outputs of on-blockchain transactions.

15. The cryptographic secure transaction system of claim 14, where the signal embedded in the transaction metadata or the unspent transaction output is a signal for an outbound transaction from the second cryptographic storage device, and the signal includes the first public key.

16. A verified credential system comprising: a first cryptographic storage device having a first master key pair, where the first master key pair has a first master private key and a first master public key, and where the first cryptographic storage device has a first public key; a verify credential server configured to: receive a credential and the first public key, if the credentials pass a validation process, then send a verified credential, where the verified credential includes the credential and first public key signed by a signing authority; and where the verified credential are shared with a second cryptographic storage device.

17. The verified credential system of claim 16 where the validation process includes: convaying the credential to a person who does a manual check on the credential, and receiving input from the person that the credential has been validated.

18. The verified credential system of claim 16 further comprising sending on a signaling pathway the verified credential.

19. The verified credential system of claim 18, where the signaling pathway comprise one of the following: an on blockchain pathway a centralized signaling pathway using a central server; a decentralized signaling pathway using an alternative blockchain; a broadcast-based signaling pathway; or a broadcast-based signaling pathway including a DHT-based messaging server.

20. The verified credential system of claim 16, where sharing the verified credential comprises: storing the verified credential in a central location; and transmitting a decryption key to authorized counterparties through a signaling pathway, where the decryption key enables the authorized counterparties to view the verified credential retrieved from the central location.

21. The verified credential system of claim 20, where the signaling pathway comprises one of the following: an on blockchain pathway a centralized signaling pathway using a central server; a decentralized signaling pathway using an alternative blockchain; a broadcast-based signaling pathway; or a broadcast-based signaling pathway including a DHT-based messaging server.

22. A method for recovering signals and reconstructing transaction history, comprising: retrieving encrypted backed-up of signals associated with a cryptographic storage device, where the encrypted backed-up signals were encrypted using a private key of the cryptographic storage device and stored in at least one of: transaction metadata of on-blockchain transactions, a centralized storage system, or a decentralized storage system; decrypting the retrieved encrypted backed-up signals using the private key of the cryptographic storage device; deriving shared secret keys from the decrypted signals using a share secrete key generation algorithm; accessing a distributed ledger; reconstructing the transaction history of the cryptographic storage device by analyzing transactions on the distributed ledger involving an address derived from the shared secret key.

23. A method for recovering signals and reconstructing transaction history, comprising: maintaining a list of all registered public keys, where each public key is associated with a corresponding name; for each registered public key in the list of all registered public keys: deriving a shared secret key using the registered public key and a private key of the cryptographic storage device according to a shared secret key generation algorithm; accessing a public distributed ledger; and reconstructing the transaction history of the cryptographic storage device by analyzing transactions on the public distributed ledger involving the addresses derived from the shared secret key.

24. A cryptographic secure transaction system comprising: a first cryptographic storage device having a first master private key and a first public key; a second cryptographic storage device having a second master private key and a second public key; a distributed ledger; a signaling pathway for transmitting the second public key to a notification address derived from the first public key; a shared-secret algorithm that generates a shared-secret key using the second public key and the first master private key; and sending fake signals from the second cryptographic storage device to the first cryptographic storage devices, the fake signals are to obfuscate the actual number of signals received by the first cryptographic storage device, where the fake signals can only be distinguished from real signals by the first cryptographic device.

25. The cryptographic secure transaction system of claim 24, where the fake signals are distinguished by the first cryptographic device by: checking if a checksum added to each received signal is valid; and ignoring the received signal if the checksum is invalid.

Images