Computer-implemented system and method for performing transaction mixing on a blockchain

Abstract

A system for performing transaction mixing between a plurality of users on a blockchain is provided. The blockchain may be, for example, the Bitcoin blockchain. The system is configured to carry out the steps of: (i) preparing a first commitment transaction arranged to transmit control of a resource from a source address of a first user to a receiving address of a second user; (ii) preparing a second commitment transaction arranged to transmit control of a resource from a source address of the second user to a receiving address of a further user; (iii) preparing a further commitment transaction arranged to transmit control of a resource from a source address of the further user to either: (a) a receiving address of the first user; or (b) a receiving address of a yet further user and repeating step (iii) until option (a) is performed to complete a transaction chain; and (iv) executing the transaction chain. At least one of the users is randomly chosen from the plurality.

Claims

1. A system comprising: one or more processors; and memory storing computer-executable instructions that, if executed, cause the one or more processors to construct a transaction channel for performing transaction mixing between a plurality of users on a blockchain by at least carrying out the steps of: (i) preparing a first commitment transaction arranged to transmit control of a resource from a source address of a first user to a receiving address of a second user; (ii) preparing a second commitment transaction different to the first commitment transaction arranged to transmit control of a resource from a source address of the second user to a receiving address of a further user, wherein the second payment channel is prepared after the first payment channel; (iii) preparing a further commitment transaction different to the first and second commitment transactions arranged to transmit control of a resource from a source address of the further user to either: (a) a receiving address of the first user; or (b) a receiving address of a yet further user and repeating step (iii) until option (a) is performed to complete a transaction chain, wherein the further payment channel is prepared after the second payment channel; and (iv) executing the transaction chain in a reverse order to an order that the transaction chain is prepared, wherein: a value of k selected by the first user is revealed to the remaining users in the reverse order such that payment transactions of the respective payment channels are submitted to the blockchain in the reverse order; the value of k is revealed by the first user to the further user or yet further user by direct communication or by retrieval from the blockchain; the value k is revealed to a next user in the reverse order by retrieval from the blockchain of an immediately previously submitted payment transaction according to the reverse order; and the second, further, and yet further user are selected at random from the plurality of users.

2. The system of claim 1, wherein at least one commitment transaction is arranged to transmit control of a respective resource responsive to satisfaction of an execution condition of the at least one commitment transaction.

3. The system of claim 2, further configured to carry out the step of preparing at least one execution transaction arranged to satisfy a respective execution condition.

4. The system of claim 2, wherein the execution condition of the at least one commitment transaction comprises supply of a respective secret value.

5. The system of claim 4, wherein at least one secret value is to be chosen by the first user, and wherein at least one execution condition comprises supply of the chosen secret value.

6. The system of claim 5, wherein at least one secret value is calculable responsive to at least one of: (i) supply of the chosen secret value; and (ii) supply of at least one other secret value.

7. The system of claim 1, wherein at least one commitment transaction is arranged to return control of a respective resource to a respective user upon satisfaction of a return condition.

8. The system of claim 7, further configured to carry out the step of preparing at least one return transaction comprising a locktime, the at least one return transaction arranged to satisfy at least one respective return condition upon expiry of the locktime.

9. The system of claim 1, further configured to submit to a blockchain at least one prepared transaction.

10. The system of claim 1, further configured to execute the transaction chain in an order reverse to the order in which the transaction chain is prepared.

11. The system of claim 1, wherein the resource from the source address of the first user, the resource from the source address of the second user, and the resource from the source address of the further user are identical to one another.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiments described herein. Embodiments of the present invention will now be described, by way of example only, and with reference to the accompany drawings, in which:

(2) FIG. 1 shows the transactions used in a payment channel of the prior art;

(3) FIG. 2 shows an Atomic Cross-Chain Trading algorithm of the prior art;

(4) FIG. 3 shows a payment channel of a first embodiment of the present invention;

(5) FIG. 4 illustrates an order in which payment channels of the present invention may be created;

(6) FIG. 5 illustrates a chain of payment channels of the first embodiment;

(7) FIG. 6 shows an example commitment transaction of the first embodiment;

(8) FIG. 7 shows an example refund transaction of the first embodiment;

(9) FIG. 8 shows an example payment transaction of the first embodiment;

(10) FIG. 9 shows an algorithm for constructing the payment channel of FIG. 1;

(11) FIG. 10 shows an algorithm for constructing a payment channel of the first embodiment;

(12) FIG. 11 shows an algorithm for constructing a chain of payment channels of the first embodiment;

(13) FIG. 12 shows an algorithm for the process of submitting payment transactions of the first embodiment;

(14) FIG. 13 shows a payment channel of a second embodiment of the present invention;

(15) FIG. 14 shows an algorithm for constructing a payment channel of the second embodiment;

(16) FIG. 15 shows an algorithm for constructing a chain of payment channels of the second embodiment;

(17) FIG. 16 illustrates a chain of payment channels of the second embodiment;

(18) FIG. 17 shows a representation of execution of a chain of payment channels of the second embodiment;

(19) FIG. 18 shows an algorithm for the process of submitting payment transactions of the second embodiment;

(20) FIG. 19 illustrates a chain of payment channels of the second embodiment including refund transactions;

(21) FIG. 20 illustrates locktime requirements for refund transactions of the second embodiment;

(22) FIG. 21 shows an example commitment transaction of the second embodiment;

(23) FIG. 22 shows an example refund transaction of the second embodiment;

(24) FIG. 23 shows an example payment transaction of the second embodiment; and

(25) FIG. 24 shows example scripts for use in the second embodiment.

DETAILED DESCRIPTION

(26) A protocol, named the Group Random Exchange (GRE) protocol embodying the present invention, is described herein for a user to move funds from one address to another while obscuring the link between the user's addresses and while removing the possibility of a user having his/her funds stolen. It is built on the concept of a group agreeing for each member of the group to pay x BTC to one other member such that everyone gets paid.

(27) Who a user pays x BTC to is random and who pays the user x BTC is also random. By doing this the user may send his x BTC to one address but accept receipt of x BTC at a different address from a different user who is randomly determined. This randomness makes it difficult for someone external to the protocol to analyse the blockchain and determine a link between the user's input and output addresses.

