Method and system for recording multiple transactions on a blockchain

Abstract

To provide a method, a program, and a device for executing a bilateral transaction recorded in a peer-to-peer distributed ledger (block chain) between two users.SOLUTION: A method 100 includes steps of: receiving a first request for transferring an amount of first cryptocurrency from a first node related to a first user (A); and receiving a second request transferring an amount of second cryptocurrency from a second node. A first transaction is executed on a condition that the second request is received, and a second transaction is executed on a condition that the first request is received. The method further includes steps of: determining that both the conditional steps for receiving the first request and the second request are satisfied; and transmitting data output to a block chain so as to record transferring of the cryptocurrency related to the first transaction and the second transaction based on the steps for verifying the first request and the second request.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates generally to transactions recorded on a peer-to-peer distributed ledger (blockchain), and more particularly to conducting bidirectional transactions between two users. [Background technology]

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Blocks are in turn composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs. Scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, then the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction, and if the transaction is verified, the node relays the transaction to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] A cryptocurrency transaction may involve multiple parties with multiple inputs and multiple outputs. Such a multi-party transaction may occur when multiple parties agree to form a single transaction (in the sense that a single transaction with multiple inputs and multiple outputs is recorded on the blockchain) to improve privacy. For example, if Alice wants to transact with Bob, she may seek out other parties (e.g., Carol) who may want to execute the transaction and make a joint payment together (e.g., a "CoinJoin" transaction).

[0006] Contractual obligations may involve consideration that is two-way. For example, Alice may want to purchase a widget from Bob in exchange for money. Thus, fulfilling the transaction involves consideration in one direction, which involves the payment of money from Alice to Bob. Consideration in the other direction, which involves Bob providing the widget to Alice.

[0007] Problems can arise when only one side fulfills their one-way obligations, for example if Alice makes a payment to Bob and Bob takes the money without delivering the widget.

[0008] Throughout this specification, the terms "comprise" or variations such as "comprises" or "comprising" are understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

[0009] Any discussion of documents, acts, materials, devices, products, or the like included in the specification of this application should not be construed as an admission that any or all of those items form part of the prior art or were common general knowledge in the art relevant to the disclosure as they existed prior to the priority date of each claim of this application. Summary of the Invention

[0010] The present invention is provided as defined in the accompanying claims.

[0011] The invention may be described as a blockchain and / or computer-implemented method and corresponding systems and devices. There may be a verification method / system for verifying the authenticity of a blockchain transaction (Tx) before executing the transaction. Additionally or alternatively, the invention may therefore be a security method / system configured to ensure that only authenticated transactions are executed. Additionally or alternatively, the invention may be a control method / system configured to determine when a transaction may be performed on the blockchain and / or when it should be prohibited. The execution of a transaction (Tx) may comprise the transfer of a cryptocurrency amount from one party to another.

[0012] The present invention may provide a validation and / or control method configured to simultaneously publish more than one blockchain transaction (Tx) once one or more conditions are determined to be met. "Publishing a transaction" may mean or include submitting the transaction output to a blockchain network so that it can be used. The conditions may be referenced or accessed using metadata within the transaction that is successfully evaluated. This may be done for the counterparty as well, resulting in the creation of two transactions.

[0013] The method may include using a blockchain transaction (Tx1) to transfer / spend a cryptocurrency amount or portion from a first user (party) A to a second user (party) B upon successful evaluation of one or more conditions. This may be referred to as a first rule set. The conditions may be a Boolean value or a rule that may be evaluated to generate an output. The conditions may be evaluated by a third party or user C. The conditions may include a rule that a request is received from the second user before the cryptocurrency amount is transferred.

[0014] The cryptocurrency transfer may be performed using a multi-sig transaction type. This may be, for example, a two-out-of-two multi-signature transaction in the Bitcoin protocol or an equivalent function. The transaction output may require the signatures of A and C in order to spend the output. The rules may be referenced by pointers included in the metadata in the tout transaction.

[0015] The method may further include using a blockchain transaction (Tx2) to transfer / spend the cryptocurrency amount or portion from the second user (party) B to the first user (party) A upon successful evaluation of one or more conditions. This may be referred to as a second rule set. The conditions may be a Boolean value or a rule that may be evaluated to generate an output. The conditions may include a rule that a request is received from the first user before the cryptocurrency amount is transferred.

[0016] The conditions may be evaluated by a third party or user C. The cryptocurrency transfer may be performed using a multi-sig transaction type. This may be, for example, a two-out-of-two multi-signature transaction in the Bitcoin protocol or an equivalent function. The transaction output may require the signatures of B and C in order to spend the output. The rules may be referenced by pointers included in the metadata in the tout transaction.

[0017] The method may include checking that both first and second conditions (rule sets) evaluate to true, and if both evaluate to true, submitting both transactions to a blockchain network to effect the transfer (spend) of the first and second cryptocurrency portions.

[0018] It should be noted that a mining process may result in one transaction in a block being earlier than another. It should also be noted that the term "user" does not necessarily mean a human user. A user may be a computer or automated process that uses or forms part of the invention. A user may be a node in a network or may be associated with it.

[0019] Additionally or alternatively, the present invention may provide a method for recording multiple transactions between multiple users on a peer-to-peer distributed ledger (blockchain), including a first transaction (Tx) from a first user (A) to a second user (B) and a second transaction (Tx) from the second user (B) to the first user (A). The method may include receiving a first request from a first node associated with the first user (A) to transfer a first cryptocurrency amount (B1) from a first user (A) to a second user (B), the first request being associated with a first transaction; receiving a second request from a second node associated with the second user (B) to transfer a second cryptocurrency amount (B2) from the second user (B) to the first user (A), the first transaction being conditional on receiving the second request and / or the second transaction being conditional on receiving the first request; and validating the first and second requests, the step of validating the first and second requests including determining that both of the conditional steps of receiving the first and second requests are satisfied. Based on the step of verifying the first request and the second request, the method further includes a step of transmitting a first data output (O1) to the peer-to-peer distributed ledger via the communications network, the first data output (O1) including a first transfer of the first cryptocurrency amount (B1) to the second user (B) and a second transfer of the second cryptocurrency amount (B2) to the first user (A).

