Cryptographic privacy-preserving transactions with verified credentials and ergonomic cryptography key infrastructure

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

CRYPTOGRPAHIC PRIVACY-PRESERVING TRANSACTIONS WITH VERIFIED CREDENTIALS AND ERGONOMIC CRYPTOGRAPHY KEY INFRASTRUCTURECROSS-REFREENCE TO ARELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 507,085, filed on June 8, 2023, and U.S. Provisional Patent Application No. 63 / 512,052, filed on July 5, 2023, both of which are incorporated herein by reference in their entirety for all purposes, except to the extent that such incorporated content may conflict with the present application. The titles of these provisional applications are "Privacy-Preserving Cryptocurrency Transactions with Enhanced Credentials and User-Friendly Pay code Infrastructure."BACKGROUNDField of the Invention

[0002] The present disclosure relates to enhancing the security, privacy, and recovery of cryptographically secured transactions. Specifically, it enables secure private transactions on a public distributed ledger sing a private cryptographic key and verified credentials, with recovery mechanisms that include reconstructing all transactions from derived deterministic keys generated from the private cryptographic key.Description of Related Art

[0002] Cryptographically secured transactions typically involve complex cryptographic addresses that are challenging for users to manage accurately. These cryptographic keys, which are complex alphanumeric strings, are not easily utilized, recognized, or checked for mistakes by humans. Traditional systems require users to see and handling these cryptographic addresses, leading to potential errors and a suboptimal user experience (poor ergonomics). Although many tools have been created to manage these keys, such as QR codes and cryptographic wallets, these solutions do not fully address the usability issues. Moreover, privacy concerns arise from the transparency of such transactions, where transaction details between address is visible to third parties. Existing solutions, such as the Ethereum Name Service (ENS), provide name-to-address mappings butcompromising user privacy by exposing information publicly and allow for anyone to check the what assets are under control of the private key associated with the ENS name entry.

[0003] Another significant issue in cryptographic systems is the secure recovery of private keys and their associated data structures. Loss or compromise of private keys can result in the permanent loss of access to assets secured by these keys. Moreover, derived deterministic keys pose a specific problem: it is not possible to determine which keys were used in transactions without extensive brute force computation. There is a need for a robust mechanism that allows users to recover their private keys and keys derived from a root private key, ensuring continued access to the assets without exposing sensitive information to potential attackers.

[0004] Additionally, current systems often lack comprehensive methods for integrating enhanced credentials, such as verified identity information, into the transaction process. This is important for complying with regulatory requirements and ensuring the authenticity of transaction participants. Existing solutions do not adequately address the seamless incorporation of such credentials while maintaining the security and privacy of individuals using the cryptographic system.

[0005] Overall, there is a need for a solution that not only simplifies the management of cryptographic addresses and enhances user privacy but also includes secure mechanisms for key recovery and the integration of verified credentials.SUMMARY

[0006] A cryptographic secure transaction system is described. It includes a first cryptographic storage device with a first master key pair (a first master private key and a first master public key) and a first public key. A computer server is configured to maintain a list of pairs, each consisting of a globally unique name and an associated public key. The server receives a request from the first device with the first public key and a proposed name, verifies if the proposed name is available, and if so, adds the proposed name and first public key as a new pair to the list.

[0007] The system also includes a second cryptographic storage device with a second master key pair (a second master private key and second master public key) and a second public key. The second device sends a signal derived from its public key to the first device using a notification address derived from the first device's public key. A shared secret key generation algorithm generates a shared secret key using the first private key and second public key. A distributed ledger records a transaction using an address derived from the shared secret key.

[0008] The first device generates its public key from its master private key using a derived key algorithm such as SHA-512 encryption, and the second device does the same. The master public keys may be used as the public keys directly. A second distributed ledger may also use an address derived from the shared secret key. The shared secret key generation algorithm may use a Diffie- Hellman algorithm.

