Methods and systems for providing offline transactions related to digital currencies

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 more particularly 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 Art

[0003] Blockchain was initially created as a storage mechanism for payment transactions using cryptocurrency. Using blockchain provides several advantages such as decentralization, distributed computing, transaction transparency, etc., while also providing anonymity for individuals or entities involved in the transaction. A relatively preferred characteristic of blockchain is the immutability of its records: that is, all transactions that are part of the chain are stored and are immutable due to the required computing power and bandwidth limitations, and this is strengthened especially as the chain grows and the blockchain network adds more nodes.

[0004] However, in traditional blockchains, for a transaction to be considered 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. To use newly acquired cryptocurrency, the transferee must wait for the transaction to be posted to the blockchain. This process can be time-consuming and also requires both parties to have an active connection to the blockchain node. There are many scenarios where both parties wish to transfer cryptocurrency but lack sufficient connectivity to the blockchain node (i.e., are offline). Such transfers are impossible in existing blockchain systems.

[0005] Therefore, there is a need for a technical solution that enables cryptocurrency transfers to be carried out offline without sacrificing blockchain security, immutability, and privacy. [Overview of the Initiative]

[0006] This disclosure provides a description of a system and method for processing standardized offline blockchain transactions. A sender's computing device and a receiver's computing device, each possessing a blockchain wallet, exchange a series of messages to complete an offline blockchain transaction. Both devices encrypt the data exchanged via messages using elliptic curve cryptography or another suitable method. By using references within the messages and processing in 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 process begins with the sender's computing device sending an initiate message to the receiver's computing device, to which the receiver's computing device responds with a handshake message, thereby establishing the data necessary to utilize elliptic curve cryptography. The sender's computing device responds with a pay message, which contains encrypted transfer data for the desired blockchain transaction. The receiver's computing device receives the pay message, decrypts the transfer data, verifies the accuracy of the transfer data, and also responds with an acknowledgment message. The sender's computing device receives an accept message, stores the transfer data in its local data store to ensure the transaction is properly accounted for, and provides an accepted message to the receiver's computing device, which can then update its own local data store with the transfer data. As a result, offline blockchain transactions are processed securely and verifiable, and can be correctly added to the blockchain as soon as a connection to the blockchain node is established.

[0007] A method for processing a standardized offline blockchain transaction includes the following steps: a step of generating an initiation message by the processor of a first computing device; a step of transmitting the initiation message to a second computing device by the transmitter of the first computing device; a step of receiving a handshake message from the second computing device by the receiver of the first computing device, wherein the handshake message includes at least a certificate and the recipient's public key; and a step of verifying the handshake message by the processor of the first computing device, wherein the verification of the handshake message includes at least verifying the certificate using a chain of certificates. A payment message is generated by the processor of the first computing device, wherein the payment message includes transfer data, the transfer data includes one or more data values ​​for a proposed blockchain transaction; the generated payment message is transmitted to the second computing device by the transmitter of the first computing device; the receiver of the first computing device receives an acceptance message from the second computing device, wherein the acceptance message includes 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.

[0008] A system for processing standardized offline blockchain transactions comprises: 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, wherein the handshake message includes at least a certificate and the recipient's public key; and the processor of the first computing device verifies the handshake message. The verification of the certificate includes at least the step of verifying the certificate using a chain of certificates, and the step of generating a payment message, wherein the payment message includes transfer data, wherein the transfer data includes one or more data values ​​for a 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, wherein the acceptance message includes at least the 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 explanation of the drawing]

[0009] The scope of this disclosure, when interpreted in conjunction with the accompanying drawings, will be best understood from the following detailed description of exemplary embodiments. The drawings include the following figures:

[0010] [Figure 1] This block diagram shows a high-level system architecture for processing standardized offline blockchain transactions, according to an exemplary embodiment. [Figure 2] This block diagram shows a computing device for processing standardized offline blockchain transactions of the system in Figure 1, according to an exemplary embodiment. [Figure 3A] This flowchart illustrates a process for handling standardized offline blockchain transactions in the system shown in Figure 1, according to an exemplary embodiment. [Figure 3B] This flowchart illustrates a process for handling standardized offline blockchain transactions in the system shown in Figure 1, according to an exemplary embodiment. [Figure 3C] This flowchart illustrates a process for handling standardized offline blockchain transactions in the system shown in Figure 1, according to an exemplary embodiment. [Figure 4] This flowchart illustrates an exemplary method for processing standardized offline blockchain transactions, according to an exemplary embodiment. [Figure 5] This block shows a computer system architecture according to an exemplary embodiment.

[0011] Further application areas of this disclosure will be obvious from the detailed description below. The detailed description of exemplary embodiments is for illustrative purposes only and is not intended to necessarily limit the scope of this disclosure. [Modes for carrying out the invention]