[0020] The first and second transactions are conditional on receiving corresponding requests to transfer the associated cryptocurrency to each other. The method includes verifying that both the first and second requests are generated before the transfer is sent for recording on the peer-to-peer distributed ledger, so that the first user (A) and the second user (B) can have greater confidence that the other user will fulfill their respective obligations in the first and second transactions. Furthermore, proof of the co-dependency of transactions between the multiple users (A, B) can be provided by a first data output (O1) that includes and represents these co-dependent transactions. In particular, instructions for both the first and second transfers are in the first data output (O1) of the same cryptocurrency transaction record. This can be helpful in providing that the first and second transactions are linked to the co-dependency.

[0021] In the method, the first request can include a first indication that the first transaction is conditional on receipt of the second request, and in the method, the second request can include a second indication that the second transaction is conditional on receipt of the first request.

[0022] The method may further include receiving a third notification, the third notification specifying that the first transaction is conditional on receipt of the second request, and that the second transaction is conditional on receipt of the first request.

[0023] In the method, verifying the first request and the second request may further include authenticating that the first request is from a first user (A) and that the second request is from a second user (B).

[0024] In the method, verifying the first and second requests may further include determining authority to transfer a first cryptocurrency amount (B1) from a first user (A) and authority to transfer a second cryptocurrency amount (B2) from a second user (B).

[0025] The first data output (O1) may further include metadata (MD) associated with one or both of the first and second transactions, the metadata (MD) associated with one or both of the first and second transactions including hashes of one or more of the following: information related to the first and / or second transactions, a pointer to information related to the first and / or second transactions, one or more identifiers related to the first user (A) and / or the second user (B).

[0026] A first cryptocurrency amount (B1) may be associated with the first token (T1) and / or a second cryptocurrency amount (B2) may be associated with the second token (T2). The method may further comprise the step of determining a first hash (H1) of a first redeem script (RS1), the first redeem script (RS1) based on at least first metadata (MD1) including information associated with the first token (T1), a second user public key (P1B) associated with a second user (B), the second user public key (P1B) cryptographically pairing with a second user private key (V1B), and a trusted entity public key (P1T) associated with a trusted entity (TE), the trusted entity public key (P1T) cryptographically pairing with the trusted entity private key (V1T), the first data output (O1) further comprising the first hash (H1), the first hash (H1) being associated with the first cryptocurrency amount (B1) to provide the first token (T1).

[0027] The method may further comprise the step of determining a second hash (H2) of a second Redeem Script (RS2), the second Redeem Script (RS2) based on at least second metadata (MD2) including information associated with the second token (T2), a first user public key (P1A) associated with the first user (A), the first user public key (P1A) cryptographically paired with the first user private key (V1A), and a trusted entity public key (P1T) associated with the trusted entity (TE), the trusted entity public key (P1T) cryptographically paired with the trusted entity private key (V1T), the first data output (O1) further comprising the second hash (H2), the second hash (H2) being associated with the second cryptocurrency amount (B2) to provide the second token (T2).

[0028] A computer-implemented method for validating a first transaction and / or a second transaction based on a first data output (O1) to a peer-to-peer distributed ledger according to any one of the above claims, comprising the steps of receiving a request to validate the first transaction and / or the second transaction, determining a first data output (O1) corresponding to a first transfer of a first cryptocurrency amount (B1) associated with the first transaction and / or a second transfer of a second cryptocurrency amount (B2) associated with the second transaction, receiving at least a portion of the first data output (O1) from the peer-to-peer distributed ledger via a communication network, determining from the first data output (O1) first instructions for the first transfer and / or second instructions for the second transfer, verifying that the first instructions for the first transfer and / or the second instructions for the second transfer correspond to the first transaction and / or the second transaction in the request, and sending an output indicative of a result of the verifying step.

[0029] The method may further include verifying that both the conditional steps of receiving the first request and the second request are satisfied based on the first instructions for the first transfer and the second instructions for the second transfer, and sending an output indicating that the first transaction is conditional on receiving the second request and / or that the second transaction is conditional on receiving the first request and that the conditional steps have been satisfied.

[0030] The method may further include determining metadata associated with the first transaction and / or the second transaction, and the verifying step further includes verifying that the metadata corresponds to the first transaction and / or the second transaction.

[0031] The method may further include receiving and determining a verification hash of one or more of information related to the first and / or second transaction, a pointer to information related to the first and / or second transaction, or one or more identifiers related to the first user and / or the second user, and verifying that the verification hash corresponds to a hash in the metadata.

[0032] A computer program comprising machine readable instructions for causing a processing device to perform any one of the methods described above.

[0033] An apparatus having a first processing unit, the apparatus being adapted to carry out any one of the methods described above.

[0034] An apparatus for recording a plurality of transactions between a plurality of users on a peer-to-peer distributed ledger, including a first transaction from a first user (A) to a second user (B) and a second transaction from the second user (B) to the first user (A), the apparatus comprising a processing device, the processing device receiving a first request from a first node associated with the first user (A) to transfer a first cryptocurrency amount (B1) from the first user (A) associated with the first transaction to the second user (B), and receiving a second cryptocurrency amount (B2) from a second node associated with the second user (B) to the first user (A), the second transaction being associated with the second transaction. and receiving a second request to transfer the cryptocurrency amount (B1) to the second user (B) and / or the second transaction is conditional on receipt of the first request, validating the first and second requests, wherein validating the first and second requests includes the processing device determining that both the first request and the second request have been received, and based on verifying the first and second requests, the processing device selectively transmits, via the communications network to the peer-to-peer distributed ledger, a first data output (O1) including first instructions for a first transfer of the first cryptocurrency amount (B1) to the second user (B) and second instructions for a second transfer of the second cryptocurrency amount (B2) to the first user (A).

[0035] Any feature described above in relation to one embodiment or aspect may be equally applied to one or more other embodiments or aspects, for example a feature described in relation to a method may be applicable to a system of the invention. [Brief description of the drawings]