[0009] The system may include a signaling pathway off the distributed ledger for transmitting the second public key to a notification address derived from the first public key. The notification address may be a beacon address that receives signals for multiple public keys. The signaling pathway may be centralized using a central server, decentralized, or broadcast-based. Various implementations are described, such as using a private central server, alternative blockchain, or DHT-based messaging server. The alternative blockchain may store signals as encrypted bundles on a decentralized storage system, indexed using a hash derived from the first private key. A group of devices may collectively maintain the alternative blockchain.

[0010] Additional public keys may be derived for signaling purposes. A backup mechanism may embed signals in transaction metadata or unspent outputs of on-blockchain transactions. This can include outbound transaction signals from the second device containing the first signaling public key.

[0011] The system may include a verify credential server that receives a credential and first public key, validates the credential, and if valid, sends a signed verified credential including the credential and first public key to be shared with the second device. Validation may involve manual checks. Verified credentials can be shared via signaling pathways or by storing them centrally and transmitting decryption keys to authorized parties via signaling.

[0012] Methods are described for recovering signals and reconstructing transaction history. One method involves retrieving backed-up encrypted signals associated with a device from various storage locations, decrypting them using the device's private key, deriving shared secret keys, accessing a distributed ledger, and reconstructing the device's transaction history by analyzing transactions involving addresses derived from the shared secret keys. Another method maintains a list of registered public keys and names, derives shared secret keys for each using the device's private key, accesses a public ledger, and reconstructs the device's transaction history from transactions involving the derived addresses.

[0013] The system may send fake signals from the second to first device to obfuscate the actual number of signals received. The first device can distinguish these using a checksum, ignoring signals with invalid checksums.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a block diagram illustrating the overall system architecture of the privacypreserving cryptocurrency transaction system.

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

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

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

[0018] FIG. 5 is a diagram illustrating the system for pay code signal quantity masking.DETAILED DESCRIPTION

[0019] 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 maycontinue 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 crytographic storage device can notify other cryptographic storage devices of incoming paycode transactions.

[0020] 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.

[0021] 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.

[0022] Once the global unique name 206 is established, the registrar 208 may generate a public pay code 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.

[0023] 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.

[0024] 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 December15, 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.

[0025] 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 user, such as Namel - Paycodel, 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.

[0026] 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 pay codes 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 pay code, 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.

[0027] 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), the signing authority 306 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.

[0028] 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.

[0029] 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.

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

[0031] 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.

[0032] 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.

[0033] 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 download the 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.

[0034] 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.

[0035] 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 PaycodeA - private keyA module 406. The PaycodeA - private keyA module 406 sends an encrypted PaycodeA 408 via a named received PaycodeA path 410 to a global name list 412. The global name list 412 includes Namel - Paycodel, Name2 - Paycode2, and NameB - PaycodeB.

[0036] The system 400 also includes an off blockchain Paycode Signaling Inbox 416 (multimodal pathways). The off blockchain Pay code 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.

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

[0038] 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 pay code 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.

[0039] 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 pay code signals to be able to know all the assets under the wallets control.

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

[0041] Paycode signaling may occur on-blockchain through encrypted pay code 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.

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

[0043] The multimodal signaling may use improvements to the pay code signaling process for example using off blockchain pay code signaling.

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

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

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

[0047] 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.

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

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

[0050] 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.

[0051] 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.

[0052] 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.

[0053] The signaling pathway may be a backup for example a CLOUD BACKUP of all paycode signals.

[0054] The signaling pathway may be a FAILSAFE ON blockCHAIN backup. The FAILSAFE 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.

[0055] 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 identityassociated 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.

[0056] 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.

[0057] 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 backed up to CLOUD BACKUP storage only accessible by the wallet. The signal may be optional or be configurable to be receive by the wallet.

[0058] The CENTRALIZED SIGNALING may be optionally configurable

[0059] The system may be configued to send ON CHAIN SINGAL 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:

[0060] IF ALTERNATE CHAIN IS UP