[0012] A system for processing standardized offline blockchain transactions. Figure 1 shows a system 100 that enables the secure and successful processing of offline blockchain transactions by utilizing encrypted and standardized messaging.

[0013] System 100 supports offline blockchain transactions between two computing devices, which are designated as the sender's computing device 102 and the receiver's computing device 104. Each computing device can be any type of device suitable for performing the functions described herein, such as a desktop computer, laptop computer, tablet computer, notebook computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, etc.

[0014] Before participating in an offline blockchain transaction, the sender's computing device 102 and the receiver's computing device 104 may be provided with certificates by the provisioning system 106. The provisioning system 106 may be an authorized entity configured to provide certificates to devices authorized to participate in offline blockchain transactions. The provisioning system 106 may verify the authorization status of a computing device and provide it with a certificate, the certificate or the data associated with it being stored in a certificate chain. The provisioning system 106 may 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 verification of certificates can be found in U.S. Patent Application No. 16 / 509,765, filed July 12, 2019, “Method and System for Secure and Verifiable Offline Blockchain Transactions,” Stephen Higgins, which is incorporated herein by reference in its entirety.

[0015] In system 100, the sender's computing device 102 may be interested in sending digital currency to the recipient's computing device 104 through an offline blockchain transaction, the transaction being recorded within the blockchain. The blockchain may be associated with a blockchain network 108. The blockchain network 108 may consist of a plurality of blockchain nodes 110. Each blockchain node 110 may be a computing system, as shown in Figure 2 or Figure 5 and detailed below, configured to perform functions related to the processing and management of the blockchain, which may include, for example, generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, verifying new blocks, and maintaining copies of the blockchain. In some embodiments, the provisioning system 106 may be a blockchain node 110.

[0016] A blockchain can be a distributed ledger comprising at least several blocks. Each block may contain at least a block header and one or more data values. Each block header may contain at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time the block header was generated and can be represented using any suitable method (e.g., UNIX timestamp, DateTime notation). The block reference value may be a value that references a preceding block in the blockchain (e.g., based on the timestamp). 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 within the block containing 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] The use of block reference values ​​and data reference values ​​within each block header can give the blockchain immutability. Attempting to change a data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for the subsequent block, and further requires the generation of a new block reference value for each subsequent block. For the change to be permanent, the above steps must be performed and updated for each blockchain node 110 within the blockchain network 108 before a new block is generated and added to the blockchain. Due to the limitations of computing and communication capabilities, such changes can be extremely difficult or even impossible, and thus the blockchain acquires 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 may contain the private key of a cryptographic key pair, which is used to generate a digital signature that acts as an endorsement of the payer with respect to the blockchain transaction. This 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” may specifically refer to the private key. In other cases, the term “blockchain wallet” may refer to a computing device (e.g., the sender’s computing device 102, the receiver’s computing device 104, etc.) that stores the private key for use in blockchain transactions. For example, each computing device may have its own private key for its respective cryptographic key pair, and each may 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 the blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, embedded computing device, etc.

[0019] Each blockchain data value stored within the blockchain may correspond to a blockchain transaction or, where applicable, the storage of other data. A blockchain transaction may comprise at least: a digital signature of the sender of the currency (e.g., the sender's computing device 102) generated using the sender's private key; the 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: the blockchain addresses of one or more senders where the blockchain currency is currently stored (e.g., where the digital signature verifies access to such currency); and an address generated using the sender's public key for any changes to be held by the sender. The address to which cryptocurrency usable in a future transaction has been sent is referred to as an "output" address because each address has been previously used to capture the output of a preceding blockchain transaction, and is also referred to as an "unspent transaction" because there is currency to be sent to the address in a preceding transaction in which the currency is still unspent. In some cases, a blockchain transaction may also include the sender's public key for entities to use when verifying the transaction. For the traditional processing of blockchain transactions, such data may be provided by either the sender or the receiver to a blockchain node 110 within 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 also verify access to the sender's funds (for example, if an unspent transaction has not yet been consumed and has been sent to an address associated with the sender's wallet), which is known as the transaction "confirmation" process, and the node can then include the blockchain transaction in a new block.In traditional blockchain implementations, a new block may be validated by other nodes in the blockchain network 108 before being added to the blockchain and distributed to all blockchain nodes 110 within the blockchain network 108. If the blockchain data value is not related to a blockchain transaction but instead to the storage of other types of data, the blockchain data value may still include or involve verification of a digital signature.