[0036] Examples of the present disclosure will now be described with reference to the following drawings.

[0037] [Figure 1] 1 is an overview of an exemplary system for recording multiple transactions between multiple users on a peer-to-peer distributed ledger.

[0038] [Diagram 2]FIG. 2 shows a first transaction from a first user to a second user and a second transaction from the second user to the first user.

[0039] [Diagram 3] 1 is a flow chart of a computer-implemented method for recording multiple transactions between multiple users.

[0040] [Figure 4] 1 is a flowchart of a computer-implemented method for validating a first transaction and / or a second transaction.

[0041] [Diagram 5] FIG. 1 illustrates a first transaction from a first user to a second user, the first transaction including a first token, and a second transaction from the second user to the first user, the second transaction including a cryptocurrency payment.

[0042] [Figure 6] 1 shows a simplified example of a processing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] <Summary> The present invention provides a method and system for enabling multiple transactions between multiple users on a peer-to-peer distributed ledger 9 (i.e. blockchain), which may or may not be the Bitcoin blockchain. In one embodiment, the invention is configured such that a (trusted) third party is only authorized to publish one or more associated transactions if some conditions are successfully evaluated. The conditions may be referenced directly from metadata within one or more of the transactions themselves. In summary, the invention may include the following steps:

[0044] Transaction 1 (Tx1) 1: A pays B, subject to some condition evaluated by C (effectively a 2-out-of-2 multisignature of A and C with a pointer to metadata rules). Transaction 2 (Tx2): B pays A subject to some condition evaluated by C (effectively a 2-out-of-2 multisignature of B and C with a pointer to metadata rules).

[0045] The condition can be assumed to be the existence of a counterparty transaction, and thus a rule in Txn1 cannot be evaluated to be truly independent of a rule in Txn2 that does the same thing. However, if both sets of rules evaluate to true, then both transactions can be published for use simultaneously (even if mining means that one occurs in an earlier block than the other).

[0046] 1 shows a system 1 including a first user (A) 5 associated with a first node 15 and a second user (B) 7 associated with a second node 17. The first node 15 and the second node 17 communicate with a third node 13 associated with a trusted entity (TE) 3 via a communication network 8.

[0047] A third node 13 associated with a trusted entity (TE) 3 communicates with a peer-to-peer distributed ledger 9 via a communication network 8 to record transactions. The peer-to-peer distributed ledger 9 may be associated with one or more processors 19 to receive and record transactions. An example of a peer-to-peer distributed ledger includes a blockchain, which is a consensus-based ledger of transactions based on the Bitcoin protocol. Thus, the processors 19 associated with the ledger may be processors used by or associated with "miners."

[0048] With reference to FIG. 2, a first user (A) 5 and a second user (B) 7 may wish to participate in a bidirectional transaction. The bidirectional transaction includes a first transaction 22 from the first user (A) 5 to the second user (B) 7 and a second transaction 24 from the second user (B) 7 to the first user (A) 5. The first and second transactions 22, 24 may include transactions of cryptocurrencies, tokenized cryptocurrencies, fiat currencies, tangible assets, intangible assets, offers of ownership thereof, etc. To effect the first transaction 22, a first cryptocurrency amount (B1) is transferred 32 from the first user (A) 5 to the second user (B) 7. Similarly, to effect the second transaction 24, a second cryptocurrency amount (B2) is transferred 34 from the second user (B) 7 to the first user (A) 5. The first and / or second cryptocurrency amount may be the subject of the transaction itself (e.g., if the intention is to transfer cryptocurrency as a payment). Alternatively, the first and / or second cryptocurrency amounts may be representative of the transaction 22, 24 (e.g., as a token of fiat currency, a tangible asset, an intangible asset, a representation of an ownership or ownership thereof, etc.).

[0049] The first user (A) 5 may not trust the first user (B) 7 to fulfill the second user (B) 7's side of the two-way transaction. Similarly, the second user (B) 7 may not trust the first user (A) 5. Thus, to give both users 5, 7 a higher degree of trust, a trusted entity (TE) 3 is involved, making the first and second transactions conditional on each other. With reference to FIG. 3, a method 100 performed by the trusted entity (TE) includes a step 130 of the trusted entity (TE) 3 verifying that it has received both (i) a first request 110 to transfer a first cryptocurrency amount (B1) from the first user (A) 5 to the second user (B) 7, and (ii) a second request 120 to transfer a second cryptocurrency amount (B2) from the second user (B) 7 to the first user (A) 5. The positive verification that both the first and second requests have been received indicates the good faith intentions of both the first and second users 5, 7. Accordingly, the third node 13 associated with the trusted entity (TE) 3 may then proceed to record the transfer of the first cryptocurrency amount (B1) and the second cryptocurrency amount (B2) by sending 140 the first data output (O1) to the peer-to-peer distributed ledger 9, which now also provides a record of the first and second transactions.

[0050] One advantage of the systems and methods described herein may include greater confidence for the first and second users 5, 7 that the obligations of the other party are more likely to be met. Another advantage is that the first data output (O1) may be used as proof that the first and second transfers are co-dependent and linked into a bi-directional transaction. In particular, instructions for both the first and second transfers are in the first data output (O1) in the same cryptocurrency transaction record.

[0051] The system 1 may also allow for later review and verification of whether the first and second transactions occurred based on records recorded in the peer-to-peer distributed ledger 9. This may include verifying that the transfer 32 of the first cryptocurrency amount (B1) (associated with the first transaction) was part of a two-way transaction linked to the transfer 34 of the second cryptocurrency amount (B2) (associated with the second transaction). This may be useful when such a verification argument is proof of the intent of both parties and the performance of their obligations. For example, if the second user (B) 7 makes a complaint that the first user (A) 5 did not pay for goods or services, the first user (A) can verify that the payment was made by referencing the record of the two-way transaction on the peer-to-peer distributed ledger that shows that the payment was made in return for the goods or services. An example of reviewing and verifying transactions is shown in method 400 of FIG. 4, which is described in more detail below.