[0061] WALLET SIGNAL BACKUP: if 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 belowIF the ALTERNATE BLOCKCHAIN IS DOWN then try the FAILSAFE. If the alternate blockchain is down and the recipient pay code is new to the wallet, then notify the recipient pay code 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.

[0062] 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.

[0063] 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 pay code from the contact list but do not notify the recipient paycode that is being paid.

[0064] 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 tothe overall system. These ‘extra noise’ records or fake signals are optional and may be configurable.

[0065] 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.

[0066] 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 pay code 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.

[0067] 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 offloaded from the wallet to a server, be it a private server or a cloud server computer.

[0068] CLOUD BACKUP may be on satellites.

[0069] 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.

[0070] 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.

[0071] Every wallet may also keep a copy of the current LIST OF ALL REGISTERED PAYCODES and optionally their associated names.

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

[0073] APPROXIMATE SIGNAL INDEXING. Signal notifications in BIP-47 / OBPP-5 (and as presently embodied in Open Transactions, OT) consist of index-frompaycodesignal (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.

[0074] 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 - frompaycodesignal” (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.

[0075] Consistent hashing employs a function d(k / , k2) that defines an abstract notion of the distance between keys ki 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 ixowns all the keys kmfor which ixis the closest ID, measured according to < (km, L). 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.

[0076] In this scheme a recipient wallet may compute its own incoming BI value and then process all the pay code signals in that inbox forthat BI value. Similarly, a sending wallet given a particular / can compute which BI to send the outgoing pay code signal too. Thus, at the expense of processing signals that are not intended for the wallet, there is increased privacy. To make the signalprocessing 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 pay code signal is intended for another wallets the checksum would be invalid and that paycode signal should not be processed by this wallet.

[0077] 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 APPRO XIMIATE SIGNAL 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.

[0078] 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 pay code 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 pay codes on many nodes in the system provides a multimodal pathway with 5-way redundancy and full decentralization.,

[0079] 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 particular paycode). 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.

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

[0081] Fig. 5 shows a system 500 for off blockchain pay code 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 pay code 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.

[0082] 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 pay code signals received.

[0083] 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.

[0084] 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.

[0085] 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 pay code 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 thepublic 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.

[0086] 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 backup medium 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] The system may allow for the private storage of the mapping between names and pay codes. 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.

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

[0092] 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.

[0093] 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.

[0094] 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.CRYPTOGRPAHIC PRIVACY-PRESERVING TRANSACTIONS WITH VERIFIED CREDENTIALS AND ERGONOMIC CRYPTOGRAPHY KEY INFRASTRUCTURECROSS-REFREENCE TO ARELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 507,085, filed on June 8, 2023, and U.S. Provisional Patent Application No. 63 / 512,052, filed on July 5, 2023, both of which are incorporated herein by reference in their entirety for all purposes, except to the extent that such incorporated content may conflict with the present application. The titles of these provisional applications are "Privacy-Preserving Cryptocurrency Transactions with Enhanced Credentials and User-Friendly Pay code Infrastructure."BACKGROUNDField of the Invention

[0002] The present disclosure relates to enhancing the security, privacy, and recovery of cryptographically secured transactions. Specifically, it enables secure private transactions on a public distributed ledger sing a private cryptographic key and verified credentials, with recovery mechanisms that include reconstructing all transactions from derived deterministic keys generated from the private cryptographic key.Description of Related Art

[0002] Cryptographically secured transactions typically involve complex cryptographic addresses that are challenging for users to manage accurately. These cryptographic keys, which are complex alphanumeric strings, are not easily utilized, recognized, or checked for mistakes by humans. Traditional systems require users to see and handling these cryptographic addresses, leading to potential errors and a suboptimal user experience (poor ergonomics). Although many tools have been created to manage these keys, such as QR codes and cryptographic wallets, these solutions do not fully address the usability issues. Moreover, privacy concerns arise from the transparency of such transactions, where transaction details between address is visible to third parties. Existing solutions, such as the Ethereum Name Service (ENS), provide name-to-address mappings butcompromising user privacy by exposing information publicly and allow for anyone to check the what assets are under control of the private key associated with the ENS name entry.