[0020] In system 100, the sender's computing device 102 and the receiver's computing device 104 can each establish a communication channel with the provisioning system 106, and can request certificates and certificate chains from the system using appropriate methods such as web pages, application programs, and application programming interfaces. The provisioning system 106 can generate certificates for each device and send certificates and certificate chains to them. In some cases, the provisioning system 106 can first verify the device's authorization and capability with respect to offline blockchain transactions before providing certificates. For example, the provisioning system 106 can request the sender's computing device 102 to digitally sign a local data store regarding the available digital currencies in the blockchain wallet (for example, using the sender's private key for its own blockchain wallet (referred to as the "sender's wallet private key")) 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 verify that the data store is correct, for example by verifying any digital signatures, blockchain addresses, digital currency amounts, etc. contained therein. In another example, the provisioning system 106 can request attestation from the sender's computing device 102 to ensure that the sender's computing device 102 is legitimate and that genuine hardware is being used. If the verification is successful, the provisioning system 106 can generate a certificate for the sender's computing device 102, add the appropriate data to the certificate chain, and provide the certificate and updated certificate chain to the sender's computing device.

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

[0022] The sender's computing device 102 can electronically transmit the start message to the recipient's computing device 104 using an appropriate communication network and method. The recipient's computing device 104 receives the start message and can determine, for example based on user instructions, whether it is interested in proceeding with an offline blockchain transaction with the sender's computing device 102. If the start message includes authentication information, the recipient's computing device 104 can first verify the authentication information before proceeding, and this verification can be done, for example, by matching the provided provisioned certificate against the chain of certificates provided by the provisioning system 106. If the recipient's computing device 104 desires to proceed with the transaction, the recipient's computing device 104 can generate a handshake message.

[0023] The handshake message can include a certificate of the recipient's computing device provided by the provisioning system 106 and the recipient's shared public key. The recipient's shared public key can be the public key of a cryptographic key pair generated by the recipient's computing device 104, which is used to establish a shared secret with the sender's computing device 102 and can be used, for example, using elliptic curve cryptography, to encrypt and decrypt data exchanged between the two computing devices. In this specification, the keys used for the shared secret are referred to as the "shared" public key and private key. As part of generating the handshake message, the recipient's computing device 104 can digitally sign the certificate and the recipient's shared public key. The digital signature can 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 can be included in the certificate itself.

[0024] The recipient's computing device 104 can electronically transmit a handshake message to the sender's computing device 102 using an appropriate communication network and method. The sender's computing device 102 can receive the handshake message and verify the data contained within it. The sender's computing device 102 can verify the digital signature using an appropriate public key, such as the recipient's wallet public key (e.g., one transmitted with the handshake message, one contained within the handshake message, or one included in a separate transmission) or a public key contained within a certificate. The sender's 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's computing device 102 can refuse to participate in the transaction, which may be done to avoid potential fraud that could be committed by an unauthorized computing device. If any verification is successful, the sender's computing device 102 can then generate a payment message for the offline blockchain transaction.

[0025] To include a payment message, the sender's computing device 102 can generate transfer data. The transfer data may 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 may include, for example, the following: the 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 the amount of digital currency. The sender's computing device 102 may 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 may generate an encryption key pair for use in elliptic curve cryptography or other suitable methods, the encryption key pair including the sender's shared private key and the sender's shared public key. The sender's shared public key may be included in the payment message. The sender's computing device 102 may generate a symmetric key using its own sender's shared private key and the recipient's shared public key, which can be done, 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 it is included in the payment message.

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

[0027] The recipient's computing device 104 can receive the payment message and verify the data contained therein. The recipient's computing device 104 can verify the reference value by hashing its own recipient's shared public key and matching the generated value with the reference value contained in the payment message. The recipient's computing device 104 can verify the digital signature of the data in the payment message using the sender's shared public key contained in the payment message. If any verification fails, the recipient's computing device 104 can refuse further participation in the offline blockchain transaction. If any verification is successful, the recipient's computing device 104 can decrypt the transferred data. The recipient's computing device 104 can generate its own symmetric key using the recipient's shared private key and the supplied sender's shared public key, for example, using elliptic curve cryptography or another suitable method. The recipient's computing device 104 can decrypt the transferred data using the generated symmetric key. The recipient's computing device 104 can then verify the transferred data, for example, by verifying the digital signature. This ensures that the unspent transaction output has sufficient digital currency, that the destination blockchain address is correct, and that the amount of digital currency is appropriate. If any of the transfer data is incorrect, the recipient's computing device 104 may refuse further participation, or may appropriately notify the sender's computing device 102 and request the sender's 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 may include at least a reference value, which may be a hash of the sender's shared public key. In some embodiments, the acceptance message may also include a digital signature, which may be of the sender's shared public key, also included in the acceptance message, and which may be generated using the recipient's shared private key. In some cases, the acceptance message may also include the decrypted transfer data, which may be digitally signed using the recipient's shared private key. In some cases, the acceptance message may include a digital signature of the decrypted transfer data without including the decrypted transfer data itself. In some cases, the acceptance message may include a hash of 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 an accepted message and verify the data contained therein. The sender's computing device 102 can verify a reference value by hashing its own sender's shared public key and matching the resulting value with the reference value contained in the accepted message. The sender's computing device 102 can also verify a digital signature, for example, by using the receiver's shared public key previously received (e.g., in a handshake message). If the accepted message contains decrypted transfer data, the sender's computing device 102 can also verify that the transfer data contained in the accepted message matches previously generated transfer data. If the accepted message contains a hash of 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 contained in the accepted message. If any verification fails, the sender's computing device 102 can halt the transaction processing. If verification is successful, the sender's computing device 102 stores the transfer data in its local data store and applies the transfer data to the device's blockchain wallet data as appropriate, which is done by updating, for example, the status of unspent transaction output, the amount of available digital currency, etc. After such storage and updating is done, the sender's computing device 102 can consider the digital currency to have been transferred and prevent any other transfers, thereby preventing any double consumption of the associated digital currency.

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

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

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

[0033] In some embodiments, the sender's computing device 102 and the receiver's computing device 104 may discard any unexpectedly received messages. For example, once processing begins (for instance, when the receiver's computing device 104 sends a handshake message to the sender's computing device 102), each computing device may discard any messages that were not expected to be based on the known message order described above. For example, after the sender's computing device 102 sends a payment message to the receiver's computing device 104, the sender's computing device 102 may discard any messages received from the receiver's computing device 104 or other computing devices that are not accepted (or rejected, as described below) messages from the receiver's computing device 104. Such message discarding ensures that offline blockchain transactions are completed completely and in the correct order, preventing double consumption or any inconsistencies between devices. In some cases, a computing device may notify other devices involved in a transaction if an received message has been discarded, which may, for example, give other devices an opportunity to generate and send an appropriate message. In some cases, the sender's computing device 102 and the receiver's computing device 104 can repeatedly send messages based on the current step of the transaction, and can continue sending copies of the message until the next appropriate message is received from another device. In such cases, the sender's computing device 102 and the receiver's computing device 104 can be prevented from skipping ahead in the transaction processing, and it can be ensured that other devices receive all the messages necessary for the transaction.In such cases, when the sender's computing device 102 or the receiver's computing device 104 receives the message, they can perform the necessary actions described above when receiving the first copy of the message, but they can refrain from performing any actions when receiving subsequent copies of the message.

[0034] If one of the computing devices involved in an offline blockchain transaction wishes to cancel the transaction, it can generate a cancel message, also known as a reject message. A computing device may request transaction cancellation due to reasons such as verification failure, missed messages, messages sent out of order, or intervention by the user of the computing device. A cancellation message can be generated by a computing device and includes a reference value (generated by hashing the shared public key of another computing device) and a digital signature generated for the symmetric key. The digital signature is generated using the device's shared private key. The cancellation message can be sent to another device, which can verify both the reference value and the digital signature. The device can also verify the symmetric key by comparing it to its own symmetric key. Once all values ​​have been verified, the device can clear its current transaction. In some cases, a cancel message may refer to an instruction entered by the user of the device to cancel the transaction, while a reject message may refer to a message sent from one device to another to cancel the transaction.

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

[0036] In some embodiments, the initiation message may include a public key generated by the sender's computing device 102 for use in generating a reference about the transaction, and is referred to herein as the transaction's public key. The sender's computing device 102 and the receiver's computing device 104 can use the transaction's public key to generate or derive a reference value, such as a session identifier or transaction number, which may be included in one or more messages transmitted between the sender's computing device 102 and the receiver's computing device 104. This ensures, for example, that the message originates from the expected computing device.

[0037] The methods and systems described herein are provided for offline blockchain transactions between two computing devices. By using standardized messages sent and received in a known order, double spending of digital currency can be prevented. Furthermore, the use of shared confidential information, hashed reference values, and other techniques already discussed enables offline blockchain transactions to be conducted securely and reliably, even if communications are intercepted or viewed by other devices. As a result, the methods and systems disclosed herein offer greater versatility in offline blockchain transactions than existing systems due to the technological advancements utilized.

[0038] Computing device Figure 2 shows an embodiment of the sender's computing device 102. It will be obvious to those skilled in the art that the embodiment of the sender's computing device 102 shown in Figure 2 is provided for illustrative purposes only and does not thoroughly represent all possible configurations of the sender's computing device 102 suitable for performing the functions of the present disclosure. For example, the computer system 500 shown in Figure 5 and described in more detail below may be a suitable configuration of the sender's computing device 102. The sender's computing device 102 can also be used as the receiver's computing device 104 in offline blockchain transactions. Similarly, the receiver's computing device 104 in system 100 can also be used as the sender's computing device 102 in offline blockchain transactions.

[0039] The sender's computing device 102 may include a receiver 202. The receiver 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiver 202 may be configured to receive data from other sender's computing devices 102, receiver's computing device 104, provisioning system 106, blockchain node 110, and other systems and entities via one or more communication methods such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, and the internet. In some embodiments, the receiver 202 may include multiple devices (for example, different receivers that receive data over different networks (e.g., a first receiver that receives data over a local area network and a second receiver that receives data over the internet)). The receiver 202 may receive an transmitted electronic data signal. Upon receiving the data signal by the receiver 202, the data may be superimposed on the data signal and then decoded, parsed, read, or retrieved. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal and obtaining superimposed data thereon. For example, the receiving device 202 may include an analysis program configured to receive the received data signal and convert it into available inputs for a function to be performed by the processing unit to execute the methods and systems of this disclosure.

[0040] The receiving device 202 may be configured to receive data signals electronically transmitted by another sender's computing device 102 or the receiver's computing device 104, which may be superimposed or encoded with start 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 may also be configured to receive data signals electronically transmitted by the provisioning system 106, which may be superimposed or encoded with certificates and certificate chains. The receiving device 202 may also be configured to receive data signals electronically transmitted by the blockchain node 110, which may be superimposed or encoded with blockchain data values, blocks, notification messages, public keys, etc.

[0041] The sender's computing device 102 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the sender's computing device 102 for use in performing the functions of the Disclosure. The communication module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, the communication module 204 may include buses, connecting pin connectors, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the sender's computing device 102 and external components of the sender's computing device 102 (e.g., externally connected databases, display devices, input devices, etc.). The sender's computing device 102 may also include a processing unit. The processing unit may be configured to perform the functions of the sender's computing device 102 of the Disclosure. This will be obvious to those skilled in the art. In some embodiments, the processing unit may include a plurality of engines and / or modules (e.g., query module 216, generation module 218, verification module 220, etc.) specifically configured to perform one or more functions of the processing unit. As in this disclosure, the term “module” may be software or hardware specifically programmed to receive an input, use said input to perform one or more processes, and provide an output. The inputs, outputs, and processes performed by various modules are obvious to those skilled 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 an appropriate data storage format and schema. The wallet data 206 may be stored in a relational database using a structured query language for storing, identifying, modifying, updating, accessing, etc., stored structured datasets. The wallet data 206 may include, for example, cryptographic key pairs, unspent transaction outputs, digital signatures, blockchain addresses, digital currency amounts, provided certificates, certificate chains, message queues for messages, symmetric keys, transfer data, etc.

[0043] The sender's computing device 102 may also include a 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's computing device 102 when performing the functions of the 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, module program code and processing device application programs, and other appropriate data used by the sender's computing device 102 when performing the functions of the disclosure. This will be obvious to a person skilled in the art who reads this disclosure. In some embodiments, the memory 214 may consist of or include a relational database using a structured query language (SQL) to store, identify, modify, update, access, etc., stored structured datasets. Memory 214 may be configured to store, for example, encryption keys, encryption key pairs, encryption algorithms, encryption algorithms, communication information, data formatting rules, blockchain data, signature generation algorithms, etc.

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

[0045] The sender's computing device 102 may also include a generation module 218. The generation module 218 may be configured to generate data used by the sender's computing device 102 when performing the functions of the disclosure. The generation module 218 may receive instructions as input values, generate data based on instructions, and output the generated data to one or more modules of the sender's computing device 102. For example, the generation module 218 may be configured to generate start messages, handshake messages, payment messages, acceptance messages, accepted messages, cancellation or rejection messages, clear messages, digital signatures, transfer data, reference values, cryptographic key pairs, symmetric keys, etc.

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

[0047] The sender's 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's computing devices 102, receiver's computing device 104, provisioning system 106, blockchain node 110, and other systems and entities via one or more communication methods such as a local area network, wireless area network, cellular communication, Bluetooth, radio frequency, and the internet. 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 for transmitting data over a local area network and a second transmitting device for transmitting data over the internet). The transmitting device 222 may electronically transmit a data signal having superimposed data that is parsed 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 transmitting device 222 may be configured to electronically transmit data signals to the other sender's computing device 102 and the receiver's computing device 104, and these data signals 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 transmitting device 222 may also be configured to electronically transmit data signals to the provisioning system 106, which may be superimposed or encoded with requests for certificates and / or certificate chains. Furthermore, the transmitting device 222 may also be configured to electronically transmit 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 Figures 3A-3C illustrate the processing for offline blockchain transactions between the sender's computing device 102 and the receiver's computing device 104 in the system 100 of Figure 1, which uses standardized and ordered messaging.

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

[0051] In S308, the generating module 218 of the recipient's computing device 104 can generate a cryptographic key pair used to generate shared confidential information for use in offline blockchain transactions, which includes the recipient's shared public key and the recipient's shared private key. In S310, the generating module 218 of the recipient's computing device 104 can generate a handshake message. The handshake message may include at least the provisioning certificate of the recipient's computing device 104, 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. In S312, the transmitting device 222 of the recipient's computing device 104 can electronically transmit the handshake message to the sender's computing device 102 using an appropriate communication network and method. In S314, the receiving device 202 of the sender's computing device 102 can receive the handshake message.

[0052] In S316, the verification module 220 of the sender's computing device 102 can verify the certificate and the digital signature for 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 a chain of certificates from the provisioning system 106. In S318, the generation module 218 of the sender's computing device 102 can generate a transfer message relating to the transfer of the desired digital currency, each transfer message containing appropriate information relating to the blockchain transaction, such as one or more unspent transaction outputs, a digital signature, a destination address, and the amount of digital currency. In 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 of 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 on the encrypted transfer message and the sender's shared public key, generated using the sender's shared private key. In S322, the sender's computing device 102's transmitting device 222 can electronically transmit the payment message to the recipient's computing device 104 using an appropriate communication network and method.

[0053] In S324, the receiving device 202 of the recipient's computing device 104 can receive the payment message. In S326, the verification module 220 of the recipient's computing device 104 can verify the data contained in the payment message, which includes verifying a 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 a digital signature using the sender's shared public key. The generation module 218 of the recipient's computing device 104 can also generate a symmetric key using the recipient's shared private key and the sender's shared public key, and can decrypt encrypted transfer data using the symmetric key. As part of the verification in S326, the verification module 220 of the recipient's computing device 104 can also verify the decrypted transfer data.

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

[0055] In S334, the verification module 220 of the sender's computing device 102 can verify the data contained in the accepted message, which includes verifying a reference value (for example, matching that value to a value generated by the generation module 218 which hashes the sender's shared public key) and verifying the digital signature of the transfer message decrypted using the receiver's shared public key. In some cases, the verification module 220 can also verify the decrypted transfer data. In S336, the query module 216 of the sender's computing device 102 can execute queries on the wallet data 206, store the transfer message there, and update the stored data about the blockchain wallet accordingly, for example, updating the available digital currency amount and the output of unspent transactions. In S338, the generation module 218 of the sender's computing device 102 can generate the accepted message. An accepted message may include a reference value (for example, generated via a generation module 218 that hashes the recipient's shared public key), the accepted message, and a digital signature on the accepted message (for example, generated by a generation module 218 using the sender's shared private key). In S340, the sender's computing device 102's transmitting device 222 can electronically transmit the accepted message to the recipient's computing device 104 using an appropriate communication network and method.

[0056] In S342, the receiving device 202 of the recipient's computing device 104 can receive the accepted message. In 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 (for example, generated via the generation module 218 of the recipient's computing device 104), and by verifying the digital signature for the accepted message using the sender's shared public key. In S346, the query module 216 of the recipient's computing device 104 can execute queries on the wallet data 206, store the transfer message there, and update the stored data regarding the blockchain wallet accordingly, for example, by updating the available digital currency amount and the unspent transaction output.

