Patent ID: 12217224

DESCRIPTION OF EMBODIMENTS

The present disclosure generally relates to methods and apparatus for utilising a peer-to-peer (P2P) distributed ledger, such as the Bitcoin blockchain, to enable the transfer of cryptocurrency between a multiple of nodes associated with a data storage and processing system such as, for example, a payroll.

Whilst embodiments described below may refer specifically to transactions that occur on the bitcoin Blockchain (referred to herein as the Blockchain), it will be appreciated that the present invention may be implemented using other P2P distributed ledgers. The Blockchain is used below to describe aspects of the invention for simplicity only due to its high level of standardisation and large quantity of associated public documentation.

Bitcoin and the Blockchain

As described above and well known in the art, the Blockchain is a transaction ledger or database which is distributed across networked nodes participating in a system based on the bitcoin protocol. Each bitcoin transaction is broadcast to the network, the transactions are confirmed and then aggregated into blocks. The blocks are then included on the Blockchain.

A full copy of a cryptocurrency's P2P distributed ledger contains every transaction ever executed in the cryptocurrency. Thus, a continuously growing list of transactional data records is provided. Since each transaction entered onto the Blockchain is cryptographically enforced, the Blockchain is hardened against tampering and revision, even by operators of the data store nodes.

Due to the transparency of the Blockchain, transaction histories are publicly available for each transaction. It is a further advantage of the Blockchain that the transaction and the record of the transaction are the same, i.e. the record of the transaction is embedded within the transaction.

In this way, the information relating to the transaction is captured in the actual transaction. This record is permanent and immutable, and each transaction that is conducted using bitcoin is therefore not only facilitated by the Blockchain, but also immutably recorded in the Blockchain. This therefore removes the requirement for a third party to keep the transaction record on a separate database.

Pay-to-Script-Hash and Multi-Signature

Whilst embodiments below may refer specifically to transactions that use the pay-to-script-hash (P2SH) method of the bitcoin protocol, it will be appreciated that the present invention may be implemented using another method of the bitcoin protocol (or an alternative protocol) such as the pay-to-public-key-hash method.

Each transaction record on the Blockchain comprises a script including information indicative of the transaction and a number of public keys. These public keys may be indicative of, and associated with, the sender and recipient of the cryptocurrency. A script can be considered as a list of instructions recorded with each transaction record on the Blockchain that describes how a user may gain access to the cryptocurrency specified in the transaction record.

As background, in a standard P2SH method of the bitcoin protocol, the output script, or redeem script, may take the form:<NumSigs PubK1 PubK2 . . . PubK15 NumKeys OP_CHECKMULTISIG>where NumSigs is the number “m” of valid signatures required to satisfy the redeem script to unlock the transaction; PubK1, PubK2 . . . PubK15 are the public keys that correspond to signatures that unlock the transaction (up to a maximum of 15 public keys) and NumKeys is the number “n” of public keys.

To redeem the above redeem script, at least a number “m” of signatures corresponding to the public keys are required. In some examples, the order of the public keys is important and the number “m” out of “n” signatures for signing must be done in sequence. For example, consider where “m” is 2 and “n” is 15. If there are two signatures are available for use, Sig1 (corresponding to PubK1) and Sig 15 (corresponding to PubK15), the redeem script must be signed by Sig1 first followed by Sig15.

While the exemplary embodiments below refer to the bitcoin Blockchain as the public ledger, it is to be understood the disclosure also applies to any public ledger that utilises a cryptocurrency.

Overview of the System

A method, device and system to transfer cryptocurrency between a multiple of nodes associated with a payroll will now be described.

FIG.1illustrates a system1that includes a first node3that is in communication with, over a communications network5, a second node7. The first node3has an associated first processing device21and the second node5has an associated second processing device27. The first and second nodes3,7may include an electronic device, such as a computer, tablet computer, mobile communication device, computer server, etc.

A P2P distributed ledger13to record transactions is also illustrated inFIG.1. The P2P distributed ledger may be associated with one or more processing devices19to receive and record transactions. As described above, an example of a P2P distributed ledger is the bitcoin Blockchain. Therefore, in the context of the Blockchain, the processing devices19associated with the P2P distributed ledger may be processing devices used by “miners.”

