Method and system for providing offline transactions for digital currency

Abstract

A method for processing an offline blockchain transaction includes generating an initiation message by a first device, sending the initiation message by the first device to a second device, receiving by the first device from the second device a handshake message including a certificate and a recipient's public key, verifying the handshake message by the first device, generating by the first device a payment message including transfer data, the transfer data including a data value for the proposed blockchain transaction, sending by the first device the generated payment message to the second device, receiving by the first device an acceptance message from the second device including a digital signature of the transfer data, and verifying by the first device the digital signature of the transfer data using at least the recipient's public key.

Description

[Technical field]

[0001] The present disclosure relates to providing offline transactions for digital currency, and in particular to enabling offline blockchain transactions in a secure manner using standardized processes.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Patent Application No. 17 / 556,381, filed December 20, 2021, the entire contents of which are incorporated by reference for all purposes. [Background technology]

[0003] Blockchain was initially created as a storage mechanism used to make payment transactions using cryptocurrencies. Its use offers several advantages such as decentralization, distributed computing, and transaction transparency, while providing anonymity for the individuals or entities involved in the transaction. A relatively favorable property of blockchain is the immutability of its records: all transactions made part of the chain are stored and are immutable due to the computational power and bandwidth limitations required, especially as the chain grows and the blockchain network adds more nodes.

[0004] However, in traditional blockchains, for a transaction to be a valid transfer, every transaction must be submitted to a node, verified, and included in a new block that is successfully added to the chain. In order to use the newly acquired cryptocurrency, the transferee must wait for the transaction to be posted to the blockchain. Not only can this process be time-consuming, but it also requires that both parties to the transaction have an active connection to a blockchain node. There can be many scenarios in which both parties want to transfer cryptocurrency even if they lack sufficient connectivity to a blockchain node (i.e., they are offline). In existing blockchain systems, such transfers are not possible.

[0005] Therefore, there is a need for a technical solution that allows cryptocurrency transfers to be performed offline without sacrificing the security, immutability, and privacy of the blockchain. Summary of the Invention

[0006] This disclosure provides a description of a system and method for processing standardized offline blockchain transactions. A sender computing device and a recipient computing device, each having a blockchain wallet, exchange a series of messages to accomplish the offline blockchain transaction. Both devices use elliptic curve cryptography or another suitable technique to encrypt the data exchanged via the messages. By using references in the messages and proceeding with a known message order, both devices can securely and accurately exchange all information, thereby adequately ensuring that the offline blockchain transaction is completed securely and without the possibility of double spend. The sender computing device begins by sending an initiate message to the recipient computing device, to which the recipient computing device responds with a handshake message, which establishes the data necessary to utilize elliptic curve cryptography. The sender computing device responds with a pay message, which includes encrypted transfer data for the desired blockchain transaction. The recipient computing device receives the pay message, decrypts the transfer data, verifies that the transfer data is accurate, and also responds with an accept message. The sender's computing device receives the accept message, stores the transferred data in a local data store to ensure the transaction is properly accounted for, and provides an accepted message to the recipient's computing device, which can then update its local data store with the transferred data, resulting in a secure and verifiable offline blockchain transaction that can be correctly added to the blockchain once a connection to a blockchain node is established.

[0007] A method for processing standardized offline blockchain transactions includes the steps of: generating, by a processor of a first computing device, an initiation message; transmitting, by a transmitter of the first computing device, the initiation message to a second computing device; receiving, by a receiver of the first computing device, a handshake message from the second computing device, the handshake message including at least a certificate and a receiver's public key; and verifying, by the processor of the first computing device, the handshake message, the handshake message including at least verifying the certificate using a chain of certificates. generating, by the processor of the first computing device, a payment message including transfer data, the transfer data including one or more data values ​​for a proposed blockchain transaction; transmitting, by the transmitter of the first computing device, the generated payment message to the second computing device; receiving, by the receiver of the first computing device, an acceptance message from the second computing device, the acceptance message including a digital signature of the transfer data; and verifying, by the processor of the first computing device, the digital signature of the transfer data using at least the public key of the receiver.

[0008] A system for processing standardized offline blockchain transactions includes: a first computing device including at least a receiver, a processor, and a transmitter; and a second computing device, wherein the processor of the first computing device generates an initiation message, the transmitter of the first computing device transmits the initiation message to the second computing device, and the receiver of the first computing device receives a handshake message from the second computing device, the handshake message including at least a certificate and a recipient's public key, and the processor of the first computing device verifies the handshake message, and generating a payment message, the payment message including transfer data, the transfer data including one or more data values ​​for a proposed blockchain transaction, wherein the transmitter of the first computing device sends the generated payment message to the second computing device and the receiver of the first computing device receives an acceptance message from the second computing device, the acceptance message including at least a digital signature of the transfer data, and the processor of the first computing device verifies the digital signature of the transfer data using at least the public key of the receiver. [Brief description of the drawings]

[0009] The scope of the present disclosure is best understood from the following detailed description of illustrative embodiments when taken in conjunction with the accompanying drawing figures, which include:

[0010] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for processing standardized offline blockchain transactions, according to an example embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating a computing device for processing standardized offline blockchain transactions of the system of FIG. 1 in accordance with an exemplary embodiment. [Figure 3A] 2 is a flow diagram illustrating a process for processing standardized offline blockchain transactions in the system of FIG. 1 according to an example embodiment. [Figure 3B] 2 is a flow diagram illustrating a process for processing standardized offline blockchain transactions in the system of FIG. 1 according to an example embodiment. [Figure 3C] 2 is a flow diagram illustrating a process for processing standardized offline blockchain transactions in the system of FIG. 1 according to an example embodiment. [Figure 4] 1 is a flow diagram illustrating an example method for processing standardized offline blockchain transactions, according to an example embodiment. [Diagram 5] FIG. 1 is a block diagram illustrating a computer system architecture, in accordance with an exemplary embodiment.

