System and method for transferring resources using a blockchain

Abstract

A computer-implemented includes sending a public key associated with a particular node in a cyclically-ordered set of nodes participating in a blockchain network to an initiator node; receiving, by the particular node from a node immediately previous to the particular node in the cyclically-ordered set, a first value based on public keys associated with each node from the particular node through to the initiator node; determining a locking value based on the first value and the public key associated with the particular node; and preparing using the locking value, a transaction arranged to transmit control of a resource from a source address associated with the particular node to a receiving address of a node immediately subsequent to the particular node. The control of the resource is to be transmitted responsive to satisfaction of an execution condition including supply of an unlocking value corresponding to the locking value.

Claims

1. A computer-implemented method comprising: randomizing a set of nodes to create a cyclically-ordered set of nodes participating in a blockchain network; selecting one of the nodes of the set of nodes to be an initiator node, U.sub.0, of the cyclically-ordered set of nodes; selecting one or more timeout values representing an amount of time required to complete actions relating to the method; determining and sending a public key associated with a particular node in the cyclically-ordered set of nodes participating in the blockchain network to the initiator node of the cyclically-ordered set; receiving, by the particular node from a node immediately previous to the particular node in the cyclically-ordered set, a first value based on public keys associated with each node in the cyclically-ordered set from the particular node through to the initiator node; determining, by the particular node, a locking value based on the first value and the public key associated with the particular node; determining that there is sufficient time left on the one or more timeout values; and establishing a payment channel between the particular node, U.sub.i, and a node immediately succeeding the particular node, U.sub.i+1, by: preparing, by the particular node, (i) a commitment transaction, T.sub.c (ii) a refund transaction T.sub.r, and (iii) a transaction, T.sub.pay, using the locking value, arranged to transmit control of a resource from a source address associated with the particular node to a receiving address of the node immediately succeeding the particular node in the cyclically-ordered set, wherein the control of the resource is to be transmitted responsive to satisfaction of an execution condition including supply of an unlocking value corresponding to the locking value.

2. The method of claim 1 wherein the unlocking value is based on private keys corresponding to the public keys associated with each node in the cyclically-ordered set from the immediately subsequent node through to the initiator node.

3. The method of claim 1 wherein the first value is a sum of the public keys associated with each node in the cyclically-ordered set from the particular node through to the initiator node.

4. The method of claim 3 wherein determining the locking value comprises subtracting the public key associated with the particular node from the first value.

5. The method of claim 1 further comprising: sending, by the particular node to the immediately subsequent node, a second value based on the first value and the public key associated with the particular node.

6. The method of claim 5 wherein the second value is determined by subtracting the public key associated with the particular node from the first value.

7. The method of claim 1 wherein another transaction is arranged to return control of the resource to the particular node upon satisfaction of a return condition.

8. The method of claim 1 further comprising: obtaining, a third value based on private keys corresponding to the public keys associated with each node in the cyclically-ordered set from the immediately subsequent node through to the initiator node; determining, by the particular node, a second unlocking value based on the third value and a private key corresponding to the public key associated with the particular node; and executing, by the particular node, a second transaction prepared by the immediately previous node and arranged to transmit control of a second resource from a source address associated with the immediately previous node to a receiving address of the particular node, wherein control of the second resource is to be transmitted responsive to satisfaction of an execution condition including supply of the second unlocking value.

9. The method of claim 8 wherein the third value is received from the immediately subsequent node.

10. The method of claim 8 wherein the third value is extracted from a transaction submitted to a blockchain of the blockchain network.

11. The method of claim 8 wherein the third value is a sum of a-private keys corresponding to the public keys associated with each node in the cyclically-ordered set from the immediately subsequent node through to the initiator node.

12. The method of claim 8 further comprising sending the second unlocking value to the immediately previous node.

13. The method of claim 1 wherein each public key and its corresponding private key form an elliptical curve cryptography public-private key pair.

14. The method of claim 1 further comprising submitting a second transaction to a blockchain of the blockchain network.

15. The method of claim 8 wherein the resource and the second resource are identical.

16. A computing device adapted to serve as a particular node in a cyclically-ordered set, the computing device comprising: a processor; a memory; a network interface; and a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by the processor cause the computing device to perform a method according to claim 1.

17. A non-transitory computer-readable storage medium storing instructions that adapt a computer system to serve as a particular node in a cyclically-ordered set wherein the instructions, when executed by a processor of the computer system, cause the computer system to perform a method according to claim 1.

18. A computing device adapted to serve as a particular node in a cyclically-ordered set, the computing device comprising: a processor; a memory; a network interface; and a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by the processor cause the computing device to perform a method according to claim 2.

19. A computing device adapted to serve as a particular node in a cyclically-ordered set, the computing device comprising: a processor; a memory; a network interface; and a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by the processor cause the computing device to perform a method according to claim 8.

Description

(1) Any feature described in relation to one aspect or embodiment of the invention may also be used in respect of one or more other aspects/embodiments. These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiment described herein. An embodiment of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

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

(3) FIG. 2 is a flowchart illustrating how a payment channel in accordance with FIG. 1 may be created;