The first node3is associated with a first user23and the second node7is associated with a second user24. The first node3may receive a first request from the first user23to transfer a first quantity of cryptocurrency. In one example, the first user23is an employer and the second user24is an employee of the employer23and the transfer of the first quantity of cryptocurrency is remuneration (i.e. salary or wage). In further examples, the second user24may be a government body such as the Australian Tax Office or a superannuation fund.

In another example, the first request from the first node3is received at a third node9. The third node9may represent an issuer or service provider25of the first and second nodes3,7. The third node9may be involved in facilitating the transfer of cryptocurrency.

FIG.2illustrates two exemplary employees at a second node7and a further node, where these employees are associated with the employer23at the first node3.

While the exemplary embodiments below refer to the first node3as performing the methods it is to be understood the disclosure may also be adapted or modified to be performed by other nodes.

The method100as illustrated inFIG.3includes receiving110a first request from the first node3to transfer a first quantity of cryptocurrency associated with the first transfer from the first node3to the second node7. The first quantity of cryptocurrency may be associated with a payroll of the first node3. For example, the first quantity of cryptocurrency may represent payment to a second user24(employee) from the first user23(employer).

The method100also includes determining120a second node master public key associated with the second node7. The second node master public key forms a cryptographic pair with a second node master private key. The method100also includes determining130a generator value (GV). The generator value may be based on a message (M) that is shared between the first and second nodes, which may include sharing the message over the communications network5.

The method100also includes determining140a second node second public key based on at least the second node master public key and the generator value (GV).

The method100also includes determining150a first output script based on at least a first metadata that includes information associated with the first transfer and the second user second public key. In one example, the first output script may be a first redeem script using the P2SH method of the bitcoin protocol. In another example, the first output script may be a first output script using the pay-to-public-key-hash method of the bitcoin protocol.

The method100also includes sending160, over a communications network5, a first data output to a P2P distributed ledger13based on an indication of the first transfer from the first node3to the second node7and the first output script. The indication of the first transfer records the underlying first quantity of cryptocurrency has been transferred to the second node7. The first data output may also comprise the first output script or a hash of the first output script.

A detailed example of the method will now be described.

Receiving a Request110

As described above the method100includes receiving110a first request to transfer a first quantity of cryptocurrency associated with the first transfer from the first node3to the second node7. In one example, the third node9or issuer/service provider25receives the request from the employer23at the first node3. For instance, personnel from the human resources department associated with the first node3may send the request to the third node9or issuer/service provider25.

In another example, personnel from the human resources department associated with the first node3may send the request to the payroll department associated with the first node3.

The request may include details associated with the first quantity of cryptocurrency, for example the exact amount of the first quantity of cryptocurrency. The request may further include details of the recipient of the first quantity of cryptocurrency, for example employee details. Employee details may include information about the employee's position at the employer, pay period and pay rate.

Determining a Second Node Master Public Key120