[0011] Further areas of applicability of the present disclosure will become apparent from the following detailed description. The detailed description of the exemplary embodiments is intended for purposes of illustration only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] A system for processing standardized offline blockchain transactions FIG. 1 illustrates a system 100 that enables secure and successful processing of offline blockchain transactions using encrypted and standardized messaging.

[0013] The system 100 supports offline blockchain transactions between two computing devices, a sender computing device 102 and a receiver computing device 104. Each computing device can be any type of device suitable for performing the functions referred to herein, such as a desktop computer, a laptop computer, a tablet computer, a notebook computer, a mobile phone, a smartphone, a smart watch, a smart TV, a wearable computing device, etc.

[0014] Prior to participating in an offline blockchain transaction, the sender computing device 102 and the recipient computing device 104 can be provided with certificates by a provisioning system 106. The provisioning system 106 can be an authorized entity configured to provide certificates to devices that are authorized to participate in offline blockchain transactions. The provisioning system 106 can verify the authorization status of a computing device and provide it with a certificate, which or data associated therewith is stored in a certificate chain. The provisioning system 106 can transmit the certificate chain to each computing device or make the certificate chain available for use by each computing device. A computing device can use the certificate chain to verify the authenticity of the provided certificate and verify that another computing device is authorized to participate in an offline blockchain transaction. Additional data regarding the use and validation of certificates can be found in U.S. patent application Ser. No. 16 / 509,765, filed July 12, 2019, entitled “Method and System for Secure and Verifiable Offline Blockchain Transactions”, Stephen Higgins, which is incorporated herein by reference in its entirety.

[0015] In the system 100, a sender computing device 102 may be interested in sending digital currency to a receiver computing device 104 through an offline blockchain transaction, which is recorded in the blockchain. The blockchain may be associated with a blockchain network 108. The blockchain network 108 may be comprised of a number of blockchain nodes 110. Each blockchain node 110 may be a computing system as shown in FIG. 2 or FIG. 5 and described in more detail below, configured to perform functions related to blockchain processing and management, which may include, for example: generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, verifying new blocks, and maintaining a copy of the blockchain. In some embodiments, the provisioning system 106 may be a blockchain node 110.

[0016] A blockchain may be a distributed ledger that includes at least a number of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header is generated and may be expressed using any suitable method (e.g., UNIX timestamp, DateTime notation, etc.). The block reference value may be a value that references (e.g., based on the timestamp) a preceding block in the blockchain. In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding each block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. Similarly, the data reference value may be a reference to one or more data values ​​stored in the block that includes the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0017] As a result of using a block reference value and a data reference value in each block header, the blockchain can be given immutability. Any attempt to change the data value requires the generation of a new data reference value for the block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of a new block reference value for each subsequent block. To make the change permanent, the above must be performed and updated for every single blockchain node 110 in the blockchain network 108 before a new block is created and added to the blockchain. Computing and communication capacity limitations can make such changes extremely difficult or impossible, and thus the blockchain achieves immutability.

[0018] In some embodiments, a blockchain can be used to store information about blockchain transactions made between two different blockchain wallets. A blockchain wallet can contain a private key of a cryptographic key pair that is used to generate a digital signature that serves as the payer's authorization for the blockchain transaction. The digital signature can be verified by the blockchain network 108 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" can refer specifically to a private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., sender computing device 102, recipient computing device 104, etc.) that stores a private key for use in blockchain transactions. For example, each computing device can have its own private key for each cryptographic key pair and each can be a blockchain wallet for use in transactions with a blockchain associated with the blockchain network. The computing device can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile phone, a smartphone, a smart watch, a smart TV, a wearable computing device, an embeddable computing device, etc.