(4) FIG. 3 is a simplified schematic diagram illustrating an example operating environment of the present application;

(5) FIG. 4 illustrates an example computing device;

(6) FIG. 5 is a flowchart illustrating operations performed by nodes of FIG. 3;

(7) FIG. 6 is a diagram illustrating a cyclically-ordered set constructed of nodes of FIG. 3;

(8) FIG. 7 is a diagram illustrating an example payment channel according to the present application;

(9) FIG. 8 illustrates an example commitment transaction according to the present application;

(10) FIG. 9 illustrates an example refund transaction according to the present application;

(11) FIG. 10 illustrates an example payment transaction according to the present application;

(12) FIG. 11 is a flowchart illustrating operations performed by a particular node of FIG. 3;

(13) FIG. 12 is a flowchart illustrating operations performed by nodes of FIG. 3;

(14) FIG. 13 is a diagram illustrating transfers between nodes in the cyclically-ordered set of FIG. 6; and

(15) FIG. 14 is a flowchart illustrating operations performed by a particular node of FIG. 3.

(16) Like reference numerals are used in the drawings to denote like elements and features.

(17) In the present application, the term “and/or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

(18) In the present application, the phrase “at least one of . . . or . . . ” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

(19) A protocol, named the Group Random Exchange Late Reveal (GRELR) protocol, embodying the present invention, is described herein for a node to move units representing a quantity of computing resources from one address to another while obscuring the link between a particular node's addresses and while reducing or limiting the possibility of a that node having its resources misappropriated. It is built on the concept of a group agreeing for each node of the group to transfer units of a computing resource to an address associated with another node of the group such that everyone receives the output of a transfer.

(20) The node associated with the address to which a particular node transfers x units is selected randomly from amongst the nodes of the group and likewise the node that transfers x units of computing resources to an address associated with the particular node is also selected randomly from amongst the nodes of the group. By doing this the particular node may transfer x units of computing resources to one address but accept receipt of x units of computing resources at a different address from a different node which is randomly determined. Put differently, it may be that, as an amount, the resource transmitted to each node is identical except for the address from which it originates. The randomizing of nodes may, however, make it difficult for parties external to the protocol to analyse the blockchain and determine a link between the particular node's input and output addresses. Thus, security can be increased.

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

(22) 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.

(23) The GRELR protocol is an improvement to the GRE protocol and, more particularly, on the GRECS protocol. GRELR improves by avoiding the need to use a common secret. It also improves by avoiding the need to prematurely reveal the particular secret associated with each node, such that participants only reveal a secret result based in part on the particular secret associated with that node when they collect their respective payments. GRELR accomplishes this by reversing the direction, as compared to GRECS, in which secret values are consolidated to form the secret results. In doing so, GRELR may avoid participating nodes having to reveal their secret value other than within the execution of a transaction in favour of an address associated with that node.

(24) While improving on GRECS, GRELR also satisfies various conditions satisfied by GRECS including:

(25) 1. The secret values for payment channels should be difficult to guess.

(26) 2. The revelation of a secret result in executing the payment transaction of a particular payment channel should allow the secret result necessary to unlock the next payment channel in GRE sequence (anticlockwise) to be revealed or at least be easily calculable.

(27) 3. It should be difficult for external observers to identify a relationship between secret keys (or secret key encryptions).

(28) 4. The protocol should be designed prevent or limit risk of losses of assets tracked by the blockchain to participants in the exchange due only to operation of the protocol.

(29) Payment Channels

(30) As mentioned above, payment channels feature in the present invention. An overview of payment channels follows.

(31) 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.

(32) 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 units 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.

(33) 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 Bitcoin (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.

(34) First, Alice creates a 2-of-2 multisignature pay to script hash (P2SH) transaction, T.sub.c, governed by both Alice and Bob that commits 15 Bitcoin 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);

(35) Next, Alice creates a separate refund transaction, T.sub.r,0, returning all units of 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;

(36) Next, Alice signs the original transaction T.sub.c.

(37) At this point Alice and Bob may proceed to create new refund transactions to reflect the (off the blockchain) transfers being made from Alice to Bob. These refund transactions would reflect the net amount that Alice is required to transfer to Bob at that point in time. As an example, if Alice is to transfer Bob 5 Bitcoin, a new refund transaction, T.sub.r, i, is created that has an output sending 5BTC to Bob and 10BTC back to Alice. If Alice needs to transfer another 5 Bitcoin to Bob then the new refund transaction, T.sub.r,i+1, is created with outputs sending 10 Bitcoin to Bob and 5 Bitcoin 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.

(38) Note that each successive refund transaction created has a lower nLockTime than that of the previous refund transaction—i.e., nLockTime(T.sub.r,i+1)<nLockTime(T.sub.r,i).

(39) 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 units (after nLockTime has expired).

(40) The final refund transaction constructed represents the net sum of the units being transferred from Alice to Bob. This transaction is submitted to the network.

(41) FIG. 1 shows the transactions T.sub.c 100A, and T.sub.r,n 100D 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 the units 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) transfers 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.

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

