Secure off-chain blockchain transactions

Abstract

To provide a method for recording transactions on a blockchain.SOLUTION: In a method 300, a party attaches a cryptocurrency deposit to an exchange platform and generates fund and refund transactions using a shared key (302). Then, the party transfers an ownership of the deposit to a second party by using a slide protocol and generates a new refund transaction and a new shared key (304). When detachment of the cryptocurrency transactions from the exchange platform is decided (Yes in 306), a current owner of the deposit detaches the deposit from the exchange by using the current shared key (308). When the detachment of the cryptocurrency transactions from the exchange platform is not decided (No in 306), timeout ends and a current beneficiary issues a refund transaction to return the deposit to a previous owner (310).SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention generally relates to blockchain technology and transactions, and more particularly to off-chain transactions via an intermediate computer system between parties. The present invention is particularly suitable for generating off-chain transactions between untrusted parties via a trusted exchange platform for implementing and operating a transaction protocol without storing any information that can be used by an attacker exposing the transaction to risk. Transactions may be generated to be broadcast to a blockchain network for recording on the blockchain. Thus, the present invention provides a more secure solution for recording transactions on a blockchain.

Background Art

[0002] As used herein, the term "blockchain" is used to include any form of electronic, computer-based, distributed ledger. These include blockchain and transaction chain technologies based on consensus, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin may be referred to herein for convenience and illustrative purposes as a useful application of the technical improvements described herein, but Bitcoin merely provides a useful application of the technology. The present invention is not limited to being used with the Bitcoin blockchain and alternative blockchain implementations and protocols, and includes implementations and protocols related to non-commercial applications encompassed within the scope of the present invention. For example, the present invention is useful in other blockchain implementations having similar constraints for blockchain verification and / or verification of cryptocurrency transactions such as Bitcoin. As an example, the techniques of the present disclosure are applicable to other aspects including computer-to-computer negotiation, whether or not a cryptocurrency exchange occurs.

[0003] A blockchain is an electronic ledger based on consensus, implemented as a computer-based decentralized distributed system composed of blocks. Also, a block is composed of transactions. Since there is no central system managing the ledger and the transactions of the ledger are verified using a consensus protocol among the nodes of the distributed system, it is also called a peer-to-peer electronic ledger. In some examples, a "blockchain transaction" represents an input message encoding a structured set of field values including data and a set of conditions. Meeting the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. In the case of Bitcoin, each transaction is a data structure encoding the transfer of control of digital assets among participants within the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks together form a chain that produces a permanent and immutable record of all the transactions written to the blockchain from its origin. Transactions include a small program known as a script embedded in their inputs and outputs. The script specifies how and by whom the outputs of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction (Tx) to be written to the blockchain, it must be "verified". Verification is determined by nodes based on a common set of rules used by most nodes with block generation capabilities. For example, in the Bitcoin protocol, some network nodes act as miners, perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Miners perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on a node performs this verification work by executing the relevant lock and unlock scripts for transactions that reference unspent transaction outputs (UTXOs). When the execution of the lock and unlock scripts evaluates to true and certain other conditions are met, the transaction is valid and the transaction is written to the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction must be i) verified by the node that received the transaction (i.e., when the transaction is verified, the node relays the transaction to other nodes within the network), ii) added to a new block constructed by the miner, and iii) mined (i.e., added to the public ledger of past transactions).

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both Bitcoin-based cryptocurrency security systems and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions can leverage the advantages of the blockchain (e.g., permanent, tamper-resistant records of events, distributed processes, etc.) while being more diverse in their applications.

[0006] DLT technologies such as the Bitcoin system provide a censorship-resistant method for exchanging assets or value without requiring trust in a central authority. However, the decentralized and distributed nature of Bitcoin results in limited scalability and the fact that transactions take a significant amount of time to process. For example, new blocks are validated and considered confirmed in a reliable way approximately every 10 minutes, and it is typically recommended that at least 6 blocks be generated above a transaction. In some cases, transactions have to wait significantly longer for reliable confirmation. These significant delays in on-chain transactions can result in unacceptable collisions in many applications, especially in point-of-sale retail or when assets are traded frequently, such as in foreign exchange.

[0007] Cryptocurrency exchanges play a role in the functioning of the digital currency ecosystem. They provide the primary means of converting fiat currency to digital assets and vice versa, enable trading between Bitcoin and other alternative coins (alt-coins), and provide off-chain payment capabilities. To operate efficiently, exchanges must enable participants to transfer assets with minimal collisions. This is fundamentally incompatible with on-chain transaction confirmation. As a result, most cryptocurrency exchange platforms retain control of customer deposits (and corresponding private keys), act like banks, and the balances in customer accounts are maintained in a proprietary internal database. This allows any transaction between two parties interacting with a particular exchange to require only a change to the internal database that can be executed immediately. By holding customer deposits, cryptocurrency exchanges can implement off-chain transactions in the same way that traditional banks process payments between accounts. However, such cryptocurrency exchanges may be limited to use by customers with deposits (and corresponding keys) registered with the exchange.

[0008] Therefore, in one or more of the above-described aspects, it is desirable to provide a method and an apparatus for improving blockchain technology. SUMMARY OF THE INVENTION

[0009] Accordingly, according to the present invention, a method as defined in the appended claims is provided.

[0010] As will be described in more detail below, a computer-implemented method and an electronic device are configured to perform an off-chain transaction between computer systems (e.g., computer systems that do not trust each other, also referred to as "parties") without requiring an on-chain transaction via a trusted exchange platform that implements and operates a transaction protocol. The off-chain transaction enables one computer system to generate a plurality of transactions recordable on blockchains in different environments, and ensures that appropriate transactions can be recorded on the blockchain depending on the method included in the plurality of transactions operated after the generation of the transaction by another computer system.

[0011] "Off-chain" may mean that the operation is not performed via the blockchain. To remain secure, the platform may be trusted only to follow a specified algorithm without storing information from the previous state. The information stored by the exchange may not need to obtain the complete keys necessary to generate additional transactions based on the off-chain transaction, so the information stored by the exchange can be obtained by a malicious entity without compromising the validity of the off-chain transaction. Further, even in the case of an encryption failure of the exchange (e.g., the exchange goes permanently offline or loses a key share), at least some of the off-chain transactions are valid for recording on the blockchain.

[0012] As described below, through the use of elliptic curve cryptography, a complete private key (and thus, ownership of the digital asset) can always be protected. A method and an electronic device implemented by a computer configured to perform an off-chain transaction of a digital asset between mutually untrustworthy parties through the exchange platform system described herein enables near-instantaneous generation of the off-chain transaction while maintaining the autonomy of the participants. It should be noted that "instantaneous" may mean "substantially instantaneous" or include some degree of variation. The terms are understood by those skilled in the art according to the context of the field of the present invention.

[0013] Accordingly, according to the present invention, a method (and corresponding system) as defined in the appended claims may be provided.

[0014] The method may be described as an immediate off-chain transaction (Tx) (which may also be referred to as a transfer as in a cryptocurrency application). Additionally or alternatively, the method may be described as a security or control method that guarantees or controls the recording of a particular transaction on a blockchain. As an example for illustration, the operations of a first computer system and a second computer system may be interdependent, such that the operation of one computer system depends on the operation of the other. For example, the first computer system may trigger the operation of the second computer system, but may execute first logic when the second computer system executes the operation, and may execute second logic when the second computer system does not execute the operation. The techniques described herein enable the first computer system to have a cryptographic guarantee that it can execute first logic or second logic depending on what the second computer system does. The first logic may, for example, result in the recording of a first transaction on a blockchain, and the second logic may, for example, result in the recording of a second transaction on a blockchain. In one embodiment, the second computer guarantees that (1) its own execution of the operation enables the recording of a first transaction on a blockchain, or (2) the execution of the operation prevents the recording of a second transaction on a blockchain, or (3) both.

[0015] Accordingly, the method described herein allows interdependent computer systems to operate in a way that enables them to reach a desired state via blockchain transactions, regardless of whether (with other computer systems or an exchange platform) the participants operate appropriately.

[0016] As described above, the technology described and proposed herein is applicable in a wide context. Some contexts utilize blockchain to manage digital assets. A digital asset may be represented by a value recorded on the blockchain within a transaction. Recording of a digital asset (or aggregation of records that aggregate to a value) may be a requirement for entry of a particular transaction, such as what is called "transfer" or "transfer control" of the digital asset, onto the blockchain. In some examples, a digital asset is a value that enables execution of particular computer system logic. For example, programming of a computer system may depend on recording of a digital asset that occurs on the blockchain and is caused by another computer. In some examples, a digital asset (and the value corresponding to the digital asset within a set of blockchain transactions) represents the amount of work to be performed by a computer system, data to be processed by the computer system, or other input to an algorithm to be executed by the computer system. In some examples, a digital asset is part or an amount of cryptocurrency, but the scope of this disclosure is generally applicable to other contexts that do not include payments or cryptocurrency.

[0017] In one embodiment, a transaction (Tx) is between mutually untrusted parties via an exchange platform method. The method implemented by a computer includes: i) attaching a digital asset of a first party (which may be a computer system or other similar entity) to an exchange platform, including (a) calculating a first shared (cryptographic) key associated with the digital asset using a key associated with the first party or otherwise associated with the first party and a first key associated with the exchange platform or otherwise associated with the exchange platform, and (b) (1) generating a fund transaction payable to any party from the digital asset using the first shared key, and (2) depositing the digital asset into a blockchain network by broadcasting the fund transaction to the blockchain network, thereby attaching; and ii) re-associating the digital asset from the first party to a second party (which may be a computer system or other similar entity), including (a) calculating a second key of the exchange platform using a key associated with the second party or otherwise associated with the second party, as a result of which (1) the key of the first party becomes invalid, and (2) a second shared key associated with the digital asset calculated from the key of the second party and the second key of the exchange platform is equal to the first shared key associated with the digital asset, and (b) replacing the first key of the exchange platform with the second key of the exchange platform, thereby re-associating.