(28) Moreover, the GRE protocol is able to accomplish this exchange between a group of n users where no user within the group risks losing their funds. The protocol uses refund transactions, where applicable, to allow a user to reclaim their funds if anything does not go as planned in the execution of the protocol.

(29) The GRE Protocol builds on two existing Bitcoin-related technologies. The first of these is Payment Channels (‘Introduction to Micropayment Channels’ http://super3.org/introduction-to-micropayment-channels/), which is a technique designed for off-block bitcoin transactions between a pair of users and notably incorporates the usage of refund transactions. The second of these technologies is Atomic Cross-Chain Trading (ACCT) (‘Atomic cross-chain trading’, https://en.bitcoin.it/wiki/Atomic_cross-chain_trading), which is a protocol designed for a user with x coins in one cryptocurrency to exchange them for another user's y coins in another cryptocurrency. This is done as a “fair exchange”, such that a first user cannot acquire a second user's coins without giving the second user the ability to collect the coins they are owed by the first user.

(30) Whereas ACCT describes an exchange between two users, the present invention relates to the GRE protocol, which provides group exchange between more than two users where a second user who is paid by a first user is not the user who pays the first user.

(31) Payment Channels

(32) Payment channels are techniques designed for users to make multiple Bitcoin transactions without committing all of the transactions to the blockchain. In a typical payment channel implementation, a nearly unlimited amount of payments can be made but it is only ever necessary to add two transactions to the blockchain.

(33) In addition to the reduced number of transactions being added to the blockchain and the associated reduced costs, payment channels also offer the advantage of speed and, importantly, the ability of the users to have their funds refunded if the things do not go as planned or either user decides not to proceed beyond a certain set of payments. A description of a payment channel implementation is outlined below.

(34) Consider the scenario where Alice needs to pay Bob for a service. This may require multiple payments from Alice to Bob over a period of time as the situation demands. Alice expects to spend at most 15 BTC (in total) to Bob in the possible set of exchanges. To facilitate this, a payment channel is established between Alice and Bob and operates as follows: Alice creates a 2-of-2 multisignature pay to script hash (P2SH) transaction, T.sub.c, governed by both Alice and Bob that commits 15BTC originating from Alice. At this point the transaction is not submitted to the bitcoin network (such a multisignature address requires that 2 individuals (Alice and Bob) sign any transaction that spends money from this address); Alice creates a separate refund transaction, T.sub.r,0, returning all the funds from the ‘multisignature controlled funds’ to Alice. This transaction includes an nLockTime value of 100 blocks (nLockTime is a Bitcoin transaction parameter that allows a Bitcoin transaction to only be executable after a specified time has passed). Bob signs the transaction. This refund transaction allows Alice to be refunded, after nLockTime has transpired, if the exchange between Alice and Bob goes awry; Alice signs the original transaction T.sub.c; At this point Alice and Bob may proceed to create new refund transactions to reflect the (off the blockchain) payments being made from Alice to Bob. These refund transactions would reflect the net sum of money that Alice is required to pay Bob at that point in time. As an example, if Alice is to pay Bob 5BTC, a new refund transaction, T.sub.r,i, is created that has an outputs sending 5BTC to Bob and 10BTC back to Alice. If Alice needs to pay another 5BTC to Bob then the new refund transaction, T.sub.r,i+1, is created with outputs sending 10BTC to Bob and 5BTC to Alice. For each new refund transaction, assuming they are in agreement with the details, both parties sign the transaction but do not necessarily submit the transaction to the network; Note that each successive refund transaction created has a lower nLockTime than that of the previous refund transaction; nLockTime(T.sub.r,i+1)<nLockTime(T.sub.r,i); If a user refuses to sign any T.sub.r,i then an aggrieved user may simply submit the T.sub.r,i−1. In the worst case scenario Alice signs T.sub.r,0 and submits it to the network reclaiming all her funds (after nLockTime has expired); and The final refund transaction constructed represents the net sum of funds being transferred from Alice to Bob. This transaction is submitted to the network.

(35) FIG. 1 shows the transactions used in a payment channel. M represents the maximum amount of money that may be sent from Alice to Bob. x.sub.i is the current net sum of funds Alice needs to pay to Bob. S.sub.stop is the nLockTime on the initial refund transaction. n is the number of refund transactions created in the ongoing (off-block) payments made between Alice and Bob (this excludes the initial refund transaction). s is the time allotted for both users to agree to a refund transaction before a party risks the other party submitting the previous refund transaction, effectively ending the exchanges between Alice and Bob.

(36) Note that:
t+n*s<S.sub.stop, where t is the current time, and
(S.sub.stop−n*s)≥s.

(37) Transactions T.sub.c and T.sub.r,n, of FIG. 1 are the transactions that appear on the blockchain. FIG. 9 shows a flow chart comprising steps involved in constructing the payment channel between Alice and Bob.

(38) Atomic Cross-Chain Trading

(39) For digital exchanges a “fair exchange” protocol is often necessary. The exchange represents a scenario where one user, UserA, is in possession of a value x and wants to exchange it for a value y owned by UserB. A fair exchange protocol allows the two users to either: (i) both honour and exchange; or (ii) neither honour and exchange. In Even, S. and Yacobi, Y., 1980. Relations among public key signature systems (Vol. 268). Technical Report 175, Technion, Haifa, Israel, (http://ftp.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/1980/CS/CS0175.pdf), it is shown that deterministic fair exchange is impossible without a trusted third party.

(40) In the case of ACCT its authors devised a fair exchange protocol for two users to exchange coins across separate cryptocurrencies. For their solution the blockchains of the cryptocurrencies act as the trusted third party. An algorithm for ACCT is shown in FIG. 2, where Alice, A, pays w BTC to Bob, B, in exchange for v alt-coins.

(41) This is ACCT (with timeout). If the process is halted, it can be reversed no matter when it is stopped.

(42) With reference to FIG. 2, below is an example timeline of events during use of ACCT by users A and B:

(43) Before 1): Nothing public has been broadcast, so nothing happens;

(44) Between 1) and 2): A can use a refund transaction after 72 hours to get his money back;

(45) Between 2) and 3): B can get a refund after 24 hours. A has 24 more hours to get his refund;

(46) After 3): Transaction is completed by 2), A must spend his new coin within 24 hours or B can claim the refund and keep his coins; B must spend his new coin within 72 hours or A can claim the refund and keep his coins.

(47) For safety, both A and B should complete the process with lots of time until the deadlines.