(43) Transactions T.sub.c 100A, T.sub.r,0 100B, T.sub.r,1 100C, and T.sub.r,n 100D of FIG. 1 are transactions that may appear on the blockchain.

(44) Operations for constructing the payment channel between Alice and Bob are shown to a flowchart 200 of FIG. 2. Operations 210 and onward are performed by one or more processors of one or more computing devices executing software comprising computer-executable instructions as may be stored on a computer-readable storage medium.

(45) At the operation 210, a processor of a computing device associated with Alice creates a 2-of-2 multisignature pay to script hash (P2SH) transaction, T.sub.c, in manners described above.

(46) From the operation 210, control flow proceeds to an operation 212. At the operation 212, a processor of a computing device associated with Alice creates a separate refund transaction, T.sub.r,0, returning all units of the ‘multisignature controlled funds’ to an account associated with Alice in manners described above.

(47) From the operation 212, control flow proceeds to an operation 214. At the operation 214, a processor of a computing device associated with Alice signs the above-described refund transaction.

(48) From the operation 214, control flow proceeds to an operation 216. At the operation 214, a processor of a computing device associated with Bob may also sign the above-described refund transaction. If the transaction is so signed, control flow advances to an operation 218. Alternatively, if the transaction is not so signed, creation of the payment channel is aborted.

(49) At the operation 218, a processor of a computing device associated with Alice signs T.sub.c and submits it to the blockchain. Control flow then advances to an operation 220.

(50) At the operation 220, the above-mentioned refund transaction is recognized as a first refund transaction so that a further transfer from Alice to Bob can be negotiated if time allows.

(51) From the operation 220, control flow advanced to an operation 222. At the operation 222, it is determined with sufficient time remains to negotiate the further transfer. If there is not sufficient time remaining, control flow advances to an operation 224 where the last refund transaction is submitted to the blockchain. Alternatively, if sufficient time remains, control flow advances to an operation 226.

(52) At the operation 226, a further transfer between Alice and Bob is negotiated. from the operation 226, control flow advances to an operation 228 where it is determined if the negotiation was successful. If that negotiation was unsuccessful, control proceeds to the operation 224 described above. Alternatively, a successful negotiation will result in control flow advancing to an operation 230.

(53) At the operation 230, a new refund transaction reflective of the agreement stemming from the successful negotiation is created in manner described above. Then, control flow advances to an operation 240 where the new refund transaction is recognized as the current refund transaction.

(54) From the operation 240, control flow advances to an operation 242 where processors of computing devices associated with Alice and Bob may sign the current refund transaction. If so, control flow returns to the operation 222 described above. Alternatively, if the transaction is not so signed, then recognition of the current refund transaction reverts to the pervious refund transaction at an operation 244. From the operation 244, control flow returns to the operation 222 described above.

(55) FIG. 3 shows an example operating environment of the present application.

(56) As illustrated, a plurality of nodes 300 are in communication via a computer network 310. Each of the nodes 300 is a computing device and participating in a blockchain and has one or more associated addresses in associated with which the blockchain reflects a quantity of units such as, for example, units of computing resources.

(57) As further described below, each of the nodes 300 may transfer a quantity, x units, from an address associated with the node to an address associated with another of the nodes 300. Conveniently, in this way, transactions on the blockchain may be mixed so as to obscure ownership relationships between input and output addresses of the various transfer transactions.

(58) FIG. 4 is a high-level operation diagram of an example computing device. Example computing device 400 may be exemplary of one or more of the computer systems described herein including, for example, one or more of the nodes 300. The example computing device 400 includes software that adapts it to perform a particular function.

(59) The example computing device 400 includes a variety of modules. For example, as illustrated, the example computing device 400 may include a processor 410, a memory 420, and a network interface 430. As illustrated, the foregoing components of the example computing device 400 are in communication over a bus 440.

(60) The processor 410 is a hardware processor. The processor 410 may, for example, be one or more ARM. Intel x86, PowerPC processors or the like.

(61) The memory 420 allows data to be stored and retrieved. The memory 420 may include, for example, random access memory, read-only memory, and persistent storage. Persistent storage may be, for example, flash memory, a solid-state drive or the like. Read-only memory and persistent storage are a non-transitory computer-readable storage medium. A computer-readable medium may be organized using a file system such as may be administered by an operating system governing overall operation of the example computing device 400.

(62) The network interface 430 allows the example computing device 400 to communicate with other computing devices and/or various communications networks such as, for example, the computer network 310 (FIG. 3).

(63) Software comprising instructions is executed by the processor 410 from a computer-readable medium. For example, software may be loaded into random-access memory from persistent storage of the memory 420. Additionally or alternatively, instructions may be executed by the processor 410 directly from read-only memory of the memory 420.

(64) As further described below, software may adapt instances of the example computing device 400 to serve as one or more of the various computer systems mentioned herein, including, for example, one or more of the nodes 300.