[0018] According to the present invention, an electronic device may be provided. The electronic device includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor. The memory may store computer-executables that configure the processor to execute the methods described herein when executed.

[0019] According to the present invention, a computer-readable storage medium may be provided. The computer-readable storage medium includes computer-executable instructions that, when executed, configure a processor to execute the methods described herein.

[0020] According to the present invention, a computer-readable storage medium may be provided that includes an elliptic curve digital signature algorithm (ECDSA) script including computer-executable instructions that, when executed, configure a processor to execute the functions of the elliptic curve digital signature algorithm described herein.

[0021] According to the present invention, a computer-readable storage medium may be provided that includes a two-party elliptic curve digital signature algorithm (two-party ECDSA) script including computer-executable instructions that, when executed, configure a processor to execute the functions of the two-party elliptic curve digital signature algorithm described herein.

[0022] According to the present invention, a computer-readable storage medium may be provided that includes a cryptographically secure pseudo-random number generator (CSPRNG) script including computer-executable instructions that, when executed, configure a processor to execute the functions of the cryptographically secure pseudo-random number generator described herein.

[0023] A method implemented by a computer includes calculating a first shared key associated with a digital asset using a key of a first party and a first key of an exchange platform; attaching the digital asset to a blockchain network, including generating, using the first shared key, a fund transaction payable from the digital asset to any party, and broadcasting the fund transaction to the blockchain network to attach; re-associating the digital asset from the first party to a second party, including calculating a second key of the exchange platform using a key of the second party, as a result, invalidating the key of the first party, and making a second shared key associated with the digital asset calculated from the key of the second party and the second key of the exchange platform equal to the first key associated with the digital asset; and replacing the first key of the exchange platform with the second key of the exchange platform.

[0024] According to the present invention, there is provided a method implemented by a computer as described above, further including detaching the digital asset from the exchange platform, including generating, using the first shared key, a second fund transaction payable from the digital asset to the second party, where the second fund transaction is at least partially based on the fund transaction, broadcasting the second fund transaction to the blockchain network, and mining the second fund transaction to provide the digital asset to the second party.

[0025] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the step of attaching the digital asset of the first party to the exchange platform includes generating, by the first party, a first refund key from the digital asset, broadcasting the first refund transaction to the blockchain network after a first time period, and mining the first refund transaction to return the digital asset to the first party.

[0026] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the first refund transaction is co-signed by the exchange platform and the first party using the two-party elliptic curve digital signature algorithm. The step of re-associating the digital asset from the first party to the second party may include generating a second refund transaction payable to the second party from the digital asset using a second refund key, broadcasting the second refund transaction to the blockchain network after a second time period, and mining the second refund transaction to return the digital asset to the second party. The second refund transaction is co-signed by the exchange platform and the second party using the two-party elliptic curve digital signature algorithm.

[0027] According to the present invention, there is provided a method implemented by a computer as described above, wherein the step of calculating the first shared key is a step of calculating a first candidate shared key, and at least includes calculating a first public key corresponding to the second key of the exchange platform using an elliptic curve cryptography method, providing the first public key to the second party, and calculating the first candidate shared key from the first public key and the key of the second party using an elliptic curve cryptography method, thereby calculating a first candidate shared key; a step of calculating a second candidate shared key, and at least includes calculating a second public key corresponding to the key of the second party using an elliptic curve cryptography method, providing the second public key to the exchange platform, and calculating the second candidate shared key from the second public key and the second key of the exchange platform using an elliptic curve cryptography method, thereby calculating a second candidate shared key; and a step of verifying that the first candidate shared key is the same as the second candidate shared key.

[0028] According to the present invention, there is provided a method implemented by a computer as described above, wherein the second shared key associated with the digital asset is calculated at least by a step of calculating a first candidate shared key, and at least includes calculating a first public key corresponding to the first key of the exchange platform using an elliptic curve cryptography method, providing the first public key to the first party, and calculating the first candidate shared key from the first public key and the key of the first party using an elliptic curve cryptography method, thereby calculating a first candidate shared key; a step of calculating a second candidate shared key, and at least includes calculating a second public key corresponding to the key of the first party using an elliptic curve cryptography method, providing the second public key to the exchange platform, and calculating the second candidate shared key from the second public key and the first key of the exchange platform using an elliptic curve cryptography method, thereby calculating a second candidate shared key; and a step of verifying that the first candidate shared key is the same as the second candidate shared key.

[0029] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the step of re-associating the digital asset from the first party to the second party includes the step of re-associating a part of the digital asset from the first party to the second party.

[0030] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the step of replacing the first key of the exchange platform with the second key of the exchange platform includes the steps of multiplying a random value by the first key of the exchange platform to generate a blind first key of the exchange platform; providing the blind first key of the exchange platform to the second party; multiplying the reciprocal of the key of the second party by the blind first key of the exchange platform to generate a first intermediate key; providing the first intermediate key to the first party; multiplying the key of the first party by the first intermediate key to generate a second intermediate key; providing the second intermediate key to the exchange platform; and multiplying the reciprocal of the random value by the second intermediate key to generate the second key of the exchange platform.

[0031] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the step of replacing the first key of the exchange platform with the second key of the exchange platform includes disabling the first key of the exchange platform.

[0032] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the key of the first party is a private key securely held by the first party, the first key of the exchange platform is a private key securely held by the exchange platform, the key of the second party is a private key securely held by the second party, and the second key of the exchange platform is a private key securely held by the exchange platform.

[0033] According to the present invention, there may be provided a method implemented by a computer as described above, wherein the exchange platform is a trusted execution environment that stores the first key of the exchange platform, stores the second key of the exchange platform, and provides remote attestation that the exchange platform complies with an exchange protocol associated with the exchange platform.

[0034] According to the present invention, there may be provided a system including a processor and a memory including executable instructions that cause the system to execute the method implemented by a computer as described above as a result of execution by the processor.

[0035] According to the present invention, there may be provided a non-transitory computer-readable storage medium storing executable instructions that cause a processor of a computer system to execute at least the method implemented by a computer as described above as a result of execution.

[0036] The above and other aspects of the present invention will be apparent from and will be taught with reference to the embodiments described in the present specification. Embodiments of the present invention will be described below by way of example only with reference to the accompanying drawings.

Brief Description of the Drawings

[0037]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

[0038] First, refer to FIG. 1. FIG. 1 shows an exemplary blockchain network 100 associated with a blockchain in the form of a block diagram. The blockchain network 100 operates under a blockchain protocol, and a distributed electronic device that executes an instance of the blockchain protocol may participate in the blockchain network 100. Such a distributed electronic device may be referred to as a node 102. The blockchain protocol may be, for example, the Bitcoin protocol.

[0039] An electronic device that executes a blockchain protocol and forms a node 102 of a blockchain network 100 may be of various types, including computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronic devices.

[0040] Nodes 102 of the blockchain network 100 are coupled to each other using appropriate communication technologies that may include wired and wireless communication technologies. Such communication follows a protocol associated with the blockchain. For example, if the blockchain is the Bitcoin blockchain, the Bitcoin protocol may be used. Node 102 maintains a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 may store a complete copy or a partial copy of the global ledger. Transactions by node 102 that affect the global ledger are verified by other nodes 102. As a result, the validity of the global ledger is maintained. When the blockchain is a proof-of-work based blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

[0041] At least some of the nodes 102 operate as miners 104 of the blockchain network 100. The blockchain network 100 of FIG. 1 is a proof-of-work blockchain in which the miners 104 perform computationally expensive calculations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve cryptographic problems. In Bitcoin, the miner 104 discovers a nonce. As a result, the block header is hashed by double SHA-256 to a number smaller than the value determined by the current mining difficulty. The hash power required for the proof-of-work algorithm means that after a certain number of blocks have been mined on it, the transactions are considered to be practically irreversible. The miner 104 that solves the cryptographic problem generates a new block of the blockchain and broadcasts the new block to the other nodes 102. The other nodes 102 verify that the miner 104 has actually solved the cryptographic problem and thus demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. The other nodes 102 also verify that the block itself is valid (e.g., that the transaction and the block header of the block are valid) before permitting the block to be added to the blockchain. The block is added to the blockchain (i.e., to the distributed global ledger) by the consensus of the nodes 102.

[0042] The blocks generated by miner 104 contain the transactions that are being broadcast to the blockchain by node 102. For example, a block may contain a transaction from an address associated with one of the nodes 102 to an address associated with another one of the nodes 102. Thus, a block functions as a record of transactions from one address to another. The parties that require a transaction to be included in a block prove that they are authorized to initiate the transfer (e.g., in the case of Bitcoin, to spend Bitcoin) by signing the request with the private key corresponding to their public key. The transfer may be added to the block only if the request is validly signed. A party (e.g., a computer system) that can use a transaction can also "unlock" the transaction.

[0043] In the case of Bitcoin, there is a one-to-one correspondence between a public key and an address. That is, each public key is associated with a single address. Thus, references herein to transferring a digital asset to or from a public key (e.g., paying to a public key), and to transferring a digital asset to or from an address associated with a public key, represent common operations.

[0044] Some of the nodes 102 do not have to operate as miners and may instead participate as verification nodes. Verification of a transaction may relate to checking signatures or other conditions specified in a lock script, verifying references to valid UTXOs, etc. The example of FIG. 1 includes six nodes 102, two of which are participating as miners 104. In practice, the number of nodes 102 or miners 104 may be different. In many blockchain networks, the number of nodes 102 and miners 104 may be much greater than the numbers shown in FIG. 1.

[0045] FIG. 2 shows an exemplary electronic device 200 that can function as a node (e.g., a node such as one of the nodes 102 described in connection with FIG. 1) in a blockchain network (e.g., a blockchain network such as the blockchain network 100 described in connection with FIG. 1) in block diagram form. The exemplary electronic device 200 may function as a node such as one of the nodes 102 in a blockchain network such as the blockchain network described in connection with FIG. 1. In one embodiment, the blockchain network is a peer-to-peer blockchain network.