(48) Group Random Exchange

(49) The present invention relates to a Group Random Exchange (GRE) protocol. It provides a solution for the swapping of bitcoins within a group of n users where n>2. Each user in the group is able to swap an amount of bitcoins in their possession for the same amount of bitcoins.

(50) However, without any change to the protocol, it is possible for the amount of bitcoins being exchanged between two users to not be equal. The value being exchanged between U.sub.i and U.sub.(i+1)mod n may be any value the pair of users is able to negotiate between themselves.

(51) Assuming x BTC is the agreed amount being exchanged, if desirable to all of the users affected, a user may pay (x+a) BTC whereas a user may withdraw (x−b) BTC. For example, a user U.sub.1 has 10BTC for exchange. U.sub.1 is willing to accept 8BTC from user U.sub.0 if that is the best offer available to U.sub.1. U.sub.1 does this while understanding that it remains possible that further user U.sub.2 will insist on receiving 10BTC. In other words, the value U.sub.1 pays does not necessarily have to be the value U.sub.1 is paid, if and only if U.sub.1 accepts these terms, and the value U.sub.1 pays may be the value U.sub.1 is paid if U.sub.1 insists.

(52) From hereon, the description is limited for explanatory purposes only to the scenario where each user pays and is paid x BTC.

(53) Furthermore, users may exchange tokens within the protocol. A token represents an asset or resource according to a smart contract associated with the token such that control of the token affords control of the asset or resource.

(54) The net change in the bitcoins owned by a user does not change after participating in the exchange protocol, assuming transaction fees are ignored (transaction fees are costs associated with every Bitcoin transaction). Given a first user being UserA, UserA pays UserB the amount x BTC, UserC pays UserA x BTC, where UserB is not the same user as UserC. Additionally, each user has a source address associated with sending payments, and a receiving address associated with receiving payments, where the source address and receiving address are different. However, by participating in the protocol the user's bitcoins which were stored at a Bitcoin address are now in effect transferred to another address owned or controlled by the same user. Due to the exchange protocol processes, the transfer of bitcoins across addresses is accomplished in a way that obscures, in analysis of the blockchain, the transfer of funds.

(55) The GRE protocol differs from ACCT in that ACCT only outlines a mutual exchange between a pair of users, whereas the GRE protocol describes an exchange where: there are more than 2 users; and in the process of being paid and paying, the second user a first user pays is not the user from whom the first user receives payment.

(56) The GRE protocol achieves this in a way that: users of the protocol are at no risk of losing their bitcoins; and the second user who a first user pays is random, as is the user who pays the first user.

(57) Group Random Exchange of the First Type—Secret Value

(58) The group random exchange protocol operates in one of two ways, each embodying the present invention. A configuration of the present invention will now be described.

(59) Given the interest of the set of n users U.sub.i|i∈[0, n−1] participating in the GRE protocol of a configuration of the present invention to swap x BTC, the protocol operates in the following way: The users are randomized to realise an ordered set {U.sub.0, U.sub.1, . . . , U.sub.n−2, U.sub.n−1}; One of these users is deemed the ‘initiator’ or ‘initiating user’. For our purposes U.sub.0 is considered the initiator; The initiator U.sub.0 chooses a random number k and calculates H(k) where H(⋅) represents a deterministic hash function; The value of k is kept private by U.sub.0 but the value H(k) is distributed to all users of the GRE; A time value s is chosen that represents the amount of time each user U.sub.i is given to construct the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n, retrieve the value of k, and submit execution transaction T.sub.pay that pays U.sub.(i+1)mod n to the Bitcoin network. Any user in the group may choose time s, given the consensus of the other users. In a preferred embodiment, the initiator chooses s to simply the protocol. Time s is expressed in either seconds or number of blocks; Another value, S, is chosen as the starting time of the first payment to a user being submitted to the Bitcoin network. Any user in the group may choose S, given the consensus of the other users. In a preferred embodiment, the initiator chooses s to simply the protocol. Note that S represents a point in time specified in either Unix time or block height, whereas s represents a time span; A one-way payment channel is established between every pair of users where the direction of the payment is such that U.sub.i pays U.sub.(i+1)mod n (represented herein by U.sub.i.fwdarw.U.sub.(i+1)mod n). As an example, assuming n=7, the payment channels of the GRE would consist of U0.fwdarw.U1, U1.fwdarw.U2, . . . , U6.fwdarw.U0. The processes of the creation of a payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n are shown in FIGS. 3 and 10, wherein σ(U.sub.i) represents the signature of U.sub.i: the initial commitment transaction T.sub.c makes available x BTC that can only be spent by providing either: (i) the signatures of both U.sub.i and U.sub.(i+1)mod n; or (ii) k and the signature of U.sub.(i+1)mod n (see FIG. 6 for reference); only one refund transaction is required here: refund function T.sub.r,0, which returns all x BTC to U.sub.1 (see FIG. 7 for reference); the refund transaction T.sub.r,0 contains an nLockTime value S+(n−i)s; The refund transaction T.sub.r,0 must be signed by U.sub.(i+1)mod n before the initial commitment transaction T.sub.c is submitted to the Bitcoin network; The payment channel contains a payment transaction T.sub.pay which pays x BTC, from the committed x BTC of T.sub.c, to U.sub.(i+1)mod n; and the <scriptSig> for the payment transaction T.sub.pay to U.sub.(i+1)mod n contains within it value k (see FIG. 8 for reference); It is important that the payment channels between pairs of users be created in an ordered sequence, in that the payment channel U.sub.i−1.fwdarw.U.sub.i is set up before the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n. This begins with the creation of the first payment channel U.sub.0.fwdarw.U.sub.1 where U.sub.0 is the initiator and ends with the last payment channel U.sub.n−1.fwdarw.U.sub.0. FIG. 4 illustrates the order of construction of the payment channels.

(60) In some configurations, the order of the sequence is important as this allows user U.sub.i, before risking making their payment, to ensure that: there exists a T.sub.pay transaction to U.sub.i that requires only that U.sub.i has knowledge of k for transaction T.sub.pay to be accepted by the Bitcoin network; and the criteria found in the T.sub.pay of the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n (U.sub.i spends) are the same as that of T.sub.pay of the payment channel U.sub.i−1.fwdarw.U.sub.i (U.sub.i receives).