[0052] <An example of a two-way transaction> <Agreement to two-way transaction> The first user (A) 5 and the second user (B) 7 reach an agreement whereby the first user (A) agrees to generate a first transaction 22 to the second user (B) 7 in exchange for the first user (A) 5 receiving a second transaction 24 from the second user (B) 7. This agreement may be the result of negotiation, multiple offers, and eventual acceptance by the first and second users 5, 7. In some instances, the agreement may be a contractual agreement, such as the result of an auction, a sale of goods and services, etc. It should be understood that bilateral transactions may be applicable to a variety of different transactions, including (but not limited to) real estate, tangible assets, intangible assets, currency, financial instruments, trading, insurance policies, stocks, superannuation, employee compensation, etc.

[0053] The first transaction 22 is associated with a first cryptocurrency amount (B1). In one example, the agreed obligation of the first user (A) 5 may be to transfer cryptocurrency as payment to the second user (B) 7. Thus, the first transaction 22 is simply the transfer of the first cryptocurrency amount (B1) to satisfy the obligation. In other examples, the agreed obligation of the first user (A) 5 may itself be something other than cryptocurrency. For example, the first transaction 22 may include the transfer of another asset, such as a fiat currency amount, a stock holding, a promise to pay, and other tangible and intangible assets and rights as described herein. These assets cannot themselves be transferred by recording them on a peer-to-peer distributed ledger, since they are not cryptocurrency. However, cryptocurrency amounts may be tokenized to represent such assets, and transfers of such "tokenized cryptocurrency" may be recorded on a peer-to-peer distributed ledger. Thus, the first transaction 22 may be represented and recorded by a transfer of an associated first cryptocurrency amount (B1) from the first user (A) 5 to the second user (B) 7. Similarly, the second transaction 24 may be represented and recorded by a transfer of an associated second cryptocurrency amount (B2) from the second user (B) 7 to the first user (A) 5.

[0054] <Select trusted entities> Even when a first user (A) 5 and a second user (B) 7 agree to proceed with a first transaction 22 and a second transaction 24, respectively, there may be mistrust between these users. For example, one user may have concerns that the other user may not fulfill the other user's obligations and run off with the user's assets. Thus, a trusted entity (TE) 3 is involved that is trusted by both the first user (A) 5 and the second user (B) 7. Here, the trusted entity only transfers 32 a first cryptocurrency amount (B1) provided there is a request to transfer 34 a second cryptocurrency amount (B2).

[0055] The trusted entity (TE) 3 may be a service provider trusted by both users. For example, the trusted entity may be a bank, another financial institution, a central bank, a mint, a company, etc. In one example, the trusted entity may be a bank that manages the electronic wallets ("eWallets") of both the first user (A) 5 and the second user (B) 7. In another example, the third party may be an entity that provides escrow services.

[0056] Importantly, the trusted entity (TE) 3 is directly trusted by both users, or alternatively, both users implicitly trust the trusted entity (TE) 3 (e.g., where the users are compensated for losses caused by errors made by the trusted entity).

[0057] <Send a request to transfer cryptocurrency to a trusted entity> The first user (A) 5, once satisfied by the trusted entity (TE) 3, then sends a first request to transfer 32 a first cryptocurrency amount (B1) from the first user (A) to the second user (B) 7 associated with the first transaction 22. In examples where the trusted entity (TE) 3 manages the e-wallet of the first user (A) 5, this may include authorizing the trusted entity (TE) 3 to use the private key of the first user (A) 5 to make the transfer 32 of the first cryptocurrency amount (B1) on their behalf. The first cryptocurrency amount may include a portion of the cryptocurrency amount in the first user's e-wallet from a previous transaction.

[0058] The first request 210 may be sent from a first node 15 associated with a first user (A) 5 to a third node associated with a trusted entity (TE) 3 .

[0059] In another example, the first request 210 to transfer the first cryptocurrency amount (B1) may be sent indirectly to the trusted entity (TE) 3. For example, a first user (A) 5 may make a request to transfer the first cryptocurrency amount (B1) to an entity managing the first user's e-wallet, which may then send a corresponding request to the trusted entity (TE) 3 to effect a conditional transfer of the cryptocurrency.

[0060] A first request 210 to transfer 32 a first cryptocurrency amount (B1) may include an explicit first notification in the request that the first transaction (including the first transfer 32) should proceed only if there is a corresponding second request to transfer 34 a second cryptocurrency amount (B2). The second request 210 may similarly include a second notification that the second transaction (including the second transfer 34) should proceed only if the first request has been made.

[0061] In an alternative embodiment, the first request 210 does not include an explicit condition, and the trusted entity (TE) 3 may determine in other ways that the first transaction (including the first transfer 32) should be conditional on the second transaction (including the second transfer 34). For example, a separate message may be sent to the trusted entity making the first transfer 32 and the second transfer 34 conditional on each other. For example, another node may be associated with an auctioneer that has effected an agreement between the first user (A) 5 and the second user (B) 7. The other node may then notify the trusted entity (TE) 3 of a third notification that the first and second transactions (including the transfer of cryptocurrency between the first user (A) 5 and the second user (B) 7) are conditional on each other before the actual transfer is performed. In some embodiments, such conditions may be stored in a data store 11 associated with the third node 13 and retrieved by the third node 13 as needed.

[0062] A second node 17 associated with a second user (B) 7 also sends 310 a second request to transfer 34 a second cryptocurrency amount (B2) from the second user (B) 7 to the first user (A) 5, where the transfer 34 is associated with the second transaction 24. This second request may be generated in the same or similar manner as described above with respect to the first request.

[0063] <Perform method 100 for recording multiple transactions> A trusted entity (TE) 3 performs a method 100 for recording a number of transactions, which is described below with reference to FIGS.

[0064] The method 100 includes step 110 of receiving a first request to transfer 32 a first cryptocurrency amount (B1), transmitted in steps 210 and 310 above, and step 120 of receiving a second request to transfer 34 a second cryptocurrency amount (B2).

[0065] The method 100 further includes a step 130 of validating the first and second requests. The step 130 of validating includes determining that both of the conditional steps 110, 120 of receiving the first and second requests are satisfied. As mentioned above, the condition may be included in one or both of the first and second requests and / or may be determined in other ways, such as receiving the condition from another party or else from the data store 11.