[0019] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or storage of other data, if applicable. A blockchain transaction may comprise at least the following: a digital signature of the sender of the currency (e.g., the sender's computing device 102) generated using the sender's private key, a blockchain address of the recipient of the currency (e.g., the recipient's computing device 104) generated using the recipient's public key, and the amount of blockchain currency to be transferred or other data to be stored. In some blockchain transactions, the transaction may also include: one or more sender's blockchain addresses where the blockchain currency is currently stored (e.g., if the digital signature demonstrates access to such currency); and an address for any changes to be held by the sender, generated using the sender's public key. Addresses to which cryptocurrency that can be used in future transactions is sent are referred to as "output" addresses because each address was previously used to capture the output of a previous blockchain transaction, and are also referred to as "unspent transactions" because there is currency sent to the address in a previous transaction where that currency has not yet been spent. In some cases, a blockchain transaction may also include the sender's public key for use by an entity in verifying the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the recipient to a blockchain node 110 in the blockchain network 108. The node can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and can verify access to the sender's funds (e.g., if an unspent transaction has not yet been spent and was sent to an address associated with the sender's wallet), a process known as "confirming" the transaction, and the node can then include the blockchain transaction in a new block.In a traditional blockchain implementation, a new block may be verified by other nodes in the blockchain network 108 before being added to the blockchain and distributed to all blockchain nodes 110 in the blockchain network 108. If the blockchain data value does not relate to a blockchain transaction but instead relates to the storage of other types of data, the blockchain data value may still include or involve verification of a digital signature.

[0020] In the system 100, the sender computing device 102 and the recipient computing device 104 can each establish a communication channel with the provisioning system 106 and can request a certificate and a certificate chain from the system using an appropriate method, such as via a web page, an application program, an application programming interface, etc. The provisioning system 106 can generate a certificate for each device and send the certificate and the certificate chain to them. In some cases, the provisioning system 106 can first verify the device's authorization and capability for offline blockchain transactions before providing the certificate. For example, the provisioning system 106 can request the sender computing device 102 to digitally sign a local data store of available digital currency in its blockchain wallet (e.g., with the sender's private key (referred to as the "sender's wallet private key") of its blockchain wallet) and send the signed data to the provisioning system 106. The provisioning system 106 can verify the digital signature using the sender's wallet public key and can verify that the data store is correct, such as by verifying any digital signatures, blockchain addresses, digital currency amounts, etc. contained therein. In another example, the provisioning system 106 can request an attestation from the sender's computing device 102 to ensure the authenticity of the sender's computing device 102 and the use of genuine hardware. Upon successful verification, the provisioning system 106 can generate a certificate for the sender's computing device 102, add appropriate data to the certificate chain, and provide the certificate and updated certificate chain to the sender's computing device.

[0021] Once both the sender computing device 102 and the recipient computing device 104 have received the certificate and are ready for the offline blockchain transaction, the sender computing device 102 can generate an initiation message. The initiation message can be a message indicating that the sender computing device 102 is ready and interested in an offline blockchain transaction that transfers digital currency from a blockchain wallet of the sender computing device to a blockchain wallet of the recipient computing device. In some embodiments, the initiation message can include authentication information associated with the blockchain wallet for validation by the sender computing device 102 or the recipient computing device 104. For example, the initiation message can include a certificate provided by the provisioning system 106.

[0022] The sender computing device 102 can electronically send an initiation message to the recipient computing device 104 using an appropriate communication network and method. The recipient computing device 104 can receive the initiation message and determine, for example, based on a user command, whether it is interested in proceeding with an offline blockchain transaction with the sender computing device 102. If the initiation message includes authentication information, the recipient computing device 104 can first verify the authentication information before proceeding, for example, by checking a provided provisioned certificate against a chain of certificates provided by the provisioning system 106. If the recipient computing device 104 wants to proceed with the transaction, it can generate a handshake message.

[0023] The handshake message may include the recipient's computing device's certificate provided by the provisioning system 106 and the recipient's shared public key. The recipient's shared public key may be the public key of a cryptographic key pair generated by the recipient's computing device 104 for use in establishing a shared secret with the sender's computing device 102, and may be used to encrypt and decrypt data exchanged between the two computing devices, for example, using elliptic curve cryptography. The keys used for the shared secret are referred to herein as the "shared" public and private keys. As part of the generation of the handshake message, the recipient's computing device 104 may digitally sign the certificate and the recipient's shared public key. The digital signature may be generated using the recipient's wallet private key or, if different, the private key corresponding to the provided certificate. In the latter case, the corresponding public key may be included in the certificate itself.

[0024] The recipient computing device 104 can electronically transmit the handshake message to the sender computing device 102 using an appropriate communication network and method. The sender computing device 102 can receive the handshake message and verify the data contained within the message. The sender computing device 102 can verify the digital signature using an appropriate public key, such as the recipient's wallet public key (e.g., sent with the handshake message, in the handshake message, or in a separate transmission) or a public key contained within the certificate. The sender computing device 102 can also verify the provided certificate itself using a chain of certificates received from the provisioning system 106. If any verification fails, the sender computing device 102 can refuse to participate in the transaction, which may be done to avoid potential fraudulent activities that may be committed by a rogue computing device, etc. If any verification is successful, the sender computing device 102 can proceed to generate a payment message for the offline blockchain transaction.

[0025] To include the payment message, the sender's computing device 102 can generate transfer data. The transfer data can include one or more messages corresponding to one or more blockchain transactions that affect the transfer of digital currency desired by the sender's computing device 102. Each message can include, for example, the following: a destination blockchain address (e.g., generated via the recipient's wallet public key), a digital signature (e.g., generated via the sender's wallet private key), one or more unspent transaction outputs, and a digital currency amount. The sender's computing device 102 can then encrypt the transfer data before including it in the payment message. To encrypt the transfer data, the sender's computing device 102 can generate a symmetric key. The sender's computing device 102 can generate a cryptographic key pair for use in elliptic curve cryptography or other suitable methods, where the cryptographic key pair includes the sender's shared private key and the sender's shared public key. The sender's shared public key can be included in the payment message. The sender's computing device 102 can generate the symmetric key using its sender's shared private key and the recipient's shared public key, for example, using elliptic curve cryptography. The symmetric key can be used by the sender's computing device 102 to encrypt the transfer data before including it in the payment message.

[0026] In addition to the encrypted transfer data and the sender's shared public key, the payment message may also include a reference value that can be used by the recipient's computing device 104 to ensure that the payment message is part of an expected transaction. The reference value may be any suitable value. In one embodiment, the sender's computing device 102 may generate the reference value via hashing the recipient's shared public key using a suitable hashing algorithm. The sender's computing device 102 may also digitally sign some (e.g., the encrypted transfer data and the sender's shared public key) or all of the data in the payment message using the sender's shared private key. The sender's computing device 102 may electronically transmit the payment message to the recipient's computing device 104 using a suitable communication network and method.

[0027] The recipient computing device 104 can receive the payment message and can also verify the data contained therein. The recipient computing device 104 can verify the reference value by hashing its recipient shared public key and matching the generated value with the reference value contained in the payment message. The recipient computing device 104 can verify the digital signature on the data in the payment message using the sender shared public key contained in the payment message. If either verification fails, the recipient computing device 104 can refuse further participation in the offline blockchain transaction. If either verification succeeds, the recipient computing device 104 can decrypt the transfer data. The recipient computing device 104 can generate its own symmetric key using the recipient shared private key and the provided sender shared public key, for example using elliptic curve cryptography or other suitable methods. The recipient computing device 104 can decrypt the transfer data using the generated symmetric key. The recipient computing device 104 can then verify the transfer data, for example by verifying the digital signature. This ensures that the unspent transaction output has enough digital currency, ensures that the destination blockchain address is correct, ensures that the digital currency amount is appropriate, etc. If any of the transfer data is incorrect, the recipient computing device 104 can refuse further participation or can appropriately notify and ask the sender computing device 102 to generate a new payment message.

[0028] If the transfer data is accurate and acceptable, the recipient's computing device 104 can generate an acceptance message. The acceptance message can include at least a reference value, which can be a hash of the sender's shared public key. In some embodiments, the acceptance message can also include a digital signature, which can be of the sender's shared public key, which is also included in the acceptance message, which can be generated using the recipient's shared private key. In some cases, the acceptance message can also include the decrypted transfer data, which can also be digitally signed using the recipient's shared private key. In some cases, the acceptance message can include a digital signature for the decrypted transfer data without including the decrypted transfer data itself. In some cases, the acceptance message can include a hash for the decrypted transfer data. The recipient's computing device 104 can then electronically transmit the acceptance message to the sender's computing device 102.

[0029] The sender's computing device 102 can receive the acceptance message and can verify the data contained therein. The sender's computing device 102 can verify the reference value by hashing its sender's shared public key and matching the generated value with the reference value contained in the acceptance message. The sender's computing device 102 can also verify the digital signature, such as by using a previously received recipient's shared public key (e.g., in a handshake message). If the acceptance message includes the decrypted transfer data, the sender's computing device 102 can also verify that the transfer data included in the acceptance message matches the previously generated transfer data. If the acceptance message includes a hash for the decrypted transfer data, the sender's computing device 102 can verify the hash by hashing the previously generated transfer data and matching it with the hash value included in the acceptance message. If any verification fails, the sender's computing device 102 can stop the transaction process. If the verification is successful, the sender computing device 102 stores the transfer data in a local data store and applies the transfer data to the device's blockchain wallet accordingly, for example by updating the state of unspent transaction outputs, the amount of available digital currency, etc. After such storage and updates have been made, the sender computing device 102 can consider the digital currency to have been transferred and can prevent any other transfers from occurring, preventing any double-spending with respect to the associated digital currency.

[0030] The sender's computing device 102 can then generate an accepted message. The accepted message can include at least a reference value, which can be a hash of the recipient's shared public key. The accepted message can also include an accepted message that is digitally signed by the sender's computing device 102 using the sender's shared private key. The sender's computing device 102 can electronically transmit the accepted message to the recipient's computing device 104 using an appropriate communications network and method.

[0031] The recipient computing device 104 can receive the accepted message and can verify the data contained therein. The recipient computing device 104 can verify the reference value by hashing its recipient's shared public key and matching the generated value with the reference value contained in the accepted message. The recipient computing device 104 can also verify the digital signature on the accepted message using the sender's shared public key. If any verification fails, the recipient computing device 104 can refuse further participation in offline blockchain transactions. If the verification is successful, the recipient computing device can store the transfer data in a local data store and can appropriately apply the transfer data to data related to the device's blockchain wallet, for example by updating the status of unspent transaction outputs, amount of available digital currency, etc. After such storage and updating, the recipient computing device 102 can consider the received digital currency available for use in future offline blockchain transactions. The offline blockchain transaction between the sender computing device 102 and the recipient computing device 104 can then be considered completed.

[0032] The next time any device establishes communication with the blockchain node 110, it can electronically transmit the transfer data to the blockchain node 110 using an appropriate communication network and method. The blockchain node 110 can verify the transfer data and include the transfer data in the blockchain as a new blockchain transaction by including the transfer data in one or more new blockchain data values ​​contained in one or more new blocks that have been verified and confirmed by a majority of the blockchain nodes 110 in the blockchain network 108.

[0033] In some embodiments, the sender computing device 102 and the recipient computing device 104 may discard any received messages that were not expected. For example, when processing begins (e.g., when the recipient computing device 104 sends a handshake message to the sender computing device 102), each computing device may discard any messages that were not expected based on the known message order as described above. For example, after the sender computing device 102 sends a payment message to the recipient computing device 104, the sender computing device 102 may discard any messages received from the recipient computing device 104 or other computing devices that are not an acceptance (or rejection, as described below) message from the recipient computing device 104. Such discarding of messages ensures that offline blockchain transactions are completed completely and in the correct order, preventing double spending or any inconsistencies between devices. In some cases, a computing device may notify other devices involved in the transaction if a received message was discarded, which may, for example, give the other devices an opportunity to generate and send an appropriate message. In some cases, the sender computing device 102 and the recipient computing device 104 may repeatedly send messages based on the current step of the transaction and may continue to send copies of the message until the next appropriate message is received from the other device. In such cases, the sender computing device 102 and the recipient computing device 104 may be prevented from skipping ahead in the transaction processing, ensuring that the other devices receive all necessary messages for the transaction.In such a case, when the sender's computing device 102 or the recipient's computing device 104 receives the message, it may take the necessary actions as described above when it receives the first copy of the message, and may not take any action when it receives subsequent copies of the message.

[0034] If one of the computing devices involved in an offline blockchain transaction wishes to cancel the transaction, the computing device can generate a cancel message, also referred to as a reject message. A computing device may seek to cancel a transaction due to a failed validation, a missed message, a message sent out of sequence, intervention by a user of the computing device, etc. The cancel message may be generated by the computing device and includes a reference value (generated by hashing the shared public key of the other computing device) and a digital signature generated on the symmetric key. The digital signature is generated using the shared private key of the device. The cancel message may be sent to the other device, which may verify both the reference value and the digital signature. The device may also verify the symmetric key by matching it with its own symmetric key. Once all values ​​are verified, the device may clear its current transaction. In some cases, the cancel message may refer to an instruction entered by a user of the device to cancel the transaction, while the reject message may refer to a message sent from one device to another to cancel the transaction.

[0035] To clear a transaction, the sender computing device 102 or the recipient computing device 104, as applicable, can delete all transfer data, shared public keys, shared private keys, symmetric keys, and any other data associated with the canceled transaction. The sender computing device 102 can also clear any message queues, such as a queue of all messages received for the transaction. In some cases, once a transaction is completed, a clearing action can be performed by the sender computing device 102 or the recipient computing device 104, for example, to ensure deletion of messages, keys, and other data associated with the completed transaction.

[0036] In some embodiments, the initiation message can include a public key generated by the sender computing device 102 for use in generating a reference for the transaction, referred to herein as the transaction public key. The sender computing device 102 and the recipient computing device 104 can use the transaction public key to generate or derive a reference value, such as a session identifier or transaction number, that can be included in one or more messages sent between the sender computing device 102 and the recipient computing device 104. This can, for example, ensure that a message is coming from an expected computing device.

[0037] The methods and systems described herein provide for offline blockchain transactions between two computing devices. Standardized messages sent and received in a known order can be used to prevent double spending of digital currency. Shared secrets, hashed references, and other techniques discussed above can be used to allow offline blockchain transactions to be safe and secure, even if communications are intercepted or viewed by other devices. As a result, the methods and systems disclosed herein provide greater versatility in offline blockchain transactions than existing systems due to the technological advances they leverage.

[0038] Computing Device FIG. 2 illustrates an embodiment of a sender computing device 102. It will be apparent to those skilled in the art that the embodiment of the sender computing device 102 illustrated in FIG. 2 is provided for illustrative purposes only and is not an exhaustive list of all possible configurations of a sender computing device 102 suitable for performing the functions of the present disclosure. For example, computer system 500 illustrated in FIG. 5 and described in more detail below may be a suitable configuration of a sender computing device 102. The sender computing device 102 can also be utilized as a recipient computing device 104 in an offline blockchain transaction. Similarly, the recipient computing device 104 in the system 100 can also be utilized as a sender computing device 102 in an offline blockchain transaction.

[0039] The sender computing device 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiving device 202 may be configured to receive data from other sender computing devices 102, recipient computing devices 104, provisioning systems 106, blockchain nodes 110, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communications networks, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 may include multiple devices (e.g., different receiving devices receiving data over different networks, such as a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet). The receiving device 202 may receive the transmitted electronic data signal. Then, upon receipt of the data signal by the receiving device 202, data may be superimposed on the data signal and decoded, parsed, read, or retrieved. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain data overlaid thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert the received data signal into usable input for functions performed by the processing device to implement the methods and systems of the present disclosure.

[0040] The receiving device 202 can be configured to receive data signals transmitted electronically by other sender computing devices 102 or recipient computing devices 104, which may be superimposed or encoded with initiation messages, handshake messages, payment messages, acceptance messages, accepted messages, cancellation messages, rejection messages, and clear messages. Such messages may include reference values, public keys, symmetric keys, encrypted data, decrypted data, certificates, other messages, and digital signatures as described above. The receiving device 202 can also be configured to receive data signals transmitted electronically by the provisioning system 106, which may be superimposed or encoded with certificates and certificate chains. The receiving device 202 can be configured to receive data signals transmitted electronically by the blockchain node 110, which may be superimposed or encoded with blockchain data values, blocks, notification messages, public keys, and the like.

[0041] The sender computing device 102 may also include a communications module 204. The communications module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the sender computing device 102 for use in performing the functions of the present disclosure. The communications module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, the communications module 204 may include a bus, a connection pin connector, wires, etc. In some embodiments, the communications module 204 may also be configured to communicate between internal components of the sender computing device 102 and external components of the sender computing device 102 (e.g., an externally connected database, a display device, an input device, etc.). The sender computing device 102 may also include a processing device. The processing device may be configured to perform the functions of the sender computing device 102 of the present disclosure. This will be apparent to those skilled in the art. In some embodiments, the processing device may include multiple engines and / or modules (e.g., query module 216, generation module 218, validation module 220, etc.) that are specifically configured to perform one or more functions of the processing device. As disclosed herein, the term "module" may refer to software or hardware that is specifically programmed to receive input, perform one or more operations using the input, and provide output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0042] The sender's computing device 102 may include wallet data 206. The wallet data 206 may be configured to store data associated with blockchain wallets and offline blockchain transactions using a suitable data storage format and schema. The wallet data 206 may be stored in a relational database using a structured query language to store, identify, modify, update, access, etc., stored structured data sets. The wallet data 206 may include, for example: cryptographic key pairs, unspent transaction outputs, digital signatures, blockchain addresses, digital currency amounts, offered certificates, chains of certificates, message queues for messages, symmetric keys, transfer data, etc.