(61) Only the initiator U.sub.0 does not have to prioritise receiving ahead of payment. However U.sub.0 cannot be cheated as U.sub.0 is the only user with knowledge of the value of k. Therefore no withdrawal can be performed by anyone in the GRE protocol until U.sub.0 is comfortable starting the process (coinciding with its release of k).

(62) The processes of the creation of the set of U.sub.i.fwdarw.U.sub.(i+1)mod n payment channels for a GRE instance are illustrated in FIG. 11.

(63) It is assumed that the final payment channel U.sub.n−1.fwdarw.U.sub.0 is finalised at or before time S. Once this final payment channel is constructed, a chain of transactions, or a transaction chain, can be said to have been completed linking all of the users of the protocol.

(64) FIG. 5 illustrates a representation of the U.sub.i.fwdarw.U.sub.(i+1)mod n payment channels existing between all users of the GRE protocol. Arrows signify the payment channels and direction of T.sub.pay payment. Expressions externally adjacent the arrows represent the criteria for transaction T.sub.pay to be accepted by the blockchain. Note that σ(U.sub.i) represents the signature of U.sub.i. Expressions internally adjacent the arrows represent the s time span values.

(65) In light of the circular arrangement, the fact that the order of U.sub.i|i∈[0, n−1] was random means that the persons paying and paid by user U.sub.i are both random. Furthermore, the persons paying and paid by user U.sub.i are different.

(66) The initiator U.sub.0 spends the transaction T.sub.pay of the existing payment channel U.sub.n−1.fwdarw.U.sub.0, revealing the value of k. U.sub.0 can communicate this value of k directly to U.sub.n−1 or this value may be retrieved from the blockchain.

(67) Similarly each user U.sub.1 may directly communicate the value k to its payer U.sub.i−1. If U.sub.i does not, user U.sub.i−1 may find the value in the blockchain ledger (within at least time s).

(68) As the blockchain takes, at the time of filing this application, on average 10 minutes to confirm a transaction, the value of s should be chosen such that the time period it represents is sufficient for any user U.sub.i to find if necessary, within that time period, the value of k in a transaction T.sub.pay (of the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n) after the transaction is submitted to the Bitcoin network. The value of s should also include an estimated time for the construction of the payment channel between a pair of users. Therefore s may be chosen to be s=s.sub.k+ε where s.sub.k is the estimated time to find k and submit T.sub.pay and ε is the estimated time to construct the payment channel.

(69) As the initiating user U.sub.0 has now submitted to the network the T.sub.pay transaction of the existing payment channel between U.sub.n−1 and U.sub.0, revealing the value of k to U.sub.n−1, the value of k can then be revealed to every other user U.sub.i in a reverse sequential way (from U.sub.n−1 to U.sub.2). This is based on the premise that each user, U.sub.i, will be invested in submitting the transaction (T.sub.pay of the payment channel U.sub.i−1 to U.sub.i) that allows themselves to get paid. User U.sub.i submitting said transaction will require obtaining the value of k from T.sub.pay of the payment channel U.sub.i to U.sub.i+1 (which would have been made available previously). Through U.sub.i submitting that transaction T.sub.pay of the payment channel U.sub.i−1 to U.sub.i, the value of k is then made available to user U.sub.i−1. This process cascades all the way from U.sub.n−1 to U.sub.1 in such a way that each user U.sub.i cashing in reveals k to user U.sub.i−1, allowing the user U.sub.i−1 to also cash in.

(70) More formally, the sequence of submission of T.sub.pay transactions executing the payment channels occurs as follows:
[T.sub.pay:U.sub.n−1.fwdarw.U.sub.0,[T.sub.pay:U.sub.n−2.fwdarw.U.sub.n−1], . . . ,[T.sub.pay:U.sub.1.fwdarw.U.sub.2],[T.sub.pay:U.sub.0.fwdarw.U.sub.1]

(71) Completion of the set of T.sub.pay transactions successfully concludes the GRE. Each user paid x BTC and each user received x BTC.

(72) The processes of submitting the T.sub.pay: U.sub.n−1.fwdarw.U.sub.(i+1)mod n transactions for a GRE instance are illustrated in FIG. 12.

(73) Below, a description is given of the construction of the Bitcoin transactions utilised in the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n between a pair of users. These payment channels comprise three main transactions: Deposit into 2-of-2 multisignature Transaction T.sub.c: This transaction represents the commitment component of the payment channel, and may be referred to as a commitment transaction. Here, through the transaction, user U.sub.i sends/commits a specified number of bitcoins, x BTC, to be governed by either: a 2-of-2 multisignature U.sub.(i+1)mod n) OR knowledge of a value k AND the signature of U.sub.(i+1)mod n; Refund Transaction T.sub.r,0: This transaction represents the refund of x BTC (from the commitment transaction) back to user U.sub.i after a specified time has expired. For this transaction to be executed successfully it requires the signatures of users U.sub.i and U.sub.(i+1)mod n; and Payment Transaction T.sub.pay: This transaction is the payment of x BTC from U.sub.i to U.sub.(i+1)mod n. For this transaction to be executed successfully it requires the knowledge of value k and the signature of U.sub.(i+1)mod n. Payment transactions may also be referred to as execution transactions.

(74) Note that while the details of the transaction are limited to the <scriptSig>, <scriptPubkey>, nLockTime, and output values of the various transactions, as these are most relevant to the GRE protocol described, other functions and values may be used.

(75) Group Random Exchange of the Second Type—Changing Secret

(76) A further configuration of the present invention will now be described.

(77) In the case of the GRE protocol of the configuration described above, the value k being common for each of the payment channels may act as a limitation on the level of anonymity the GRE may provide to a user thereof. This is due to the fact that the shared use of k and/or its hash, H(k), makes it easier for an external observer to associate the set of transactions involved in that specific instance of a GRE. This reduces the observer's effort required to trace a user's movement of funds from one address to another.

(78) In contrast to the configuration described above which uses the same secret value in all payment channels, the configuration described below uses a different secret value for each of the payment channels in the GRE exchange. Moreover, although the secret value is different for each channel, the revelation of the secret value when a transaction is submitted to the blockchain provides sufficient information for the subsequent revelation of the secret value in the next payment channel of the sequence.