[0057] Exemplary methods for handling offline blockchain transactions Figure 4 illustrates a method 400 for processing standardized offline blockchain transactions using standardized and ordered messaging and cryptography.

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

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

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

[0061] In some embodiments, the generation of a 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, an accepted message may further include the reference value, and method 400 may further include the following steps: generating a hash value by a processor of the first computing device (e.g., generation module 218) by hashing the sender's public key; and verifying the reference value using the generated hash value by a processor of the first computing device (e.g., verification module 220). In further embodiments, the payment message may further include the sender's public key.

[0062] Computer System Architecture Figure 5 shows a computer system 500, in which embodiments or parts thereof of the present disclosure may be implemented as computer-readable code. For example, the sender's computing device 102, the receiver's computing device 104, the provisioning system 106, and the blockchain node 110 in Figure 1 may be implemented in computer system 500 using hardware, a non-temporary 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 can embody modules and components used to implement the methods of Figures 3A-3C and Figure 4.

[0063] Where programmable logic is used, such logic runs on a commercially available processing platform consisting of executable software code and may be an application-specific or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit (ASIC), etc.). Those skilled in the art will understand that embodiments of the disclosed subject matter are executable in a variety of computer system configurations. Such configurations include multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and general-purpose or miniature computers that can be implemented in substantially any device. For example, at least one processor device and memory may be used to implement the above embodiments.

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