[0046] The electronic device may take various forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smartwatch, or another type of form.

[0047] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores a computer software program including machine-readable instructions and data for performing the functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement a protocol associated with the blockchain network 100 (e.g., the blockchain network 100 described in connection with FIG. 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0048] Memory 220 may store the global ledger of a blockchain network (e.g., the blockchain network 100 described in connection with FIG. 1) or a portion thereof. That is, memory 220 may store all the blocks of the blockchain, or a portion of the blocks such as the most recent blocks, or a portion of the information in some blocks.

[0049] Memory 220 is shown as a single block in FIG. 2, but in reality, the electronic device 200 may include multiple memory components. The memory components may be of various types including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Further, although memory 220 is shown separately from processor 210, processor 210 may include built-in memory.

[0050] As shown in FIG. 2, processor 210 may include a secure area such as a Trusted Execution Environment (TEE). TEE 250 is an independent execution environment that provides additional security to the electronic device 200, such as independent execution, integrity of trusted applications, and asset confidentiality. TEE 250 provides an execution space that guarantees that the computer instructions and data loaded inside TEE 250 are protected in terms of confidentiality and integrity. TEE 250 may be used to protect the integrity and confidentiality of critical resources such as cryptographic keys. TEE 250 is implemented at least partially at the hardware level. As a result, the instructions and data executed within TEE 250 are protected against access and manipulation from the rest of the electronic device 200 and from external parties such as the owner of the electronic device. The data and calculations within TEE 250 are secured from the party operating the node (e.g., node 102 described in connection with FIG. 1) that includes TEE 250.

[0051] The TEE250 can operate to instantiate a secure execution environment (also referred to herein as an "enclave") and then add memory pages one by one, while cumulatively hashing the added memory pages. In one embodiment, the hashing of the memory pages is performed on a remote machine (e.g., the developer's machine or another machine). As a result, the remote machine determines and stores the expected hash. The content of the enclave can thus be verified by any remote machine, ensuring that the enclave is executing an approved algorithm. This verification may be performed by comparing the hashes. Once the enclave is fully constructed, it is immobilized. It is possible to execute code within the TEE250 and send secrets to the code, but once the enclave is locked, the code cannot be changed. The final hash may be signed with an attestation key and made available for the data owner to verify it before the data owner sends any secrets to the enclave.

[0052] As described below, the TEE250 may be used to protect the reliability and integrity of the shared keys stored in the exchange. For example, the TEE250 may be used for the generation and storage of secret key shares. The TEE250 is for ensuring that no member can directly obtain information regarding the secret key shares or other secret key shares held within the TEE250 from member-to-member communication or enclave-to-enclave communication. The protocol is also robust against the compromise of threshold enclaves. Further, the TEE250 may enable remote attestation. Remote attestation may be used by a node (e.g., a node such as one of the nodes 102 described in connection with FIG. 1) to prove to other nodes that the TEE250 is secure and executing approved computer-executable instructions for the protocol implemented by the blockchain network 100. Remote attestation may be provided by the TEE250 by executing a particular piece of code and transmitting, within the enclave, a hash of the code signed by the enclave's internal attestation key.

[0053] The TEE250 may include a secure random number generator. This secure random number generator is within the enclave of the TEE and can be used to generate secret keys, random challenges, or other random data. The TEE250 may also be configured to read data from external memory and write data to external memory. Such data may be encrypted with a secret key held only within the enclave.

[0054] The TEE250 may be implemented using various platforms such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). SGX, for example, supports remote attestation. Remote attestation enables an enclave to obtain a signed statement from the processor executing a particular enclave as a member-provided hash known as a quote. A third-party attestation service such as the Intel Attestation Service (IAS) may authenticate that these attested statements originate from a genuine CPU compliant with the SGX specification.

[0055] The present invention may provide a method (and corresponding system) configured to change a cryptographic public key embedded within a lock script of a blockchain transaction (Tx) using undetermined data provided within an unlock script of another transaction. For example, when used in relation to a signature check opcode (e.g., OP_CHECKSIG) in the Bitcoin protocol that uses transaction bytecode as a message, both the transaction and the data require authorization or authentication from the owner of the public key. This protects them from being changed.

[0056] The method described in this specification verifies various transactions using one or more digital signature schemes. The digital signature scheme may be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. The digital signature may be a two-party ECDSA scheme. The digital signature may be a threshold ECDSA scheme. This scheme may be used to construct a valid signature without the need to reconstruct the private key and without any party having to disclose their key share to another party. For example, in a two-party ECDSA scheme, two parties exist and both need to reconstruct the private key. However, in the ECDSA scheme, when generating a signature corresponding to a shared private key, the private key may not need to be reconstructed to generate the signature. In one embodiment, the signature corresponding to the shared private key is generated without reconstructing (i.e., regenerating) the shared private key.

[0057] This ECDSA scheme includes various mechanisms that can be used by nodes such as node 102 described in connection with FIG. 1 to identify malicious or non-cooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomial required for Shamir's Secret Sharing (SSS). SSS is a form of secret sharing where the secret is divided into parts and each participant is provided with their own unique part. These parts may be necessary to reconstruct the secret. VSS may be used by nodes to identify malicious nodes or members when conflicting shares are provided to different nodes 102, or when shares are sent secretly to nodes as opposed to hidden shares that are broadcast to all nodes. The conflicting shares may be identified by any of the nodes. The sharing of the secret can be made verifiable by including auxiliary information that allows the nodes to verify that their shares are non-conflicting.

[0058] Transmission of an incorrect share to an individual node (i.e., a share different from the hidden share that is broadcast) can be identified by the intended receiving node of the share. Identification of an incorrect share being secretly sent to a node can be made publicly verifiable using the technology of Publically Verifiable Secret Sharing (PVSS). Such technology can avoid the delay that may occur in identifying an incorrect sender, which may occur when PVSS is not used and the receiving side of the incorrect share is offline or separated from the fundamental part of the network when the incorrect share is sent.

[0059] Improper acts such as providing conflicting shares to different nodes can be resolved by a network that prevents malicious acts. For example, when a node is identified as a malicious party by other nodes, a majority of nodes may cooperate to impose a penalty on the malicious party. For example, a node may take measures related to digital assets (digital currency, tokens, or other stakes or values) deposited in a blockchain network by a malicious party. For example, the blockchain network may burn them by transferring them to an unusable address. Alternatively, the blockchain network may confiscate such digital assets by reaching a consensus with other nodes to reject them. Nodes that are not the nodes performing the improper act may prevent improper acts by cooperating to exclude the nodes performing the improper act (e.g., by effectively invalidating key shares, e.g., by excluding nodes from participating in a council protocol, or by re-sharing secret keys and not allocating shares to the nodes performing the improper act).

[0060] The above ECDSA technology may be extended through the use of a TEE. For example, threshold ECDSA signature technology anticipates a powerful form of adversary here called a Byzantine adversary. This type of adversary may act arbitrarily. For example, they may not only refuse to participate in the signature process or stop a party midway, but may also pretend to participate honestly and send malicious information. However, by using a TEE and generating data for use in signatures within the enclave of the TEE where the secret private key shares are stored, additional security can be provided because the enclave is very unlikely to be exposed to a significant number of risks. If each TEE is assigned more than one key share, for example, the number of TEEs exposed to possible risks can reasonably be expected not to approach the threshold of robustness against adversaries, assuming n is large enough. This makes the protocol secure when it is resistant to a small percentage of malicious adversaries relative to the total number of key shares.

[0061] For example, if all nodes have a TEE, the acquisition of secrets stored within the enclave can only be achieved with great effort and expense, only by physical access to the node, provided the TEE manufacturer has not fallen. Such manufacturer-level corruption is expected to be manageable. For example, if the manufacturer were to falsely claim that a large number of public keys correspond to honest TEEs, they could gain direct access to the private key shares and initiate an attack. However, such an attack may require a sufficient number of key shares for the manufacturer to generate valid signatures without the assistance of other nodes. This could mean accumulating a large portion of all the stakes, which can be very costly. Furthermore, by executing the attack, a large portion of the value of the stakes held can be destroyed.

[0062] When a TEE is used, it is useful to intend the robustness of the protocol against "corrupted nodes". A corrupted node is a node where the hardware outside the TEE contains errors but the integrity of the TEE is not put at risk. A corrupted node may have control over what information the enclave receives and does not receive. In particular, a corrupted node may stop, i.e., refrain from participating in the protocol. If the information provided to the protocol needs to be signed by a secret key that is secretly held within the enclave (when the corresponding public key is authenticated during attestation), the secret key can be as trustworthy as the enclave itself. Thus, a corrupted node cannot send arbitrary (authenticated) information to the protocol and can only try to interfere by stopping or trying to deceive the enclave into misbehaving, e.g., by providing old information. Next, in a corrupted node, a successful attack may require collecting a sufficient number of partial signatures to generate a complete signature.

[0063] In one or more embodiments, other threshold schemes including non-ECDSA signature schemes may be used.

[0064] Nodes within a blockchain network may implement an exchange protocol based on a selected digital signature scheme. Such nodes may include computer-executable instructions stored in memory 220 that implement the exchange protocol. When executed by a processor 210, such instructions cause a node (such as electronic device 200) to execute one or more methods of the exchange protocol. Such methods may include, but are not limited to, methods implemented by any one or combination of processes 300, 500, 800, 1300, or 1500 of FIGS. 3, 5, 8, 13, and 15. Thus, the exchange protocol may include one or more of processes 300, 500, 800, 1300, or 1500 of FIGS. 3, 5, 8, 13, and 15. The processes may be executed by the node or may be executed in cooperation by other nodes of the blockchain network.