(79) To achieve this functionality, this configuration utilises the property of Elliptical Curve (EC) cryptography such that E(m)+E(n)=E(m+n); where E(x)=xG and G is a base point on the Elliptic Curve. However, other types of encryption having substantially similar homomorphic-like properties may be used in place of EC encryption.

(80) An Elliptic Curve is the set of points described by the equation:
y.sup.2≡x.sup.3+ax+b(mod p);
where 4a.sup.3+27b.sup.2 ≢0 (mod p) and p is prime.

(81) The EC Arithmetic functionality required inside Bitcoin script is that of point multiplication by scalar. This is the operation such that:

(82) $nP = \underset{\underset{n}{︸}}{P + P + .Math. + P};$

(83) where n is a natural number, P is a point on the Elliptic Curve, and + is the operator for addition of points on the EC.

(84) Scalar multiplication in turn requires the specific EC group operations Point Addition and Point Doubling: Point Addition P+Q: With this operation, we compute a new point on the EC as a negation of the intersection of the curve. This can be described as R=P+Q, Point Doubling P+P: Using point addition, we can compute a point double of P. This can be described as R=P+P=2P.

(85) More specifically, given two points, P(x.sub.1,y.sub.1) and Q(x.sub.2,y.sub.2), on the EC:

(86) $P + Q = (x_{3}, y_{3});$ $where :$ $x_{3} = m^{2} - x_{1} - x_{2} \mod p;$ $y_{3} = m (x_{1} - x_{3}) - y_{1} \mod p; and$ $m = {\begin{matrix} \frac{y_{2} - y_{1}}{x_{2} - x_{1}} \mod p = if P \neq Q & (Point Addition) \\ \frac{3 x_{1}^{2} + a}{2 y_{1}} \mod p : if P = Q & (Point Doubling) \end{matrix} .$

(87) As described above, the use of the value k (and in tandem H(k)), as criterion in each of the payment channels in the GRE circuit of the configuration using the same secret value in all payment channels, may prove to be a limitation as it relates to desire for anonymity.

(88) If a user desires anonymity in the GRE exchange as it relates to the user's movement of bitcoins, it is expected that the address that U.sub.1 pays x BTC from is different from the address that user receives x BTC into. This disconnect between addresses is meant to disassociate the payment and receipt transactions from each other in the Bitcoin blockchain.

(89) However, an external observer with knowledge of the GRE protocol would know that Bitcoin transactions with scripts that contain a type of criteria are artefacts of an instance of a GRE. Moreover, since k and its hash are found within a subset of these GRE instances, the external observer would then be able to identify all transactions related to a specific instance of GRE, or at least drastically reduce the size of the set of possible transactions.

(90) While not guaranteeing success, this puts the external observer in a better position to track the movement of bitcoins in the GRE instance.

(91) This configuration uses a GRE protocol wherein each payment channel uses a different unique secret value (sv) and a corresponding encrypted version of the secret value. It is to be noted that, in this configuration, hash functions themselves are not used but are replaced by EC encryption. This serves to reduce the ability for external observers to identify the set of transactions belonging to a specific GRE instance.

(92) The different secret values of this configuration are expected to satisfy the following conditions: a. The secret values should be difficult to guess; b. The revelation of an sv.sub.(i+1)mod n in executing T.sub.Pay for the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n should allow sv.sub.1 of the next payment channel in GRE sequence U.sub.i−1.fwdarw.U.sub.i (anticlockwise) to be revealed or at least be easily calculable; c. It should be difficult for external observers to identify a relationship between secret keys (or secret key encryptions (ciphertexts)); and d. Users in the exchange should be at no risk of losing their funds.

(93) It is possible to satisfy the previous criteria using EC encryption as a replacement of hash functions. For EC encryption a scalar value is multiplied by a base point G on the EC. The scalar value k is a secret key and Q=kG is the encrypted output. Determining k from Q is a ‘hard’ discrete logarithm problem.

(94) Furthermore, for the addition operator of Elliptic Curve arithmetic, mG+nG=(m+n) G for a base point G.

(95) This characteristic of EC cryptography allows for the revelation of another secret value, in sequence, for condition b.

(96) Given a group of n users {U.sub.1|i∈[0, n−1]} participating in the GRE protocol to swap x BTC, the protocol of this configuration of the present invention operates in the following way. Users agree upon parameters (p,a,b,G,n,h) of Elliptic Curve Digital Signature Algorithm (ECDSA) curve. e.g. secp256k1; The users are randomized to realise an ordered set {U.sub.0, U.sub.1, . . . , U.sub.n−2, U.sub.n−2}; One of these users is deemed the ‘initiator’. For our purposes U.sub.0 is considered the initiator; The initiator U.sub.0 chooses a random number k.sub.s and calculates k.sub.sG where G represents the base point on the Elliptic Curve; The value of k.sub.s is kept private by U.sub.0; Each of the other users U.sub.1 to U.sub.n−1 chooses a random number. U.sub.1 selects k.sub.1, U.sub.2 selects k.sub.2, . . . , and U.sub.n−1 selects k.sub.n−1. Each of these other users securely send their chosen value to U.sub.0. U.sub.0 also chooses a second random number, k.sub.0. A time value s is chosen that represents the amount of time each U.sub.i is given to construct the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n, retrieve the necessary secret value, and submit the execution transaction T.sub.Pay that pays U.sub.(i+1)mod n to the Bitcoin network. Time s is expressed as either seconds or number of blocks. Another value S is chosen as the starting time of the first payment to a user being submitted to the Bitcoin network. Note that S represents a point in time specified in either Unix time or block height, whereas s represents a time span.

(97) A one-way payment channel is established between every pair of users where the direction of the payment is such that U.sub.i pays U.sub.(i+1)mod n. As an example, assuming n=7, the payment channels of the GRE would comprise U.sub.0.fwdarw.U.sub.1, U.sub.1.fwdarw.U.sub.2, . . . , and U.sub.6.fwdarw.U.sub.0.

(98) The processes of the creation of a payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n are described below and illustrated in FIGS. 13 and 14: The initial commitment transaction T.sub.c makes available x BTC that can only be spent, as per its <scriptPubkey>, by either ‘the signatures of both U.sub.i and U.sub.(i+1)mod n’ OR ‘sv.sub.(i+1)mod n AND signature of U.sub.(i+1)mod n’; There is only need for one refund transaction for our purposes; this refund transaction, T.sub.r,0 returns all x BTC to U.sub.1; The refund transaction, T.sub.r,0, of the payment channel contains an nLockTime value S+(n−i)s; The refund transaction T.sub.r,0 must be signed by U.sub.(i+1)mod n before the initial commitment transaction T.sub.c is submitted to the Bitcoin network; The payment channel contains a payment transaction T.sub.Pay which pays x BTC, from the committed x BTC of T.sub.c, to U.sub.(i+1)mod n; and The <scriptSig> for the payment transaction T.sub.Pay to U.sub.(i+1)mod n, is expected to contain within it a value sv.sub.(i+1)mod n.

(99) It is important that the payment channels between pairs of users be created in an ordered sequence, in that the payment channel U.sub.i−1.fwdarw.U.sub.i is set up before the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n. This begins with the creation of the first payment channel U.sub.0.fwdarw.U.sub.1 where U.sub.0 is the initiator and ends with the last payment channel U.sub.n−1.fwdarw.U.sub.0.

(100) In some configurations, the order of the sequence is important as this allows user U.sub.1 to, before making their payment and undertaking the risk associated with making the payment, ensure that there exists a T.sub.Pay transaction to U.sub.i that U.sub.i is able to successfully execute if U.sub.i makes his/her T.sub.Pay payment to U.sub.(i+1)mod n.

(101) With reference to FIGS. 15 and 16, the preparation of the secret values used in this configuration will now be described. 1. The default value of the sv.sub.0 is set as sv.sub.0=k.sub.s. Recall that k.sub.s is a random value chosen by the initiator, U.sub.0, in the GRE protocol list of users. This k.sub.s value is central to the security of the protocol, is known only to U.sub.0, and kept secret until all payment channels are created and completed to the satisfaction of U.sub.0; 2. U.sub.0 encrypts the default sv value k.sub.s by multiplying it by the base point G of the Elliptic Curve. Where Q.sub.i is the encrypted version of the sv.sub.i value, the encrypted version of the default sv is Q.sub.0=sv.sub.0G=k.sub.sG; 3. For the first payment channel created, U.sub.0.fwdarw.U.sub.1, U.sub.1 communicates its random number k.sub.1 to U.sub.0 and U.sub.0 communicates the ‘encrypted version of the secret key’, Q.sub.0, to U.sub.1; 4. The sv value for payment channel created, U.sub.0.fwdarw.U.sub.1, is to be sv.sub.1=sv.sub.0+k.sub.1, for which its ciphertext is:
Q.sub.1=Q.sub.0+k.sub.1G; Noting that: The new secret value (k.sub.s+k.sub.1) is present in the calculation of Q.sub.1, given that:
Q.sub.1=k.sub.sG+k.sub.1G=(k.sub.s+k.sub.1)G; user U.sub.1 has no knowledge of k.sub.s and in tandem the secret value for the transaction; and both U.sub.1 and U.sub.0 can calculate and verify the other's calculation of Q.sub.1; 5. Steps 3 and 4 may be generalised for all other payment channels in the GRECS circuit. This generalisation is described below: U.sub.(i+1)mod n communicates their random number k.sub.(i+1)mod n to Ui. U.sub.i communicates the encrypted version of the secret key, Q.sub.i, to U.sub.(i+1)mod n; The sv value for payment channel created is to be sv.sub.(i+1)mod n=sv.sub.i k.sub.(i+1)mod n, for which its encrypted value is:
Q.sub.(i+1)mod n=Q.sub.i+k.sub.(i+1)mod nG; Noting that, for the payment channel: the new secret value sv.sub.(i+1)mod n=k.sub.s+k.sub.1+k.sub.2+ . . . +k.sub.1+k.sub.(i+1)mod n can be seen in the calculation of Q.sub.(i+1)mod n, given that:

(102) $Q_{(i + 1) \mod n} = \underset{\underset{Qi}{︸}}{k_{s} G + k_{1} G + k_{2} G + .Math. + k_{i} G} + k_{(i + 1) \mod n} G = (k_{s} + k_{1} + k_{2} + .Math. + k_{i} + k_{(i + 1) \mod n)} G;$ user U.sub.(i+1)mod n has no knowledge of the secret value for the transaction as k.sub.s and all other previous iterations of sv have been encrypted; and both U.sub.(i+1)mod n and U.sub.i can calculate and verify the other's calculation of Q.sub.(i+1)mod n. Note that the previous processes apply also to the final payment channel U.sub.n−1.fwdarw.U.sub.0. As such, in addition to the secret random number k.sub.s, U.sub.0 must also create a second random value k.sub.0. k.sub.0 is the final value added to the secret value. Note that the final secret value is labelled sv.sub.final rather than sv.sub.0; and 6. Only the initiator U.sub.0 does not have to prioritise having the payment channel that pays him/her be established before the payment channel where he/she pays. This is because U.sub.0 cannot be cheated as U.sub.0 is the only person with knowledge of the value of k.sub.s which is required by all T.sub.Pay transactions of the all payment channels. Therefore no withdrawal can be done by any user of the GRE protocol of this configuration until U.sub.0 is comfortable starting the process (coinciding with its release of the final secret value sv.sub.final=k.sub.s+k.sub.1+k.sub.2+ . . . +k.sub.n−1+k.sub.0, which includes the value of k.sub.s).

(103) The final payment channel U.sub.n−1.fwdarw.U.sub.0 is finalised at or before time S. The set of payment channels connecting the users can be visualised as a circle as shown in FIG. 16, which shows a representation of the U.sub.i.fwdarw.U.sub.(i+1)mod n payment channels existing between all users of the protocol of this configuration. Arrows signify the payment channels and direction of T.sub.Pay payment. Values externally adjacent the arrows represent the secret value required for the transaction T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n to be accepted by the blockchain. Values internally adjacent the arrows represent the s time span values. The Q.sub.i values represent the encrypted value of the payment channel's secret value.

(104) In light of the circular arrangement, the fact that the order of {U.sub.i|I∈[0,n−1]} was random means that the user who pays a user U.sub.i is random and the user who U.sub.i pays is random. Likewise the user who pays a user U.sub.i is different from the user who U.sub.i pays.

(105) The initiator U.sub.0 spends the transaction T.sub.Pay of the existing payment channel U.sub.n−1.fwdarw.U.sub.0, revealing the value of sv.sub.final=k.sub.s+k.sub.1+k.sub.2+ . . . +k.sub.n−1+k.sub.0. As described above, it was U.sub.0 who created the values k.sub.s and k.sub.0, and all users were required to send their k.sub.i values to U.sub.0.

(106) U.sub.0 can communicate this value of sv.sub.final directly to U.sub.n−1, or this value may be retrieved from the blockchain.

(107) Although U.sub.n−1 now knows sv.sub.final, this is not the secret value needed for U.sub.n−1 to receive payment via the payment channel U.sub.n−2.fwdarw.U.sub.n−1:
sv.sub.final=k.sub.s+k.sub.1+k.sub.2+ . . . +k.sub.n−1+k.sub.0, whereas:
sv.sub.n−1=k.sub.s+k.sub.1+k.sub.2+ . . . +k.sub.n−1.

(108) However, U.sub.n−1 may easily calculate sv.sub.n−1 by subtracting k.sub.0 from sv.sub.final, then submit the T.sub.Pay transaction for their payment. U.sub.n−1 would have known k.sub.0 from previous processes in constructing the payment channel transactions.

(109) Similarly each user U.sub.(i+1)mod n may directly communicate the value sv.sub.(i+1)mod n to its payer U.sub.i. If U.sub.(i+1)mod n does not, user U.sub.i may retrieve the value sv.sub.(i+1)mod n in the blockchain ledger (within at least time s).

(110) From sv.sub.(i+1)mod n, user U.sub.i can calculate sv.sub.i by subtracting k(i+1)mod n from sv.sub.(i+1)mod n. This allows U.sub.i to be paid via T.sub.Pay: U.sub.i−1.fwdarw.U.sub.i.

(111) As the blockchain takes on average 10 minutes to confirm a transaction, the value of s should be chosen such that the time period it represents is sufficient for any user U.sub.i to find if necessary, within that time period, the value of sv.sub.(i+1)mod n in a transaction T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n, after said transaction is submitted to the Bitcoin network. If the average time to confirm a transaction changes, then s can be chosen accordingly.

(112) The value of s should also include an estimated time for the construction of the payment channel between a pair of users. Therefore s would be s=s.sub.sv+ε where s.sub.sv is the estimated time to find sv.sub.(i+1)mod n and submit T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n, and ε is the estimated time to construct the payment channel.

(113) Due to the initiator U.sub.0 having submitted to the network the T.sub.Pay transaction of the existing payment channel between U.sub.n−1 and U.sub.0, revealing the value of sv.sub.final to U.sub.n−1, the value of sv.sub.i can then be revealed to every other user U.sub.i in an anticlockwise way (from U.sub.n−1 to U.sub.1): see FIG. 17. This is based on the premise that each user, U.sub.i, will be invested in submitting the transaction (T.sub.Pay of the payment channel U.sub.i−1 to U.sub.i) that allows themselves to get paid.

(114) User U.sub.i submitting said transaction will require obtaining the value of sv.sub.(i+1)mod n from T.sub.Pay of the payment channel U.sub.i to U.sub.(i+1)mod n from which U.sub.i would derive sv.sub.i. Through U.sub.i submitting that transaction T.sub.Pay of the payment channel to U.sub.i−1 to U.sub.i, the value of sv.sub.i is then made available to user U.sub.i−1 who then derives sv.sub.i−1. This process cascades like dominoes falling all the way from U.sub.n−1 to U.sub.1 in such a way that each user U.sub.1 cashing in reveals the sv.sub.i−1 to user U.sub.i−1, allowing the user U.sub.i−1 to also cash in.

(115) More formally, the sequence of T.sub.Pay transactions (executed/submitted) of the payment channels occurs as follows:
[T.sub.Pay: U.sub.n−1.fwdarw.U.sub.0],[T.sub.Pay:U.sub.n−2.fwdarw.U.sub.n−1], . . . ,[T.sub.pay:U.sub.1.fwdarw.U.sub.2],[T.sub.Pay: U.sub.0.fwdarw.U.sub.1],

(116) Completion of the set of T.sub.Pay transactions successfully concludes the process. Each user paid x BTC and each user received x BTC.

(117) The processes of submitting the T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n transactions in this configuration are illustrated in FIG. 18, wherein t is current time, PC is payment channel, U.sub.i+1=U.sub.(i+1)mod n, and be is blockchain. For payment channel U.sub.n−1.fwdarw.U.sub.0, the sv value is named sv.sub.final.

(118) The submission of all refund transactions, T.sub.r,0, to the blockchain is restricted by the nLockTime value. This value of the nLockTime parameter represents an absolute time value such that T.sub.r,0 will only be accepted by the blockchain at or after that time. The nLocktime value for U.sub.i.fwdarw.U.sub.(i+1)mod n is S+(n−i)s.

(119) A user U.sub.i submits T.sub.r,0: U.sub.i.fwdarw.U.sub.(i+1)mod n if U.sub.(i+1)mod n fails to sign and reveal sv.sub.(i+1)mod n for Q.sub.(i+1)mod n before the nLocktime value.

(120) If U.sub.i submits T.sub.r,0:U.sub.i.fwdarw.U.sub.(i+1)mod n this means that the payment transaction T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n has not been and will never be executed. This means that sv.sub.(i+1)mod n will not revealed and thus U.sub.i−1 will not be able to calculate, from the blockchain, the sv.sub.i necessary for the payment transaction T.sub.Pay: U.sub.i−1.fwdarw.U.sub.i.

(121) U.sub.i−1 will have to wait till at or after the nLockTime value for U.sub.i−1.fwdarw.U.sub.i before submitting his refund transaction T.sub.r,0: U.sub.i−1.fwdarw.U.sub.i.

(122) These refund submission processes are repeated, in an anticlockwise manner, for all users up to and including the initiator U.sub.0 who submits T.sub.r,0: U.sub.0.fwdarw.U.sub.1. Each of these transactions can only occur at or after a specific point in time. An example of this sequence of refund transactions is shown in FIG. 19, wherein U.sub.4 fails to sign and produce sv.sub.4 for T.sub.Pay: U.sub.3.fwdarw.U.sub.4 before t=S+4s. Refund transactions are represented by arrows pointing anticlockwise. Payment, or execution, transactions are represented by arrows pointing clockwise.

(123) It is important to note that a refund transaction does not have to be submitted at the exact nLockTime value. It can be applied at that time or after. This means that while U.sub.i may grant U.sub.(i+1)mod n extra time, t.sub.x, to sign and produce sv.sub.(i+1)mod n for T.sub.Pay: U.sub.i.fwdarw.U.sub.(i+1)mod n this would mean that U.sub.i would consequently have less time to produce sv.sub.i for T.sub.Pay: U.sub.i−1.fwdarw.U.sub.i (assuming U.sub.i is not granted extra time by U.sub.i−1). See FIG. 20, wherein U.sub.0, given extra time t.sub.x, leads to U.sub.n−1 having less time to calculate sv.sub.n−1 and submit T.sub.Pay: U.sub.n−2.fwdarw.U.sub.n−1 to the blockchain due to U.sub.0's late submission of T.sub.Pay: U.sub.n−1.fwdarw.U.sub.0.

(124) Below, a description is given of the construction of the Bitcoin transactions utilised in the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n between a pair of users of the protocol of this configuration. These payment channels are composed of three main transactions: Deposit into 2-of-2 multisignature Transaction T.sub.c: This transaction represents the commitment component of the payment channel, and may be referred to as a commitment transaction. Here, through the transaction, user U.sub.i sends/commits a specified number of bitcoins, x BTC, to be governed by either: a 2-of-2 multisignature U.sub.(i+1)mod n) OR knowledge of a value sv.sub.(i+1)mod n AND the signature of U.sub.(i+1)mod n; Refund Transaction T.sub.r,0: This transaction represents the refund of x BTC (from the commitment transaction) back to user U.sub.i that becomes eligible for submission to the blockchain after a specified time has expired. For this transaction to be executed successfully it requires the signatures of users U.sub.i AND U.sub.(i+1)mod n; and Payment Transaction T.sub.Pay: This transaction is the payment of x BTC from U.sub.i's committed funds to user U.sub.(i+1)mod n. For this transaction to be executed successfully it requires the knowledge of a secret value sv.sub.(i+1)mod n and the signature of the user U.sub.(i+1)mod n. Payment transactions may also be referred to as execution transactions.