(65) Operations performed by nodes 300 acting in cooperation are described with reference to a flowchart 500 of FIG. 5. Operations 510 and onward are performed by one or more processors of various of the nodes 300. As such, operations 510 and onward are performed by one or more processors of computing devices, such as, for example, the processor 410 (FIG. 4) of suitably configured instances of the example computing device 400 executing software comprising computer-executable instructions as may be stored on a computer-readable storage medium such as for, example, storage of the memory 420.

(66) At the operation 510, a set consisting of the nodes 300 is identified. For example, it may be that nodes 300 all register with an authority (such as, for example, another node or a particular one of the nodes 300).

(67) Next, at the operation 512, the set consisting of the nodes 300 is randomized to realize a cyclically-ordered set of the nodes 300 as depicted in FIG. 6.

(68) As shown in FIG. 6, the cyclically-ordered set may be considered as a ring 600, with each of the nodes 300 having two other ones of the nodes as an immediately successive node and an immediately previous node to that node.

(69) Each of the nodes 300 in the ring 600 may, as shown, be assigned a label U.sub.i for 0<i<n, where n is the number of nodes. Conveniently then, the immediately previous node to a node U.sub.i is the node U.sub.(i−1)mod n and the immediately successive node to a node U.sub.i is the node U.sub.(i+1)mod n.

(70) Returning to FIG. 5, following the operation 512, at an operation 514, one of the nodes 300 is selected to as an initiator node. For example, it may be that each of the nodes 300 performs an operation or participates in a protocol resulting a particular one of the nodes being selected as the initiator node. Alternatively, one of the nodes 300 may be selected as the initiator by some central authority.

(71) For the purposes of illustration, the following explanation assumes that the initiator node is U.sub.0 and the terms initiator and the label U.sub.0 are used synonymously, though this is merely by way of example and is by no means required.

(72) The initiator chooses a private key k.sub.s which may, for example, be a suitable random number k.sub.s. A corresponding public key of a private-public key pair may be generated as can be denoted P.sub.s. The initiator maintains the value k.sub.s.

(73) It may be the elliptical curve cryptography is employed and k.sub.s and P.sub.s may be an elliptical curve cryptography public-private key pair such that P.sub.s=k.sub.sG where G is a base point on an elliptical curve with order q. q×G=0, where q is a large prime number and 0<k.sub.s<q. In a particular example, the elliptical curve secp256k1—defined in the document “Standards for Efficient Cryptography 2 (SEC 2)”, Certicom Corp, Jan. 27, 2010—may be employed. When elliptical curve cryptography is employed, therefore, P.sub.s may be determined from k.sub.s using the relation P.sub.s=k.sub.sG.

(74) Next, at an operation 516, various timeout values are selected as follows.

(75) First, a time value s is chosen that represents the amount of time each user U.sub.i requires to complete certain operations which are further described below, namely constructing a payment channel U.sub.i.fwdarw.U.sub.(i+1)mod n, receiving a secret value, and submitting an execution transaction T.sub.pay that transfers x units in favour of U.sub.(i+1)mod n to the blockchain. Any one of the nodes 300 may choose time s, given the consensus of the other users. In some implementations, the initiator may choose s which may simplify the protocol. Time s may be expressed in appropriate units such as, for example, seconds or number of blocks.

(76) Second, a value, S, is chosen as the starting time of the first transfer to a user being submitted to the Bitcoin network. Any of the nodes 300 may choose S, given the consensus of the other nodes. In some implementations, the initiator chooses S which may simplify implementation of the protocol.

(77) Notably, S represents a point in time such a may be specified, for example, in either Unix time or block height, whereas s represents a time span.

(78) Next, at an operation 518, each of the nodes 300 other than the initiator—i.e., U.sub.1 . . . U.sub.n-1—selects a corresponding secret random value k.sub.i, a private key associated with U.sub.i. Each of the nodes, U.sub.i, then determines a corresponding public key P.sub.i and sends it to the initiator, U.sub.0.

(79) As noted above, elliptical curve cryptography may be employed and each k.sub.i and its corresponding P.sub.i may be an elliptical curve public-private key pair such that P.sub.i=k.sub.iG. In other words, each public key P.sub.i and its corresponding private key k.sub.i may form an elliptical-curve public-private key pair. If elliptical curve cryptography is employed, therefore, P.sub.i may be determined by nodes 300 from their respective k.sub.i using the relation P.sub.i=k.sub.iG.

(80) As further described below, payment channels are next established between each of the nodes 300 and the immediately succeeding one of the nodes 300.

(81) As depicted by an operation 519, processing occurs relative to each of the nodes according to a notional iterator value i which can be considered to be initialized to 0—i.e., payment channel creation begins at initiator U.sub.0 as further described below.