[0065] Figure 3 shows, in flowchart form, an exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform. Process 300 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as blockchain network 100 described in connection with FIG. 1. That is, a node such as one of the nodes 102 described in connection with FIG. 1 may perform exemplary process 300 to perform an off-chain cryptocurrency transaction between untrusted parties using the exchange platform described in connection with FIG. 3.

[0066] In step 302 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a party attaches a cryptocurrency deposit to the exchange platform and generates a funds and refund transaction using at least a shared key described hereinafter in connection with FIGS. 4-6.

[0067] In step 304 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party transfers ownership of the deposit to a second party (i.e., re-associates the deposit from the first party to the second party) using a slide protocol that generates a new refund transaction and a new shared key, as described hereinafter in connection with FIGS. 7-11.

[0068] In step 306 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, it is determined whether to detach the cryptocurrency transaction from the exchange platform (i.e., it is determined whether the current owner will claim the cryptocurrency deposit).

[0069] In step 306 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined to detach the cryptocurrency transaction from the exchange platform, then in step 308 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using the exchange platform, the current owner of the deposit detaches the deposit from the exchange using the current shared key, as will be described later in connection with at least FIGS. 12 and 13.

[0070] In step 306 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is not determined to detach the cryptocurrency transaction from the exchange platform, then in step 310 of exemplary process 300 for performing an off-chain cryptocurrency transaction between untrusted parties using the exchange platform, a timeout occurs and the current owner of the current deposit, as will be described later in connection with at least FIGS. 14 and 15, the current recipient issues a refund transaction to return the deposit to the previous owner.

[0071] Note that one or more of the operations performed in exemplary process 300 shown in FIG. 3 may be performed in various orders and combinations including in parallel.

[0072] FIG. 4 shows in block diagram form an exemplary environment 400 in which the attach phase of an off-chain cryptocurrency transaction between untrusted parties is performed using an exchange platform. Each of the blocks of the block diagram of exemplary environment 400 will be described in detail below in connection with FIGS. 5 and 6.

[0073] Party 402 may initiate the attachment phase of an off-chain cryptocurrency transaction between untrusted parties 404 by attaching cryptocurrency deposit 406 to an exchange platform 408. In one embodiment, Party 402 is a node such as one of the nodes 102 described in connection with FIG. 1. Cryptocurrency 406 may be based on Bitcoin or may be based on any other similar cryptocurrency defined as attachable by exchange platform 408.

[0074] Party 402 and exchange 408 then cooperate to generate a shared public key 410. The shared public key 410 is used by Party 402 to generate a transaction 412 that is broadcast (414) to blockchain 416 as described herein. In one embodiment, transaction 412 is payable from cryptocurrency deposit 406 to any party capable of generating the shared key 410 (i.e., transaction 412 pays the amount from cryptocurrency deposit 406 to the shared public key 410). In one embodiment, transaction 412 is payable from cryptocurrency deposit 406 to any party capable of providing a signature corresponding to the private key associated with the shared public key 410 (i.e., transaction 412 pays the amount from cryptocurrency deposit 406 to an entity capable of providing a signature corresponding to the private key associated with the shared public key 410). In one embodiment, transaction 412 pays out the entire cryptocurrency deposit 406. In one embodiment, transaction 412 pays out a portion of cryptocurrency deposit 406 and one or more other transactions pay out other portions of cryptocurrency deposit 406. The shared public key 410 is generated from the private keys of Party 402 and exchange platform 408, as well as the public keys of Party 402 and exchange platform 408, as described herein.

[0075] Party 402 also generates a refund transaction 418 that enables the party to recapture the cryptocurrency deposit 406 after the passage of time from something. In one embodiment, the refund transaction 418 time period (also referred to herein as the "timeout" and denoted as t0) is based on a future time such as the time maintained by one or more computer systems. In one embodiment, the refund transaction time period is based on a future block height of the blockchain 416 (e.g., the number of blocks in the blockchain that is more than the current block number of the blockchain). It should be noted that the refund transaction time period may be substantially longer than the expected lifespan of the attachment. For example, if the expected attachment period is 30 days from when the attachment starts, the refund transaction 418 time period may be 90 days. The party saves the refund transaction 418 instead of broadcasting the refund transaction. The party may broadcast the refund transaction 418 when the timeout expires, as described below.

[0076] Although not shown in FIG. 4, Party 402 and the exchange platform 408 co-sign the refund transaction 418 with the shared public key 410 using the two-party ECDSA protocol as described herein.

[0077] It should be noted that the security of the cryptocurrency deposit 406 is derived from the multiple splitting of the complete private key in combination with the use of two-party ECDSA as described herein. The shared public key 410 is calculated during the attachment, but as described below, no party knows the complete private key at any point until it is reconstructed at the detachment.

[0078] Since the key shares are updated as described below, the key shares of the private key become invalid. However, the invalidation of the previous party's key shares depends on the exchange platform 408 replacing the key shares and deleting all records of the previous values of the key shares. When following this protocol, the scheme is secure in the case of attachment as long as the current exchange platform 408 key shares do not collide with anyone other than the current owner. Therefore, if the exchange platform 408 follows the protocol of replacing the key shares and deleting all records of the previous values of the key shares, the exchange platform 408 does not need to be trusted to maintain the security of the cryptocurrency deposit 406.

[0079] If the exchange platform 408 behaves dishonestly and retains records of the previous iterations of the key shares, there is a possibility that the exchange platform 408 could collude with the previous owner of the funds to regenerate the complete key. This collusion is unlikely to be in the long-term interest of the exchange platform 408 as a business. However, a malicious entity could gain control of the exchange platform and record all information when transactions are processed. In this case, the malicious entity may also need to collude with the previous owner of the funds to regenerate the complete key. Since the attack requires the simultaneous theft of both the exchange and deposit keys, or collusion with the previous legitimate owner of the funds, the likelihood of a malicious entity compromising the exchange platform 408 is limited.

[0080] As described above, in one embodiment, the exchange platform 408 may include a TEE. In the above-described embodiments, in order to maintain the security of the system, it is not even required that the exchange platform replace the key share and delete all records of the previous value of the key share. By operating the exchange protocol within the TEE, the exchange key share is further protected by the TEE. Alternatively, the TEE can attest remotely to other participants that they comply with the protocol within the TEE and, as a result, it is impossible for the exchange platform 408 to discover or record the key share. In such an embodiment, the exchange platform 408 is the only party required to contribute within the TEE. Other participants do not require a TEE to implement the exchange protocol.

[0081] FIG. 5 shows, in flowchart form, an exemplary process 500 for performing the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform. Process 500 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the exemplary process 500 to perform the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using the exchange platform described in connection with FIG. 5.

[0082] In step 502 of exemplary process 500 for performing the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a party begins to attach a cryptocurrency deposit to the exchange.

[0083] In step 504 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a party generates an attach private key and a refund private key. In one embodiment, the party generates the attach private key and the refund private key using a computationally secure pseudo-random number generator, such as a pseudo-random number generator provided by a key generation service.

[0084] In step 506 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party calculates an attach public key corresponding to the attach private key and transmits the attach public key to the exchange. In one embodiment, the party calculates the attach public key corresponding to the attach private key using elliptic curve cryptography (ECC) operations.

[0085] In step 508 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the exchange generates an exchange private key. In one embodiment, the exchange generates the exchange private key using a computationally secure pseudo-random number generator, such as a pseudo-random number generator provided by a key generation service.

[0086] In step 510 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the exchange calculates an exchange public key corresponding to the exchange private key and transmits the exchange public key to the party. In one embodiment, the exchange calculates the exchange public key corresponding to the exchange private key using ECC.

[0087] In step 512 of exemplary process 500 for performing the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party and the exchange each generate a shared public key from their respective private keys and the received public keys, as described below. In one embodiment, the party and the exchange can jointly verify the calculations so far by comparing their generated shared public keys with the shared public keys generated by others (e.g., the party can compare the shared public key it generated with the shared public key generated by the exchange, and vice versa). The values should be the same. Before jointly verifying the calculations in this regard, the shared public key generated by the party and the shared public key of the exchange may be referred to as candidate shared keys in this specification. Thus, for example, the shared public key generated by the party may be referred to as a first candidate shared value in this specification, and the shared public key of the exchange may be referred to as a second candidate shared key in this specification (or vice versa). The party and the exchange can jointly verify the calculations in this regard by verifying that the first candidate shared key is the same as the second candidate shared key.

[0088] In step 514 of exemplary process 500 for performing the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described in this specification, the party generates a cryptocurrency transaction to pay the amount of the cryptocurrency using the shared public key.

[0089] In step 516 of exemplary process 500 for performing the attachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party calculates a refund public key corresponding to the refund private key and sends the refund public key to the exchange. In one embodiment, the party calculates the refund public key corresponding to the refund private key using ECC.

[0090] In step 518 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a party generates a refund transaction having a timeout value using a refund public key. As a result, the party can claim a refund after the specified timeout value using the refund private key.

[0091] In step 520 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party and the exchange co-sign a refund transaction that the party saves for future use, as described below. In one embodiment, the party and the exchange co-sign the refund transaction using two-party ECDSA based on the party's attach private key and the exchange's attach private key.

[0092] In step 522 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party verifies the co-signature of the refund transaction based on the party's attach private key and the exchange's attach public key.

[0093] In step 524 of exemplary process 500 for performing the attach phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described herein, the party broadcasts the cryptocurrency transaction to the cryptocurrency network (e.g., to the blockchain of the Bitcoin network).

[0094] Note that one or more of the operations performed in exemplary process 500 shown in FIG. 5 may be performed in various orders and combinations, including in parallel.

[0095] Figure 6 shows a data flow diagram 600 of the attachment stage of an off-chain cryptocurrency transaction between untrusted parties executed using an exchange platform. Party 604 starts the attachment stage of the off-chain cryptocurrency transaction and generates an attachment private key (S1) and a refund private key (Y1) 608. Party 604 then calculates the attachment public key (S1×G) using ECC 610 and sends the attachment public key to the exchange 602.