[0043] The sender computing device 102 may also include memory 214. The memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the sender computing device 102 in performing the functions of the present disclosure. The memory 214 may be configured to store data using appropriate data formatting methods and schemas and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). The memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs for the processing unit, and other appropriate data used by the sender computing device 102 in performing the functions of the present disclosure. This will be apparent to those of skill in the art upon reading this disclosure. In some embodiments, the memory 214 may consist of or include a relational database that uses Structured Query Language (SQL) to store, identify, modify, update, access, etc., stored structured data sets. The memory 214 may be configured to store, for example, cryptographic keys, cryptographic key pairs, cryptographic algorithms, encryption algorithms, communication information, data formatting rules, blockchain data, signature generation algorithms, and the like.

[0044] The sender computing device 102 may also include a query module 216. The query module 216 may be configured to perform a query on a database to identify information. The query module 216 may receive one or more data values ​​or query strings and based thereon may perform a query string on an indicated database (e.g., memory 214 of the sender computing device 102) to identify information stored therein. The query module 216 may then output the identified information to an appropriate engine or module of the sender computing device 102 as needed. The query module 216 may, for example, perform a query on the wallet data 206 to identify a shared public key for generating a hash value to match a reference value in a received message.

[0045] The sender computing device 102 may also include a generation module 218. The generation module 218 may be configured to generate data for use by the sender computing device 102 in performing functions of the present disclosure. The generation module 218 may receive instructions as input, generate data based on the instructions, and output the generated data to one or more modules of the sender computing device 102. For example, the generation module 218 may be configured to generate an initiation message, a handshake message, a payment message, an acceptance message, an accepted message, a cancellation or rejection message, a clear message, a digital signature, transfer data, a reference value, a cryptographic key pair, a symmetric key, etc.