(125) Note that the details of the transactions of FIGS. 21 to 24 are limited to the <scriptSig>, <scriptPubkey>, nLockTime, and output values of the various transactions, as these are the transaction elements most relevant to this configuration.

(126) The transaction details are shown in FIGS. 21 to 24. Below, details of an Elliptic Curve opcode are described.

(127) This configuration uses Elliptic Curve encryption. Given a secret value k, its EC encrypted value is Q=kG; where G is a base point on the Elliptic Curve.

(128) This EC encryption serves as an equivalent of the hash function of the GRE of the configuration using the same secret value in all payment channels. However, the homomorphic-like property of EC addition enables a changing sv value in the payment channels of this configuration, while enabling the domino cascade of secret values starting with the reveal of the final version of sv, sv.sub.final.

(129) For each payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n the commitment transaction T.sub.c includes a condition that stipulates that, apart from the refund, the committed funds can only be spent if the secret value sv.sub.(i+1)mod n is presented that produces the encrypted value Q.sub.(i+1)mod n. This non-refund spending of committed funds is to be done by the T.sub.Pay of the payment channel.
Q.sub.(i+1)mod n=sv.sub.(i+1)mod nG

(130) Where sv.sub.(i+1)mod n=k.sub.s+k.sub.1+k.sub.2+ . . . k.sub.i+k.sub.(i+1)mod n