[0096] The exchange 602 generates an exchange private key (S E ) 606 and, in response to receiving the attachment public key (S1×G) from Party 604, calculates an exchange attachment public key (S E ×G) using ECC 612 and sends the exchange attachment public key to Party 604.

[0097] Party 604 calculates a shared public key (A) by multiplying the party's attachment private key (S1) by the exchange's attachment public key (S E ×G) using ECC 616. It should be noted that Party 604 does not have access to the exchange's attachment private key (S E ) but only has access to the calculation result of the exchange's attachment public key (S E ×G) received from the exchange 602.

[0098] The exchange 602 calculates a shared public key (A) by multiplying the exchange's attachment private key (S E ) by the party's attachment public key (S1×G) using ECC 614. As used in this specification, the symbol "×" (e.g., in the calculation of S1×G) represents an elliptic curve multiplication operation where an integer (e.g., S1) is multiplied by a "point" (e.g., G) on the elliptic curve. It should be noted that the exchange 602 does not have access to the party's attachment private key (S1) but only has access to the calculation result of the party's attachment public key (S1×G) received from Party 604. Due to the properties of ECC, the shared public key (A) of the exchange 602 (S E×(S1×G)) is the shared public key (A) of Party 604 (S1×(S E ×G)), and the shared public key (A) is the same when the shared public key is generated by calculating the public key from the shared secret key (S). Here, the shared secret key is (S E *S1) or (S1*S E ). As used in this specification, the symbol "*" indicates standard multiplication (as opposed to the elliptic curve multiplication indicated by the symbol "×" as described above). Therefore, A = S×G.

[0099] As shown in FIG. 6, Party 604 generates a cryptocurrency transaction 618 (denoted as Tx0) and broadcasts the cryptocurrency transaction 618 to the cryptocurrency network 620. In one embodiment, Party 604 delays the broadcast of the cryptocurrency transaction 618 to the cryptocurrency network 620 until after the party verifies the signature of the refund transaction and completes the attachment step, as described in connection with FIG. 5.

[0100] Party 604 calculates the refund public key (B1) from the refund secret key (Y1) by ECC at 622 (e.g., B1 = Y1×G), and uses the refund public key (B1) to generate a refund transaction 630 (denoted as Tx1) having a timeout value t o , and sends the refund public key (B1) to the exchange. As a result, when the refund transaction 630 is broadcast to the cryptocurrency network 620 as described below, the refund public key (B1) can be used later.

[0101] Party 604 and the exchange 602 jointly sign the refund transaction 630 using two-party ECDSA to calculate a signature (Sig(S E , S1)) based on the attachment secret key (S E ) of the exchange and the attachment secret key (S1) of the party, thereby completing the attachment step.

[0102] Figure 7 shows, in block diagram form, an exemplary environment 700 in which the transfer stage of an off-chain cryptocurrency transaction between untrusted parties is executed using an exchange platform. A first party 702 (shown as "Party 1" in Figure 7) has a shared key 710 with the exchange platform 704 for a cryptocurrency deposit 706, which may be one of a plurality of cryptocurrency deposits 708 attached to the exchange platform 704 as described herein. The first party 702 has a refund transaction 712 with a timeout t0.

[0103] As will be described later with reference to Figures 8 - 10, when the first party 702 transfers ownership of some or all of the cryptocurrency deposit 706 to a second party 714 (shown as "Party 2" in Figure 7), the second party 714 and the exchange platform 704 generate a new shared key 716 using the techniques described herein, and the second party 714 generates a refund transaction 718 with a timeout t0 - t c as described above, where t c is selected at least in part based on a desired attachment period. In one embodiment, t c is selected to be longer than the expected confirmation time of a transaction within the Bitcoin network. For example, if the expected confirmation time of a transaction within the Bitcoin network is 1 hour (i.e., 6 blocks every 10 minutes), then t c is selected to be longer than 1 hour. When the first party 702 transfers ownership of some or all of the cryptocurrency deposit 706 to the second party 714 (e.g., when the first party transfers ownership of at least a portion of the cryptocurrency deposit), the act of transferring ownership may be referred to herein as "reassociating the cryptocurrency deposit" or "reassociating the digital asset" (e.g., "reassociating the digital asset from the first party to the second party" or "reassociating a portion of the digital asset from the first party to the second party").

[0104] For example, if the desired attachment period is 30 days and t0 is selected to be longer than the desired attachment period (e.g., 90 days), then t c may be selected such that sufficient time for refund to a particular party can be generated, while on the other hand, a sufficient number of transfers of ownership can occur before the end of the cryptocurrency deposit 706. For example, if t c is 30 minutes (or, in one embodiment, a confirmation time of 10 minutes per block and 3 blocks), then t0 - n*t c (n = 2880) can result in approximately 2880 transfers of ownership occurring before it becomes less than 30 days (e.g., the desired attachment period). In other words, if t c is 30 minutes, there are 48 refund periods per 24 hours in a day and 2880 refund periods in 60 days.

[0105] The second party 714 and the exchange platform 704 generate a new shared key 716. When the new shared key 716 is valid at 720, the shared key 716 becomes invalid at 722 and can no longer be used to claim the cryptocurrency deposit 706. Thus, at all times, only one shared key (e.g., shared key 710 or new shared key 716) is valid, and this valid shared key indicates the current ownership of the cryptocurrency deposit 706.

[0106] FIG. 8 shows, in flowchart form, an exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform. The process 800 may be performed by a node such as one of the nodes 102 of the blockchain network 100 described in connection with FIG. 1. That is, a node such as one of the nodes 102 described in connection with FIG. 1 may execute the exemplary process 800 to perform a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using the exchange platform described in connection with FIG. 8.

[0107] In step 802 of exemplary process 800 for performing the transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the first party begins transferring ownership of the cryptocurrency deposit attached to the exchange to the second party.

[0108] In step 804 of exemplary process 800 for performing the transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party generates a new attachment secret key and a new refund key. In one embodiment, the second party generates the new attachment secret key and the new refund secret key using a computationally secure pseudorandom number generator, such as a pseudorandom number generator provided by a key generation service.

[0109] In step 806 of exemplary process 800 for performing the transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the exchange multiplies the exchange secret key by a random value and sends the result to the second party. The random value is a random value (also referred to herein as a random blind factor) that causes the exchange secret key to be hidden from all parties (including the first party and the second party). In one embodiment, the random value is generated using a computationally secure pseudorandom number generator, such as a pseudorandom number generator provided by a key generation service.