[0046] The sender computing device 102 may also include a verification module 220. The verification module 220 may be configured to perform verification on the sender computing device 102 as part of the functionality of the present disclosure. The verification module 220 may receive instructions as input (which may also include data used to perform the verification), perform the verification as requested, and output the results of the verification to another module or engine of the sender computing device 102. The verification module 220 may be configured to verify, for example, certificates, digital signatures, reference values, transfer data, message ordering, etc.

[0047] The sender computing device 102 may also include a transmitting device 222. The transmitting device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 222 may be configured to transmit data to other sender computing devices 102, recipient computing devices 104, provisioning systems 106, blockchain nodes 110, and other systems and entities via one or more communication methods, such as a local area network, a wireless area network, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmitting device 222 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks (e.g., a first transmitting device transmitting data over a local area network and a second transmitting device transmitting data over the Internet)). The transmitting device 222 may electronically transmit a data signal with the superimposed data, the data being analyzed by the receiving computing device. In some embodiments, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting data into a data signal suitable for transmission.

[0048] The sending device 222 can be configured to electronically send data signals to other sender computing devices 102 and recipient computing devices 104, which may be superimposed or encoded with initiation messages, handshake messages, payment messages, acceptance messages, accepted messages, cancellation messages, rejection messages, and clear messages. Such messages may include reference values, public keys, symmetric keys, encrypted data, decrypted data, certificates, other messages, and digital signatures as described above. The sending device 222 can also be configured to electronically send data signals to the provisioning system 106, which may be superimposed or encoded with requests for certificates and / or certificate chains. The sending device 222 can also be configured to electronically send data signals to the blockchain node 110, which may be superimposed or encoded with transfer data for new blockchain transactions.