(82) At an operation 520, a locking value Q.sub.i+1 is determined. The locking value may be based on the public keys associated with each of the nodes 300 in the cyclically ordered set from the node U.sub.i through to the initiator (i.e., going clockwise around ring 600 (FIG. 6).

(83) Q.sub.i+1 may be determined based on P.sub.s and P.sub.1 . . . P.sub.n-1. For example, where elliptical key cryptography is being employed, Q.sub.i+1 may be determined as the sum P.sub.i+ . . . ++P.sub.n-1+P.sub.s. Notably in the case of the initiator, U.sub.0, determining Q.sub.1, is possible because of the receiving of the P.sub.i values at the operation 518. Further, each one of the nodes 300 after the initiator may, prior to creating a payment channel, may learn the value Q.sub.n from a node immediately previous to that node. Put differently, each one of the nodes 300 may communicate its respective Q.sub.i+1 value to its successor in the cyclically-ordered set. Conveniently, these received values may be used by each of the nodes following the initiator to determine a respective Q.sub.i+1. For example, in the case of where elliptical curve cryptography is employed Q.sub.i+1 may be determined from Q.sub.n by subtracting the value P.sub.n. Notably P.sub.n is known to each U.sub.n (where n>0) because it generated that value at the operation 518.

(84) Next, at an operation 522, a check is made to ensure sufficient time is remaining to complete the necessary steps in GRELR protocol. In particular, the current time may be compared to the starting time of the first transfer, S, to ensure that sufficient time exists such that each of the payment channels not yet established can be allotted the determined time s for completion in series. In other words, the check may be to ensure S−t>(n−i)s, where t is the current time.

(85) If the check at the operation 522 fails, GRELR is aborted. Otherwise, another check is made at an operation 524 to see if payment channel set-up is completed—i.e., where i is still less than the number of nodes, n.

(86) If payment channel setup is done, processing at this stage stops so that the protocol may move on to further processing as described below. Otherwise, next, at an operation 526, a payment channel is established between nodes U.sub.i and U.sub.i+1. As further described below, the value Q.sub.i+1 will be employed to lock the payment transaction of the payment channel.

(87) FIG. 7 provides a representation 700 of a U.sub.i.fwdarw.U.sub.(i+1)mod n payment channel such as may be established at the operation 526.

(88) As illustrated, the channel includes three transactions, T.sub.c, T.sub.pay, and T.sub.r. Note that σU.sub.i represents the signature of U.sub.i.

(89) The T.sub.c transaction represents the commitment component of the payment channel. Here, through the transaction, U.sub.i sends/commits a specified number of units to be governed by either: a 2-of-2 multisignature (U.sub.i, U.sub.i+1) or knowledge of a value sv.sub.(i+1) and the signature of U.sub.(i+1).

(90) The T.sub.r transaction represents a refund of the specified number of units (from the commitment transaction) back to U.sub.i that becomes eligible for submission to the blockchain after a specified time has expired. As such, T.sub.r is arranged to return control of a resource to a particular node, U.sub.i upon satisfaction of the return condition of time expiry. For this transaction to be executed successfully it requires the signatures of U.sub.i and U.sub.i+1.

(91) The T.sub.Pay transaction is the transfer of the specified number of units from committed funds of U.sub.i to U.sub.(i+1). For this transaction to be executed successfully it requires the knowledge of a secret value sv.sub.i+1 and the signature of the user U.sub.i+1. As further described below, sv.sub.i+1 is the counterpart to Q.sub.i+1 and may, such as where elliptical curve cryptography is employed, represent a private key related to Q.sub.i+1 viewed as a public key—i.e., such that Q.sub.i+1=sv.sub.i+1G.

(92) Notably, because of the ring—i.e., cyclically-ordered—arrangement of the nodes 300, and the fact that the ordering of the nodes 300 in that ring was random means that the nodes transferring to and being transferred to by a particular one of the nodes 300, U.sub.i, are both random. Furthermore, the nodes being transferred to and receiving a transfer from U.sub.i are different.

(93) Where the blockchain is the Bitcoin blockchain, each of T.sub.c, T.sub.r and T.sub.pay may be Bitcoin transactions.

(94) FIG. 8 includes a table 800 showing details of an example T.sub.c Bitcoin transaction.

(95) FIG. 9 includes a table 900 showing details of an example T.sub.r Bitcoin transaction.

(96) FIG. 10 includes a table 1000 showing details of an example T.sub.pay Bitcoin transaction.

(97) Notably, the details of the transactions shown in each of table 800, table 900 and table 1000 is limited to the <scriptSig>, <scriptPubkey>, nLockTime, and output values of the various transactions, as these are the transaction elements most relevant to the GRELR protocol.

(98) Further, the transactions shown in each of table 800, table 900 and table 1000 assumes elliptical-key cryptography is being employed for GRELR. Notably, in transaction T.sub.C a non-standard opcode OP_ECPMULT is employed. OP_ECPMULT takes an encoded Elliptic Curve Point and a number and performs Elliptic Curve Multiplication by Scalar, outputting the result as an encoded Elliptic Curve Point.

(99) Returning to FIG. 5, following the operation 526, flow advances to an operation 528 where a check is made to determine whether a payment channel was created successfully at the operation 526. If so, the counter i is incremented at an operation 529 and then the flow returns to the operation 520 to process the next node, if any. Alternatively, if there was a failure in payment channel creation at the operation 526, the check at the operation 528 will fail and GRELR will terminate.

(100) Notably, for each of the nodes 300 other than the initiator node U.sub.0, the payment channel in favour of that node is created in advance of the payment channel where that node acts as a provider of resources. This sequence allows each node U.sub.i to ensure that there is a T.sub.pay transaction in its favour that it would be able to execute if U.sub.i+1 were to ever collect on the T.sub.pay from U.sub.i to U.sub.i+1. Meanwhile, U.sub.0 is safe without this guarantee because, unlike the other nodes, the initiator node U.sub.0 cannot be “cheated” as it is the only node with knowledge of the value k.sub.s which is required to construct the unlocking value of each and every one of the payment channels. As such, no transaction T.sub.pay (including T.sub.pay from U.sub.0 to U.sub.1) may be executed unless and until U.sub.0 discloses k.sub.s.

(101) FIG. 11 will now be discussed. FIG. 11 shows a flowchart 1100 illustrating operations performed by a particular node of FIG. 3 in carrying out operations in accordance with the flowchart 500 (FIG. 5). Operations 1110 and onward are performed by one or more processors of a particular, non-initiator one of the nodes 300. As such, operations 1110 and onward are performed by one or more processors of a computing device, such as, for example, the processor 410 (FIG. 4) of a suitably configured instance of the example computing device 400 executing software comprising computer-executable instructions as may be stored on a computer-readable storage medium such as for, example, storage of the memory 420.

(102) The flowchart 1100 presumes that a cyclically-ordered set has been formed with the nodes 300 by randomizing the nodes as described above. Additionally, it is assumed particular node, U.sub.i, has generated a secret value, k.sub.i, a private key, and also a corresponding public key P.sub.i. For example, the particular node may have generated k.sub.i and then determined P.sub.i using the relation P.sub.i=k.sub.iG as discussed above if elliptical curve cryptography is being utilized in a particular implementation of GRELR.

(103) At the operation 1110, the particular node sends a value P.sub.i corresponding to k.sub.i to the initiator node U.sub.0. P.sub.i, as discussed above, is a public key corresponding to k.sub.i. As such, at the operation 1110, the particular node sends a public key associated with the particular node to the initiator node of the cyclically-ordered set.

(104) From the operation 1110, control flow proceeds to an operation 1120. At the operation 1120, a first value, Q.sub.i, is received from the immediately previous node—i.e., U.sub.i−1. As discussed above the received value is based on public keys associated with each node in the cyclically-ordered set from the particular node through to the initiator node—i.e., U.sub.0 through to U.sub.i. For example, where elliptical curve cryptography is being utilized, that value may be a sum of the public keys associated with each node in the cyclically-ordered set from the particular node through to the initiator node.

(105) From the operation 1120, control flow proceeds to an operation 1130. At the operation 1130, a second value, locking value Q.sub.i+1, is determined based on Q.sub.i in manners described above. In other words, the locking value is determined based on the first value, Q.sub.i, and on the public key, P.sub.i, associated with the particular node. For example, where elliptical curve cryptography is being utilized and Q.sub.i=P.sub.i+ . . . +P.sub.n-1+P.sub.s, determining the locking value Q.sub.i+1 may include subtracting the public key associated with the particular node, P.sub.i, from the received value.

(106) From the operation 1130, control flow proceeds to an operation 1140 where U.sub.i creates a payment channel between U.sub.i and U.sub.i+1. In doing so, various transactions will be prepared as described above. For example, a transaction, T.sub.pay, is prepared using the locking value. That transaction is, as described above, arranged to transmit a resource—e.g., x units of computing resources—from a source address associated with the particular node to a receiving address of a node immediately subsequent to the particular node—i.e., U.sub.i+1—in the cyclically-ordered set. According to that transaction, control of the resource is to be transmitted responsive to satisfaction of an execution condition including supply of an unlocking value (sv.sub.i+1) corresponding to the locking value.

(107) Referring to FIG. 12, a flowchart illustrates further operations performed by nodes 300 acting in cooperation to complete the payment transactions of each of the payment transaction established in manners described above. Operations 1210 and onward are performed by one or more processors of various of the nodes 300. As such, operations 1210 and onward are performed by one or more processors of computing devices, such as, for example, the processor 410 (FIG. 4) of suitably configured instances of the example computing device 400 executing software comprising computer-executable instructions as may be stored on a computer-readable storage medium such as for, example, storage of the memory 420.

(108) At the operation 1210, the initiator node U.sub.0 determines an unlocking value sv.sub.0 for unlocking the T.sub.pay transaction in favour of U.sub.0. Recall that the locking value employed to lock each transaction is based on the public key associated with the nodes that follow the particular node in the cyclically-ordered set through to the initiator node. This means that in the case of the aforementioned T.sub.pay transaction, the value locking the transaction is based only on the public key of the initiator node, P.sub.s corresponding to the private key k.sub.s. As such, the unlocking value is based on k.sub.s. For example, it may be that sv.sub.0=k.sub.s.

(109) Next, control flow proceeds to an operation 1212 where U.sub.0 signs the T.sub.pay transaction in favour of U.sub.0. Put differently, U.sub.0 may sign the transaction that, when submitted to the blockchain, will transfer resource U.sub.n-1.fwdarw.U.sub.0. For example, U.sub.0 may sign the corresponding T.sub.pay transaction and may input sv.sub.0 into the unlocking script—e.g. into the redeemScript shown in table 800 (FIG. 8).

(110) U.sub.0 also reveals sv.sub.0. For example, it may be that U.sub.0 sends sv.sub.0 to U.sub.1 by way of a transmission over the computer network 310.

(111) Alternatively, U.sub.0 may rely on U.sub.1 retrieving sv.sub.0 from the blockchain such as, for example, when the transaction T.sub.pay is submitted thereto at an operation 1216 (described below). Notably, where retrieval of sv.sub.0 from the blockchain is relied upon, the value s should be chosen such that the time period provides sufficient time for any participant to find the value after that transaction is submitted to the blockchain network, taking into account the average time to confirm a transaction on a particular blockchain.

(112) From the operation 1212, control flow proceeds to an operation 1214.

(113) At the operation 1214, it is determined whether sufficient time remains for U.sub.0 to submit, to the blockchain, the T.sub.pay transaction in favour of U.sub.0. In other words, it is determined whether the time S+s has occurred (t<S+s, where t is the current time).

(114) If the check at the operation 1214 fails (not enough time), GRELR is aborted. Alternatively, if the check succeeds, control flow proceeds to the operation 1216.

(115) At the operation 1216, the signed T.sub.pay transaction in favour of U.sub.0 is submitted to the blockchain. In other words, the transaction transferring resource U.sub.n-1.fwdarw.U.sub.0 is submitted to the blockchain.

(116) From the operation 1216, control flow proceeds to an operation 1217. At the operation 1217, a counter, i, is initialized. In particular, because transactions will be unlocked in a counter-clockwise direction around the ring 600 (FIG. 6), i, is initialized to the index of the node preceding the initiator node in the cyclically-ordered set—e.g., i=n−1.

(117) Flow control proceeds from the operation 1217, to an operation 1218. At the operation 1218 it is determined whether there are still T.sub.pay transactions to unlock. In other words, it is determined whether i>0. If no, GRELR is completed. Alternatively, if yes, control flow proceeds to an operation 1220.

(118) At the operation 1220, the last unlocking value (sv.sub.(i+1) mod n) is obtained by the node U.sub.i. For example, the value may have been received from the preceding node such as for, example at the operation 1212 or an operation 1224 (described below), as the case may be. Alternatively, the value may be determined from a transaction submitted to the blockchain, such as, for example, from a transaction submitted at the operation 1216 or at an operation 1230 (described below), as the case may be.

(119) From the operation 1220, control flow proceeds to an operation 1222. At the operation 1222, U.sub.i determines the unlocking value sv.sub.i using the last unlocking value obtained at the operation 1120 and the private key associated with U.sub.i.

(120) An example of such a determination follows.

(121) First, recall that the value used to lock the transaction transferring resources from U.sub.(i−1)mod n to U.sub.i is based on the public key associated with each node from U.sub.i through to the initiator node U.sub.0 in the cyclically-ordered set. The transaction may be unlocked using the corresponding private key.

(122) Regarding the locking value (the public key), recall that where the elliptical curve cryptography is employed, the locking value may be determined as the sum Q.sub.i=P.sub.i+ . . . +P.sub.n-1+P.sub.s.

(123) Further, recall that in elliptical curve cryptography P=kG. Also recall that, according to the homomorphic property of elliptical curve addition, E(m+n)=E(m)+E(n), where E is the function E(x)=xG.

(124) Further, recall that P.sub.i=k.sub.iG. Accordingly, Q.sub.i=k.sub.iG+ . . . +k.sub.(n-1)G+k.sub.sG=G(k.sub.1+ . . . +k.sub.(n-1)). Observe that, therefore, a private key corresponding to a public key Q.sub.i is the sum of the secret values k.sub.i+k.sub.i+1+ . . . k.sub.n-1+k.sub.s.

(125) Put differently, the unlocking value corresponding to the locking value Q, that is the sum of public keys associated with each node in the cyclically-ordered set from the particular node through to the initiator node may be a private key obtained by summing the private keys associated with each of those public keys—i.e. the sum of the values k.sub.i associated with each node in the cyclically-ordered set from the particular node through to the initiator node.

(126) Notably, this is made possible by the homomorphic property. Accordingly, another method of combining values could be utilized that has a similar homomorphic property such as for example, various homomorphic hash functions as may be known to persons skilled in the art. Additionally or alternatively, while homomorphic addition is illustrated above, homomorphism may exist over other operations. Accordingly, in some implementations homomorphism over operations other than addition may be exploited.

(127) Returning to FIG. 12, following the operation 1222, control flow advances to an operation 1224. At the operation 1224, U.sub.i signs the T.sub.pay transaction in favour of U.sub.i. Put differently, signs the transaction that, when submitted to the blockchain, will transfer resource U.sub.(i−1) mod n.fwdarw.U.sub.i. For example, U.sub.i may sign the corresponding T.sub.pay transaction and may input sv.sub.i into the unlocking script—e.g. into the redeemScript shown in table 800 (FIG. 8).

(128) U.sub.i also reveals sv.sub.i. For example, it may be that U.sub.i sends sv.sub.i to U.sub.i−1 by way of a transmission over the computer network 310. Alternatively, U.sub.i may rely on U.sub.i−1 retrieving sv.sub.0 from the blockchain such as, for example, when the transaction T.sub.pay is submitted thereto at the operation 1230 (described below).

(129) Following the operation 1224, control flow proceeds to an operation 1226.

(130) At the operation 1226, it is determined whether sufficient time remains to allow submission, to the blockchain, of the T.sub.pay transaction in favour of U.sub.i. In other words, it is determined whether the time S+(n−i)s has occurred—i.e., whether t<(n−i)S+s, where t is the current time, is satisfied.

(131) If the check fails, control flow proceeds to an operation 1228. Alternatively, if the check succeeds control flow proceeds to the operation 1230.

(132) At the operation 1228, the lack of sufficient remaining time is handled by having U.sub.i−1 trigger undo and abort of GRELR by triggering the refund transactions. In particular, U.sub.i−1 submits to the block chain its respective refund transaction, T.sub.r, thereby starting a process of having nodes U.sub.i to U.sub.0 submitting their respective refund transactions to the blockchain.

(133) At the operation 1230, given there is sufficient remaining time, U.sub.i submits, to the blockchain, the signed T.sub.pay transaction transferring some resource from U.sub.i−1 to U.sub.i.

(134) From the operation 1230, control flow proceeds to an operation 1231 where the counter, i, is decremented and then control flow returns to the operation 1218 to determine if further transactions exist to unlock.

(135) Conveniently, in this way, the secret values, sv.sub.i, are revealed and the payment transactions may be unlocked. An overview of the various values (including the various secret values sv.sub.i) to the nodes 300 in the cyclically-ordered sets relationship is shown in a diagram 1300 in FIG. 13.

(136) In FIG. 13, arrows signify the 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. Expressions internally adjacent the arrows represent the s time span values.

(137) FIG. 14 will now be discussed. FIG. 14 shows a flowchart 1400 illustrating operations performed by a particular node of FIG. 3 in carrying out operations in accordance with the flowchart 1200. Operations 1410 and onward are performed by one or more processors of a particular, non-initiator one of the nodes 300. As such, operations 1410 and onward are performed by one or more processors of a computing device, such as, for example, the processor 410 (FIG. 4) of a suitably configured instance of the example computing device 400 executing software comprising computer-executable instructions as may be stored on a computer-readable storage medium such as for, example, storage of the memory 420.

(138) At the operation 1410, the value sv.sub.i+1 is obtained. Recall that sv.sub.i+1 is based on the secret values k.sub.i associated with each node following the particular node, U.sub.i through to the initiator node U.sub.0. Furthermore, recall that each of k.sub.i is a private key corresponding to the public keys P.sub.i. In other words, by obtaining sv.sub.i+1 a third value is obtained that is based on private keys corresponding to the public keys associated with each node in the cyclically-ordered set from the node immediately subsequent to the particular node through to the initiator node.

(139) Notably the value sv.sub.i+1 may, as described above, be received from the node U.sub.i+1—i.e. from the immediately subsequent node. Additionally or alternatively, the value may be extracted from a transaction already submitted to the blockchain as described above.

(140) Further, recall that in some implementations sv.sub.i+1 may be a sum k.sub.i+1+ . . . +k.sub.n. 1+k.sub.s such as, for example, when elliptical key cryptography is employed. Put differently, the value sv.sub.i+1 may be a sum of the private keys, k.sub.i, corresponding to the public keys, P.sub.i, associated with each node in the cyclically-ordered set from the node immediately subsequent to the particular node through to the initiator node.

(141) Following the operation 1410, control flow proceeds to an operation 1420. At the operation 1420, a second unlocking value sv.sub.i is determined based on the unlocking value sv.sub.i+1 and the private key, k.sub.i, associated with the particular node (and corresponding to the public key P.sub.i). From example, where elliptical key cryptography is employed in a particular implementation, determining the second unlocking value may include adding the private key, k.sub.i, associated with the particular node (and corresponding to the public key P.sub.i) as described above.

(142) Following the operation 1420, control flow proceeds to an operation 1430 where the transaction T.sub.pay transferring a resource to U.sub.i is executed. That T.sub.pay transaction is, as described above, prepared by the node immediately previous to U.sub.i—i.e., U.sub.(i−1)mod n and is arranged to transmit control of some resource from a source address associated with that immediately previous node to a receiving address associated with the particular node responsive to satisfaction of an execution condition including supply of the second unlocking value sv.sub.i as described above.

(143) In addition to the operations described above, it may be that the second unlocking value is sent to the immediately previous node (e.g., as discussed above in the discussion of the operation 1224 (FIG. 12)).

(144) Additionally or alternatively, it may be that the transaction in favour of U.sub.i is submitted to the blockchain by the particular node (e.g., as discussed above in the discussion of the operation 1230 (FIG. 12)).

(145) It should be noted that the above-mentioned embodiments illustrate rather than limit the subject matter of the present 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 subject matter of the present 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.