As also described above the method100further includes determining120a second node master public key associated with the second node (e.g. an employee's public key), wherein the second node master public key forms a cryptographic pair with a second node master private key. In one example, the second node master public key is received over the communications network5from the second node7. In another example, the second node master public key is retrieved from a data store17. In yet another example, the second node master public key is received from a third node9or the issuer/service provider25.

Determining the Generator Value130

As described above, the method100includes determining130a generator value and further includes determining140a second node second public key by way of the second node master public key and the generator value (GV). The present disclosure may also determine a first node second public key based on the first node master public key and the generator value (GV).

To determine the generator value (GV) the nodes3,7may perform steps of respective methods300,400as illustrated inFIG.4.

The generator value (GV) may be random, pseudo random, or user defined. In one example, the generator value (GV) is based on a string associated with the first node3. For example, the string may be the identification number of the second user24(e.g. an employee identification number). In a further example the generator value (GV) may be a concatenation of the string as described above with one or more values. For instance, the value may be the date that the first request is received.

A further example of the value may be a string indicating the purpose of the key being derived. For instance, if the key is to be used to transfer cryptocurrency associated with tax withheld of the second user24, the value may comprise a string that includes the word ‘tax.’

In yet another example, the generator value (GV) is based on Unix time and a nonce. In a further example the generator value (GV) changes based on a payment period associated with the first node and the second node. For example, if the payment period is fortnightly, the generator value (GV) may change on a fortnightly basis.

FIG.5illustrates two accounts that are associated with an employee A located at the second node7. The first account is for the month of January and has a designated generator value GV-January, and the second account is for the month of February and has a designated generator value GV-February.

In some examples, the generator value may be arbitrary. However, it is to be appreciated that the generator value may have selective values (such as Unix time, etc) that may be useful in some applications.

The generator value may be retrieved from a data store17. In another example the generator value is received from a third party.

Generating a Message (M)

The generator value that is determined in step130may be based on a message (M). As illustrated inFIG.6, the method300performed by the first node3includes generating310a message (M). The message (M) may be random, pseudo random or user defined as described above with respect to the generator value.

In one example, the message (M) is based on Unix time and a nonce (arbitrary value). For example, the message (M) may be provided as:
Message(M)=UnixTime+nonce  (Equation 1).

The method300includes sending315the message (M), over the communications network5, to the second node7. The message (M) may be sent over an unsecure network as the message (M) does not include information on the private keys.

Determining the Generator Value (GV) from the Message (M)

The method300as illustrated inFIG.6further includes the step of determining320a generator value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. An example of a cryptographic hash algorithm includes SHA-256 to create a 256-bit generator value (GV). That is:
GV=SHA-256(M)  (Equation 2).

It is to be appreciated that other hash algorithms may be used. This may include other hash algorithms in the Secure Hash Algorithm (SHA) family. Some particular examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256. Other hash algorithms may include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A particular example may include RIPEMD-160. Other hash functions may include families based on Zémor-Tillich hash function and knapsack-based hash functions.

Determining a Second Node Second Public Key140

The method100further includes determining140a second node second public key based on at least the second node master public key and the generator value.

As described above, the second node master public key and the second node master private key form a cryptographic pair. This cryptographic pair may be generated using the common elliptic curve cryptography (ECC) system with a base point (G).

That is, the step of generating the second node master public key and the second node master private key may comprise: generating the second node master private key (V1E) based on a random integer in the allowable range specified in the common ECC system; and determining the first node master public key (P1C) based on elliptic curve point multiplication of the first node master private key (V1C) and the base point (G) according to the following formula:
P1P=V1P×G.(Equation 3).

In this example, since the public key (that is, the second node master public key P1E) is determined370′ as the private key with elliptic curve point multiplication with the generator (G), it can be shown that the second node second public key (P2E) can be expressed as:
P2E=P1E+GV×G(Equation 4).

Thus the second node second public key (P2E) is not a random value but is instead deterministically derived given knowledge of the second node master public key.

Determining a First Output Script150

The method100further includes determining150a first output script that is based on at least a first metadata that includes information associated with the first transfer. In the P2SH method of the bitcoin protocol, metadata may be included in the output script by way of the method outlined below.

Metadata

Metadata may be embedded in the redeem script in one or more of the15places available for the public keys in a P2SH multi-signature redeem script. For example, the redeem script may take the form of:<NumSigs Metadata1 Metadata2 . . . PubK1 PubK2 . . . NumKeys OP_CHECKMULTISIG>where Metadata1 and Metadata2 each include metadata that takes the place of a public key in the redeem script and PubK1 and PubK2 are public keys.

By inserting metadata that is associated with the transfer of cryptocurrency, for example information associated with the payroll and the second node7, the hash of the information will be included in the ledger when the transaction (Tx) is written to the blockchain.

Therefore, the use of multi-signature P2SH bitcoin transactions in embodiments of the present disclosure offers an advantage as it enables the transfer of cryptocurrency associated with a payroll to carry a metadata payload.

The metadata may include a description or keyword describing conditions associated with the transfer of cryptocurrency. For example, the date of the transfer, name, date of birth, address, contact details, or other details of the first user23or second user24at the first node3or second node7respectively may be included. In a further example, information associated with the quantity of cryptocurrency may be included.

In the example of where the first user23associated with the first node3is the employer and the second user24associated with the second node7is the employee, the information in the metadata may be analogous to the information in a traditional payslip. The metadata may comprise the name of the employer and employee, the pay period, date of payment, gross and net pay to the employee, the pay rate of the employee, any tax withheld or superannuation contributions, bonuses and the official business number of the employer (such as the Australian Business Number).

In a further example the metadata may comprise a string associated with the employer or employee, such as an identification number of series of characters.

The metadata in the redeem script may include the information in a number of ways. In one example, the contents of the information may be included. In a further example, a cryptographic hash of the information may be included. The hash of the information may be determined using the SHA-256 algorithm to create a 256-bit representation of the information. It is to be appreciated that other hash algorithms may be used, including other algorithms in the Secure Hash Algorithm (SHA) family. Some particular examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256. Other hash algorithms may include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A particular example may include RIPEMD-160. Other hash functions may include families based on Zémor-Tillich hash function and knapsack-based hash functions.

In a further example, the metadata may include a pointer, address or other reference to a location e.g., file that contains the information. For instance, the metadata may include a pointer to a payslip that is associated with the first node and the second node. This pointer may comprise an IPv6 address of the actual file location.

In further embodiments of the present disclosure, combinations including one or more of the above may be included in the metadata. Since the metadata may be made public by way of the P2P distributed ledger such as the Blockchain, or transmitted over an unsecure network, it may be desirable that specific details of the metadata be veiled or hidden for privacy reasons.

Sending a First Data Output to a P2P Distributed Ledger160

The method100further includes sending160, over a communications network5, a first data output to a P2P distributed ledger provides a record on the ledger of the first transfer from the first node3to the second node7. In other words, the transaction (Tx) is sent to the blockchain network for validation and subsequent inclusion in a block on the ledger.

The first data output may be the transaction record stored on the Blockchain. Each transaction record on the Blockchain comprises at least a first node public key associated with the first node3and a second node public key associated with the second node7. The first node public key may comprise the first node master public key, first node second public key or first node additional public keys. The second node public key may comprise the second node master public key, second node second public key or second node additional public keys. As is described later in the present disclosure, methods300and400may be repeated to yield the first node additional public keys and the second node additional public keys. This identifies that the first node3and the second node7are involved in the transaction that is stored on the Blockchain.

Further, each transaction record on the Blockchain comprises at least an indication of the first transfer of a first quantity of cryptocurrency from the first node3to the second node7.

Examples of transactions may include cryptocurrency transactions, fiat currency transactions or tokens as described in further detail below.

Variations

Determining a Common Secret for Securely Transmitting Data

To determine the generator value and common secret (CS) at both the first node3and second node7, the nodes3,7perform steps of respective methods300,400without communicating private keys over the communications network5. A description of the process of determining the generator value and common secret, as well as generating the first node second public and private keys and the second node second public and private keys now follows. A summary of the methods300and400is provided below with reference to the figures.

As illustrated inFIG.4, the method300performed by the first node3includes determining330a first node second private key (V2P) based on at least the first node master private key (V1P) and a generator value (GV) as described above. The generator value (GV) may in some examples be based on a message (M) that is shared between the first and second nodes3,7, which may include sharing the message over the communications network5as described in further detail below. The method300also includes determining370a second node second public key (P2E) based on at least the second node master public key (P1E) and the generator value (GV). The method300includes determining380the common secret (CS) based on the first node second private key (V2P) and the second node second public key (P2E).

Importantly, the same common secret (CS) can also be determined at the second node7by method400. The method400includes determining430a first node second public key (P2P) based on the first node master public key (P1P) and the generator value (GV). The method400further includes determining470a second node second private key (V2E) based on the second node master private key (V1E) and the generator value (GV). The method400includes determining480the common secret (CS) based on the second node second private key (V2E) and the first node second public key (P2P). The methods300,400may be repeated to yield first node additional public keys or second node additional public keys, as will be described later.

The communications network5, may include a local area network, a wide area network, cellular networks, radio communication network, the internet, etc. These networks, where data may be transmitted via communications medium such as electrical wire, fibre optic, or wirelessly may be susceptible to eavesdropping, such as by an eavesdropper11. The method300,400may allow the first node3and second node7to both independently determine a common secret without transmitting the common secret over the communications network5. Thus one advantage is that the common secret (CS) may be determined securely by each node without having to transmit a private key over a potentially unsecure communications network5. In turn, the common secret may be used as a secret key (or as the basis of a secret key) for encrypted communication between the first and second nodes3,7over the communications network5.

Determine the Common Secret380at the First Node3and Second Node7

An example of determining a common secret (CS) will now be described with reference toFIG.6. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node3and the second node7and it may not be desirable, or secure, to use the same common secret (CS). Thus the common secret (CS) may be changed between different sessions, time, transactions, etc.

The first node3may determine380the common secret (CS) based on the determined first node second private key (V2P) and the determined second node second public key (P2E). The common secret (CS) may be determined by the first node3by the following formula:
CS=V2P×P2E(Equation 5).

The second node7may further determine470the common secret (CS) based on the second node private key (V2E) and the first node second public key (P2P) based on the following formula:
CS=V2E×P2P(Equation 6).
Securely Transmitting Information

The metadata as described above may comprise information of a confidential or sensitive nature. The first node3or second node7may require secure transmission of at least part of metadata or the information contained in the metadata, which may be achieved by having only the hash of that information stored within the unlocking (redeem) script. In a further example, the first output script may need to be securely transmitted. In yet a further example, a message or information associated with the payroll and the second user24(for instance, details of a payslip) may require secure transmission from the first node3to the second node7.

The present disclosure may be used to facilitate secure communication, in particular sending and receiving communication messages, between the first node3and the second node7over a potentially unsecure communications network5. This may be achieved by using the common secret (CS) determined separately by the first node and second node as the basis for a symmetric-key. It is to be understood that there may be various methods of generating a common secret that can be used with the invention. However, the method of determining a common secret (CS) and using the symmetric-key for encryption and decryption of the communication messages as disclosed herein may be more computationally efficient compared to known public-key encryption methods.

Methods500,600of secure communication between the first node3and second node7will now be described with reference toFIG.7. The first node3determines510a symmetric-key based on the common secret (CS) determined in the method above. This may include converting the common secret (CS) to a standard key format. Similarly, the second node7can also determine610the symmetric-key based on the common secret (CS).

To send a first communication message securely from the first node3, over the communications network5, to the second node7, the first communication message needs to be encrypted. Thus the symmetric-key is used by the first node for encrypting520a first communication message to form an encrypted first communication message, which is then sent530, over the communications network5, to the second node7. The second node7, in turn, receives620the encrypted first communication message620, and decrypts630the encrypted first communication message, with the symmetric-key, to the first communication message.

Similarly, the second node7may encrypt640a second communication message, with the symmetric-key, to an encrypted second communication message, which is then sent650to the first node3. The first node3may then receive540the encrypted second communication message, and decrypt550it to the second communication message.

Hierarchy of Accounts—Chain Structure

As can be seen from the methods300,400described above, the second node second public key (P2E) is deterministically derived from the second node master public key (P1E). Similarly, the first node second public key may also be deterministically derived from the first node master public key (P1P). By performing the methods300,400repeatedly, a first node additional public key and second node additional public key may also be deterministically derived.

That is, the methods300,400described above may be used to determine a series of successive generator values, where each successive generator value may be determined based on the preceding generator value. Alternatively, successive keys may be determined based directly on the master key. Alternatively successive keys may be determined by a combination of the above methods.

For example, instead of repeating steps310to370′ of method300to generate successive single-purpose keys, by prior agreement between the nodes3,7, the previously used message for the generator value (GV) can be rehashed repeatedly by both parties to establish a hierarchy of generator values. In effect, the generator value, based on the hash of a message (M), can be a next generation message (M′) for the next generation of generator value (GV-2). Doing this allows successive generations of shared secrets to be calculated without the need for further protocol-establishment transmissions, in particular transmission of multiple messages for each generation of common secrets. The next generation common secret (CS′) can be computed as follows.

Firstly, both the first node3and the second node7independently determine the next generation of the generator value (GV-2). This is similar to steps320and420but adapted with the following formulas:
M′=SHA-256(M)  (Equation 7)
GV-2=SHA-256(M′)  (Equation 8)
GV-3=SHA-256(SHA-256(M))  (Equation 9).

The first node3may then determine the next generation of the second node second public key (P3E) and the first node second private key (V3P) similar to steps370and330as described above. In this example, the next generation is the third generation, i.e., the second node third public key and the second node third private key are determined. The second node7may then determine the next generation (third generation) of the first node second public key (P3P) and the second node second private key (V3E) similar to steps430and470as described above.

The first node3and the second node7may then each determine the next generation common secret (CS′).

In particular, the first node3determines the next generation common secret (CS′) with the formula:
CS′=V3P×P3E(Equation 10).

The second node7determines the next generation common secret (CS′) with the formula:
CS'=V3E×P3P(Equation 11).

Further generations (CS″, CS′″, etc.) can be calculated in the same way to create a chain hierarchy. This technique requires that both the first node3and the second node7keep track of the original message (M) or the originally calculated generator value (GV), and to which node it relates. As this is publicly known information there are no security issues regarding the retention of this information. Accordingly, this information might be kept on ‘hash tables’ (linking hash values to public keys) and distributed freely across the network5(for example using Torrent). Furthermore, if any individual common secret (CS) in the hierarchy is ever compromised, this does not affect the security of any other common secrets in the hierarchy provided the private keys V1P, V1Eremain secure.

FIG.8demonstrates an example of a hierarchical chain structure of keys. In this structure, the generator values GV-2 and GV-3 may be computed as described above in Equations 7 to 9. However, it is to be understood that the generator values may be calculated in alternative ways.

The different keys may be used for different payment purposes and represent accounts associated with the first node3or the second node7. For example, P2Pmay represent the account where the cryptocurrency, for example payroll funds of the employer associated with the first node, is transferred from and P2Emay represent the corresponding account at the second node7that receives the transferred cryptocurrency from the first node3.

In a further example, P3Pmay represent the tax withheld by the employer associated with the first node3for the second node7which may be transferred into the account represented by P3E. In this example, the account represented by P3Emay be associated with the tax withheld, or may be a general account for receiving cryptocurrency. In yet a further example, P4P(or any subsequent next generation public key) may represent the superannuation contribution of the second node, which may be transferred into P4E(or any subsequent next generation public key). In this example, the account represented by P4Emay be associated with the superannuation contribution, or may be a general account for receiving cryptocurrency.

In the instance where the first node3transfers a second quantity of cryptocurrency associated with tax withheld to the second node7, the second node7may request a second transfer associated with the received second quantity of cryptocurrency. This may comprise a transfer from the second node7to a further node that is representative of a relevant tax body, for example, the Australian Tax Office.

In a further example, in the instance where the first node3transfers a third quantity of cryptocurrency associated with a superannuation contribution to the second node7, the second node7may request a third transfer associated with the third quantity of cryptocurrency. This may comprise a transfer from the second node7to a further node that is representative of a relevant superannuation fund.

In another example, the first node3may transfer the second quantity of cryptocurrency to the relevant tax body. In a further example the first node may transfer the third quantity of cryptocurrency to the relevant superannuation fund.

In yet another example, the first node3may make regular payments to the accounts associated with the second node7including payments to multiple accounts. The multiple accounts may represent a bank loan, house mortgage payment, a college fund account or a holiday fund. In this example, the next generation public key of the first node or the second node may represent the bank loan, house mortgage payment, college fund or holiday fund.

In another example, the message to generate the generator value may change with the generation of the successive keys. This may be necessary, for example, when there is a requirement for a shared common secret (CS) between the successive public keys. These common secrets may be used, for instance, for encryption of information relevant to the successive public keys.

Hierarchy of Accounts—Tree Structure

In another example, a hierarchy in the form of a tree structure can be created.

With a tree structure, a variety of keys for different purposes such as authentication keys, encryption keys, signing keys, payment keys, etc. may be determined whereby these keys are all linked to a single securely maintained master key. This is best illustrated inFIG.9that shows a tree structure901with a variety of different keys. Each of these can be used to create a shared secret with another party.

Tree branching can be accomplished in several ways, three of which are described below.

(I) Master Key Spawning

In the chain hierarchy, each new ‘link’ (public/private key pair) is created by adding a multiply rehashed message to the original master key. For example, (showing only the private key of the first node3for clarity):
V2P=V1P+SHA-256(M)  (Equation 12)
V2P′=V1P+SHA-256(SHA-256(M))  (Equation 13)
V2P″=V1P+SHA-256(SHA-256(SHA-256(M)))  (Equation 14). . . and so on.

To create a branch, any key can be used as a sub-master key. For example V2P′ can be used as a sub-master key (V3P) by adding the hash to it as is done for the regular master key:
V3P=V2P′+SHA-256(M)  (Equation 15).

The sub-master key (V3P) may itself have a next generation key (V3P′), for example:
V3P′=V2P′+SHA-256(SHA-256(M))  (Equation 16).

This provides a tree structure903using the master key spawning method as shown inFIG.10.

(II) Logical Association

In this method all the nodes in the tree (public/private key pairs) are generated as a chain (or in any other way) and the logical relationships between the nodes in the tree is maintained by a table in which each node in the tree is simply associated with its parent node in the tree using a pointer. Thus the pointer may be used to determine the relevant public/private key pairs for determining the common secret key (CS) for the session.

(III) Message Multiplicity

New private/public key pairs can be generated by introducing a new message at any point in the chain or tree. The message itself may be arbitrary or may carry some meaning or function (e.g., it might be related to a ‘real’ bank account number, etc). It may be desirable that such new messages for forming the new private/public key pairs are securely retained.

Verifying the First Transfer

It may be desirable or required for the first node3or second node7to verify the first transfer of the first quantity of cryptocurrency. In some circumstances it may be required for a further node, such as the third node9or the issuer/service provider25, to verify the first transfer. For instance, the employee associated with the second node may wish to confirm that the amount of cryptocurrency associated with the payroll funds is correct.

FIG.11illustrates a method600of verifying the first transfer of cryptocurrency from the first node3to the second node7. The method600includes receiving610a request to confirm the first transfer. The request may be received at the first node3, or at a further node such as the third node9in the instance where the third node9is facilitating the transfer of cryptocurrency. The method600includes determining620the first data output corresponding to the first transfer of the first quantity of cryptocurrency. Determining the first data output may include receiving the first data output from the first node3or the second node7. In another example, it may include receiving the first data output from a further node such as the third node9. In yet another example, it may include receiving the first data output from a data store17.

The method600then includes receiving630, over the communications network, at least part of the first data output from the P2P distributed ledger. This may include receiving part of the transaction record stored on the ledger.

The method600further includes determining640, from the first data output, the indication of the first transfer and verifying650that the indication of the first transfer corresponds to the first transfer in the request. This may include, for example, confirming that the first quantity of cryptocurrency that is associated with the first transfer in addition to confirming that the public keys in the transaction record as received in step630correspond to the public keys of the first node3and the second node7.

The method600further includes sending660an output indicative of the result of verifying. The output may be sent to the node that sent the request, for example the first node3, the second node7or the third node9. In a further example the output may be sent to more than one node.

Tokens

It will be appreciated that the first quantity of cryptocurrency, second quantity of cryptocurrency or third quantity of cryptocurrency as described in the methods above may relate to a token amount of cryptocurrency. Tokens may represent transferable contract conferring specified rights upon the holder to be redeemed for fiat currency, goods or services. The contract might be a machine executable smart contract, as known in the art.

Thus, the invention may incorporate a tokenisation technique or method for exchanging or transferring a digital token from one party to another. One such method, as mentioned above, comprises the steps of:generating a blockchain transaction (Tx) having an output (TxO) related to a quantity of cryptocurrency, and a hash of a redeem script. The redeem script comprises:metadata comprising a token which is a representation of, or a reference to, a tokenised entity; andat least one (preferably two or more) public cryptographic keys.

The quantity of cryptocurrency may be Bitcoin but the invention is not limited in this regard. The redeem script may be provided within a locking script associated with the transaction output TxO. The metadata may be provided in the redeem script at a location which is designated in the blockchain's underlying protocol as a location for a cryptographic key.

The method may further include the step of submitting the transaction Tx to the blockchain. In effect, the cryptocurrency may thus be locked on the blockchain in association with the token. The quantity of cryptocurrency can only be spent (redeemed) upon provision of an unlocking script which meets the requirements of the locking script for the output TxO. In particular, a redeem script must be presented which, when hashed, matches the hash provided in the locking script of TxO. As the locking script for output TxO comprises the hash of the redeem script which in turn includes the token (in the metadata), the cryptocurrency is associated with the token. Upon presentation of the correct unlocking (redeem) script, ownership of the cryptocurrency may be transferred to the redeeming party or user i.e., it is spent.

In summary, a token is an exchangeable entity that can be used to represent a contract or some other type of entity. The contract may take one of several forms. It may be a computer-executable smart contract. For example, the contract may confer a right upon the holder or denote ownership of property. The value of the token may be contractually specified and is linked to the underlying bitcoin amount of the output (TxO) via a ‘pegging rate.’ The token is exchangeable via a novel type of transaction using a cryptocurrency protocol such as the bitcoin protocol. The bitcoin value on the transaction output (TxO) acts as a token representing a rights contract in digital form. The contract itself may be stored on the transaction, or somewhere else on the blockchain, or off the blockchain, or may be kept in a publicly accessible location, or may be held privately by the parties to the contract depending on the particular embodiment. Where the contract is not stored on or in the transaction, the transaction may store a unique pointer or reference to the contract.

Tokens may be divisible. A divisible token is one in which the value on the transaction output can be subdivided into smaller amounts which can be allocated across multiple new tokens. Examples of divisible tokens include tokens for fiat currency or for shares in a race horse. Divisible contracts may be defined as those that specify a non-zero pegging rate. In other words, the token value is tied to the underlying bitcoin value. Alternatively, tokens may be non-divisible. A non-divisible token is a contract that specifies the holder's rights in terms of a fixed value, e.g. a contract to redeem a house or AU$1000. Non-divisible tokens are therefore not linked to the value of the underlying bitcoin.

In some examples, tokens must be digitally signed by a token issuer to be valid. The issuer may, for example be an authority such as a Registrar of Title deeds. The issuer may issue a token to a user in return for payment. That token may then give the user the right to exercise the contract linked to the token, whether the contract represents the right to redeem fiat currency or for a service to performed.

Examples of tokens include:A fiat currency token that is pegged to the BTC value of the transaction output by the issuer of the contract. For example, “the spender of this token (bitcoin transaction) is entitled to redeem any fraction of this token for Australian dollars at a rate of 1 share (10 cents) for every 1000 satoshi”.Partial ownership in an item such as a photocopier.Employee leave entitlements such as annual leave or personal leave.Further employee benefits such as time in lieu, overtime or bonuses.Employee fringe benefits.A contract for the right to a service to be performed. It is noted that this is not the same as the actual service itself, but only the right to have the service performed for them. This right can be traded. For example, a voucher from Michael's Mowing for up to 3 hours lawn mowing within the Sydney metropolitan area. The holder of this voucher (contract) can redeem it for the actual service.

Tokens must specify the value of a share, e.g., 1 share=10 cents CAD, 1 share=1 rupiah, 1 share=1 day of annual leave, or 1 share=1% ownership of an item (photocopier, computer, etc).

In one embodiment of the methods described above, the method may be used to comprise tokenised benefits in addition to or in lieu of cryptocurrency. For example, the second user24(employee) associated with the second node7may receive a tokenised benefit of an hour of annual leave for every month of employment at the first user23(employer) associated with the first node3.

The details associated with the tokenised benefits may be placed in the redeem script of a P2SH transaction. For example, the details may be comprised in the metadata field of the redeem script according to the methods described above.

In this instance, the first node3acts as an issuer of the tokens and creates the tokens to represent the benefits. The tokens can then be transferred from the first node3to the second node7, for example into the main payroll account of the second node7or another derived account.

In another example, the third node9may act as the issuer. In another example, the issuer/service provider25may act as the issuer.

The tokens received by the second node7may be transferred to another node. For example, the tokens may be transferred to another employee of the employer associated with the first node3. Effectively, the transferable tokens described above may represent tradable employment rights and benefits of the first node (employer) or second node (employee). These tokenised rights and benefits may be traded between different employees of the same employer.

Processing Device

As noted above, the first and second nodes3,7may be an electronic device, such as a computer, tablet computer, mobile communication device, computer server etc. The electronic device may include a processing device21,27, a data store17and a user interface15.

FIG.12illustrates an example of a processing device21,27. The processing device21,27may be used at the first node3, second node7or other nodes9or25. The processing device21,27includes a processor1510, a memory1520and an interface device1540that communicate with each other via a bus1530. The memory1520stores instructions and data for implementing the method100,200,300,400described above, and the processor1510performs the instructions from the memory1520to implement the method100,200,300,400. The interface device1540, may include a communications module that facilitates communication with the communications network5and, in some examples, with the user interface15and peripherals such as data store17. It should be noted that although the processing device1501may be independent network elements, the processing device501may also be part of another network element. Further, some functions performed by the processing device1501may be distributed between multiple network elements. For example, the first node3may have multiple processing devices21to perform method100,300in a secure local area network associated with the first node3.

Where this disclosure describes that a user, employer, employee, issuer, merchant, provider or other entity performs a particular action (including signing, issuing, determining, calculating, sending, receiving, creating etc.), this wording is used for the sake of clarity of presentation. It should be understood that these actions are performed by the computing devices operated by these entities.

A user having an account with another entity may comprise the entity storing information about the user, such as email address, name and potentially public keys. For example, the entity may maintain a database, such as SQL, OrientDB, MongoDB or others. In some examples, the entity may also store one or more of the user's private keys.

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