[0003] Another significant issue in cryptographic systems is the secure recovery of private keys and their associated data structures. Loss or compromise of private keys can result in the permanent loss of access to assets secured by these keys. Moreover, derived deterministic keys pose a specific problem: it is not possible to determine which keys were used in transactions without extensive brute force computation. There is a need for a robust mechanism that allows users to recover their private keys and keys derived from a root private key, ensuring continued access to the assets without exposing sensitive information to potential attackers.

[0004] Additionally, current systems often lack comprehensive methods for integrating enhanced credentials, such as verified identity information, into the transaction process. This is important for complying with regulatory requirements and ensuring the authenticity of transaction participants. Existing solutions do not adequately address the seamless incorporation of such credentials while maintaining the security and privacy of individuals using the cryptographic system.

[0005] Overall, there is a need for a solution that not only simplifies the management of cryptographic addresses and enhances user privacy but also includes secure mechanisms for key recovery and the integration of verified credentials.SUMMARY((( To be completed once claims are set)))BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram illustrating the overall system architecture of the privacy-preserving cryptocurrency transaction system.FIG. 2 is a flowchart depicting the process of initial onboarding of a new private cryptographic security key.FIG. 3 is a diagram showing the process of generating and managing verified credentials.FIG. 4 is a schematic representation of the multimodal pathway configuration for off-blockchain paycode signaling and backup.FIG. 5 is a diagram illustrating the system for paycode signal quantity masking.DETAILED DESCRIPTION

[0006] FIG. 1 provides an overview of three parts of the system, specifically Initial onboarding of a new private key 102, optionally enhanced identity with Verified KYC / AML, and off blockchain notification of paycode signals.

[0007] FIG. 2 provides details for initial onboarding of a new private key. Bringing a new user onto the system may comprise the following steps in an onboarding process.

[0008] Initially, the user may select a globally unique name to use to create cryptocurrency transactions. The system 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 then each user has a distinct global unique name.

[0009] Once the global unique name is established, the system may generate a BIP-47 / OBPP5 public paycode and corresponding public and private key. A cryptocurrency hardware and software wallet may generate the public paycode and private key. 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.

[0010] 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 ofthe 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.

[0011] 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.

[0012] The generated public paycode and private key may be stored securely by the system along with the corresponding global unique name. 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.

[0013] Once the onboarding process is complete, the user's wallet may be configured to allow transactions to be made using global unique names, the wallet may be configured to exclusively use the global unique name. In the “exclusive globally unique name mode” the wallet functions under the hood with both paycodes and legacy addressees but the UI only exposes plain language names and legacy addresses. As such the wallet is universally compatible with all other noncustodial crypto wallets but allows for far greater ease of use. The user interface of the wallet may not display the public paycode, this means 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 modem 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 fortransacting with crypto currency 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, observers unrelated to the transaction cannot determine if there was a transaction between the wallet of Alice and the wallet of Bob. Consequently, the transaction remains untraceable to third- party observers, but with the convenient and familiar experience provided by modem financial services, but only visible to the involved parties.

[0014] FIG. 3 provides details for adding enhanced credentials to the user’s wallet.

[0015] The system may provide enhanced credentials, allowing users to obtain enhanced identity credentials for their global unique names. To acquire these credentials, a user may submit specific KYC / AML ("Know Your Customer" / " Anti-Money Laundering.") credentials, such as a driver's license or passport. The credentials may be submitted through the wallet. The submitted credentials may undergo a KYC / AML check. The KYC / AML check may be conducted by a third-party provider, a Verification Service Provider. The Verification Service Provider may conduct the check using dedicated processing servers. In the event of a positive check result (i.e., user credentials are verified), a recognized Signing Authority (e.g., Wallet Provider like Swiss Fortress) may provide verified credentials, for example the Signing Authority have a key pair with a published public key may execute a private key signature on a payload. The Verification Service Provider and the Signing Authority may be the same entity.