[0065] Various embodiments of this disclosure are described in relation to this exemplary computer system 500. After reading this disclosure, it will be obvious to those skilled in the art how to implement this disclosure using other computer systems and / or computer architectures. While operations are disclosed as sequential processes, some operations may actually be executed concurrently, simultaneously, and / or in a distributed environment. In this case, the program code is stored locally or remotely for access by single-processor or multi-processor machines. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosure.

[0066] The processor device 504 may be a purpose-specific or general-purpose processor device specifically configured to perform the functions of the Disclosure. The processor device 504 may be connected to a communication infrastructure 506 (e.g., a bus, message queue, network, multicore message path scheme, etc.). The network may be any network suitable for performing the functions of the Disclosure and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wi-Fi), 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 obvious to those skilled in the art. The computer system 500 may also include main memory 508 (e.g., random access memory, read-only memory, etc.) and auxiliary memory 510. The auxiliary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, magnetic tape drive, optical disk drive, 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-temporary readable recording medium.

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

[0069] Data stored in the computer system 500 (for example, in main memory 508 and / or auxiliary memory 510) may be stored on any type of suitable computer-readable medium (e.g., optical storage (compact discs, digital multipurpose discs, Blu-ray discs, etc.) or magnetic tape storage (e.g., hard disk drives)). The data may be configured in any type of suitable database configuration (e.g., relational databases, structured query language (SQL) databases, distributed databases, object databases, etc.). Suitable configurations and storage types are obvious to those skilled in the art.