[0110] In step 808 of exemplary process 800 for performing the transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party multiplies the value received from the exchange by the reciprocal of the new attachment secret key (i.e., the reciprocal of the second party's attachment secret key) and sends the result of this multiplication to the first party.

[0111] In step 810 of exemplary process 800 that executes a transfer stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the first party multiplies the value received from the second party by the first party's attachment private key and transmits the result of this multiplication to the exchange.

[0112] In step 812 of exemplary process 800 that executes a transfer stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the exchange multiplies the value received from the first party by the reciprocal of a random value and stores this result as a new exchange private key. By multiplying the value received from the first party by the reciprocal of the random value, the exchange platform reverses the initial blinding of the random blindance performed by the exchange in step 806. The resulting value is the exchange attachment private key combined with the reciprocal of the first party's attachment private key and the second party's attachment private key. This resulting value becomes the exchange's new attachment private key, and the exchange's old attachment private key is discarded.

[0113] In step 814 of exemplary process 800 that executes a transfer stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, after step 812 of exemplary process 800 that executes a transfer stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party's attachment private key becomes valid as described herein, and the first party's attachment private key becomes invalid (i.e., the first party's attachment private key can no longer be used to distribute cryptocurrency deposits). Since the first party's attachment private key no longer corresponds to the exchange secret attachment key (e.g., the new exchange secret attachment key), the first party's attachment private key becomes invalid due to the discard of the previous exchange attachment private key.

[0114] In step 816 of exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described above in connection with step 512 of FIG. 5, the second party verifies a new attachment private key jointly with the exchange (e.g., both the second party and the exchange generate a shared public key and compare the generated values to ensure they are the same).

[0115] In step 818 of exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party calculates a new refund public key from the new refund private key and transmits the new refund public key to the exchange. In one embodiment, the second party calculates the new refund public key from the new refund private key using ECC.

[0116] In step 820 of exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described herein, the second party generates a new refund public key having a new timeout value prior to the first party's refund transaction timeout value.

[0117] In step 822 of exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party and the exchange jointly sign a new refund transaction that the second party stores for future use, as described herein.

[0118] In step 824 of exemplary process 800 for performing a transfer phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the second party verifies the joint signature of the new refund transaction based on the second party's attachment private key and the exchange's attachment public key.

[0119] Note that one or more of the operations performed in the exemplary process 800 shown in FIG. 8 may be performed in various orders and combinations, including in parallel.

[0120] FIG. 9 shows a first portion 900 of a data flow diagram of the transfer stage of an off-chain cryptocurrency transaction between untrusted parties executed using an exchange platform. A first party 904 (shown as "Party 1" in FIGS. 9 and 10) initiates the transfer stage of the off-chain cryptocurrency transaction and transfers ownership of a cryptocurrency deposit attached to the exchange 902. In the example shown in FIG. 9, the first party 904 is transferring ownership of the cryptocurrency deposit from the first party 904 to a second party 906 (shown as "Party 2" in FIGS. 9 and 10).

[0121] The exchange 902 generates a random value (R) 908 and uses the random value to calculate the exchange's blind attachment secret key (RS E ) 912. As described above, the random value (also referred to herein as a random "blind nonce") ensures that the exchange's attachment secret key (S E ) cannot be determined by any of the parties or by any malicious attacker. The exchange 902 sends the exchange's blind attachment secret key (RS E ) to the second party 906.

[0122] The second party 906 generates an attachment secret key (S2) and a refund secret key (Y2) 910 as described above. The second party 906 multiplies the modular inverse of the attachment secret key (S2 E ) by the exchange's blind attachment key (RS -1 ) to calculate an intermediate key value 914. The second party 906 sends the result of this multiplication (RS E S2 -1 ) to the first party 904.

[0123] The first party 904 receives the value (RS E S2 -1) Calculate a second intermediate key value by multiplying the attachment secret key (S1) of the first party 904 by 916. The first party 904 transmits the result (RS E S2 -1 S1) of this multiplication to the exchange 902.

[0124] The exchange 902 multiplies the value (RS E S2 -1 S1) received from the first party 904 by the reciprocal (R -1 ) of the random blinding number (R) to calculate a new attachment secret key (S E S2 -1 S1) at 918. When the exchange 902 replaces the previous attachment secret key (S E ) with the new secret key (S E S2 -1 S1) at 920, as described in the present specification, the secret attachment key (S1) of the first party 904 becomes invalid at 922.

[0125] Note that even when the secret attachment key (S1) of the first party 904 becomes invalid at 922, the complete shared secret key (S) and the corresponding shared public key (A) remain unchanged. However, it can only be composed of the new secret attachment key (S E new ) of the exchange 902 and the secret attachment key (S2) of the second party 906. The reason is as follows: S new =S E new S2=(S E old S2 -1 S1)S2=(S E old S1S2 -1 )S2=(S E old S1)(S2 -1 S2)=(S E old S1)=S old However, when the exchange 902 is operating the protocol correctly, S new is not equal to S E new S1, and SE old No longer exists.

[0126] FIG. 10 shows a second part 1000 of a data flow diagram of a transfer stage of an off-chain cryptocurrency transaction between untrusted parties executed using an exchange platform. The second part 1000 of the data flow diagram of the transfer stage of the off-chain cryptocurrency transaction between untrusted parties follows the first part 900 of the data flow diagram shown in FIG. 9. Here, a first party 904 (corresponding to the first party 1004 in FIG. 10) is transferring ownership of a cryptocurrency deposit from the first party 904 to a second party 906 (corresponding to the first party 1006 in FIG. 10).

[0127] In the second part 1000 of the data flow diagram of the transfer stage of the off-chain cryptocurrency transaction between untrusted parties executed using an exchange platform, the first party 1004 does not participate. The second party 1006 calculates 1008 an attached public key (S2×G) corresponding to an attached private key (S2) using ECC and sends the attached public key to an exchange 1002 (corresponding to the exchange 902 described in FIG. 9).

[0128] The exchange 1002 also calculates 1010 an attached public key (S E ) corresponding to a new exchange attached private key (S E ×G) and sends the attached public key to the second party 1006.

[0129] The second party 1006 calculates 1014 a shared public key (A) by multiplying (using ECC) the attached private key (S2) of the second party by the attached public key (S E ×G) of the exchange. It should be noted that the second party 1006 does not have access to the attached private key (S E ) of the exchange but only has access to the calculation result of the attached public key (S E ×G) received from the exchange 1002.

[0130] The exchange 1002 calculates the shared public key (A) by multiplying the attached private key (S E ) of the exchange by the attached public key (S2×G) of the second party (by ECC). It should be noted that the exchange 1002 does not have access to the attached private key (S2) of the second party, but only has access to the calculation result of the attached public key (S2×G) of the second party received from the second party 1006. Due to the characteristics of ECC, the shared public key (A) (S E ×(S2×G)) of the exchange 1002 is the same as the shared public key (A) (S2×(S E ×G)) of the second party 1006, and the shared public key (A) is the same when the shared public key is generated by calculating the public key from the shared secret key (S). Here, the shared secret key is (S E *S2) or (S2*S E ). Therefore, as described above, A = S×G. In one embodiment, after the operation of the transfer stage, both A and the shared secret key S remain unchanged.

[0131] The second party 1006 calculates the refund public key (B2) from the refund private key (Y2) by ECC as described in this specification 1016 (for example, B2 = Y2×G), and uses the refund public key (B2) to generate a refund transaction 1024 (shown as Tx2) having a timeout value t o -t c , and sends the refund public key (B1) to the exchange. As a result, when the refund transaction 630 is broadcast to the cryptocurrency network 620 as described later, the refund public key (B1) can be used later.

[0132] The second party 1006 and the exchange 1002 jointly sign the refund transaction 1024 using two-party ECDSA to calculate a signature (Sig(S E ,S2)) based on the attached private key (S E ) of the exchange and the attached private key (S2) of the second party, thereby completing the transfer stage.

[0133] FIG. 11 shows, in block diagram form, an exemplary environment 1100 in which multiple ownership transfers of an off-chain cryptocurrency transaction between untrusted parties are executed using an exchange platform. The exchange platform 1102 has a current attached secret key (S E ) 1104 multiplied by a random blind factor (R) as described herein. The result (RS E ) 1108 is provided to a party 1110 (in this case, the fourth party, denoted as "P4"). In the example shown in FIG. 11, the party 1110 is the party to which the ownership is transferred, and the party 1116 (in this case, the third party, denoted as "P3") is the party from which the ownership is transferred.

[0134] As described above, the party 1110 uses the result (RS E ) 1108 to generate a refund transaction 1112 (denoted as Tx4) having a timeout value t0 - 3t c . As described above, the party 1110 combines the result (RS E ) 1108 with the reciprocal (S4 -1 ) of the attached secret key (S4) of the party 1110 to generate an intermediate key value (RS E S4 -1 ).

[0135] The intermediate key value (RS E S4 -1 ) 1114 is provided to the party 1116 having a previous refund transaction 1118 (denoted as Tx3) with a timeout value t0 - 2t c . The party 1116 multiplies the intermediate key value (RS E S4 -1 ) 1114 by the attached secret key (S3) of the party 1116 to generate an intermediate key value (RS E S4 -1 ) 1114 is used to generate an intermediate key value (RS E S4 -1 S3) 1120.

[0136] The party 1116 uses the intermediate key value (RS E S4 -1S3) 1120 to the exchange 1102. The exchange 1102 sends the new attachment private key (S E S4 -1 S3) into the intermediate key value (RS E S4 -1 S3) 1120. The exchange 1102 extracts the intermediate key value (RS E S4 -1 New Attached Private Key from S3)1120 E S4 -1 S3) to retrieve the old attachment private key (S E ) to replace 1122.

[0137] The exchange 1102 receives the intermediate key value (RS E S4 -1 New Attached Private Key from S3)1120 E S4 -1 S3) to retrieve the old attachment private key (S E ) 1122, the attached private key (S3) from party 1116 becomes invalid 1136.

[0138] In the example shown in FIG. 11, the exchange 1102 receives the intermediate key value (RS E S4 -1 New Attached Private Key from S3)1120 E S4 -1 S3) to retrieve the old attached private key (S E ) to replace the currently attached private key (S E ) 1104 is a private attachment key (S E S3 -1 S2) 1128. Similarly, the previous private attachment key (S E S2 -1 S1) 1134 is created as a result of an ownership transfer from party 1130 (denoted "P2") to party 1124 (i.e., the first ownership transfer described above).

[0139] In the example shown in FIG. 11, the refund transaction 1112 of the party 1110 is cFrom t0 - 2t c is available until, and the refund transaction before Party 1116 is, t0 - 2t c From t0 - t c is available until, and the refund transaction 1126 of Party 1124 is, t0 - t c From t0 until is available, and the refund transaction 1132 of Party 1130 (i.e., the first party) is available after t0.

[0140] In the example shown in FIG. 11, S E each time is updated, the previous key share becomes invalid, and even if S E is later leaked, it cannot be used. The transfer speed may be limited by the communication channel delay and / or the execution time of the operations described in this specification. As expected, the cost of arithmetic operations can be ignored, and ECC operations can be calculated in less than a millisecond on modern CPUs. Two-party ECDSA is more efficient and takes only a few seconds for the calculation. However, two-party ECDSA only requires a refund transaction. Almost instant transfer can be performed when each of the parties is online and responds to the requests associated with the transfer operation.

[0141] Each time the ownership changes, a new refund transaction is generated and signed with a timeout set earlier than the previously issued refund transaction at t c . In order to become valid, as described later, the refund transaction must be broadcast to the blockchain network after the timeout has expired. Broadcasting the refund transaction to the blockchain network after the timeout has expired invalidates the previous backup if the exchange does not cooperate or is unable to do so. Thus, for the first owner P1, the timeout is set at t0, and for the owner P n the timeout is set at t0 - nt c . In one embodiment, the task of the exchange is to record t0, the value t c , and the current n for each cryptocurrency deposit.

[0142] Figure 12 shows, in block diagram form, an exemplary environment 1200 in which a detachment phase of an off-chain cryptocurrency transaction between untrusted parties is executed using an exchange platform. In the example shown in Figure 12, a party 1202 (shown as "Party n+1") initiates a detachment 1214 of a cryptocurrency deposit 1206 attached to an exchange 1204. As described above, the cryptocurrency deposit 1206 may be one of a plurality of cryptocurrency deposits 1208 attached to the exchange 1204.

[0143] In one embodiment, as described above, for example when a previous transaction transferred ownership of one or more portions of the cryptocurrency deposit 1206, the party 1202 may initiate a detachment 1214 that is less than the total amount of the cryptocurrency deposit 1206.

[0144] The party 1202 is currently designated as the owner of the cryptocurrency deposit 1206 by the current shared key 1210. The current shared key 1210 is generated from the attachment secret key (S E ) of the exchange and the attachment secret key (S n+1 ) of the party 1202, as described herein. In the example shown in Figure 12, the party 1202 has a refund transaction 1212 with a timeout of t0-nt c , and since the party 1202 is the current owner, this refund transaction timeout is the earliest among the refund transactions of the previous owners.