[0016] Verified credentials 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.

[0017] The payload may include the globally unique name, public paycode, blind claims, unblinded claims and other data. The Signing Authority may return to the user’s wallet the verifiedcredentials. These verified credentials may be stored in the wallet or stored centrally for universal access. The verified credentials may be shared with selected counterparties.

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

[0019] 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.

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

[0021] For sending enhanced credentials, the credentials may be securely stored, 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 send a key to decrypt it. The counterparty may download the encrypted credential 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.

[0022] 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 herebyincorporated 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.

[0023] FIG. 4 shows one possible multimodal pathway configuration that include off-blockchain paycode signaling and backup.

[0024] 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.

[0025] 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.

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

[0027] 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.

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

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

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

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

[0032] The system may include dual / triple redundant pay code signal paths.

[0033] 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.

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

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

[0036] 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.

[0037] 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.

[0038] 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.

[0039] The signaling pathway may be a backup for example a CLOUD BACKUP of all paycode signals.

[0040] The signaling pathway may be a FAILSAFE ON blockCHAIN backup. The FAILSAFE ON blockCHAIN backup may include additional extra or random data, i.e. NOISE. If the pay code 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.

[0041] An alternate way to reconstruct the pay code 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.

[0042] 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 thesystem may also use NOISE PROTOCOL on the ‘Alternate Chain.” The wallet signals may be backed-up to a CLOUD BACKUP.

[0043] 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 backed up to CLOUD BACKUP storage only accessible by the wallet. The signal may be optional or be configurable to be receive by the wallet.

[0044] The CENTRALIZED SIGNALING may be optionally configurable

[0045] The system may be configued to send ON CHAIN SINGAL 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:

[0046] IF ALTERNATE CHAIN IS UP

[0047] WALLET SIGNAL BACKUP: if 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 belowIF 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.

[0048] NOISE PROTOCOL: The alternate blockchain is up or the wallet has randomly chosen to not do a real notification.

[0049] a. then 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.

[0050] b. IF all known paycodes from the wallet’s contact list are already notified on this blockchain then 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 are optional and may be configurable.

[0051] c. if the wallet is out of contacts to notify, as in steps a. and b above, 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.

[0052] 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, anda 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.

[0053] 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 offloaded from the wallet to a server, be it a private server or a cloud server computer.

[0054] CLOUD BACKUP may be on satellites.

[0055] 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.

[0056] 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.

[0057] Every wallet may also keep a copy of the current LIST OF ALL REGISTERED PAYCODES and optionally their associated names.

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