[0049] Processing Methods for Offline Blockchain Transactions 3A-3C illustrate a process for an offline blockchain transaction between a sender computing device 102 and a recipient computing device 104 in the system 100 of FIG. 1 using standardized, sequenced messaging.

[0050] At S302, the generation module 218 of the sender computing device 102 may generate an initiation message to initiate an offline blockchain transaction with the recipient computing device 104. The initiation message may include information regarding the desired digital currency transfer, such as the amount of the digital currency. At S304, the sending device 222 of the sender computing device 102 may electronically transmit the initiation message to the recipient computing device 104 using an appropriate communication network and method. At S306, the receiving device 202 of the recipient computing device 104 may receive the initiation message.

[0051] At S308, the generation module 218 of the recipient computing device 104 can generate a cryptographic key pair used to generate a shared secret for use in offline blockchain transactions, including the recipient's shared public key and the recipient's shared private key. At S310, the generation module 218 of the recipient computing device 104 can generate a handshake message. The handshake message can include at least the recipient's computing device 104 provisioning certificate, the recipient's shared public key, and a digital signature on the certificate and the recipient's shared public key, for example, using the recipient's wallet private key. At S312, the sending device 222 of the recipient computing device 104 can electronically send the handshake message to the sender computing device 102 using a suitable communication network and method. At S314, the receiving device 202 of the sender computing device 102 can receive the handshake message.

[0052] At S316, the verification module 220 of the sender's computing device 102 can verify the certificate and the digital signature on the recipient's shared public key using an appropriate public key, such as the recipient's wallet public key, and can also verify the certificate using the chain of certificates from the provisioning system 106. At S318, the generation module 218 of the sender's computing device 102 can generate transfer messages for the desired digital currency transfers, each transfer message including appropriate information for the blockchain transaction, such as one or more unspent transaction outputs, a digital signature, a destination address, and a digital currency amount. At S320, the generation module 218 of the sender's computing device 102 can generate a payment message. The payment message may include: a reference value (e.g., generated by the generation module 218 via hashing the recipient's shared public key), an encrypted transfer message (e.g., encrypted using a symmetric key generated using the recipient's shared public key and the sender's shared private key generated by the generation module 218), the sender's shared public key, and a digital signature for the encrypted transfer message and the sender's shared public key generated using the sender's shared private key. At S322, the sending device 222 of the sender's computing device 102 can electronically send the payment message to the recipient's computing device 104 using an appropriate communications network and method.

[0053] At S324, the receiving device 202 of the recipient's computing device 104 may receive the payment message. At S326, the verification module 220 of the recipient's computing device 104 may verify the data contained in the payment message, including verifying the reference value using a hash value generated by the generation module 218 of the recipient's computing device 104 using the recipient's shared public key and verifying the digital signature using the sender's shared public key. The generation module 218 of the recipient's computing device 104 may also generate a symmetric key using the recipient's shared private key and the sender's shared public key, and may use the symmetric key to decrypt the encrypted transfer data. As part of the verification at S326, the verification module 220 of the recipient's computing device 104 may also verify the decrypted transfer data.

[0054] At S328, the generating module 218 of the recipient computing device 104 can generate an acceptance message for the offline blockchain transaction. The acceptance message can include at least a reference value (e.g., generated via the generating module 218 hashing the sender's shared public key) and a digital signature for the transfer message decrypted using the recipient's shared private key. At S330, the sending device 222 of the recipient computing device 104 can electronically send the acceptance message to the sender computing device 102 using an appropriate communication network and method. At S332, the receiving device 202 of the sender computing device 102 can receive the acceptance message.

[0055] At S334, the verification module 220 of the sender's computing device 102 can verify the data included in the acceptance message, including verifying the reference value (e.g., matching the value to a value generated by the generation module 218 hashing the sender's shared public key) and verifying the digital signature on the decrypted transfer message using the recipient's shared public key. In some cases, the verification module 220 can also verify the decrypted transfer data. At S336, the query module 216 of the sender's computing device 102 can query on the wallet data 206, store the transfer message therein, and update stored data related to the blockchain wallet accordingly, such as updating the available digital currency amount and unspent transaction outputs. At S338, the generation module 218 of the sender's computing device 102 can generate an accepted message. The accepted message may include a reference value (e.g., generated via generation module 218 hashing the recipient's shared public key), the accepted message, and a digital signature for the accepted message (e.g., generated by generation module 218 using the sender's shared private key). At S340, the sending device 222 of the sender's computing device 102 may electronically transmit the accepted message to the recipient's computing device 104 using an appropriate communications network and method.

[0056] At S342, the receiving device 202 of the recipient's computing device 104 can receive the accepted message. At S344, the verification module 220 of the recipient's computing device 104 can verify the data contained in the accepted message, for example, by verifying a reference value by matching it against a hash of the recipient's shared public key (e.g., generated via the generation module 218 of the recipient's computing device 104) and verifying the digital signature on the accepted message with the sender's shared public key. At S346, the query module 216 of the recipient's computing device 104 can query the wallet data 206, store the transfer message therein, and update stored data related to the blockchain wallet accordingly, for example updating the available digital currency amount and unspent transaction outputs.