[0145] When the party 1202 initiates a detachment 1214 of some or all of the cryptocurrency deposit 1206, a transaction 1216 is generated that provides for the transfer of the cryptocurrency deposit 1206 to the party 1202, and the cryptocurrency deposit 1206 is detached from the exchange 1204. As a result, further off-chain cryptocurrency transactions using the cryptocurrency deposit 1206 cannot be executed. In one embodiment, the attachment secret key (S E) is shredded or otherwise discarded, ensuring that no further off-chain cryptocurrency transactions can be performed using the cryptocurrency deposit 1206.

[0146] FIG. 13 shows, in flowchart form, an exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform. The process 1300 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node such as one of the nodes 102 described in connection with FIG. 1 may perform the exemplary process 1300 to perform the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using the exchange platform described in connection with FIG. 13.

[0147] In step 1302 of the exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described above, the party requests detachment from the exchange.

[0148] In step 1304 of the exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, it is determined whether the party is the current owner (i.e., whether the party is authorized to distribute the cryptocurrency deposit). In one embodiment, it is determined whether the party is the current owner by calculating from the exchange's attach secret key (S E ) and the party's attach secret key (e.g., S of the nth party n ). In one embodiment, the current owner can be verified using the current owner's attach public key by combining the current owner's attach public key with the exchange's attach secret key and comparing the result to the shared public key to ensure they are equal.

[0149] In step 1304 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if a party is determined not to be the current owner, in step 1306 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, detachment is not permitted. In one embodiment, the party requesting detachment receives a message from the enclave indicating that detachment is not permitted.

[0150] In step 1304 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if a party is determined to be the current owner, in step 1308 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described herein, it is determined whether a first timeout (i.e., the timeout with the earliest start time) has been reached. For example, if the fourth party is the current owner and the fourth party has a refund transaction with timeout t0 - 3t c as described at least in connection with FIG. 11, if the current time is before the timeout t0 - 3t c then the first timeout has not been reached, and if the current time is after the timeout t0 - 3t c then the first timeout has been reached.

[0151] In step 1308 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that a first timeout has been reached, in step 1310 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a refund transaction for the cryptocurrency deposit is initiated, and thus detachment is not permitted as described in step 1306 of exemplary process 1300.

[0152] In step 1308 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that the first timeout has not been reached, in step 1312 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, detachment is permitted.

[0153] In step 1314 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the exchange sends the current exchange private key to the party requesting detachment.

[0154] In step 1316 of exemplary process 1300 for performing the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party generates a shared key using the exchange private key and the party's attach private key (e.g., the shared key (S) is generated by multiplying the exchange's private key (S E ) by the party's private attach key (e.g., S of the nth party n ).

[0155] In step 1318 of exemplary process 1300 that executes the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, as described above, the party verifies the shared key with the exchange.

[0156] In step 1320 of exemplary process 1300 that executes the detachment phase of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the party uses the shared key to generate a transaction that should use the UTXOs from the cryptocurrency deposit until the earliest timeout is reached from the current time. That is, the party can generate a transaction using the shared key at any time before the earliest timeout is reached. If the party waits to generate a transaction using the shared key after the earliest timeout is reached, the transaction may fail due to a refund interruption. "Using" the UTXOs means, in a technical sense, that the recording of the transaction on the blockchain prevents the UTXOs from being used as inputs to another transaction on the blockchain, for example, the UTXOs are used as inputs to a transaction.

[0157] Note that one or more of the operations performed in exemplary process 1300 shown in FIG. 13 may be performed in various orders and combinations, including in parallel.

[0158] FIG. 14 shows in block diagram form an exemplary environment 1400 in which the refund phase of an off-chain cryptocurrency transaction between untrusted parties is performed using an exchange platform. In the example shown in FIG. 14, the current time 1402 is t0 - nt c where it is the first timeout period, longer than the attachment period (e.g., for a 30-day attachment period, t0 is 90 days), and t c is the refund time (e.g., 30 minutes or 3 blocks). For example, if there are 481 parties (or 480 ownership transfers), the current time 1402 is t0 - 480 * t cand this is 480 times 90 days - 30 minutes, or 80 days after the cryptocurrency deposit is attached.

[0159] In the example shown in FIG. 14, none of the parties have detached the cryptocurrency deposit, and the refund process starts based on the current time. During the first refund period 1406, a party 1408 (e.g., the 481st party) may broadcast its refund transaction to the blockchain 1412 to obtain a refund of the cryptocurrency deposit. During the second refund period 1414, a party 1416 (e.g., the 480th party) may broadcast its refund transaction to the blockchain 1412 to obtain a refund of the cryptocurrency deposit. Here, assume that during the first refund period 1406, the party 1408 does not broadcast its refund transaction to the blockchain 1412 to obtain a refund of the cryptocurrency deposit. The exchange protocol can recover from an invalid transfer of ownership (e.g., transfer of ownership from party 1416 to party 1408) during the second refund period 1414.

[0160] The refund process continues until one of the parties successfully broadcasts its refund transaction to the blockchain 1412 during its refund period. If the refund period 1420 ends and the party 1422 (e.g., the 2nd party) does not broadcast its refund transaction to the blockchain 1412 at 1424, the party 1428 (e.g., the 1st party) can broadcast its refund transaction during the last refund period 1426 at 1430. In one embodiment, the exchange automatically generates a refund transaction to the first party after the last refund period 1426 (e.g., after reaching time t0).

[0161] Note that refund transactions can be mined (i.e., used on the blockchain) at any time after the timeout (also called "locktime" in the Bitcoin network). That is, a party is not restricted from mining a refund transaction during the refund period. Once the timeout has elapsed for a party, the transaction remains valid from that point forward. Generally, the party with the closest timeout will submit their refund transaction first after their timeout has elapsed. Once the first refund transaction is confirmed, all other refund transactions that reference the same UTXO become invalid. The party with the closest timeout is incentivized to submit their refund transaction as soon as possible. This is because delaying the submission until the next timeout (e.g., the next party's timeout) creates a risk that the next party will mine the refund transaction. For example, during the second refund period 1414, parties 1408 and 1416 may broadcast refund transactions to blockchain 1412 to obtain a refund of their cryptocurrency deposit.

[0162] As described herein, the most recent refund transaction is the one that can be mined into the blockchain the earliest. Thus, the new refund transaction becomes valid earlier and is thus usable first, rendering the older transactions (i.e., refund transactions with later timeouts) redundant.

[0163] FIG. 15 shows, in flowchart form, an exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform. The process 1500 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the exemplary process 1500 to perform a refund stage of an off-chain cryptocurrency transaction between untrusted parties using the exchange platform described in connection with FIG. 15.

[0164] In step 1502 of the exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a first timeout period is reached, and as described herein, the refund transaction may start according to the priority of the requesting party (e.g., a new owner may have a higher refund priority than an old owner).

[0165] In step 1504 of the exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a first party (e.g., the most recent owner) is selected.

[0166] In step 1506 of the exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, it is determined whether a timeout of the selected party has started, based at least in part on the time t0 and the number of the refund periods t used. c used.

[0167] In step 1506 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that the timeout of the selected party has not started, then in step 1508 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the refund transaction is not permitted at a predetermined time. As expected, if the timeout period of the earliest party has not started, then the timeout period of any of the later parties has not started yet. Therefore, there is no party that can request a refund.

[0168] In step 1506 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that the timeout of the selected party has started, then in step 1510 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, whether the next timeout has been reached (i.e., whether the timeout of the selected party has ended) is determined based at least on the time t0 used and the number of the refund period t c is determined.

[0169] In step 1510 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that the next timeout has been reached (i.e., that the timeout of the selected party has ended), then in step 1512 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, it is determined whether there is an earlier party to be selected (e.g., a party earlier in the ownership chain).

[0170] In step 1512 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that there is a faster party to select, then as described above in step 1504 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the next faster party is selected.

[0171] In step 1512 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that there is no faster party to select, then in step 1514 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the earliest party is selected and, as described below, exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform continues at step 1516.

[0172] In step 1510 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, if it is determined that the next timeout has been reached (i.e., the timeout of the selected party has ended), then in step 1516 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, the selected owner having the current refund period determined in steps 1506 and 1510 broadcasts the saved refund transaction to the blockchain.

[0173] In step 1508 of exemplary process 1500 for performing a refund stage of an off-chain cryptocurrency transaction between untrusted parties using an exchange platform, a selected owner having the currently determined refund period determined in steps 1506 and 1510 receives the UTXOs of the refund transaction broadcast as described herein.

[0174] Note that one or more of the operations performed in exemplary process 1500 shown in FIG. 15 may be performed in various orders and combinations, including in parallel.

[0175] FIG. 16 shows in block diagram form an exemplary computing device 1600 in which various embodiments of the present invention may be implemented. FIG. 16 shows a simplified block diagram of an exemplary computing device 1600 that may be used to implement at least one particular embodiment of the present disclosure. In various embodiments, the exemplary computing device 1600 may be used to implement any of the above-described systems or methods shown herein. For example, the exemplary computing device 1600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 16, the exemplary computing device 1600 may include one or more processors 1602 operably coupled and configured to communicate via a bus system 1604 with a number of peripheral subsystems. The processor 1602 may be utilized to implement an exchange protocol as described herein. These peripheral subsystems may include a storage subsystem 1606 including a memory subsystem 1608 and a file storage subsystem 1610, one or more user interface input devices 1612, one or more user interface output devices 1614, and a network interface subsystem 1616. Such a storage subsystem 1606 may be used for temporary or long-term storage of information related to the transactions or operations described in the present disclosure.

[0176] The bus subsystem 1604 may provide a mechanism for various components and subsystems of the exemplary computing device 1600 to communicate with each other as needed. Although the bus subsystem 1604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 1616 may provide an interface to other computing devices and networks. The network interface subsystem 1616 may function as an interface for receiving data from and transmitting data to other systems from the exemplary computing device 1600. For example, the network interface subsystem 1616 may enable a user to connect the device to a wireless network or any other network as described herein. The bus subsystem 1604 may be utilized to communicate data related to the transactions or operations described in this disclosure to one or more processors 1602 and / or to other entities external to the system via the network interface subsystem 1616.

[0177] The user interface input device 1612 may include one or more user input devices such as a keyboard, a pointing device such as an integrated mouse, a touch pad, or a graphics tablet, a scanner, a barcode scanner, a touch screen built into a display, an audio input device such as a voice recognition system, a microphone, and other types of input devices. Generally, the use of the term "input device" is intended to include any possible types of devices and mechanisms for inputting information into the computing device 1600. The one or more user interface output devices 1614 may include a display subsystem, a printer, or a non-visual display such as an audio output device, etc. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. Generally, the use of the term "output device" is intended to include any possible types of devices and mechanisms for outputting information from the computing device 1600. The one or more output devices 1614 may be used, for example, to present a user interface to assist in the user interaction with an application that executes the processes described herein and its variations when such interaction is appropriate.

[0178] The memory subsystem 1606 may provide a computer-readable storage medium that stores basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) may, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure and may be stored in the memory subsystem 1060. These application modules or instructions may be executed by one or more processors 1602. The memory subsystem 1606 may further provide a repository for storing data used in accordance with the present disclosure. The memory subsystem 1606 may include a memory subsystem 1608 and a file / disk storage subsystem 1610.