[0066] In a further example, validating the first and second requests further comprises authenticating that the first request is from a first user (A) 5 and / or the second request is from a second user (B) 7. This may involve a trusted entity (TE) 3, or authentication agent, authenticating that the requests were generated by the first and second users 5, 7 and / or their respective associated first and second nodes 15 / 17.

[0067] In another example, the step of verifying the first and second requests further includes determining the authority 32 to transfer the first cryptocurrency amount (B1) from the first user (A) 5 and the authority 34 to transfer the second cryptocurrency amount (B2) from the second user (B) 7. This may be useful in case of restrictions on asset transfer. For example, there may be a situation where the users 5, 7 do not have the authority to freely transfer assets. This may include liens on the assets. Thus, the trusted entity (TE) may determine in the verifying step 130 whether the cryptocurrency transfer should proceed. In one example, the step of determining the authority to transfer may include the trusted entity (TE) sending a query to a property securities register to determine whether restrictions exist for the transfer or the asset or assets that are the subject of the first transaction 22 and the second transaction 24.

[0068] Based on validation of the first and second requests in step 130, the method 100 may proceed to record the transfers 32, 34 of the first and second cryptocurrency amounts. This may be achieved by step 140 transmitting a first data output (O1) to the peer-to-peer distributed ledger 9 via the communications network 8. The first data output (O1) includes (i) a first instruction for a first transfer 32 of the first cryptocurrency amount (B1) to the second user (B) 7, and (ii) a second instruction for a second transfer 34 of the second cryptocurrency amount (B2) to the first user (A) 5.

[0069] The first data output (O1) on the peer-to-peer distributed ledger 9 achieves the following:

[0070] First, it records the transfer 32 of a first cryptocurrency amount (B1) to a second user (B) 7. The first cryptocurrency amount (B1) represents a related first transaction 22 from the first user (A) 5 to the second user (B) 7. The value of the first cryptocurrency amount (B1) to the second user (B) 7 may include (i) the nominal cryptocurrency value of the first cryptocurrency amount (B1) and / or (ii) other related values, such as a "token value" or "asset" that the first cryptocurrency amount (B1) represents. The second user (B) 7 may use the first cryptocurrency amount (B1) in the future for future transactions.

[0071] Secondly, it records the transfer 34 of the second cryptocurrency amount (B2) to the first user (A) 5. This may be used by the first user (A) 5 in a similar manner as the second user (B) 7 uses the received first cryptocurrency amount (B1), as described above.

[0072] Third, the first data output (O1) becomes a permanent record on the peer-to-peer distributed ledger that can be used to verify that a two-way transaction occurred. Furthermore, this can give users confidence in a two-way transaction because the record is permanent and instructions for multiple transfers that are part of the two-way transaction are present in the same first data output (O1). This is described in more detail below.

[0073] <Method of confirming the first transaction 22 and / or the second transaction 24> A method 400 for validating a first transaction 22 and / or a second transaction 24 is described below with reference to FIG.

[0074] In some situations, for example during an audit or dispute between a first user (A) 5 and a second user (B) 7, it is desirable to verify the records of the first transaction 22 and / or the second transaction 24. This may include a step 510 in which the first user (A) 5, the second user (B) 7, or another party (such as an auditor, legal representative, or arbitrator) transmits a request to verify the first transaction 22 and / or the second transaction 24. The request 510 may be configured in a variety of ways, including but not limited to a reference to the first and / or second transaction 22, 24, the first and / or second transfer 32, 34 of cryptocurrency, or a transaction generated by the first or second user 5, 7. It should be understood that the step 510 of transmitting the request may further include a step of transmitting a request to verify that both the first transaction 22 and the second transaction 24 were generated in a related bilateral transaction.

[0075] The method 400 includes a step 410 in which a trusted entity (TE) 3, or another entity, receives a request to verify the first transaction 22 and / or the second transaction 24.

[0076] The method 400 then includes determining 420 a first data output (O1) corresponding to (i) the first transfer 32 of the first cryptocurrency amount (B1) associated with the first transaction 22 and / or (ii) the second transfer 34 of the second cryptocurrency amount (B2) associated with the second transaction 24. In one example, the determining 420 may include receiving records from the data store 11 or another node that enable the determination of the corresponding first data output (O1) associated with the first transfer 32 and / or the second transfer 34. For example, such records may include a table that maps the first data output to the first transfer 32 and the second transfer 34, to transfers associated with the first user (A) 5, and / or to transfers associated with the second user (B) 7, etc. In another example, this may include determining transactions involving the first user (A) 5 and / or the second user (B) 7 based on records from a peer-to-peer distributed ledger to identify the first data output (O1).

[0077] The next step includes receiving 430 at least a portion of the first data output (O1) from the peer-to-peer distributed ledger 9 via the communications network 8. In some examples, the first data output (O1) or a record thereof is stored in the data store 11. However, receiving at least a portion of the first data output (O1) from the peer-to-peer distributed ledger 9 allows for verification that the first data output (O1) was actually recorded.

[0078] The next step involves determining 440 a first direction of the first transfer 32 and / or a second direction of the second transfer 34 from the first data output (O1).

[0079] Method 400 further includes verifying 450 that the first instructions of first transfer 32 and / or the second instructions of second transfer 34 correspond to the queried first transaction 22 and / or second transaction in the received request. For example, this may include comparing the first instructions of first transfer 32 of the expected cryptocurrency transfer with the first transaction 22 (and / or similarly comparing the second instructions of second transfer 34 with the queried second transaction 24).

[0080] The method 400 may further include a step 460 of transmitting an output indicative of a result of the verifying step 450. The output may be received 520 by the first user (A) 5, the second user (B) 7, or other entity or node with the queried or requested confirmation of the first and / or second transaction 22, 24.