[0057] Exemplary Methods for Processing Offline Blockchain Transactions FIG. 4 illustrates a method 400 for processing standardized offline blockchain transactions using standardized and sequenced messaging and encryption.

[0058] At S402, an initiation message may be generated by a processor (e.g., generation module 218) of a first computing device (e.g., sender computing device 102). At S404, the initiation message may be transmitted by a transmitter (e.g., sending device 222) of the first computing device to a second computing device (e.g., recipient computing device 104). At S406, a handshake message from the second computing device may be received by a receiver (e.g., receiving device 202) of the first computing device, where the handshake message may include at least a certificate and a recipient public key. At S408, the handshake message may be verified by a processor (e.g., verification module 220) of the first computing device, where verifying the handshake message includes at least verifying the certificate using a chain of certificates.

[0059] At S410, a payment message can be generated by a processor (e.g., generation module 218) of the first computing device, the payment message including transfer data, the transfer data including one or more data values ​​for the proposed blockchain transaction. At S412, the generated payment message can be transmitted by a transmitter of the first computing device to the second computing device. At S414, an acceptance message can be received from the second computing device by a receiver of the first computing device, the acceptance message can include at least a digital signature of the transfer data. At S416, the digital signature of the transfer data can be verified by a processor (e.g., verification module 220) of the first computing device using at least the public key of the receiver.

[0060] In one embodiment, the certificate and the recipient's public key in the handshake message can be digitally signed, and verifying the handshake message can further include verifying the digital signature of the certificate and the recipient's public key in the handshake message using the certificate's public key included in the certificate. In some embodiments, generating the payment message can further include: generating a symmetric key by a processor (e.g., generating module 218) of the first computing device using the recipient's public key and the sender's private key; and encrypting the transfer data by a processor (e.g., generating module 218) of the first computing device using the symmetric key, and the payment message can further include the sender's public key of the encryption key pair that includes the sender's private key. In one embodiment, the method 400 can further include the steps of: generating an accepted message by a processor (e.g., generating module 218) of the first computing device; and transmitting the generated accepted message by a transmitter of the first computing device to the second computing device. In a further embodiment, generating the accepted message may further include digitally signing the accepted message with the sender's private key, and the payment message may further include the sender's public key of a cryptographic key pair that includes the sender's private key.

[0061] In some embodiments, generating the payment message may further include generating a reference value by hashing the recipient's public key, and the payment message may further include the reference value. In one embodiment, the acceptance message may further include the reference value, and the method 400 may further include the steps of: generating a hash value by a processor (e.g., generation module 218) of the first computing device by hashing the sender's public key; and verifying the reference value by a processor (e.g., verification module 220) of the first computing device using the generated hash value. In a further embodiment, the payment message may further include the sender's public key.

[0062] Computer System Architecture 5 illustrates a computer system 500, in which embodiments of the present disclosure or portions thereof may be implemented as computer readable code. For example, the sender computing device 102, the recipient computing device 104, the provisioning system 106, and the blockchain node 110 of FIG. 1 may be implemented in the computer system 500 using hardware, a non-transitory computer readable medium having stored instructions, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may embody modules and components used to implement the methods of FIGS. 3A-3C and 4.

[0063] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, resulting in special purpose or dedicated devices (e.g., programmable logic arrays, application specific integrated circuits (ASICs), etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core, multi-processor systems, minicomputers, mainframe computers, distributed functionality linked or clustered computers, and general purpose or miniature computers that may be implemented in virtually any device. For example, at least one processor unit and memory may be used to implement the embodiments described above.

[0064] A processor unit or device of the present disclosure may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor “cores.” The terms “computer program medium,” “non-transitory computer readable medium,” and “computer usable medium” of the present disclosure are generally used to refer to tangible media (e.g., removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512, etc.).

[0065] Various embodiments of the present disclosure are described with respect to this exemplary computer system 500. After reading this disclosure, it will be obvious to one of ordinary skill in the art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations are disclosed as sequential processes, some operations may in fact be performed in parallel, concurrently and / or in a distributed environment, where the program code is stored locally or remotely for access by a single processor or multi-processor machine. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.

[0066] The processor unit 504 may be a special purpose or general purpose processor unit that is specially configured to perform the functions of the present disclosure. The processor unit 504 may be connected to a communication infrastructure 506 (e.g., a bus, a message queue, a network, a multi-core message passing scheme, etc.). The network may be any network suitable for performing the functions of the present disclosure, and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wifi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 may also include a main memory 508 (e.g., random access memory, read only memory, etc.) and may also include a secondary memory 510. The secondary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.).

[0067] The removable storage drive 514 may read from and / or write to the removable storage unit 518 in a well-known manner. The removable storage unit 518 may include a removable storage medium that can be read from and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a USB port, the removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 may be a non-transitory readable recording medium.

[0068] In some embodiments, secondary memory 510 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 500 (e.g., removable storage unit 522 and interface 520). Examples of such means may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the art.