[0179] The memory subsystem 1608 may include a number of memories including a main random access memory (RAM) 1618 for storing instructions and data during program execution, and a read only memory (ROM) 1620 in which fixed instructions may be stored. The file memory subsystem 1610 may provide non-transitory persistent (non-volatile) storage for program and data files (also referred to herein as non-transitory computer-readable storage media), and may include a hard disk drive, a floppy disk drive in conjunction with associated removable media, a compact disk read only memory (CD-ROM) drive, an optical drive, a removable media cartridge, and other similar storage media.

[0180] Exemplary computing device 1600 may include at least one local clock 1624. Local clock 1624 may be a counter representing the number of time units elapsed since a particular start date, and may be integrated and disposed inside exemplary computing device 1600. Local clock 1624 may be used to synchronize data transfers to particular clock pulses within the processor of exemplary computing device 1600 and all subsystems included therein, and may be used to coordinate synchronization operations between exemplary computing device 1600 and other systems within a data center. In one embodiment, local clock 1624 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0181] Exemplary computing device 1600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described herein. Further, exemplary computing device 1600 may include another device that may be connected to exemplary computing device 1600 through one or more ports 1626 (e.g., headphone jack, optical connector, etc.). A device that may be connected to exemplary computing device 1600 may include a plurality of ports configured to receive optical fiber connectors. Thus, a device that may be connected to exemplary computing device 1600 may be configured to convert an optical signal into an electrical signal. The electrical signal may be transmitted for processing through a port that connects the device to exemplary computing device 1600. Due to the constantly changing nature of components and networks, the description of exemplary computing device 1600 shown in FIG. 16 is intended only as a specific example for the purpose of illustrating one embodiment of the device. Many other configurations with more or fewer components than the system shown in FIG. 16 are possible.

[0182] Accordingly, this specification and the accompanying drawings are to be construed as illustrative rather than restrictive. However, it is clear that various changes can be made without departing from the broad spirit and scope of the invention as set forth in the claims.

[0183] Other variations are within the spirit of the disclosure. Accordingly, the disclosed technology is subject to various modifications and alternative configurations, although the specific illustrated embodiments are shown in the drawings and described in detail above. However, it should be understood that the invention is not limited to the one or more specific forms disclosed, but rather, as set forth in the appended claims, all modifications, alternative configurations, and equivalents are intended to be included within the spirit and scope of the invention.

[0184] In the context of describing the disclosed embodiments, the terms "a", "an", and "the", and similar referents (in particular, in the context of the following claims) should be considered to cover both the singular and the plural, unless otherwise indicated or clearly contradicted by the context. The terms "comprising", "having", "including", "containing" should be considered as broad terms (i.e., meaning "including, but not limited to") unless otherwise specified. The term "connected" should be considered as representing a physical connection without modification, even if something intervenes, and as being included, attached, or joined together, either partially or wholly. The detailed description of a range of values in this specification is, unless otherwise specified in this specification, intended to function simply as a concise way of referring individually to each distinct value included in the range, and each distinct value is incorporated into this specification as if it were individually set forth herein. The use of the term "set" (e.g., "a set of items") or "subset" should be considered, unless otherwise indicated or inconsistent with the context, as a non-empty set containing one or more components. Further, unless otherwise noted or inconsistent with the context, the corresponding set term "subset" does not necessarily denote a proper subset of the corresponding set, and the subset and the corresponding subset may be equal.

[0185] Logical language such as phrases in the form of "at least one of A, B, and C" or "at least one A, B, and C" is understood to be used to indicate that an item, etc. may be any of A or B or C, or any non-empty subset of the set of A and B and C, unless otherwise stated or unless clearly inconsistent with the context. For example, in an example for the description of a set having three components, the logical language "at least one of A, B, and C" or "at least one A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such logical language is not usually intended to mean that in a particular embodiment, each of at least one A, at least one B, and at least one C must be present.

[0186] The operations of the processes described in this specification may be executed in any suitable order unless otherwise shown in this specification or clearly inconsistent with the context. The processes described in this specification (or their variations and / or combinations) may be executed under the control of one or more computer systems composed of executable instructions, and may be implemented in hardware, or in combination therewith, as code (e.g., executable instructions, one or more computer programs or one or more applications) executed collectively on one or more processors. The code may be stored in a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory (i.e., it may be a non-transitory computer-readable storage medium).

[0187] The use of any and all examples or exemplary language (e.g., "such as") provided in this specification is merely intended to better illustrate embodiments of the invention and is not intended to limit the scope of the invention unless otherwise stated. No language in the specification should be considered as indicating any non-claimed element essential to the practice of the invention.

[0188] Embodiments of the present disclosure include those described in this specification and the best mode known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art after reading the foregoing description. The inventors expect skilled artisans to appropriately utilize these variations, and the inventors intend for the embodiments of the present disclosure to be practiced in a manner different from that particularly described in this specification. Accordingly, the scope of the present disclosure includes all variations and equivalents of the subject matter recited in the appended claims as permitted by appropriate law. Further, any combination of the above-described elements in all possible variations is included within the scope of the present disclosure unless otherwise specifically stated herein or clearly inconsistent with the context.

[0189] Note that, in the context of describing embodiments of the disclosure, unless otherwise specified, the use of the expression regarding executable instructions (also referred to as code, applications, agents, etc.) that perform operations (e.g., data transmission, calculation, etc.) that are not normally performed alone by an instruction indicates that the instruction is executed by a machine, thereby causing the machine to perform the specified operations.

[0190] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention defined by the appended claims. In the claims, any reference signs enclosed in parentheses shall not be construed as limiting the claim. The terms "comprising" or "comprises" etc. do not exclude the presence of elements or steps other than those listed in any claim and in the specification as a whole. In the present specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The reference to a singular element does not exclude the presence of a plurality of such elements, and vice versa. The present invention can be implemented by hardware having a plurality of distinct elements or by a computer appropriately programmed. In a claim of an apparatus listing a plurality of means, these plurality of means can be implemented by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used advantageously.

Claims

1. 1. A computer-implemented method comprising: receiving, by a first node of the blockchain network, a request by a first entity to detach a deposit from the exchange platform; determining, by the first node, whether detachment of the deposit is permitted, determining that the first entity is a current owner of the deposit; determining that the first time period has not expired; and sending, by the first node, an exchange private key to the first entity; generating, by the first entity, a first shared key based at least in part on the exchange private key and an attachment private key of the first entity; verifying, by the first entity, the first shared key with the exchange platform; generating, by the first entity, a blockchain transaction using the first shared key to detach the deposit from the exchange platform and provide the deposit to the first entity; A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the generated blockchain transaction is recorded on a blockchain network, and recording the transaction prevents unspent transaction outputs (UTXOs) from being used as inputs for another transaction on the blockchain network.

3. The step of determining whether the first entity is a current owner of the deposit comprises: calculating a second shared key from an attachment private key of the exchange platform and the attachment private key of the first entity; comparing the second shared key to the first shared key to verify that the second shared key and the first shared key are equal; 3. The computer-implemented method of claim 1, comprising:

4. The step of determining whether the first entity is a current owner of the deposit comprises: combining an attached public key of the first entity with the attached private key of the exchange platform; comparing the result of the combination with the first shared key to verify that they are equal; 4. The computer-implemented method of claim 1, comprising:

5. The step of determining, by the first node, that detachment of the deposit is not permitted comprises: determining that the first entity is not the current owner of the deposit; and / or determining that the first time period has expired; 5. The computer-implemented method of claim 1, comprising:

6. 6. The computer-implemented method of claim 5, upon determining that detachment of the deposit is not permitted, the method further comprises notifying the first entity that the detachment is not permitted.

7. 6. The computer-implemented method of claim 5, wherein upon determining that the first time period has expired, the method further comprises broadcasting a refund transaction to the blockchain network.

8. 8. The computer-implemented method of claim 7, wherein the deposit is attached to the exchange platform by a second entity and the refund transaction is jointly signed by the exchange platform and the second entity using a two-entity Elliptic Curve Digital Signature Algorithm.

9. The computer-implemented method of any of claims 1 to 8, wherein the first shared key is generated by multiplying the attached private key of the exchange platform with the attached private key of the first entity.

10. 10. The computer-implemented method of any of claims 2-9, wherein once the deposit is detached, the attached private key of the exchange platform is destroyed such that further off-chain cryptocurrency transactions cannot be performed using the deposit.

11. 1. A computer system comprising: A processor; a memory containing executable instructions which, upon execution by the processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 10; 1. A computer system comprising:

12. A non-transitory computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least one of the computer-implemented methods of any one of claims 1 to 10.

Images