(131) To determine if sv.sub.(i+1)mod n is correct the following EC opcode is employed, which provides for the multiplication Q=kG. This opcode is called OP_ECPMULT. OP_ECPMULT takes an encoded Elliptic Curve Point and a number and performs Elliptic Curve Multiplication by Scalar. It outputs the result as an encoded Elliptic Curve Point.

(132) The scripts of the transactions T.sub.c, T.sub.r,0, and T.sub.Pay of the payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n are shown in FIGS. 21 to 24. In particular, FIG. 24 shows how the <scriptPubKey> of the commitment transaction T.sub.c is combined with the <scriptSig> of the payment transaction T.sub.Pay, using the above-described opcode OP_ECPMULT, to unlock the committed x BTC.

(133) Configurations of the present invention have been described above as using either the same secret value for all payment channels or different secret values for all payment channels, though it is within the remit of the skilled person to combine the configurations so as to use a combination of changing secret values and unchanging secret values.

(134) Furthermore, it is to be understood that other communication channels, such as email, file transfer protocol, and peer-to-peer sharing may be used to communicate information by users of any configuration of the present invention, and that this information may relate to secret values or information relating thereto, details of one or more transactions, and complete or incomplete versions of one or more transactions themselves, and that the extent to which communication channels other than the Blockchain are used may depend on the level of trust existing between given pairs of users of the present invention.