[0081] In some examples, the method 400 further includes verifying the conditional provisions for the first transfer 32 and the second transfer 34. Thus, the method 400 may further include verifying that both the conditional steps of receiving the first request 110 and the second request 120 have been fulfilled based on the first instructions of the first transfer 32 and the second instructions of the second transfer 34. This verification step may further include querying, for example, from the data store 11 for records in which the first and second transfers 32, 34 are conditional with respect to each other. The method 400 may further include sending an output indicating that the first transaction 22 is a condition for the step of receiving the second request 120 and / or that the second transaction 24 is a condition for the step of receiving the first request 110 and that the conditional steps have been fulfilled.

[0082] <Transformation> <Metadata showing two-way transactions in data output> In some further variations, information related to the first transaction 22 and / or the second transaction 24 may be included in the first data output (O1) recorded on the peer-to-peer distributed ledger 9. The inclusion of such information may be useful for verifying the first and second transactions 22, 24 (and corresponding first and second transfers 32, 34).

[0083] One way to include such information is to include the information in metadata within the first data output (O1) associated with one or both of the first transaction 22 and the second transaction 24. Such information may include, but is not limited to: transaction conditions related to the first and / or second transactions, pointers to information related to the first and / or second transactions, one or more identifiers related to the first user (A) 5 and / or the second user (B) 7.

[0084] In some examples, the information may be of a substantial length and / or may be confidential information. Thus, in some examples, the information, or at least a portion of the information, may be hashed. This is advantageous as the hashed length is reduced and it functions to conceal the information. At the same time, the hashed information is permanently recorded on the peer-to-peer distributed ledger 9, making the record available for verifying the information. For example, an entity desiring to verify the information can hash the queried information, which is then compared to the hash recorded on the peer-to-peer distributed ledger 9.

[0085] <Metadata in the Redeem script for a pay-to-script-hash transaction> In the peer-to-peer method of the Bitcoin protocol, the metadata may be included in the output script. One example of providing metadata in the first data output is described below with reference to a pay-to-script-hash transaction. In the standard pay-to-script-hash method of the Bitcoin protocol, the output script or Redeem script may take the following form: <NumSigs PubK1 PubK2 ... PubK15 NumKeys OP_CHECKMULTISIG> Here, NumSigs is the number of valid signatures "m" required to satisfy the Redeem script to undo the transaction. PubK1, PubK2, ..., PubK15 are the public keys corresponding to the signatures that undo the transaction (up to a maximum of 15 public keys). NumKeys is the number of public keys "n".

[0086] To redeem the Redeem script above, at least "m" signatures corresponding to the public keys are needed. In some cases, the order of the public keys is important and "m" out of "n" signers must be sequential. For example, consider the case where "m" is 2 and "n" is 15. If there are two signatures available, Sig1 (corresponding to PubK1) and Sig15 (corresponding to PubK15), then the Redeem script must first be signed by Sig1, followed by Sig15.

[0087] The metadata may be embedded in the Redeem Script in one or more of the 15 locations available for the public key in the Redeem Script. For example, the Redeem Script may take the following form: <NumSigs Metadata1 Metadata2 ... PubK1 PubK2 … NumKeys OP_CHECKMULTISIG> Here, Metadata1 and Metadata2 each contain metadata that replaces the public keys in the Redeem Script, and PubK1 and PubK2 are public keys.

[0088] By inserting metadata associated with the transfer of cryptocurrency, for example information associated with the first and second transactions 22, 24, a hash of the information is included in the peer-to-peer distributed ledger 9 as a permanent record.

[0089] Thus, the method 400 for validating the first transaction 22 and / or the second transaction 24 may further include determining metadata that may be responsive to the first transaction and / or the second transaction. For example, this may include retrieving information from the data store 11, the first node 15, the second node 17, the third node 13, or other nodes related to the first and / or second transaction 22, 24. This information may be used to verify metadata associated with the first and / or second transaction 22, 24, in particular metadata that may be present in the first data output (O1) recorded on the peer-to-peer distributed ledger. If the metadata was hashed in the first data output (O1), the verifying step may include hashing said information for comparison with the hashed metadata.

[0090] <Tokenized cryptocurrency> The first transaction 22 and / or the second transaction 24 may include an intent to transfer assets (tangible and intangible) that are not strictly cryptocurrency (such as first and second cryptocurrency amounts). Alternatively, the intent may include an intent to transfer assets. Thus, one or both of the first transfer 32 and the second transfer 34 of cryptocurrency may be executed using “tokenized cryptocurrency,” such that there is a transfer of “tokens” that represent assets and rights. Among other things, the tokens may represent transferable contracts that grant certain rights to the holder to be exchanged for fiat currency, goods or services, real estate rights, etc.

[0091] In method 100, a first cryptocurrency amount (B1) may be associated with a first token (T1) and / or a second cryptocurrency amount (B2) may be associated with a second token (T2).

[0092] An example of a two-way transaction recorded in a cryptocurrency transaction (ID-600) involving tokens is described below with reference to Table 1 (miner fees are not shown for simplicity) and FIG. 5. It involves a first transaction 22 involving the transfer of a first cryptocurrency amount (B1) associated with a first token (T1). In particular, here a first user (A) 5 has a first token (T1) and intends to transfer the first token (T1) to a second user (B) 7. The other party in this two-way transaction is a second user (B) 7 transferring a second cryptocurrency amount (B2) to the first user (A) 5. In this example, the second cryptocurrency amount (B2) is not tokenized and represents a payment by the second user (B) 7 for the first token (T1). [Table 1] [Table 1]

[0093] <Input> Rows 4-8 of Table 1 represent the input of a tokenized first cryptocurrency amount (B1). The first cryptocurrency amount (B1) was the result of a previous transaction (ID-110) that transferred a first token for the benefit of a first user (A) 5. Thus, the previous transaction output script includes the first user's public key (P1A). Thus, to unlock this previous output, the script must be signed with the first user's private key (V1A). In this example, the Redeem script includes MULTISIG. MULTISIG also requires the trusted entity (TE) 3 to sign with the trusted entity's private key (V1T) to prevent inadvertent use (however, it should be understood that in some other variants, this may not be required). Row 7 of Table 1 indicates that the unlock script includes "TokenMetadata" within the Redeem script. TokenMetadata includes information allowing this first cryptocurrency amount (B1) to be recognized as a first token (T1). Finally, row 8 of Table 1 indicates that this first cryptocurrency amount (B1) will be the first output in a two-way transaction (ID-600).

