ABSTRACT
Abstract
A hybrid crypto process includes calling an on-chain smart contract function. The smart contract function receives a ghost blockchain address. Then the hybrid crypto function can call an oracle function with arguments that include the ghost blockchain address. The oracle function is associated to a program payment code and the oracle function can determine from the ghost blockchain address a payment code. If the request is to receive crypto assets, then the payment code is a sender payment code. The request may include a crypto asset amount and the oracle function may associate the crypto asset amount with the sender payment code. If the request is to send crypto assets, then the payment code is a destination payment code, and the oracle function returns a destination blockchain address. The ghost blockchain address may be generated according to BIP 33, BIP 47 or OBPPV5.
Description
BACKGROUND OF THE INVENTION
Field of the Invention
This disclosure has to do with crypto currency and more specifically with cryptographically secured on and off blockchain transactions.
Background of the Invention
The Bitcoin blockchain, its derivatives and other blockchain based cryptocurrencies provide a âfoundation layerâ of hard money, where transactions are irreversible and censorship-resistant, consisting of peer-to-peer payments secured by proof algorithms like proof-of-work.
Blockchain ecosystems are also a medium for issuing third party tokens. Third-party tokens allow the blockchain-based circulation of unique units of value from different issuers. Several protocols exist for third party tokens, for example Simple Ledger Protocol (SLP) for Bitcoin-based blockchains, and ERC-20 for Ethereum.
Blockchain users and custodians need solutions to a variety of identity problems, such as a reusable address that can be used as a public ID and that supports return addresses. Solving the problems of receiving addresses is important for usability and for unifying identity across blockchains.
Blockchain users also often deposit crypto assets with 3rd-party custodians such as exchanges for the increased functionality available there, like trading on markets. These 3rd-party custodians are historically where most theft and fraud have occurred, and the losses are in the billions.
Unfortunately, third party servers in use today are only trusted in the traditional way one puts trust in the institution. User have to trust the institution that custody of their cryptocurrency to properly run and secure the computers that hold the cryptocurrency, to accurately maintain their internal ledger and customer balances, and to faithfully execute transactions legitimately requested by users.
Crypto custodial institutions, for example currency exchanges and other trading platforms, usually desire to perform order matching more rapidly than is possible on the blockchain. Crypto custodial institutions accept custody of user cryptocurrency, perform transactions in a separate off-chain system like a traditional database to track customer account balances. Typically, the services provided are not cryptographically secured, or independently auditable. To use these crypto custodial institution services users give-up full control of their deposited crypto assets and have to trust the crypto custodial institution, which exposes them to the risk of theft or loss of their crypto assets (e.g. currency and coins).
Unlike legacy currencies, cryptocurrencies can be irrevocably lost or stolen, and it's typically not possible to distinguish between internal or external theft. Historically, this ambiguity appears to have been routinely exploited.
Ascertaining user identity is critical for many blockchain-based transactions. What is âidentity,â from a software perspective? A social security card or driver's license is not the sum total of one's identity, not even in court. Like a marriage license, or a dog license, or even a witness statement in an affidavit; each is just one piece of evidence about someone. More specifically, each piece of evidence about a person (i.e. a claim or set of claims) is a claim that has been certified by someone that others trust (i.e. an authentication authority). The someone, may either a person or an organization, like an official authority, like social security administration. These pieces of evidence (claims) are like a cloud of data formed about a person.
But even the cloud of data is not one's identity itself. Identity is ethereal. The cloud of data merely consists of various pieces of evidence about a person's identity, which is the closest we have come in the real world to tracking a person's identity. For example, having the name âBill Gatesâ is not the same thing as being the Bill Gates who founded Microsoft. It's not the name alone, nor some singular taxpayer ID number that imbues identity, but rather, those names and numbers are just examples of verified (or verifiable) facts about that person.
A person's true identity is not tracked as anything more than a set of claimsâand claims about those claimsâregarding specific facts, relationships and accomplishments in that person's life, that distinguish the person from anyone else subjectively, in the eyes of those the person is interacting with. A user may create and control his own credentials, alternatively an authentication authority, may create and control a user's credentials.
However, even given a system where users have full control over their own cryptographic credentials, authorities may still be used, and authorities may set permissions or revoke access in their systems. What is needed is a system that provides a decentralized model of identity, provides users with self-determination, while ensuring that various organizations and platforms can still be in control and regulate their systems.
Many blockchain-based enterprises would like to be able to identify a user, and from there to be able to link that user to what they sign, the payments they make, the messages they send, and the claims that distinguish their identity along with authentications about those claims made by authorities.
The users of deposit-accepting services should never experience a loss of deposited crypto assets. Security threats to loss of deposited crypto assets may be grouped into three general categories:
Type 1 Event (Theft/Loss). A user permanently loses their crypto assets because a third party has gained control of them without the user's consent, or because the private keys needed to spend them have been irrevocably lost.
Type 2 Event (Denial of Service). A user temporarily loses some or all of their ability to use their crypto assets, but no third party has gained control over them.
Type 0 Event. Type 0 Events will be used to describe all other abnormal conditions from which the pool must recover which do not directly involve a loss of customer deposits
What is needed is a cryptographic system that removes the need to trust the crypto custodian organization and provides solution to the identity and security problems identified above challenges.
SUMMARY OF THE INVENTION
A hybrid crypto process includes calling an on-chain smart contract function. The smart contract function receives a ghost blockchain address. Then the hybrid crypto function can call an oracle function with arguments that include the ghost blockchain address. The oracle function is associated to a program payment code and the oracle function can determine from the ghost blockchain address a payment code.
If the request is to receive crypto assets, then the payment code is a sender payment code. The request may include a crypto asset amount and the oracle arguments may include the crypto asset amount, and in this case the oracle function may associate the crypto asset amount with the sender payment code.
If the request is to send crypto assets, then the payment code is a destination payment code, and the oracle function returns a destination blockchain address.
The ghost blockchain address may be generated according to BIP 33, BIP 47 or OBPP Ver 5 (Oen Bitcoin Privacy Project version five). The payment code may have an associated user claim that is signed by a trusted private key, the hybrid crypto system may use the user claim for KYC-AML (Know your Customer-Anti-Money Laundering) compliance.
The program payment code may have an associated program claim, and the hybrid system may ensure the program claim is signed by a trusted private key before executing some capability.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 provides an overview of the actors (Stakers and Borrowers) & (Staker & Borrower Nodes) with Matter Converter.
FIG. 2 Illustrates a block diagram showing Staker and Borrower nodes interacting with a blockchain Oracle.
FIG. 3 illustrates a flowchart showing sending a crypto asset using a secret user identifier (e. g. a ghost address).
FIG. 4 Illustrates a flowchart showing receiving a crypto asset using a ghost payment address.
DETAILED DESCRIPTION
A hybrid crypto system providing the following which may be implemented with open protocols:
Actor crypto address, that a user may use to control identity and payments across multiple blockchains. An example of an actor crypto address may be a BIP-47 payment address. A simple actor crypto address may be a bitcoin wallet address, though standard best practices are to constantly be creating new bitcoin wallet addresses as is specified in BIP 32 and BIP 43 and BIP 44. The actor crypto address may have a single, re-usable address which may be used across many blockchains, with return addresses, privacy for on-blockchain transactions, and proof that any given deposit, payment or withdrawal really was sent to person identified as being associated to the actor crypto address.
Associated to actor crypto address may be user credentials for handling KYC-AML (Know Your Customer and Anti Money Laundering) regulatory requirements for regulated parties such as banks, while maintaining users' control over their own identity.
Issuer-controlled issuance of tokens on-blockchain, for example using Simple Ledger Protocol (SLP).
Server deposits for off-blockchain transactions of coins and tokens, based on a secure cryptographic sign and notarized messaging protocol, like the Open-Transactions standard.
The hybrid crypto system may provide currency agnostic integration of multiple blockchains and their derivatives.
The hybrid crypto system On-blockchain, off-blockchain, and cross-blockchain interactions.
A solution for theft and fraud wherever crypto assets are deposited with 3 rd -party custodians, based on pools of servers that employ multisig (Multiple Signature) storage of crypto assets.
The above feature set allows for hybrid (âonâ and âoffâ blockchain) Distributed Finance âDeFiâ implementations where custodians can issue cross-chain moving tokens, DeFi smart contracts can run off-chain in specific jurisdictions, on-chain smart contracts can use fast processing off-chain multi-sig endpoints, and touring incomplete coins' smart contracts can be processed off-chain and returned on-chain.
Properly running the computers includes securing the computers and private keys.
The hybrid crypto system may have notary servers and audit servers. The notary server and audit server may implement crypto notary messaging like the Open-Transactions protocol. The notary servers security (that users trust) may be based on cryptographic proofs instead of institutional trust, allowing any willing parties who wish to contract with each other to enjoy the benefits of off-chain transactions without the need for institutional trust.
In this paradigm, transaction servers are demoted to mere notary server, with the ability to countersign contracts that have originated from a user (more specifically a user crypto address) and have been signed by the private key of the user crypto address. Since only each client (user) has access to its own private key, receipts are unforgeable by the notary server, that can only âtimestampâ transactions as they come through, thus the notary server is incapable of creating a false receipt, since they lack the user's private key.
The notary server can thusâin a trustless manorârun off-blockchain transactions on the notary server based entirely on cryptographic proofs, thus making it possible to prevent theft of reserves in off blockchain transaction by storing blockchain coins and tokens in multi-signature voting pools (requiring X approvals from a pool of Y approvers, X-of-Y) that can only be moved after a signed receipt has received X approvals. The Y notary servers also audited by each other. Whenever a withdrawal needs approval, the auditors vote multisig on-blockchain to release crypto assets, but only when authorized by users' signed receipts. To build such a pool is enabled by using a server based on cryptographic proofs, which is different than traditional servers.
The hybrid crypto system may use an actor crypto address. The actor crypto address may provide a unified identity, for example a unified identity may be provided with an implementation of BIP-47 payment code, identity credentials, and blind claims.
The hybrid crypto system may employ a unified identity with Open-Transactions identity credentials, which allows users to make claims about themselves regarding their facts, relationships, and accomplishments. Moreover, anyone else (be it people, organization intuitions or government agency), e.g. trusted authorities, as colleagues, family members, etc. can cryptographically sign the claim to verify the claim. And it is in those authenticated claims where the hybrid crypto system can find the proofs needed for identifying each person according to the needs of the scenario, for example when an exchange performs a withdrawal for a user.
The hybrid crypto system may link a set of credentials to a specific re-usable ID (an actor crypto address) and its signatures. For example, the link may be made using the BIP-47.
An actor crypto address is another name for payment code.
An actor crypto address is an address that has an actor private key and an actor public key combined with a communication channel for sending messages to and from the actor crypto address.
The hybrid crypto system may use a hieratical deterministic wallet (HD wallet), like BIP 32. The hybrid crypto system may use the BIP-47 code in conjunction with identity credentials to create a publicly verifiable actor payment address.
An actor crypto address may be associated to an identity.
The actor crypto address may be used for Reusable Payment Codes which implement Hierarchical Deterministic Wallets. BIP-47 is based on BIP-44 which is an extension of BIP-32.
The BIP-47 Payment Code is a way to format blockchain addresses so that each actor can have a single (aka actor crypto address) that is a re-usable address. The actor crypto address may be able to be used across all blockchains. The actor crypto address may be able to be used for secure private two-way communication between actors of the hybrid crypto system. Actors may include users (e.g. stakers, borrowers, buyers, sellers etc.), and programs (for example the converter smart contract, notary servers and audit servers).
The actor crypto address for a user is also known as a user crypto address. The actor crypto address for user who is also a staker may also be known as a staker crypto address. The actor crypto address for user who is also a borrower may also be known as a borrower crypto address. The actor crypto address for user who is al
BACKGROUND OF THE INVENTION
Field of the Invention
This disclosure has to do with crypto currency and more specifically with cryptographically secured on and off blockchain transactions.
Background of the Invention
The Bitcoin blockchain, its derivatives and other blockchain based cryptocurrencies provide a âfoundation layerâ of hard money, where transactions are irreversible and censorship-resistant, consisting of peer-to-peer payments secured by proof algorithms like proof-of-work.
Blockchain ecosystems are also a medium for issuing third party tokens. Third-party tokens allow the blockchain-based circulation of unique units of value from different issuers. Several protocols exist for third party tokens, for example Simple Ledger Protocol (SLP) for Bitcoin-based blockchains, and ERC-20 for Ethereum.
Blockchain users and custodians need solutions to a variety of identity problems, such as a reusable address that can be used as a public ID and that supports return addresses. Solving the problems of receiving addresses is important for usability and for unifying identity across blockchains.
Blockchain users also often deposit crypto assets with 3rd-party custodians such as exchanges for the increased functionality available there, like trading on markets. These 3rd-party custodians are historically where most theft and fraud have occurred, and the losses are in the billions.
Unfortunately, third party servers in use today are only trusted in the traditional way one puts trust in the institution. User have to trust the institution that custody of their cryptocurrency to properly run and secure the computers that hold the cryptocurrency, to accurately maintain their internal ledger and customer balances, and to faithfully execute transactions legitimately requested by users.
Crypto custodial institutions, for example currency exchanges and other trading platforms, usually desire to perform order matching more rapidly than is possible on the blockchain. Crypto custodial institutions accept custody of user cryptocurrency, perform transactions in a separate off-chain system like a traditional database to track customer account balances. Typically, the services provided are not cryptographically secured, or independently auditable. To use these crypto custodial institution services users give-up full control of their deposited crypto assets and have to trust the crypto custodial institution, which exposes them to the risk of theft or loss of their crypto assets (e.g. currency and coins).
Unlike legacy currencies, cryptocurrencies can be irrevocably lost or stolen, and it's typically not possible to distinguish between internal or external theft. Historically, this ambiguity appears to have been routinely exploited.
Ascertaining user identity is critical for many blockchain-based transactions. What is âidentity,â from a software perspective? A social security card or driver's license is not the sum total of one's identity, not even in court. Like a marriage license, or a dog license, or even a witness statement in an affidavit; each is just one piece of evidence about someone. More specifically, each piece of evidence about a person (i.e. a claim or set of claims) is a claim that has been certified by someone that others trust (i.e. an authentication authority). The someone, may either a person or an organization, like an official authority, like social security administration. These pieces of evidence (claims) are like a cloud of data formed about a person.
But even the cloud of data is not one's identity itself. Identity is ethereal. The cloud of data merely consists of various pieces of evidence about a person's identity, which is the closest we have come in the real world to tracking a person's identity. For example, having the name âBill Gatesâ is not the same thing as being the Bill Gates who founded Microsoft. It's not the name alone, nor some singular taxpayer ID number that imbues identity, but rather, those names and numbers are just examples of verified (or verifiable) facts about that person.
A person's true identity is not tracked as anything more than a set of claimsâand claims about those claimsâregarding specific facts, relationships and accomplishments in that person's life, that distinguish the person from anyone else subjectively, in the eyes of those the person is interacting with. A user may create and control his own credentials, alternatively an authentication authority, may create and control a user's credentials.
However, even given a system where users have full control over their own cryptographic credentials, authorities may still be used, and authorities may set permissions or revoke access in their systems. What is needed is a system that provides a decentralized model of identity, provides users with self-determination, while ensuring that various organizations and platforms can still be in control and regulate their systems.
Many blockchain-based enterprises would like to be able to identify a user, and from there to be able to link that user to what they sign, the payments they make, the messages they send, and the claims that distinguish their identity along with authentications about those claims made by authorities.
The users of deposit-accepting services should never experience a loss of deposited crypto assets. Security threats to loss of deposited crypto assets may be grouped into three general categories:
Type 1 Event (Theft/Loss). A user permanently loses their crypto assets because a third party has gained control of them without the user's consent, or because the private keys needed to spend them have been irrevocably lost.
Type 2 Event (Denial of Service). A user temporarily loses some or all of their ability to use their crypto assets, but no third party has gained control over them.
Type 0 Event. Type 0 Events will be used to describe all other abnormal conditions from which the pool must recover which do not directly involve a loss of customer deposits
What is needed is a cryptographic system that removes the need to trust the crypto custodian organization and provides solution to the identity and security problems identified above challenges.
SUMMARY OF THE INVENTION
A hybrid crypto process includes calling an on-chain smart contract function. The smart contract function receives a ghost blockchain address. Then the hybrid crypto function can call an oracle function with arguments that include the ghost blockchain address. The oracle function is associated to a program payment code and the oracle function can determine from the ghost blockchain address a payment code.
If the request is to receive crypto assets, then the payment code is a sender payment code. The request may include a crypto asset amount and the oracle arguments may include the crypto asset amount, and in this case the oracle function may associate the crypto asset amount with the sender payment code.
If the request is to send crypto assets, then the payment code is a destination payment code, and the oracle function returns a destination blockchain address.
The ghost blockchain address may be generated according to BIP 33, BIP 47 or OBPP Ver 5 (Oen Bitcoin Privacy Project version five). The payment code may have an associated user claim that is signed by a trusted private key, the hybrid crypto system may use the user claim for KYC-AML (Know your Customer-Anti-Money Laundering) compliance.
The program payment code may have an associated program claim, and the hybrid system may ensure the program claim is signed by a trusted private key before executing some capability.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 provides an overview of the actors (Stakers and Borrowers) & (Staker & Borrower Nodes) with Matter Converter.
FIG. 2 Illustrates a block diagram showing Staker and Borrower nodes interacting with a blockchain Oracle.
FIG. 3 illustrates a flowchart showing sending a crypto asset using a secret user identifier (e. g. a ghost address).
FIG. 4 Illustrates a flowchart showing receiving a crypto asset using a ghost payment address.
DETAILED DESCRIPTION
A hybrid crypto system providing the following which may be implemented with open protocols:
Actor crypto address, that a user may use to control identity and payments across multiple blockchains. An example of an actor crypto address may be a BIP-47 payment address. A simple actor crypto address may be a bitcoin wallet address, though standard best practices are to constantly be creating new bitcoin wallet addresses as is specified in BIP 32 and BIP 43 and BIP 44. The actor crypto address may have a single, re-usable address which may be used across many blockchains, with return addresses, privacy for on-blockchain transactions, and proof that any given deposit, payment or withdrawal really was sent to person identified as being associated to the actor crypto address.
Associated to actor crypto address may be user credentials for handling KYC-AML (Know Your Customer and Anti Money Laundering) regulatory requirements for regulated parties such as banks, while maintaining users' control over their own identity.
Issuer-controlled issuance of tokens on-blockchain, for example using Simple Ledger Protocol (SLP).
Server deposits for off-blockchain transactions of coins and tokens, based on a secure cryptographic sign and notarized messaging protocol, like the Open-Transactions standard.
The hybrid crypto system may provide currency agnostic integration of multiple blockchains and their derivatives.
The hybrid crypto system On-blockchain, off-blockchain, and cross-blockchain interactions.
A solution for theft and fraud wherever crypto assets are deposited with 3 rd -party custodians, based on pools of servers that employ multisig (Multiple Signature) storage of crypto assets.
The above feature set allows for hybrid (âonâ and âoffâ blockchain) Distributed Finance âDeFiâ implementations where custodians can issue cross-chain moving tokens, DeFi smart contracts can run off-chain in specific jurisdictions, on-chain smart contracts can use fast processing off-chain multi-sig endpoints, and touring incomplete coins' smart contracts can be processed off-chain and returned on-chain.
Properly running the computers includes securing the computers and private keys.
The hybrid crypto system may have notary servers and audit servers. The notary server and audit server may implement crypto notary messaging like the Open-Transactions protocol. The notary servers security (that users trust) may be based on cryptographic proofs instead of institutional trust, allowing any willing parties who wish to contract with each other to enjoy the benefits of off-chain transactions without the need for institutional trust.
In this paradigm, transaction servers are demoted to mere notary server, with the ability to countersign contracts that have originated from a user (more specifically a user crypto address) and have been signed by the private key of the user crypto address. Since only each client (user) has access to its own private key, receipts are unforgeable by the notary server, that can only âtimestampâ transactions as they come through, thus the notary server is incapable of creating a false receipt, since they lack the user's private key.
The notary server can thusâin a trustless manorârun off-blockchain transactions on the notary server based entirely on cryptographic proofs, thus making it possible to prevent theft of reserves in off blockchain transaction by storing blockchain coins and tokens in multi-signature voting pools (requiring X approvals from a pool of Y approvers, X-of-Y) that can only be moved after a signed receipt has received X approvals. The Y notary servers also audited by each other. Whenever a withdrawal needs approval, the auditors vote multisig on-blockchain to release crypto assets, but only when authorized by users' signed receipts. To build such a pool is enabled by using a server based on cryptographic proofs, which is different than traditional servers.
The hybrid crypto system may use an actor crypto address. The actor crypto address may provide a unified identity, for example a unified identity may be provided with an implementation of BIP-47 payment code, identity credentials, and blind claims.
The hybrid crypto system may employ a unified identity with Open-Transactions identity credentials, which allows users to make claims about themselves regarding their facts, relationships, and accomplishments. Moreover, anyone else (be it people, organization intuitions or government agency), e.g. trusted authorities, as colleagues, family members, etc. can cryptographically sign the claim to verify the claim. And it is in those authenticated claims where the hybrid crypto system can find the proofs needed for identifying each person according to the needs of the scenario, for example when an exchange performs a withdrawal for a user.
The hybrid crypto system may link a set of credentials to a specific re-usable ID (an actor crypto address) and its signatures. For example, the link may be made using the BIP-47.
An actor crypto address is another name for payment code.
An actor crypto address is an address that has an actor private key and an actor public key combined with a communication channel for sending messages to and from the actor crypto address.
The hybrid crypto system may use a hieratical deterministic wallet (HD wallet), like BIP 32. The hybrid crypto system may use the BIP-47 code in conjunction with identity credentials to create a publicly verifiable actor payment address.
An actor crypto address may be associated to an identity.
The actor crypto address may be used for Reusable Payment Codes which implement Hierarchical Deterministic Wallets. BIP-47 is based on BIP-44 which is an extension of BIP-32.
The BIP-47 Payment Code is a way to format blockchain addresses so that each actor can have a single (aka actor crypto address) that is a re-usable address. The actor crypto address may be able to be used across all blockchains. The actor crypto address may be able to be used for secure private two-way communication between actors of the hybrid crypto system. Actors may include users (e.g. stakers, borrowers, buyers, sellers etc.), and programs (for example the converter smart contract, notary servers and audit servers).
The actor crypto address for a user is also known as a user crypto address. The actor crypto address for user who is also a staker may also be known as a staker crypto address. The actor crypto address for user who is also a borrower may also be known as a borrower crypto address. The actor crypto address for user who is also a buyer may also be known as a buyer crypto address. The actor crypto address for user who is also a seller may also be known as a seller crypto address.
The actor crypto address for a program is also known as a program crypto address. The actor crypto address for a program running on a distributed ledger may also be known as smart contract crypto address. The actor crypto address for a notary server may also be known as a notary crypto address. The actor crypto address for an audit server may also be known as an audit crypto address. The program crypto address may be a smart contract crypto address, a notary crypto address, or an audit crypto address. An off-chain program crypto address may be a notary crypto address or an audit crypto address.
The actor crypto address may not appear in any on-blockchain transactions. Instead, the receiving addresses are calculated deterministically using for example a Diffie-Hellman shared secret. This is a process whereby each party, using his own private key and the other party's public key, is able to calculate a shared secret key, which no one else can calculate without one of the private keys. The parties may also increment an index after each transfer, so there is a new blockchain receiving address calculated for each transaction between them.
BIP-47 uses payment codes. A payment code includes in part a public key and BIP-47 provides a technique for creating payment addresses (for example Bitcoin addresses) that can be reused and publicly associated with a real-life identity without creating a loss of financial privacy. Payment codes are similar to stealth addresses but involve a different set of trade-offs and features that may make them more practical. A payment code may be used along with a counter party (i.e. another actor crypto address) private key to use Diffie-Hellman process to generate payment addressees.
Depending on the actor crypto address the hybrid crypto system may behave differently. For example, if the hybrid crypto system receives communication from a standard address then it may process it as normal and would need a return address to be provided for any returns. If the actor crypto address is from a hierarchical deterministic wallet with Diffie-Hellman determined addresses (for example BIP 47) then the hybrid crypto system may calculate the destination address to use when needed, for example to return or crypto assets (e.g. to pay-out coins or tokens).
The actor crypto address, like a BIP-47 payment code, may provide users with a single ID that can be used across different blockchains, without having to generate different ID (e.g. randomly generated IDs) for each blockchain, where that generated difference ID must be stored and cannot be deterministically derived again. The same ID will work on Litecoin, Bitcoin, Bitcoin Cash, etc.âany blockchain where the user holds a private key. The actor crypto address may work across all Bitcoin-derived blockchains, such as Litecoin, BSV, and Bitcoin Cash, as well as on-and-off blockchain. The hybrid crypto system may also allow the same actor crypto address to work on non-bitcoin-derived blockchains like Ethereum and EOS.
An actor crypto address, for example a BIP-47 payment code, may be freely published everywhere and serve as the user's âpublic IDâ without loss of security or anonymity.
Actors only need to exchange the actor crypto address, like BIP-47 payment codes, once. Thereafter, messages and payments, agreements, and smart contracts, including DiFi contracts themselves can safely flow between the actors, without having to exchange a new address (e.g. a new random address) each time.
The actor crypto address that is used for payments may also be used for messaging, and for signing messages that are sent, as well as for verifying signatures on messages received.
A third-party public observer will not see an actor crypto address in any of on-blockchain transactions, because the on-blockchain transactions use receiving addresses that are generated deterministically by both parties without having to transmit anything, using a Diffie-Hellman shared secret.
The counter parties to a transaction may see their entire history between each other. This is possible because each party has one of the private keys needed to generate the deterministic receiving addresses used for prior transactions with the other party.
So, when a message or payment is sent, a sender knows for certain who the recipient will be, and there is no ability for the recipient to provide some third party's receiving address instead of their own.
Also, when a user receives a payment, the recipient knows who the sender is. The recipient will see the sender's âdisplay nameâ on the incoming payment, and can even hit âreplyâ to send a payment or message back to the sender.
The above identity features of the hybrid crypto system may allow for use worldwide of on-chain and off-chain Defi. For example, a user may enter into a smart DeFi contract that may calculate a return or destination address using a smart contract oracle, specifically a destination address oracle. The destination address oracle may generate a destination address and the smart contract can use the destination address to send crypto assets (for example withdrawals, refunds, payments) to the actor crypto address.
The destination address oracle may be called to determine the destination address given a public key seed like a BIP-47 payment code. The destination address oracle may have a private key used in a Diffie-Hellman calculation along with the actors public key seed (like a BIP-47 payment code) to derive a shared secret number that may be used in establishing communication or encryption between the actor crypto address and the hybrid crypto system.
The communication between the smart contract and the oracle may be encrypted. The communication from the actor crypto address (e.g. crypto wallet) to the smart contract may be encrypted.
FIG. 1 , the actor crypto address, (e.g. Staker Node, user wallet, staker wallet . . . ), invokes API on converter smart contract including a parameter that can be used as a payment code. The converter smart contract may call the destination address creator oracle (also known as destination address oracle) and passes it the payment code. The destination address oracle may return a destination payment address. The smart contract may use the destination payment address for an on-blockchain transaction.
Having a mathematical guarantee that the crypto assets are coming and going to the same actor crypto address may be useful especially when dealing with KYC and AML regulations. Meanwhile the smart contract (whether its running on some chain or off-chain on a notary server) can maintain a mathematically provable audit trail of its own transactions while still co-existing in a de-centralized ecosystem. This allows for interesting use cases such as an on-chain DeFi smart contract that executes a portion of its code in a certain physical location. In such a case, the notary server would be required to have a 3rd party digitally signed claim from a recognized authority that certified that the notary node is in fact in a certain location. Government financial regulators would be good certification identity signers, for example providing signed claims for citizenship, or signing saying that the servers are located in a building in their physical jurisdiction.
The hybrid crypto system may include an actor crypto address where the actor crypto address includes an identity credential scheme, for example BIP-47 such that additional data (such as certifying a notary node location) is implemented in the hybrid crypto system's identity credential scheme. The system may also attach metadata to that ID in the form of credentials, consisting of claims and claim verifications by various authorities.
In the hybrid crypto system, a pseudonym (or simply âNymâ) is a potential identity that has an actor crypto address (i.e. a public address; for example a BIP-47 ID aka a payment code), a corresponding private key, and a set of credentials. A Nym doesn't mean that any real-world information has been authenticated regarding the person represented by the Nym.
Actor Crypto address Wallets (for examples one implementing BIP-47) when they receive an on-blockchain payment they can display the name of the sender. For example, this can be accomplished if using Open Transaction because the Open Transactions API has already downloaded the sender's identity credentials, which are cryptographically verified against the actor crypto address's keys. The display name field is one example of the sort of metadata that can be provided as credentials via as self-signed claim.
An actor crypto address credentials may contain claims about the owner, regarding various facts, relationships, and accomplishments. For example, âMy SSN is XXX-XX-XXXX, self-signed, by the actor crypto address private key.â Other claims maybe in credentials that are signed by others. For example, a credential may be signed verified claim might look like this, if imagined in human-readable form âThe hash fingerprint of an encrypted JPG of my scanned driver's license is 1Jasd876y2jhg34h998, signed by actor crypto addressâ followed by: âWe have officially authenticated this information in person and can reproduce it upon demand, signed by a trusted authority crypto address.â The trusted authority may have an actor crypto address or just a private/public key with a published public key.
For example, when meeting someone in person one may add them as a new contact to a smart phone by scanning their QR code, the actor crypto address may be part of a crypto wallet implementation running on a smart phone and may create reciprocal verified claims between both parties smart phones, providing proof to anyone later that they have definitely met each other in real life. Using these verified claims, a âweb of trustâ can form organically, without any need for âkey signing parties.â Various trusted authorities may be responsible to identify users and verify claims, as described below. With a claim signed by a trusted authority a user will be able to prove their identity, without having to ask the authentication authority, since the authentication authority already signed the claim, thus claim is a verified claim.
User credentials may also contain blind claims, that is claims that are proven without having to publicly disclose the data behind a claim, but rather the data behind the claim in a âblindâ way. To do this, the value field of the claim is encrypted, and the trusted authority, after assuring the content of the encrypted claim, signs a hash of this blind value instead of signing the plaintext value as might normally occur. The trusted authority may have seen and verified the plaintext value, before signing the claim verification. For example, there may be legal requirements in certain situations to prove a person's age, and so it would be useful for users to be able to prove their age and provide a photo when necessary, without having to post their birthdate or photo publicly for the whole world to see. This is possible using a blind claim. The structure of a blind claim may be the same as for a normal claim, except there is no value field. Instead, the claim includes a blind value field that's encrypted to a (deterministic) key; structured like the Open-Transaction's structure.
Note that the blind value itself is encrypted to a deterministic key which is recoverable from the user's seed. Publicly only the blind hash is visible on the user's credentials, as well as any signed verifications of the claim.
For example, the State of California could sign the hash of an encrypted birthdate in order to allow one to prove their age on demand, when required.
Alternately, a user may be able identify themselves to a notary public, and then the notary may take a picture of the user on the spot and sign the hash of an encrypted JPG of picture. So, when the user is signing documents, not only is the user's signature provably the correct signature from the BIP-47 ID, but a user can also reveal their photo to any challenger while simultaneously proving that an authentication authority, in this example the notary public, has certified the photo (i.e. signed the hash) and thus authenticated it for that same BIP-47 ID.
A notary publicâor an on-boarding departmentâcould additionally scan a user driver's license and then sign the hash of a JPG of the user driver license, thus certifying the were presented the driver's license by the person shown on the driver's license.
In this way authenticated data (i.e. verified claims) are made available for a user to prove those claims, as authenticated by a trusted authority, to others, without having to reveal the data publicly, and without having to re-verify their identity over and over again to an on-boarding service. On-boarding processes, exists to verify the identity of a user who are new to a system, for example this may be done over a webcam.
The hybrid crypto system can enable data that is of value when it's been authenticated by an authentication authority. Sherpas may certify that a user climbed Mount Everest. A trusted authority may certify the user as a U.S. citizen. Colleagues may certify they have worked the user.
Other forms of proofs, including zero-knowledge proofs, may be used in user credentials. For example, Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-NSARKS) and Zero-Knowledge Scalable Transparent ARguments of Knowledge (zk-STARKS) may be used for various blind or transparent proofs.
The hybrid crypto system has a cryptographic proof messaging (crypto notary messaging). The cryptographic proof messaging system (aka crypto messaging system) provides off-blockchain transactions secured by cryptographic proofs. The cryptographic proofs can take many forms such as all messages are signed by a private key, and messages may also be signed by a notary private key. An example of a crypto notary messaging system is the Open-Transactions (OT) project. The OT project is a collaborative effort to develop a robust, commercial grade, fully-featured, free-software toolkit that implements off-blockchain transactions purely as cryptographic proofs.
The hybrid crypto system ecosystem may consist of proprietary and open-source software which implements the open source OT protocol.
Open-Transactions (OT) uses strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and homomorphic encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing a receipt history, as long as one has the last signed receipt.
The cryptographic poof system may implement financial instruments as Ricardian Contracts, which are contracts that can be understood by humans as well as manipulated by software.
All contracts in the cryptographic proof system may use the same basic structure: all parties involved sign an agreement which is notarized by an independent third-party witness (i.e. a notary). This technique is known as Triple-Signed Receipts. Importantly, transactions are formed and signed on the user (i.e. client side) first before being notarized by a notary server. A user (i.e. client) is thus ensured that an notary server cannot falsely create receipts, since the server lacks the user's private key and thus can't forge a signed starting receipt.
A cryptographically provable off-blockchain transaction is a group of operations on contracts capable of objectively proving information, for example balances (and changes of balance) between adversarial parties.
Transactions may use the same basic structure: the private key of a user crypto address signs agreements that are then countersigned by the private keys of a notary server. Transactions are irreversible since the receipts are always formed and signed on the client side first, before being notarized by a notary server. This prevents the notary server from creating a false receipt, since it can't forge the user crypto address signature.
This basic structure may be built upon to create many types of financial instruments, for example transfers, cash, cheque, voucher invoice, market offer, reoccurring payment smart contracts. A transfer is an atomic movement of crypto assets from one account to a different account, like a bank account-to-account transfer. Cash is an untraceable cryptographic token, which can be securely redeemed by the recipient without revealing the sender. A cheque is a payment which is not deducted from the sender's account until the recipient claims it. A voucher is a payment which is deducted from the sender's account at the time of creation. An invoice is a payment request which the recipient can opt to pay from any of his accounts. A market offer is an open agreement to exchange a given quantity of one unit type for a given quantity of another unit type. A recurring Payment is an agreement between two parties that includes an optional initial payment, followed by a set number of additional payments over a specified period of time. A smart contract is a customizable agreement between multiple parties, containing user defined scripted clauses, hooks, and variables.
An example implementation of these financial instruments may be found in Open Transaction, OT.
The crypto notary messaging system may supports DeFi smart contracts which makes it possible for the hybrid crypto system to execute DeFi off-chain where the notary server may set transaction fees. This allows for implementations that provide real time processing and notary server operator controlled transaction fees. One example would be quant trading. Furthermore, the entire smart contract need not be off-chain. With the hybrid crypto system, a wide array of hybrid (i.e. on- and off-chain) functionality is possible.
An actor crypto address may be a user crypto address and the transaction may be an authorization to share medical information. In this use case each medical provider (e.g. hospital) may have a notary node, and a request may originate from a patient crypto address as a cryptographically signed request. For example, hospital âAâ may run a notary node and want to release medical records to Hospital B's crypto address. Once the patient release transaction has been verified and notarized by the Notary node then the medical records may be sent from the crypto address of hospital âAâ to the crypto address of hospital âBâ.
In the hybrid crypto system, each notary server signed receipt contains a copy of the original user-signed request. If the requirements for a valid request also includes an authenticated (i.e. signed) statement of the balance, one can always prove the current balance using the most recent receipt.
The hybrid crypto system may prove which instruments are still valid by including a list of outstanding transaction numbers on each request. The request may also include a list of any incoming transactions where each incoming transaction use a transaction number, in an OT implementation for example an open transaction number.
At all times throughout the process, all parties are able to prove their current balance, as well as which instruments are valid and which transaction numbers are closed, without storing any history except the last signed receipt. Alice's own signature on her request proves these things to Alice, and Bob's own signature on his request proves these things to Bob. The notary server is unable to defraud them.
Users are not forced to keep their receipt history in order to prove the current state. Proofs which require a full history are O(n), whereas the hybrid crypto system's proofs are O(1). O(1) balance proofs are preferable to O(n) proofs, because even though most users would choose to save their transaction history, the risk of a balance proof failing due to data loss does not grow without bound over time like the full history O(n) solution does.
Although a notary server is unable to falsify Alice's cryptographically signed requests, one risk of loss remaining is counterfeiting crypt oassets with a dummy account. A bad actor notary server could try and create a dummy account (with a made-up crypto address) and then sign a false receipt for that dummy account, and thus create counterfeited crypto assets which can then be sent to an accomplice crypto address.
Counterfeiting can be combated by auditing the receipts.
The hybrid crypto system may allow users to deposit their on-blockchain assets (e.g., coins or tokens) into a multi-signature voting pool composed of several notary servers, where each computer server running the notary server software may also run the audit server software, and the pool of servers may vote on-blockchain when necessary to approve withdrawals. This is only possible to do without institutional trust if the off-blockchain system is based on cryptographic proofs, for example Open-Transactions.
The voting pool arrangement has advantages in combatting counterfeiting and theft. Regarding counterfeiting, multiple audit servers, ideally owned and managed by different parties are auditing each notary server, which prevents any one audit server (e.g. a compromised notary server) from counterfeiting transactions on its ledger. Regarding theft, an individual notary server is incapable of stealing coins out of the pool, since a multi-signature vote is necessary to retrieve the crypto assets, and those votes are controlled by the audit servers (aka auditors).
The hybrid crypto system may use voting pools as an open standard with the intent that a voting pool is an arrangement of notary servers and audit servers to securely store and account for customer crypto asset deposits, and to honor valid withdrawal requests even in the event the customer's notary server of choice has completely disappeared. Voting pools are designed to ensure that no single person or organization can perform unilateral actions on deposited crypto assets, this reduces the risk of loss or theft, and custodial liability. Each notary server in the voting pool may operate its own audit server, and each audit server may have a corresponding audit crypto address (e.g. blockchain wallet). The blockchain wallet may manage the multi-signature transaction generation, as well as a hierarchical and deterministic list of addresses for crypto assets (e.g. bitcoins and colored coins).
When a user wants to deposit x units of cryptocurrency into a voting pool, the user may use a user crypto address to send x to the crypto address of the voting pool, which records the corresponding units against the user crypto address account on a notary server. Each audit server watches the receipt stream for requests to deposit or withdraw crypto assets (e.g. bitcoins or colored coins) from the voting pool, and then communicates with the audit crypto address (e.g. a bitcoin wallet) in regards to any on-chain transactions, for example send a signed transaction to the multisig address (pool crypto address) on the blockchain.
Each audit server may independently verify the transaction operations of all notary servers in the voting pool, as well as the crypto currency held by the pool on the blockchain itself. The audit server uses the audit data to know when it should approve the wallet (i.e. multisig pool crypto address) to create a withdrawal transaction, and the audit server is also the component responsible for information sharing and achieving consensus between all members of the pool.
Effectively each audit server conducts a permanent, real time proof-of-reserves audit against of the notary servers in the pool, and simultaneously enforces it by only signing off on the transaction when the transaction passes audit. If the transaction passes then the audit sever may send the signature for the multisig. It is the audit server and the pool crypto address (e.g wallets) who hold the keys to creating blockchain transactions at the request of the user through the notary server. The audit servers must act by consensus and through the pool audit address (e.g. the wallet) to authorize the multi-signature blockchain transaction.
Each voting poolâregardless of how many notary servers (aka notaries)âmay still be implemented as a single notary node with its own actor crypto address (e.g. BIP-47 payment code), aka an pool crypto address, or off-chain crypto address, that supports on-chain mulitsig.
In order to achieve security and robustness for voting pools, the following criteria are enforced, avoid bitcoin address re-use. The hybrid crypto system may discourage user from reusing deposit addresses. The voting pool itself may never reuse a bitcoin address. Each notary node of the pool may calculate all of the series of deposits and changes to an account. Withdrawal transaction input selection should be deterministic in order to minimize the cost of coordinating transaction signing.
The hybrid crypto system may keep a majority of the private keys offline for security reasons and bring them online as needed to process withdrawals.
The hybrid crypto system may alter the voting pool by adding, removing, or replacing members in a coordinated and secure fashion. It is necessary to use Smart Properties to accomplish this.
These are described in the below in the discussion on colored coins.
If the probability of m+1 (Type 1 Event) or n m+1 (Type 2 Event) services simultaneously and identically behaving in a malicious or incompetent manner is lower than the probability of any individual server behaving in a malicious or incompetent manner, user deposits on that service are at less risk of loss if the service is a member of an m-of-n voting pool than they would be at risk if the service is not a member of a voting pool.
Voting pools can guarantee the integrity of user deposits if, in any given situation, at least m pool members are well-behaving for Type 1 events and at least n m pool members are well-behaving for Type 2 events.
The audit server listens to the audit streams broadcast by all the notary servers and independently verifies them for correctness. The same stream which carries regular transaction (e.g. OT transaction information) may also contain the OT receipts for Bitcoin withdrawal requests from the pool. The audit server initiates or authorizes a blockchain withdrawal transaction via the wallet if and only if the audit for that service is clean (verified correct).
The auditor is responsible for maintaining an independent copy of the same deposit database as the notary server. the audit server also tracks withdrawals from the time at which notary server receives a transaction (e.g. an OT receipt), containing a withdrawal request, until the corresponding Bitcoin transaction is fully confirmed on the blockchain.
All messages which must travel between the notary server and the blockchain wallet pass through the audit server.
In order to create withdrawal transaction, wallets must be able to select inputs and change outputs, and calculate the minimum required transaction fee deterministically. In order to achieve determinism, the sequence of withdrawals must be globally consistent. Before sending any withdrawal request to the wallet, the auditors are responsible for achieving consensus on a serialization order for withdrawals.
The notary server keeps track of all distributed-ledger-denominated balances via signed notarized receipts, for example OT receipts. In addition to the separate account(s) for each user, the server may have a notary crypto address (aka a service account) to hold the distributed-ledger-denominated balances managed by the notary server itself.
If necessary, the server should also maintain an application account to hold the balance of any funds which are being manipulated by an external system.
For example, in the case of a high-frequency exchange, the application account would belong to the order matching engine. When a user enters a trade, the exchange front-end will send the applicable crypto notary messaging (e.g. call the applicable OT functions) to transfer the appropriate balance from the selling crypto address (e.g. OT account) to the notary crypto address (e.g. application OT account) and also from the application account back to the appropriate purchasing customer's OT account. Any trade fees that the exchange earns would be sent to the service account as part of the transaction. The separation of application account, service account, and customer account, prevents the mingling of crypto assets.
The notary server may also be responsible for passing PaymentRequests from the Auditor to the user, crediting user balances after the successful receipt of a blockchain deposit, and passing withdrawal requests to the rest of the voting pool via the audit servers.
The notary server must maintain a permanent deposit database containing each PaymentRequest generated for that server and its associated status (number of blockchain confirmations and the OT receipt crediting the appropriate Nym with the deposit)
The notary server may broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.
The five types of messages are, 1) an update to an inbox, 2) an update to an outbox, 3) an update to an account balance file, 4) an update to a Nym box file, 5) notary server replies to transaction requests.
In order for users to deposit cryptocurrency into the voting pool, the OT Client may be capable of parsing, verifying, and if necessary, forwarding to another blockchain wallet client, payment requests. This is necessary to ensure a malicious notary server cannot send a fake deposit request that results in a customer sending crypto assets to an address not controlled by the pool.
Users of services which are part of a voting pool may have an OT client running on their device in order to use the service. The service front end can communicate transparently with the OT Client via a local websocket interface.
The OT client will be capable of operating in the background with the bare minimum necessary interaction in order to provide the lowest possible disturbance of the front end service's user experience (UX).
Each server in the pool requires an offline, air-gapped machine for key generation called a key server. It is equipped with either a dedicated, non-networked printer, or else a CDR drive. No media of any kind is ever allowed to cross the air gap in the onlineâoffline direction.
The key server generates random BIP32 seeds in batches (default: 52, or enough for one year).
When a batch is created, it prints the xpubs (extended public keys) for all 52 seeds on paper as QR codes (alternately on a virgin CDR which is discarded after a single use). This paper is then manually walked to the auditing server and scanned. The auditing server adds each xpub to the keyset definition.
At the same time, the key server also prints two redundant copies of the QR codes containing the xprivs (extended private keys), one per page (one per CD) which the service should hold in some physically secure fashion and back up securely. It is not necessary for all individual services to take extraordinary measures to protect the private keys from physical destruction, since the pool can tolerate a loss of keys that involves less than (n-m) members. One copy held in an offsite location with another copy held on site is sufficient.
Xprivs are loaded into the auditing server in series number order to create the hot series. Each participant in the pool should have a method of being notified when the hot series is close to being exhausted so that an employee can be instructed to load the next xpriv into the auditing server.
New key batches should be generated early before the old batch is consumed (default: 75 percent used). If for any reason one of the participants is late and does not generate a new batch on time, the last defined series number is used for accepting deposits until the administrators of the other pool members can correct the situation.
The key server must also be equipped with a scanner. Prior to putting any keys into service, they must be validated.
Validation procedure: The key server will create the first one million public and private keypairs from each seed in the batch, sign a nonce with each private key and verify the signature with the corresponding public key.
Then the user will scan in the printed public and private keys, and the key server will verify the scanned versions match the original versions and repeat the million keypair test.
Both versions of the test must match identically before placing any of the keys into service.
Every pool represents a compromise between performance and cost. For security and reliability purposes, higher reliability levels are better, however they must be balanced against the cost factor. Standard pool sizes are the lowest cost pools that produce a given reliability level.
Customers will normally request a deposit address by interacting with the service front end web site or some other software application. When the service receives such a request, it notifies the OT client via the OT client API function: requestBailment.
When the OT client receives notice of a user desire to deposit crypto assets to a voting pool, via any method, it sends a bailment transaction request to the notary server to initiate the deposit process.
The notary server validates this request, and replies with a signed receipt. A copy of this receipt is broadcasted to the audit stream, and another copy is stored inside an initiatedBailment notice that's placed in the user's inbox. The notary server adds this association to a bailment database for future reference.
When an audit server validates the notary server's reply to the bailment message from the notary server to which it is assigned, the audit server adds the receipt identifier to its bailment database and calls getDepositScript via the websocket interface to the blockchain wallet, using the address identifier for the next unused deposit address.
The wallet calculates and returns the designated deposit address as P2SH output script. The audit server uses this information to update the bailment database, and to assemble and sign a PaymentRequest.
The audit server broadcasts the PaymentRequest to all notaries and auditors in the pool. The notary server replaces the user's initiatedBailment notice in the inbox with a pendingBailment notice containing a copy of the PaymentRequ
CLAIMS
Claims ( 22 )
The invention claimed is:
1. A hybrid crypto process comprising:
receiving at an on-chain smart contract function running on a distributed ledger a request that includes a secret user identifier,
calling a blockchain address oracle running on a computer server with arguments that include the secret user identifier, where the blockchain address oracle returns a distributed ledger address, and
the on-chain smart contract function uses the distributed ledger address in a distributed ledger transaction.
2. The hybrid crypto process of claim 1 where the request is a receive crypto assets request and the blockchain address oracle determines an actor public key seed from the secret user identifier.
3. The hybrid crypto process of claim 2 where:
the request includes a crypto asset amount,
the arguments include the crypto asset amount,
the actor public key seed is a sender public key seed, and
the blockchain address oracle associates the crypto asset amount with the sender public key seed.
4. The hybrid crypto process of claim 1 where the request is a send crypto assets request and the blockchain address oracle determines from the secret user identifier an actor public key seed, where the actor public key seed is a destination public key seed, and the blockchain address oracle returns a destination blockchain address.
5. The hybrid crypto process of claim 2 where, the actor public key seed is a user public seed key and associated to the actor public key seed is a user claim that is signed by a trusted private key, and in addition:
using the user claim for know your customer compliance.
6. The hybrid crypto process of claim 2 where, the actor public key seed is a user public key seed and associated to the user public key seed is a user claim signed by a trusted private key, and in addition:
using the user claim for anti-money laundering compliance.
7. The hybrid crypto process of claim 2 where, the actor public key seed is a program public seed key and associated to the program public key seed is a program claim, and in addition:
ensuring the program claim is signed by a trusted private key before executing some capability.
8. The hybrid crypto process of claim 1 where the on-chain smart contract function is invoked by a notary server running on another computer server, where the notary server uses cryptographic proof messaging to facilitate an off-chain transaction between two actor crypto addresses.
9. The hybrid crypto process of claim 1 where the secret user identifier enables privacy in on-blockchain transactions by generating receiving addresses deterministically using a Diffie-Hellman shared secret.
10. The hybrid crypto process of claim 1 , where the blockchain address oracle uses a hierarchical deterministic tree of blockchain addresses to determine the distributed ledger address using the secret user identifier.
11. A hybrid crypto system comprising:
an on-chain smart contract running on a distributed ledger that accepts a secret user identifier, and
a blockchain address oracle running on a computer server that accepts a blockchain address, where associated to the blockchain address oracle is an oracle private key seed and the blockchain address oracle determines from the blockchain address an actor public key seed and calculates a shared secret number from the actor public key seed and the oracle private key seed, and
where the on-chain smart contract calls the blockchain address oracle, passing in the secret user identifier as the blockchain address.
12. The hybrid crypto system of claim 11 where the on-chain smart contract receives crypto assets and the actor public key seed is a sender public key seed.
13. The hybrid crypto system of claim 12 where:
the on-chain smart contract also accepts a crypto asset amount and
the blockchain address oracle also accepts a provided crypto asset amount,
where the blockchain address oracle associates the crypto asset amount with the sender public key seed.
14. The hybrid crypto system of claim 11 where the on-chain smart contract is sending crypto assets and the actor public key seed is a destination public key seed and the blockchain address oracle returns a destination blockchain address.
15. The hybrid crypto system of claim 11 where, the actor public key seed is a user public key seed and associated to the user public key seed is a user claim signed by a trusted private key, and in addition:
the hybrid crypto system uses the user claim for know your customer compliance.
16. The hybrid crypto system of claim 11 where, the actor public key seed is a user public key seed, and associated to the user public key seed is a user claim signed by a trusted private key, and in addition:
the hybrid crypto system uses the user claim for anti-money laundering compliance.
17. The hybrid crypto system of claim 11 where the blockchain address oracle generates destination addresses for sending crypto assets to actor crypto addresses without requiring the actor crypto addresses to appear in any on-blockchain transactions.
18. The hybrid crypto system of claim 11 , where the blockchain address oracle generates the distributed ledger address by:
deriving a master key from the shared secret number;
generating a hierarchical deterministic tree of blockchain addresses from the master key; and
selecting the distributed ledger address from the hierarchical deterministic tree.
19. A hybrid crypto process comprising:
calling a blockchain address oracle from a smart contract, where the smart contract is running on a distributed ledger with arguments that include a secret user identifier, where associated to the blockchain address oracle is an oracle public key seed and the blockchain address oracle determines from the secret user identifier a user public key seed.
20. A hybrid crypto system comprising:
a first computer server comprising a processor and memory storing instructions that, when executed, implement an off-chain program with a user public key seed, where the off-chain program generates a secret user identifier associated to the user public key seed,
a second computer server comprising a processor and memory storing instructions that, when executed, implement a blockchain address oracle running on a second computer server with arguments that include the secret user identifier, where the blockchain address oracle determines from the secret user identifier the user public key seed, and
a distributed ledger network comprising multiple computing nodes that collectively implement an on-chain smart contract,
where the off-chain program calls the on-chain smart contract and provides the secret user identifier, the on-chain smart contract calls the blockchain address oracle and provides the secret user identifier, and the on-chain smart contract receives back from the blockchain address oracle a destination address.
21. The hybrid crypto system of claim 20 where the instructions of the first computer server, when executed, implement the off-chain program as a notary server that processes off-blockchain transactions secured by cryptographic proofs, and the notary server is associated with a notary crypto address.
22. The hybrid crypto system of claim 20 where the secret user identifier enables the on-chain smart contract to send crypto assets to the user public key seed without the user public key seed appearing in any on-blockchain transaction, thereby preserving privacy while maintaining a mathematically provable audit trail.
US17/583,189
2021-01-22
2022-01-24
Cryptographically secured hybrid (on and off blockchain) cryptocurrency system
Active
2042-11-05
US12412162B2
( en )
Priority Applications (1)
Application Number
Priority Date
Filing Date
Title
US17/583,189
US12412162B2
( en )
2021-01-22
2022-01-24
Cryptographically secured hybrid (on and off blockchain) cryptocurrency system
Applications Claiming Priority (2)
Application Number
Priority Date
Filing Date
Title
US202163140270P
2021-01-22
2021-01-22
US17/583,189
US12412162B2
( en )
2021-01-22
2022-01-24
Cryptographically secured hybrid (on and off blockchain) cryptocurrency system
Publications (2)
Publication Number
Publication Date
US20220253813A1
US20220253813A1 ( en )
2022-08-11
US12412162B2
true
US12412162B2 ( en )
2025-09-09
Family
ID=82703959
Family Applications (1)
Application Number
Title
Priority Date
Filing Date
US17/583,189
Active
2042-11-05
US12412162B2
( en )
2021-01-22
2022-01-24
Cryptographically secured hybrid (on and off blockchain) cryptocurrency system
Country Status (1)
Country
Link
US
( 1 )
US12412162B2
( en )
Cited By (1)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20240273515A1
( en )
*
2023-01-23
2024-08-15
Dos Centavos, Llc
COMPUTER METHOD FOR SIMPLIFIED CREATION OF NFTs
Families Citing this family (15)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
WO2022195860A1
( en )
*
2021-03-19
2022-09-22
æ¥æ¬é»æ°æ ªå¼ä¼ç¤¾
Voting system and voting method
EP4160978B1
( en )
*
2021-09-30
2024-07-31
Tata Consultancy Services Limited
System and method to randomize distribution of cryptographic keys across multiple secure key storage devices
US11989722B2
( en )
*
2021-10-15
2024-05-21
Coinbase, Inc.
Omnibus address generation and autoconversion of cryptocurrency
CN114707973A
( en )
*
2022-03-08
2022-07-05
ä¸ç§è®¡ç®ææ¯åæ°ç 究é¢
Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application
US20230289337A1
( en )
*
2022-03-14
2023-09-14
LayerZero Labs Ltd.
Trustless omnichain communication protocol platforms
US12259970B1
( en )
*
2022-03-23
2025-03-25
Gen Digital Inc.
Systems and methods for identifying security threats in smart contract-based services to protect against malicious attacks utilizing off-blockchain resources
US20230396456A1
( en )
*
2022-06-06
2023-12-07
Salt Blockchain Inc.
Secure hardware cryptocurrency keystore and key generation ceremony
EP4540751A1
( en )
*
2022-06-17
2025-04-23
Frontage Road Holdings, LLC
Multisignature custody of digital assets
WO2024043936A1
( en )
*
2022-08-25
2024-02-29
MatterFi
Secure cryptographic server card
CN115514568A
( en )
*
2022-09-23
2022-12-23
è´µå·çµç½æéè´£ä»»å ¬å¸
Block chain-based power information safety system and method
CN115987520B
( en )
*
2022-12-05
2024-12-24
ä¸ä¿¡é¶è¡è¡ä»½æéå ¬å¸
Method and system for processing cross-chain transaction by multiple notarizers
CN116795382A
( en )
*
2023-03-31
2023-09-22
èèåºåé¾ç§æ(ä¸æµ·)æéå ¬å¸
Methods and blockchain nodes for deploying contracts in the blockchain
US20240338381A1
( en )
*
2023-04-04
2024-10-10
Fmr Llc
NFT Based Secure Authentication and Notification Apparatuses, Processes and Systems
US20240386425A1
( en )
*
2023-05-18
2024-11-21
International Business Machines Corporation
Revoking in-fly audited transactions
EP4629121A1
( en )
*
2024-04-04
2025-10-08
BSV Association
Processing a blockchain transaction over a peer-to-peer network
Citations (6)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US9565020B1
( en )
*
2016-02-02
2017-02-07
International Business Machines Corporation
System and method for generating a server-assisted strong password from a weak secret
US20180288022A1
( en )
*
2017-03-31
2018-10-04
Dr. Vijay Madisetti
Method and System for Identity and Access Management for Blockchain Interoperability
US10402823B1
( en )
*
2018-12-30
2019-09-03
Alexander Vladimirovich Vlasov
System for exchanging private keys for mutual settlements between users of a cryptocurrency outside blockchains
US20200059364A1
( en )
*
2018-08-18
2020-02-20
Eygs Llp
Methods and systems for implementing zero-knowledge proofs in transferring partitioned tokens on distributed ledger-based networks
US20200328893A1
( en )
*
2019-04-15
2020-10-15
Eygs Llp
Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US20220335422A1
( en )
*
2020-12-15
2022-10-20
MatterFi
Crypto currency hardware wallet
2022
2022-01-24
US
US17/583,189
patent/US12412162B2/en
active
Active
Patent Citations (8)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US9565020B1
( en )
*
2016-02-02
2017-02-07
International Business Machines Corporation
System and method for generating a server-assisted strong password from a weak secret
US20180288022A1
( en )
*
2017-03-31
2018-10-04
Dr. Vijay Madisetti
Method and System for Identity and Access Management for Blockchain Interoperability
US20200059364A1
( en )
*
2018-08-18
2020-02-20
Eygs Llp
Methods and systems for implementing zero-knowledge proofs in transferring partitioned tokens on distributed ledger-based networks
US11528141B2
( en )
*
2018-08-18
2022-12-13
Eygs Llp
Methods and systems for enhancing privacy and efficiency on distributed ledger-based networks
US10402823B1
( en )
*
2018-12-30
2019-09-03
Alexander Vladimirovich Vlasov
System for exchanging private keys for mutual settlements between users of a cryptocurrency outside blockchains
US20200328893A1
( en )
*
2019-04-15
2020-10-15
Eygs Llp
Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US11316691B2
( en )
*
2019-04-15
2022-04-26
Eygs Llp
Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US20220335422A1
( en )
*
2020-12-15
2022-10-20
MatterFi
Crypto currency hardware wallet
Non-Patent Citations (20)
* Cited by examiner, â Cited by third party
Title
Amir Taaki, BIP 0033, May 15, 2012, Bitcoin Wiki,https://en.bitcoin.it/wiki/BIP_0033. (Year: 2012).
*
Andrey Sergeenkov, Reusable Payment Codesâthe Secret Ingredient to a User-Friendly Crypto Wallet, Nov. 23, 2018. (Year: 2018).
*
Ben Laurie. " Lucre: Anonymous Electronic Tokens v1.8. Technical report 1999, 2008, ".
Bill St. Clair, " Truledger in Plain English, 2008. " [retrieved on Jan. 24, 202] Retrieved from the Internet: <URL:https://nakamotoinstitute.org/truledger/>.
Chris Odom, " Triple Signed Receipts 2010, " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:http://opentransactions.org/wiki/index.php? title=Triple-Signed_Receipts.>.
Chris Odom.," Open-Transactions: Secure Contracts between Untrusted Parties 2010, " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:http: //www.opentransactions.org/open-transactions.pdf.>.
David Chaum, R.L Rivest, A.T Sherman " Blind Signatures for Untraceable Payments ", Advances in Cryptology Proceedings of Crypto 82, pp. 199-203, 1983.
Ian Grigg, " The Ricardian Contract. " Proceedings of IEEE Workshop on Electronic Contracting Jul. 6, pp. 25-31, 2004.
Ian Grigg, " Triple Entry Accounting 2005, " [retrieved on Jan. 24, 2022]. Retrieved from the Internet: <URL:http://iang.org/papers/triple_entry.html.>.
John Galt, Open Bitcoin Privacy Project Ranks Winners and Losers for Wallet Privacy, May 20, 2015, Bitcoin Magazine. (Year: 2015).
*
Jonaldfyookball, James Cramer, Unwriter, Mark B. Lundeberg, Calin Culianu, and Ryan X. Charles, " SLP Token Type 1 Protocol Specification 2018, " [retrieved on Jan. 23, 2022]. Retrieved from the internet: <URL:https://github.com/simpleledger/slp-specifications/blob/master/slp-token-type-1.md>.
Justus Ranvier, " BIP-47 Specification 2015, " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:https://github.com/bitcoin/bips/pull/159.>.
Justus Ranvier, " Payment Codes, " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:https://www.reddit.com/r/Bitcoin/comments/3alzga/ bip47_reusable_payment_codes/.>.
Justus Ranvier, " Voting Pool Deposit Process. " [retrieved on Jan. 24, 2022]. Retrieved from the Internet: <URL:http://opentransactions.org/wiki/index.php/Voting_Pool_Deposit_Process.>.
Justus Ranvier, " Voting Pool Withdrawal Process. " [retreived on Jan. 23, 2022]. Retrieved from the Internet: <URL:http://opentransactions.org/wiki/index.php/Voting_Pool_Withdrawal_Process.>.
Justus Ranvier, " Voting Pools. " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:http://opentransactions.org/wiki/index.php/Voting_Pools>.
Justus Ranvier, Jimmy Song, " Hierarchy for Colored Voting Pool Deterministic Multisig Wallets. " [retrieved on Jan. 24, 2022]. Retrieved from the Internet: <URL:https://github.com/Open-Transactions/rfc/blob/master/bips/bip-vpc01.mediawiki>.
Justus Ranvier, Jimmy Song, " Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets. " [retrieved on Jan. 24, 2022]. Retrieved from the Internet: <URL:https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki>.
Matt B, BIP47: Reusable Payment Codes for Hierarchial Deterministic Wallets, Mar. 27, 2019, Medium. (Year: 2019).
*
Satoshi Nakamoto, " Bitcoin: A peer-to-peer electronic cash system 2008, " [retrieved on Jan. 23, 2022]. Retrieved from the Internet: <URL:http://bitcoin.org/ bitcoin.pdf.>.
Cited By (1)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20240273515A1
( en )
*
2023-01-23
2024-08-15
Dos Centavos, Llc
COMPUTER METHOD FOR SIMPLIFIED CREATION OF NFTs
Also Published As
Publication number
Publication date
US20220253813A1
( en )
2022-08-11
Similar Documents
Publication
Publication Date
Title
US20220253813A1
( en )
2022-08-11
Cryptographicaly secured hybrid (on and off blockchain) cryptocurrency system
US20230267458A1
( en )
2023-08-24
Secure transaction controller for value token exchange systems
US11720887B1
( en )
2023-08-08
System, method and program product for depositing and withdrawing stable value digital assets in exchange for fiat
US20240104521A1
( en )
2024-03-28
System and method for compliance-enabled digitally represented assets
US11562333B1
( en )
2023-01-24
System, method and program product for generating and utilizing stable value digital assets
US20230020084A1
( en )
2023-01-19
Digital value token processing systems and methods having improved security and scalability
US11475442B1
( en )
2022-10-18
System, method and program product for modifying a supply of stable value digital asset tokens
US10540653B1
( en )
2020-01-21
System, method and program product for modifying a supply of stable value digital asset tokens
US11880836B1
( en )
2024-01-23
Gated control for blockchain units
US20220084013A1
( en )
2022-03-17
Identity management, smart contract generator, and blockchain mediating system, and related methods
US20220172198A1
( en )
2022-06-02
Real-time blockchain settlement network
CN117151853A
( en )
2023-12-01
Method for secure point-to-point communication on a blockchain
WO2024076387A1
( en )
2024-04-11
Gated control for blockchain units
Ji et al.
2021
Generalized proof of liabilities
Dold
2019
The GNU Taler system: practical and provably secure electronic payments
Sarencheh et al.
2024
Parscoin: A privacy-preserving, auditable, and regulation-friendly stablecoin
Michalopoulos et al.
2025
Privacy and compliance design options in offline central bank digital currencies
US12627517B2
( en )
2026-05-12
Systems and methods for performing secure transactions on blockchain
Gross et al.
2022
How to design a compliant, privacy-preserving fiat stablecoin via zero-knowledge proofs
US20240249275A1
( en )
2024-07-25
Group signatures for a smart wallet on a blockchain platform
Masseport et al.
2020
Proof of usage: User-centric consensus for data provision and exchange
McCorry
2018
Applications of the Blockchain using Cryptography
Senthilkumar
2019
Data confidentiality, integrity, and authentication
Odom
2022
MatterFI TM: Powering a comprehensive solution for blockchain-based financial instruments
Liu et al.
2026
ARC-CBDC: Enhancing Anonymity and Regulatory Compliance in Central Bank Digital Currency
Legal Events
Date
Code
Title
Description
2022-01-24
FEPP
Fee payment procedure
Free format text : ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY
2022-02-01
FEPP
Fee payment procedure
Free format text : ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY
2022-02-24
AS
Assignment
Owner name : MATTERFI, WYOMING
Free format text : ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:POSPIESZALSKI, MICHAL;REEL/FRAME:059084/0530
Effective date : 20220223
2022-05-25
STPP
Information on status: patent application and granting procedure in general
Free format text : DOCKETED NEW CASE - READY FOR EXAMINATION
2023-06-22
STPP
Information on status: patent application and granting procedure in general
Free format text : NON FINAL ACTION MAILED
2024-01-09
STPP
Information on status: patent application and granting procedure in general
Free format text : NON FINAL ACTION MAILED
2024-10-07
STPP
Information on status: patent application and granting procedure in general
Free format text : RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER
2024-10-21
STPP
Information on status: patent application and granting procedure in general
Free format text : FINAL REJECTION MAILED
2025-05-09
STPP
Information on status: patent application and granting procedure in general
Free format text : NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS
2025-08-13
STPP
Information on status: patent application and granting procedure in general
Free format text : PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED
2025-08-14
STPP
Information on status: patent application and granting procedure in general
Free format text : PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED
2025-08-27
STCF
Information on status: patent grant
Free format text : PATENTED CASE