[0070] The computer system 500 may also include a communication interface 524. The communication interface 524 may enable software and data to be sent and received between the computer system 500 and external devices. An exemplary communication interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transferred via the communication interface 524 may be in signal form. The signal form may be electronic, electromagnetic, optical, or other signals obvious to those skilled in the art. The signals propagate through a communication path 526. The path is configured to carry signals and may be implemented using wires, cables, optical fibers, telephone lines, mobile phone links, radio frequency links, etc.

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

[0072] The computer program medium and computer-usable medium may refer to memory (e.g., main memory 508 and auxiliary memory 510) and may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 500. The computer program (e.g., computer control logic) may be stored in the main memory 508 and / or auxiliary memory 510. The computer program may also be received via the communication interface 524. When executed, such a computer program may enable the computer system 500 to perform the methods of the present disclosure. In particular, when executed, the computer program may enable the processor device 504 to perform the methods shown in Figures 3A-3C and 4 as described herein. Thus, such a computer program represents a 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 a removable storage drive 514, interface 520, and hard disk drive 512 or communication interface 524.

[0073] The processor device 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, it may use software (for example, this corresponds to program code or programs stored in main memory 508 or auxiliary memory 510). In such embodiments, the program code may be compiled by the processor device 504 (for example, 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 low-level language. This is for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntactic-driven translation, code generation, code optimization, and the use of any other techniques suitable for translating the program code into a low-level language for control of the computer system 500 and performing the functions of the disclosure. It will be obvious to those skilled in the art that such processing will result in a specially configured computer system 500 that is uniquely programmed to perform the above-mentioned functions.

[0074] The technology consistent with this disclosure provides a system and method for processing standardized offline blockchain transactions, although it also has other features. Various exemplary embodiments of the system and method of this disclosure are described above, but it should be understood that they are provided for illustrative purposes only and not for limitation. They are not exhaustive, and this disclosure is not limited to the disclosed form itself. Modifications and variations are possible in light of the above teachings. Modifications and variations may be derived from implementations of this disclosure without departing from the scope or extent.

Claims

1. A method for processing standardized offline blockchain transactions, A step of generating an initiation message by the processor of a first computing device for initiating an offline blockchain transaction with a second computing device, wherein the initiation message includes a certificate of the first computing device indicating that the first computing device is authorized to participate in the offline blockchain transaction; The steps include: transmitting the start message to the second computing device using the transmitter of the first computing device; A step of receiving a handshake message from a second computing device via a receiver of the first computing device, wherein the handshake message includes at least a certificate of the second computing device and a public key of the second computing device indicating that the second computing device is authorized to participate in offline blockchain transactions. A step of verifying the handshake message using the processor of the first computing device, wherein the verification of the handshake message includes at least verifying the certificate of the second computing device using a certificate chain. Upon successful verification of the certificate of the second computing device, the first computing device's processor generates a payment message, wherein the payment message includes transfer data, and the transfer data includes one or more data values ​​for the proposed blockchain transaction. The steps include: transmitting the generated payment message to the second computing device using the transmitter of the first computing device; The steps include: receiving an acceptance message from the second computing device via the receiver of the first computing device, wherein the acceptance message includes at least a digital signature of the transferred data; The first computing device's processor verifies the digital signature of the transferred data using at least the public key of the second computing device, If the verification of the digital signature of the transferred data is successful, the steps include storing the transferred data in the memory of the first computing device, Methods that include...

2. In the method according to claim 1, The certificate and public key of the second computing device in the handshake message are digitally signed. A method for verifying the handshake message, further comprising verifying the digital signatures of the second computing device's certificate and the second computing device's public key in the handshake message using the public key of the second computing device's certificate contained within the second computing device's certificate.

3. In the method according to claim 1, The generation of the aforementioned payment message further involves, The processor of the first computing device generates a symmetric key using the public key of the second computing device and the private key of the first computing device, The process includes encrypting the transferred data using the symmetric key by the processor of the first computing device, The payment message further includes the public key of the first computing device of a cryptographic key pair including the private key of the first computing device, in a method.

4. The method according to claim 1, further, Upon successful verification of the digital signature of the transferred data, the processor of the first computing device generates an accepted message indicating the receipt of the accepted message; The steps include: transmitting the generated accepted message to the second computing device by the transmitter of the first computing device; Methods that include...

5. In the method according to claim 4, The generation of the accepted message further includes digitally signing the accepted message using the private key of the first computing device, The payment message further includes the public key of the first computing device of a cryptographic key pair including the private key of the first computing device, in a method.

6. In the method according to claim 1, The generation of the payment message further includes generating a reference value by hashing the public key of the second computing device, The payment message further includes the reference value, in a manner.

7. In the method according to claim 1, The aforementioned acceptance message further includes a reference value, The above method further, The steps include generating a hash value by hashing the public key of the first computing device, and the processor of the first computing device, The steps include: verifying the reference value using the generated hash value with the processor of the first computing device; Methods that include...

8. The method according to claim 7, wherein the payment message further includes the public key of the first computing device.

9. A system for processing standardized offline blockchain transactions, A first computing device including at least a receiver, a processor, a transmitter, and memory, A second computing device is provided, The processor of the first computing device generates an initiation message for initiating an offline blockchain transaction with the second computing device, the initiation message includes a certificate of the first computing device indicating that the first computing device is authorized to participate in the offline blockchain transaction. The transmitter of the first computing device transmits the start 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 includes at least the certificate of the second computing device and the public key of the second computing device, indicating that the second computing device is authorized to participate in offline blockchain transactions. The processor of the first computing device is A step of verifying the handshake message, wherein the verification of the handshake message includes at least verifying the certificate of the second computing device using a certificate chain. Upon successful verification of the certificate of the second computing device, the following steps are performed: generating a payment message, wherein the payment message includes transfer data, and the transfer data includes 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 includes at least a digital signature of the transferred data. The processor of the first computing device is The digital signature of the transferred data is verified using at least the public key of the second computing device, A system that, upon successful verification of the digital signature of the transferred data, stores the transferred data in memory.

10. In the system described in claim 9, The certificate and public key of the second computing device in the handshake message are digitally signed. The verification of the handshake message further includes verifying the digital signature of the second computing device's certificate and the second computing device's public key in the handshake message using the public key of the second computing device's certificate contained within the second computing device's certificate.

11. In the system described in claim 9, The generation of the aforementioned payment message further involves, The processor of the first computing device generates a symmetric key using the public key of the second computing device and the private key of the first computing device, The process includes encrypting the transferred data using the symmetric key by the processor of the first computing device, The payment message further includes the public key of the first computing device, which is part of a cryptographic key pair containing the private key of the first computing device.

12. In the system described in claim 9, The processor of the first computing device, upon successful verification of the digital signature of the transferred data, generates an accepted message indicating receipt of the accepted message. A system wherein the transmitter of the first computing device further transmits the generated received message to the second computing device.

13. In the system according to claim 12, The generation of the accepted message further includes digitally signing the accepted message using the private key of the first computing device, The payment message further includes the public key of the first computing device, which is part of a cryptographic key pair containing the private key of the first computing device.

14. In the system described in claim 9, The generation of the payment message further includes generating a reference value by hashing the public key of the second computing device, The payment message further includes the reference value, according to the system.

15. In the system described in claim 9, The aforementioned acceptance message further includes a reference value, The processor of the first computing device further, A hash value is generated by hashing the public key of the first computing device. A system that verifies the reference value using the generated hash value.

16. The system according to claim 15, wherein the payment message further includes the public key of the first computing device.

Images