[0069] Data stored in computer system 500 (e.g., in main memory 508 and / or secondary memory 510) may be stored on any type of suitable computer-readable medium, such as optical storage (compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., hard disk drive). The data may be organized in any type of suitable database structure (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable structures and storage types will be apparent to those skilled in the art.

[0070] Computer system 500 may also include a communications interface 524. Communications interface 524 may allow software and data to be sent and received between computer system 500 and external devices. Exemplary communications interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, and the like. The software and data transferred through communications interface 524 may be in the form of signals. The signals may be electronic, electromagnetic, optical, or other signals as would be apparent to one skilled in the art. The signals propagate through communications path 526. The paths are configured to carry the signals and may be implemented using wire, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, and the like.

[0071] Computer system 500 may further include a display interface 502. Display interface 502 may be configured to allow data to be transferred between computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. Display 530 may be any suitable type of display to display data transferred via display interface 502 of computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.

[0072] The computer program medium and computer usable medium may refer to memory (e.g., main memory 508 and auxiliary memory 510), which may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 500. Computer programs (e.g., computer control logic) may be stored in the main memory 508 and / or the auxiliary memory 510. The computer programs may also be received via the communication interface 524. Such computer programs, when executed, may enable the computer system 500 to perform the methods of the present disclosure. In particular, the computer programs, when executed, may enable the processor unit 504 to perform the methods shown in Figures 3A-3C and 4 as described herein. Thus, such computer programs represent the controller of the computer system 500. The present disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard disk drive 512 or the communication interface 524.

[0073] The processor unit 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware and in some embodiments using software (e.g., which corresponds to a program code or program stored in the main memory 508 or the secondary memory 510). In such embodiments, the program code may be compiled by the processor unit 504 (e.g., by a compilation module or engine) before execution by the hardware of the computer system 500. For example, the program code may be source code (e.g., assembly language or machine code) written in a programming language that is translated into a lower-level language for execution by the processor unit 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, syntax analysis, semantic analysis, syntax-driven translation, code generation, code optimization, and any other techniques suitable for translating the program code into a lower-level language for control of the computer system 500 to perform the functions of the present disclosure. Those skilled in the art will appreciate that such processing results in computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions described above.

[0074] Among other features, technology consistent with the present disclosure provides a system and method for processing standardized offline blockchain transactions. While various exemplary embodiments of the systems and methods of the present disclosure have been described above, it should be understood that they are presented for purposes of illustration only and not limitation. It is not exhaustive and does not limit the present disclosure to the precise forms disclosed. Modifications and variations are possible in light of the above teachings. Modifications and variations may be made from the implementation of the present disclosure without departing from the scope or spirit of the present disclosure.

Claims

1. 1. A method for processing standardized offline blockchain transactions, comprising: generating, by a processor of the first computing device, an initiation message; transmitting, by a transmitter of the first computing device, the initiation message to a second computing device; receiving, by a receiver of the first computing device, a handshake message from the second computing device, the handshake message including at least a certificate and a receiver's public key; validating, by the processor of the first computing device, the handshake message, where the validating the handshake message includes at least validating the certificate using a chain of certificates; and generating, by the processor of the first computing device, a payment message, the payment message including transfer data, the transfer data including one or more data values ​​for a proposed blockchain transaction; transmitting, by the transmitter of the first computing device, the generated payment message to the second computing device; receiving, by the receiver of the first computing device, an acceptance message from the second computing device, the acceptance message including at least a digital signature of the transfer data; verifying, by the processor of the first computing device, the digital signature of the transfer data using at least the recipient's public key; A method comprising:

2. 10. The method of claim 1 , the certificate and the recipient's public key in the handshake message are digitally signed; The method, wherein verifying the handshake message further comprises digitally verifying the signature of the certificate and the recipient's public key in the handshake message using a certificate public key contained within the certificate.

3. 10. The method of claim 1 , The generation of the payment message further comprises: generating, by the processor of the first computing device, a symmetric key using the recipient's public key and a sender's private key; encrypting, by the processor of the first computing device, the transfer data with the symmetric key; The method of claim 1, wherein the payment message further includes a sender's public key of a cryptographic key pair that includes the sender's private key.

4. The method of claim 1 further comprising: generating, by the processor of the first computing device, an accepted message; transmitting, by the transmitter of the first computing device, the generated accepted message to the second computing device; A method comprising:

5. 5. The method of claim 4, generating the accepted message further includes digitally signing the accepted message using a sender's private key; The method of claim 1, wherein the payment message further includes a sender's public key of a cryptographic key pair that includes the sender's private key.

6. 10. The method of claim 1 , generating the payment message further includes generating a reference value by hashing the recipient's public key; The payment message further comprises the reference value.

7. 10. The method of claim 1 , The acceptance message further includes a reference value; The method further comprises: generating a hash value by the processor of the first computing device by hashing a sender's public key; verifying, by the processor of the first computing device, the reference value using the generated hash value; A method comprising:

8. The method of claim 7 , wherein the payment message further includes a public key of the sender.

9. A system for processing standardized offline blockchain transactions, comprising: a first computing device including at least a receiver, a processor, and a transmitter; a second computing device, The processor of the first computing device generates an initiation message; the transmitter of the first computing device transmits the initiation message to the second computing device; the receiver of the first computing device receives a handshake message from the second computing device, the handshake message including at least a certificate and a receiver's public key; The processor of the first computing device: validating the handshake message, the validating the handshake message including at least validating the certificate using a chain of certificates; generating a payment message, the payment message including transfer data, the transfer data including one or more data values ​​for the proposed blockchain transaction; the transmitter of the first computing device transmits the generated payment message to the second computing device; the receiver of the first computing device receives an acceptance message from the second computing device, the acceptance message including at least a digital signature of the transfer data; The processor of the first computing device verifies the digital signature of the transfer data using at least the recipient's public key.

10. 10. The system of claim 9, the certificate and the recipient's public key in the handshake message are digitally signed; The system, wherein verifying the handshake message further comprises digitally verifying the signature of the certificate and the recipient's public key in the handshake message using a certificate public key contained within the certificate.

11. 10. The system of claim 9, The generation of the payment message further comprises: generating, by the processor of the first computing device, a symmetric key using the recipient's public key and a sender's private key; encrypting, by the processor of the first computing device, the transfer data with the symmetric key; The payment message further includes a sender's public key of a cryptographic key pair that includes the sender's private key.

12. 10. The system of claim 9, The processor of the first computing device further generates an accepted message; The transmitter of the first computing device further transmits the generated accepted message to the second computing device.

13. 13. The system of claim 12, generating the accepted message further includes digitally signing the accepted message using a sender's private key; The payment message further includes a sender's public key of a cryptographic key pair that includes the sender's private key.

14. 10. The system of claim 9, generating the payment message further includes generating a reference value by hashing the recipient's public key; The payment message further includes the reference value.

15. 10. The system of claim 9, The acceptance message further includes a reference value; The processor of the first computing device further comprises: Generate a hash value by hashing the sender's public key; The system verifies the reference value using the generated hash value.

16. 16. The system of claim 15, wherein the payment message further includes a public key of the sender.

Images