[0094] Rows 9-13 of Table 1 represent the input of a second cryptocurrency amount (B2) that is not tokenized. This second cryptocurrency amount (B2) was the result of a previous transaction (ID-210) that transferred cryptocurrency for the benefit of a second user (B) 7. The previous transaction output script therefore includes the second user's public key (P1B). Thus, to unlock this previous output, the script requires a signature by the second user's private key (V1B). Finally, row 13 of Table 1 indicates that this second cryptocurrency amount (B2) becomes the second output in a two-way transaction (ID-600).

[0095] <Output> Lines 15-17 of Table 1 represent the first output of this two-way transaction (ID-600), which in this case represents the first token (T1) transferred to the second user (B) 7. Line 15 represents the output value, which is the amount of the first cryptocurrency amount (B1). Line 17 represents the output script, which is the " <redeem-script-hash>" is included.

[0096] <redeem-script-hash>is the hash of the Redeem Script. In this example, the first Redeem Script (RS1) is of the form: <2 TokenMetadata P1B P1T 3 OP_CHECKMULTISIG>

[0097] The first Redeem script (RS1) includes the metadata "TokenMetadata" in one of the fields of the MULTISIG. Thus, this first cryptocurrency amount (B1) can still be recognized as the first token (T1). Since the first token (T1) was transferred for the benefit of the second user (B) 7, this first cryptocurrency amount (B1) is locked such that the first Redeem script (RS1) includes the second user's public key (P1B) and therefore requires the second user's private key (V1B) for unlocking. In this example, the Redeem script also includes the trusted entity's public key (P1T) and therefore requires the trusted entity's private key (V1T) for unlocking. It should be understood that some other variations may not include the trusted entity (TE) 3 in the future use of the first cryptocurrency amount (B1), and in such cases, it may not be necessary to include the trusted entity's public key (P1T) in the first Redeem script (RS1).

[0098] The first Redeem script (RS1) described above is then hashed to determine a first hash (H1) that is sent for recording on the peer-to-peer distributed ledger 9.

[0099] In a future transaction of a first cryptocurrency amount (B1), for example when a second user (B) 7 wants to transfer a first token (T1), the script (e.g. an Input Script Signature (ScriptSig) of the future transaction) for unlocking the first cryptocurrency amount (B1) may be in the following format: Sig-V1B Sig-V1T <2 TokenMetadata P1B P1T3 OP_CHECKMULTISIG>

[0100] Lines 18-20 of Table 2 represent the second output of this two-way transaction (ID-600), which in this case is the second cryptocurrency amount (B2) transferred to the first user (A) 5. This second cryptocurrency amount (B2) has a value of "10000", as shown in line 18. Because this second cryptocurrency amount (B2) has not been tokenized, the first user (A) 5 should be free to use it as they see fit. Referring to line 20, the output script shows that the second cryptocurrency amount (B2) is locked with the first user's public key (P1A). It can be unlocked, if necessary, with the first user's private key (V1A).

[0101] These outputs are then recorded on the peer-to-peer distributed ledger 9 along with a first data output (O1). In particular, the first instructions of the first data output (O1) include a first hash (H1) associated with a first cryptocurrency amount (B1) to provide a first token (T1) (based on the outcome of the output script at line 17 of Table 1). The first output (O1) also includes second instructions associated with a second cryptocurrency amount (B2) (where the second instructions are based on the outcome of the output script at line 20 of Table 1).

[0102] The above examples described a first cryptocurrency amount (B1) being tokenized. It should be appreciated that in some examples a second cryptocurrency amount (B2) may also be tokenized and thus the above methods may be adapted such that the second cryptocurrency amount (B2) may provide a second token (T2). The second token (T2) may be similarly transferred and the result recorded on the peer-to-peer distributed ledger 9 including a second hash (H2) of the second Redeem script (RS2).

[0103] While the above example describes two users (5, 7) and two individual transactions (22, 24), it should be understood that variations of the method may be implemented having additional users and additional transactions. For example, an additional third user may be included, whereby the third user and the first user (A) 5 agree to have third and fourth transactions between each other. For example, the first user (A) 5 may be a retail store and the second and third users may be customers.

[0104] <Processing equipment> As described above, the first user (A) 5, the second user (B) 7, and the trusted entity (TE) 3 may be associated with the first node 15, the second node 17, and the third node 13, respectively. The first node 15, the second node 17, and the third node 13 may be electronic devices such as computers, tablet computers, mobile communication devices, computer servers, computer terminals, etc. The electronic devices may include a processing device 23, a data store 11, and a user interface. Examples of user interfaces include a keyboard, a mouse, a monitor, a touch screen display, etc. The peer-to-peer distributed ledger 9 may also be associated with a number of processing devices 19.

[0105] 6 shows an example of a processing device 19, 23. The processing device 19, 23 includes a processor 1510, a memory 1520, and an interface device 1540, which communicate with each other via a bus 1530. The memory 1520 stores instructions and data for performing the above-mentioned methods 100, 400, and the processor 1510 executes the instructions (such as computer programs) from the memory 1520 to perform the methods 100, 400. The interface device 1540 may include a communication module for enabling communication with the communication network 8 and, in some examples, peripherals such as a user interface and a data store 11. It should be noted that the processing device 1510 may be an independent network element, but the processing device 1510 may be part of another network element. Furthermore, some functions performed by the processing device 19, 23 may be distributed among multiple network elements. For example, a trusted entity (TE) 3 may be associated with multiple processing devices 23 to perform the methods 100, 400 in a secure local area network associated with the trusted entity (TE) 3.

[0106] It will be understood by those skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments without departing from the broad general scope of the present disclosure, The present embodiments are therefore considered in all respects to be merely illustrative and not restrictive.

Claims