[0059] APPROXIMATE SIGNAL INDEXING. Signal notifications in BIP-47 / OBPP-5 (and as presently embodied in Open Transactions, OT) consist of index-frompaycodesignal (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 3rdpartyobservers can estimate how busy a particular paycode is by seeing how many encrypted paycode messages it receives from senders.

[0060] 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 - frompaycodesignal” (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.

[0061] Consistent hashing employs a function d(ki, k2) that defines an abstract notion of the distance between keys ki and k , which is unrelated to geographical distance or network latency. Each node is assigned a single key called its identifier (ID). A node with ID ixowns all the keys kmfor which ixis the closest ID, measured according to b(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.

[0062] In this scheme a recipient wallet may compute its own incoming BI value and then process all the pay code signals in that inbox for that BI value. Similarly, a sending wallet given a particular / 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 pay code 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 pay code signal is intended for another wallets the checksum would be invalid and that paycode signal should not be processed by this wallet.

[0063] 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 APPROXIMIATE SIGNAL 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 OFALL REGISTERED PAYCODES that is backed up in decentralized manor, for example on filecoin.

[0064] 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 pay code 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.,

[0065] Paycode signal quantity masking avoids on-chain paycode signaling that reveals the number of pay code signals received by a particular pay code. On-blockchain pay code 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 particular pay code). The possible security leak is that a 3rdparty can theorize that a wallet that received 100 pay code 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.

[0066] FIG. 5 shows ways the system may address this vulnerability by the use of multimodal pathways that are off-blockchain. The system may use a private server-based approach for pay code 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.

[0067] 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 pay code signals a specific wallet has received.

[0068] 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.

[0069] 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.

[0070] 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 backup medium 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.

[0071] 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.

[0072] ENS lacks a public paycode infrastructure and associated pay code 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 becomespublicly accessible. This ensures that only the transacting parties possess knowledge of each other's identities, maintaining a high level of privacy.

[0073] 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.

[0074] 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.

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

[0076] 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.

[0077] 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.

[0078] 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.

Claims

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

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

18. The system for managing and sharing verified credentials of claim 16 further comprising sending on a signaling channel the verified credentials.

19. The system for managing and sharing verified credentials of claim 16 further comprising: encrypting the first private key and storing the encrypted verified credentials in a publicly accessible location and sending a decrypt key over a signaling channel.

20. The system of claim 16, wherein sharing the verified credentials comprises: storing the verified credentials centrally; and transmitting a decryption key to authorized counterparties through one or more signaling channels, enabling the authorized counterparties to access the centrally stored verified credentials.

21. The system of claim 16, wherein the one or more signaling channels comprise at least one of:An on blockchain channel a centralized signaling pathway using a central server;a decentralized signaling pathway using an alternative blockchain; a broadcast-based signaling pathway; a centralized signaling pathway using a private central server; or a broadcast-based signaling pathway including a DHT-based messaging server.

22. A method for recovering paycode signals and reconstructing transaction history, comprising: retrieving backed-up paycode signals associated with a cryptographic storage device, wherein the backed-up paycode signals are: encrypted using a private key of the cryptographic storage device, and embedded in transaction metadata of on-blockchain transactions, or stored in an encrypted form on a centralized storage system, or stored in an encrypted form on a decentralized storage system; decrypting the encrypted backed-up paycode signals using the private key of the cryptographic storage device; deriving shared secret addresses from the decrypted pay code signals using a predetermined algorithm; reconstructing the transaction history of the cryptographic storage device by analyzing transactions on a distributed ledger involving the derived shared secret addresses.

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

23. A cryptographic secure transaction system comprising:a first cryptographic storage device having a first private key and a first signaling key pair with the first signaling key pair having a first signaling private key and a first signaling public key; a second cryptographic storage device having a second private key and a second signaling key pair with the second signaling key pair having a second signaling private key and a second signaling public key; a distributed ledger; a signaling channel for transmitting the second signaling public key to a signaling address; a shared-secret address algorithm that generates a shared-secret address using the second signaling public key and the first signaling private key; sending fake signals from the second cryptographic storage device to obfuscate the actual number of signals received, wherein the fake signals can only be distinguished from real signals by a receiving first signaling public key.

24. A cryptographic secure transaction system of claim 23, where the fake signals are distinguished by the receiving paycode by: checking if a checksum added to each received signal is valid; and ignoring the received signal if the checksum is invalid.CLAIMSWhat 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 derived from 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; ora 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 wher 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 signaling 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 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 system for managing and sharing verified credentials 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 system of claim 20, where the signaling pathway comprise 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.CLAIMS:

1. A cryptographic secure transaction system comprising: a first cryptographic storage device having a first private key and a first signaling key pair with the first signaling key pair having a first signaling private key and a first signaling public key; a computer server configured to: maintain a list of pairs, each pair comprising a globally unique name and an associated signaling public key, receive a request from the first cryptographic storage device, the request comprising the first signaling 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 signaling public key as a new pair to the list of pairs; and a second cryptographic storage device having a second private key and a second signaling key pair with the second signaling key pair having a second signaling private key and a second signaling public key; where the second cryptographic storage device sends a signal comprising the second signaling public key to the first signaling public key; a shared secret address generation algorithm generates a shared secret address using the first signaling private key and the second signaling public key; a distributed ledger records a transaction that uses the shared secret address.

2. The cryptographic secure transaction system of claim 1, where: the first cryptographic storage device is configured to generate the first signaling address from the first private key using a derived key -pair algorithm; and the second cryptographic storage device is configured to generate the second signaling address from the second private key using the derived key -pair 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 signaling private key is the first private key; and the second signaling private key is the second private key.

5. The cryptographic secure transaction system of claim 1, where the shared secret address is use in a transaction on a second distributed ledger.

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

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

8. The cryptographic secure transaction system of claim 7 where the signaling address is a beacon address9. The cryptographic secure transaction system of claim 7, where the signaling channel comprises at least one of: a centralized signaling pathway using a central server; a decentralized signaling pathway using an alternative blockchain; 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 securely stores paycode signals as encrypted bundles on a decentralized storage system, wherein the 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 comprises a group of cryptographic storages, wherein 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 is configured to generate the first signaling key pair from the first private key using a derived key-pair algorithm; the second cryptographic storage device is configured to generate the second signaling key pair from the second private key using the derived key-pair algorithm; and the first cryptographic storage device is further configured to generate an additional first signaling key pair from the first private key using the derived key-pair algorithm, where either the first signaling public key or additional first signaling public key is used as the signaling address for transmitting the second signaling public key.

14. The cryptographic secure transaction system of claim 7, further comprising a backup mechanism for backing up signals, wherein the backup mechanism is configured to: embed signals in transaction metadata of on-blockchain transactions; or embed signals in unspent transaction outputs (UTXO) 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 (UTXO) is a signal for an outbound transaction from the second cryptographic storage device, and the signal comprises the first signaling public key.

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

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

18. The system for managing and sharing verified credentials of claim 16 further comprising sending on a signaling channel the verified credentials.

19. The system for managing and sharing verified credentials of claim 16 further comprising: encrypting the first private key and storing the encrypted verified credentials in a publicly accessible location and sending a decrypt key over a signaling channel.

20. The system of claim 16, wherein sharing the verified credentials comprises: storing the verified credentials centrally; and transmitting a decryption key to authorized counterparties through one or more signaling channels, enabling the authorized counterparties to access the centrally stored verified credentials.

21. The system of claim 16, wherein the one or more signaling channels comprise at least one of:An on blockchain channel a centralized signaling pathway using a central server;a decentralized signaling pathway using an alternative blockchain; a broadcast-based signaling pathway; a centralized signaling pathway using a private central server; or a broadcast-based signaling pathway including a DHT-based messaging server.

22. A method for recovering paycode signals and reconstructing transaction history, comprising: retrieving backed-up paycode signals associated with a cryptographic storage device, wherein the backed-up paycode signals are: encrypted using a private key of the cryptographic storage device, and embedded in transaction metadata of on-blockchain transactions, or stored in an encrypted form on a centralized storage system, or stored in an encrypted form on a decentralized storage system; decrypting the encrypted backed-up paycode signals using the private key of the cryptographic storage device; deriving shared secret addresses from the decrypted pay code signals using a predetermined algorithm; reconstructing the transaction history of the cryptographic storage device by analyzing transactions on a distributed ledger involving the derived shared secret addresses.

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

23. A cryptographic secure transaction system comprising:a first cryptographic storage device having a first private key and a first signaling key pair with the first signaling key pair having a first signaling private key and a first signaling public key; a second cryptographic storage device having a second private key and a second signaling key pair with the second signaling key pair having a second signaling private key and a second signaling public key; a distributed ledger; a signaling channel for transmitting the second signaling public key to a signaling address; a shared-secret address algorithm that generates a shared-secret address using the second signaling public key and the first signaling private key; sending fake signals from the second cryptographic storage device to obfuscate the actual number of signals received, wherein the fake signals can only be distinguished from real signals by a receiving first signaling public key.

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

Images