(135) It is to be understood that, while the configurations of the present invention described above refer only to the transfer of Bitcoins between users, that users may instead exchange other resources using the protocol, such as information, contracts, and tokens. A token represents an asset or resource according to a smart contract associated with the token, such that control of the token affords control of the asset or resource. The smart contract itself may be stored off-blockchain, or it may be stored inside one or more transactions.

(136) Herein, the term “system” is used to encompass a system of computer hardware and/or software configured to carry out steps of at least one configuration of the GRE protocol described above, the protocol itself, and the protocol saved on computer hardware.

(137) It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Computer-implemented system and method for performing transaction mixing on a blockchain

Assignee

Inventors

Cpc classification

Classification Explorer

H04L9/3239

ELECTRICITY

Classification Explorer

G06Q20/383

PHYSICS

Classification Explorer

G06Q20/3678

PHYSICS

Classification Explorer

G06Q2220/00

PHYSICS

Classification Explorer

H04L9/3247

ELECTRICITY

Classification Explorer

G06Q20/02

PHYSICS

Classification Explorer

H04L9/0637

ELECTRICITY

Classification Explorer

G06Q20/405

PHYSICS

Classification Explorer

G06Q20/0658

PHYSICS

Classification Explorer

H04L9/50

ELECTRICITY

Classification Explorer

G06Q20/3674

PHYSICS

International classification

Classification Explorer

G06Q20/36

PHYSICS

Classification Explorer

G06Q20/06

PHYSICS

Classification Explorer

G06Q20/40

PHYSICS

Classification Explorer

H04L9/06

ELECTRICITY

Abstract

Claims

Description