1. 1. A computer-implemented method for recording a plurality of transactions between a plurality of users on a blockchain, the plurality of transactions including a first transaction from a first user to a second user and a second transaction from the second user to the first user, the method comprising: receiving, from a first node associated with the first user, a first request to transfer a first cryptocurrency amount from the first user to the second user, the first request being associated with the first transaction; receiving, from a second node associated with the second user, a second request to transfer a second amount of cryptocurrency from the second user to the first user, the second request being associated with the second transaction, the first transaction being executed contingent on receipt of the second request, and / or the second transaction being executed contingent on receipt of the first request, the first transaction and the second transaction requiring a signature of one of the first user and the second user in addition to a third party; validating the first request and the second request; Including, The step of verifying the first request and the second request further comprises: determining that both the first request and the second request have been received, wherein receipt of both the first request and the second request is evaluated by the third party; Based on the step of validating the first request and the second request, the method further comprises: The third party transmits the information to the blockchain via a communication network. a first instruction for a first transfer of the first amount of cryptocurrency to the second user; and second instructions for a second transfer of the second amount of cryptocurrency to the first user; transmitting a first data output including:

2. The method of claim 1 , wherein the condition comprises one or more rules that are evaluated to generate a Boolean value or output.

3. The method of claim 1 , wherein the first request includes a first indication that the first transaction is to be performed contingent upon receipt of the second request.

4. 4. The method of claim 1, wherein the second request includes a second indication that the second transaction is to be performed conditional on receipt of the first request.

5. 5. The method of claim 1, further comprising: receiving a third notification, the third notification specifying that the first transaction is to be executed conditional on receipt of the second request, and that the second transaction is to be executed conditional on receipt of the first request.

6. 6. The method of claim 1, wherein the step of verifying the first request and the second request further comprises the step of authenticating that the first request is from the first user and that the second request is from the second user.

7. 7. The method of claim 1, wherein the step of verifying the first request and the second request further comprises determining authority to transfer the first cryptocurrency amount from the first user and authority to transfer the second cryptocurrency amount from the second user.

8. The method of claim 1 , wherein the first data output further comprises metadata associated with one or both of the first transaction and the second transaction.

9. The metadata associated with one or both of the first transaction and the second transaction includes: information relating to said first and / or second transactions; a pointer to information relating to said first and / or second transactions; One or more identifiers associated with the first user and / or the second user; The method of claim 8 , comprising hashing one or more of:

10. 10. The method of claim 1, wherein the first cryptocurrency amount is associated with a first token and / or the second cryptocurrency amount is associated with a second token.

11. The method comprises: determining a first hash of the first Redeem script; The first Redeem script includes: at least first metadata including information associated with the first token; a second user public key associated with the second user, the second user public key forming a cryptographic pair with a second user private key; a trusted entity public key associated with the trusted entity, the trusted entity public key forming a cryptographic pair with the trusted entity private key; Based on The first data output is: the first hash, the first hash being associated with the first cryptocurrency amount to provide the first token; The method of claim 10.

12. The method comprises: determining a second hash of the second Redeem script; The second Redeem script includes: at least second metadata including information associated with the second token; a first user public key associated with the first user, the first user public key forming a cryptographic pair with a first user private key; a trusted entity public key associated with the trusted entity, the trusted entity public key forming a cryptographic pair with the trusted entity private key; Based on The first data output is: the second hash, the second hash being associated with the second cryptocurrency amount to provide the second token; 12. The method according to claim 10 or 11.

13. 13. A computer-implemented method for validating the first transaction and / or the second transaction based on the first data output to a blockchain according to any one of claims 1 to 12, comprising: receiving a request to confirm the first transaction and / or the second transaction; determining the first data output corresponding to the first transfer of the first cryptocurrency amount associated with the first transaction and / or the second transfer of the second cryptocurrency amount associated with the second transaction; receiving at least a portion of the first data output from the blockchain via the communications network; determining from the first data output the first indication of the first transfer and / or the second indication of the second transfer; verifying that the first indication of the first transfer and / or the second indication of the second transfer correspond to the first transaction and / or the second transaction in the request; sending an output indicative of the results of said verifying step; The method includes:

14. The method comprises: verifying that both the first request and the second request have been received based on the first indication of the first transfer and the second indication of the second transfer; sending an output indicating that the first transaction is conditional on receipt of the second request and / or that the second transaction is conditional on receipt of the first request, and that both the first request and the second request have been received; 14. The method of claim 13, comprising:

15. The method comprises: determining metadata associated with the first transaction and / or the second transaction; the verifying step further comprises verifying that the metadata corresponds to the first transaction and / or the second transaction.

15. The method according to claim 13 or 14 dependent on claim 8.

16. The method comprises: receiving and determining a verification hash, information relating to said first and / or second transactions; a pointer to information relating to said first and / or second transactions; One or more identifiers associated with the first user and / or the second user; receiving and determining one or more verification hashes of Verifying that the verification hash corresponds to a hash in the metadata of claim 9; 16. The method of any one of claims 13 to 15, further comprising:

17. A computer program comprising machine readable instructions for causing a processing device to carry out a method according to any one of claims 1 to 16.

18. Apparatus comprising a first processing unit adapted to carry out a method according to any one of claims 1 to 16.

19. 1. An apparatus for recording a plurality of transactions between a plurality of users on a blockchain, the plurality of transactions including a first transaction from a first user to a second user and a second transaction from the second user to the first user, the apparatus comprising: a processor, the processor comprising: receiving a first request from a first node associated with the first user to transfer a first cryptocurrency amount from the first user to the second user, the first request being associated with the first transaction; receiving a second request from a second node associated with the second user to transfer a second amount of cryptocurrency from the second user to the first user, the second request being associated with the second transaction, the first transaction being executed contingent on receipt of the second request, and / or the second transaction being executed contingent on receipt of the first request, the first transaction and the second transaction requiring a signature of one of the first user and the second user in addition to a third party; verifying the first and second requests, wherein verifying the first and second requests includes the processing device determining that both the first and second requests have been received, wherein receipt of both the first and second requests is evaluated by the third party; Based on verifying the first request and the second request, the processing device transmits, via a communication network, to a blockchain; a first instruction for a first transfer of the first amount of cryptocurrency to the second user; and second instructions for a second transfer of the second amount of cryptocurrency to the first user; a first data output including:

Images