BLOCKCHAIN-IMPLEMENTED METHOD FOR CONTROL AND DISTRIBUTION OF DIGITAL CONTENT

Abstract

The disclosure relates to a blockchain-implemented system and method of controlling the transmission and/or distribution of digital content. A first user transfers a deposit quantity of cryptocurrency to a common address. A first node associated with the first user: sends a request to the second node to provide an episode of digital content from a series of digital content; determines a payment transaction to transfer a payment quantity of cryptocurrency to the second user based on a quantity of episodes of digital content in the series; and signs and sends the payment transaction to a second node. The second node associated with the second user: receives the request and the payment transaction; verifies the payment transaction; and based on a result of verifying: provides access to the episode of digital content to the first node; and co-signs and sends the payment transaction to a distributed ledger.

Claims

1-29. (canceled)

30. A computer-implemented method of receiving digital content, wherein a first node (15) associated with a first user (5) receives digital content in return for payment to a second user (7) associated with a second node (17), wherein the first user (5) is associated with a deposit quantity of cryptocurrency (B1) at a common address (23), and wherein to spend from the common address requires signatures of both a first private key (V.sub.1) of the first user (5) and a second private key (V.sub.2) of the second user (7), the method-comprising: (A) sending, over the communications network (8), a request to the second node (17) to provide an episode of digital content (i) from a series of digital content; (B) determining a payment transaction (E.sub.i) to transfer from the common address (23) a payment quantity of cryptocurrency (B2) to the second user (7), wherein the payment quantity of cryptocurrency (B2) is based on a quantity of episodes of digital content in the series of digital content requested by the first user (5); (C) signing, with the first private key (V1), the payment transaction (E.sub.i) and subsequently sending the payment transaction (E.sub.i) to the second node (17) to cause the second node (17) to verify the payment transaction; wherein based on the second node (17) having verified that the payment transaction includes the payment quantity of cryptocurrency (B2), the method further comprises: (D) accessing, over the communications network (8), the episode of digital content i.

31. The method of claim 30, wherein the first and second nodes (15, 17) send the transaction to other intermediate nodes that in turn send it to other nodes and/or a blockchain (9).

32. The method of claim 30, wherein after a specified time without a transaction of the deposit quantity of cryptocurrency from the common address (23), the deposit quantity of cryptocurrency (B1) is refunded, and the first processing device is further configured to: co-sign, with a first private key (V.sub.1) of the first user (5), a second transaction to transfer the deposit quantity of cryptocurrency (B1) from the common address (23) to the first user (5); wherein the second processing device is further configured to: co-sign, with the second private key (V.sub.2), the second transaction, wherein the co-signed second transaction with both the first private key (V.sub.1) and the second private key (V.sub.2) is sent to a blockchain (9) and is valid after the specified time to refund the deposit quantity of cryptocurrency (B1); and send the co-signed payment transaction to the blockchain (9) before the specified time.

33. The method of claim 32, wherein the second node (17), upon verifying the payment transaction, immediately co-signs and send the payment transaction (Tx) to the blockchain (9).

34. The method of claim 32, wherein the second node (17), upon verifying the payment transaction, defers co-signing and sending the payment transaction (Tx) to the blockchain (9) until a time closer to the specified time to refund the deposit of the second transaction (25).

35. The method of claim 30, further comprising subsequent payment transactions, the subsequent payment transactions having a respective specified time that is earlier than the specified time of the preceding payment transaction.

36. The method of claim 30, wherein in step (III), the second node (17) provides access to the digital content by sending digital content from a first data store (18) to the first node (15).

37. The method of claim 30, wherein in step (III), wherein the second node (17) provide access to the digital content by making digital content at a second data store (11) associated with a content server (3) available, via the communication network (8), to the first node (15).

38. The method of claim 37, wherein the first node (15) receives the encrypted episode from the data store (11) at a suitable time for the first node (15).

39. The method of claim 30, wherein the second node (15) provides an episode specific encryption key to decrypt the episode.

40. The method of claim 30, wherein if the second user (7) fails to meet their obligation, the exposure to the first user is the price of one episode of digital content.

41. The method of claim 30, wherein the deposit quantity of cryptocurrency (B1) is a quantity mutually agreed upon by the first and second user (5, 7), preferably equivalent to the cost of the maximum amount of episodes of digital content in the series of digital content that can be received.

42. The method of claim 30, further comprising: determining at each of the nodes a common secret to encrypt information for secure transmission based on the second private and public keys, at the first node, the common secret (CS) is based on: (i) a first node second private key (V.sub.2P) based on the first node master private key (V.sub.1P) and the generator value (GV); and (ii) a second node second public key (P.sub.2E) based on the second node master public key (P.sub.1E) and the generator value (GV). at the second node, the same common secret (CS) can be determined based on: (iii) a first node second public key (P.sub.2P) based on the first node master public key (P.sub.1P) and the generator value (GV); and (iv) a second node second private key (V.sub.2E) based on the second node master private key (V.sub.1E) and the generator value (GV).

43. The method of claim 30, further comprising a symmetric key based on the common secret for encrypting and decrypting information between the two nodes.

44. The method of claim 30, wherein the first node (15) determines the common address by: determining the first public key (P.sub.1) corresponding the first private key (V.sub.1) of the first user (5), which should be known to the first node (5); and determining the second public key (P.sub.2) of the second user (5), which may be determined by receiving the second public key (P.sub.2) from the second node (17), a third party, or from a data store; optionally wherein the second public key (P.sub.2) is encrypted with a shared symmetric encryption key (S).

Description

BRIEF DESCRIPTION OF DRAWINGS

[0074] Examples of the present disclosure will be described with reference to:

[0075] FIG. 1 is a schematic diagram of an example system to distribute digital content;

[0076] FIG. 2 is a diagram illustrating transactions between a first user, a second user, and a common address;

[0077] FIG. 3 is a flow chart of computer-implemented methods for distributing and receiving digital content;

[0078] FIG. 4 is a flow chart of a computer-implemented method of initialising and creating a refund transaction;

[0079] FIG. 5 is a detailed flow chart of a computer-implemented method for distributing and receiving digital content according to one example; and

[0080] FIG. 6 illustrates a schematic example of a processing device.

DESCRIPTION OF EMBODIMENTS

Overview

[0081] A system, devices and methods for controlling the distribution and transmission of digital content from one node and receiving the digital content at another node will now be described. FIG. 1 illustrates a system 1 that includes a first node 15 associated with a first user 5 that is in communication, over a communications network 8, with a second node 17 associated with a second user 7. In this example, the first user 5 can request to receive digital content at the first node 15 and the second user 7, via the second node 17, provides access to the digital content. The second node 17 may provide access to the digital content in a number of ways including: sending digital content from a first data store 18 to the first node 15; and making digital content at a second data store 11 associated with a content server 3 available, via the communication network 8, to the first node 15.

[0082] The first node 15 and/or second node 17 are in communication, over the communications network 8, with a peer-to-peer distributed ledger (blockchain) 9. The blockchain 9 may be associated with one or more processing devices 19 to receive and record transactions. An example of a peer-to-peer distributed ledger includes the blockchain, which is a distributed ledger of transactions (Txs) based on the Bitcoin protocol. Thus the processing device 19 associated with the ledger may be processing devices used by, or associated with, “miners”.

[0083] Referring to FIG. 2, the first user 5 may wish to purchase an unknown number of digital content from a series of digital content from the second user 7. Before making digital content available to the first user 5, the second user 7 requires a deposit to provide confidence that the second user 7 will be paid for the digital content.

[0084] To provide the deposit, the first user 5 may perform a first transaction 21 to transfer a deposit quantity of cryptocurrency (B1) to a common address 23. The common address 23 may be a pay-to-script-hash (P2SH) address according the Bitcoin protocol, and spending from the common address 23 requires signatures of both a first private key (V.sub.1) of the first user 5 and a second private key (V.sub.2) of the second user 7. That is a transaction from the common address 23 must be signed by both the first user 5 and second user 7 and thereby both sides can have confidence that the deposit will not be spent without authority from both sides. It is to be appreciated that alternative multi-signature methods may be used to authorise a transaction from the common address 23.

[0085] In some examples, the deposit may be time limited whereby if the first user 5 does not make a request to receive episodes of digital content within a specified time (and/or other condition), the deposit is refunded back to the first user 5. An example of this is shown in FIG. 2 as a second transaction 25 that refunds the deposit quantity of cryptocurrency (B1) to the first user 5. In some examples, this may be achieved by having both the first user 5 and second user 7 to co-sign a second transaction from the common address (23) to the first user 5, where the second transaction is only valid after a specified time. For examples, the specified may be d days in the future expressed in Unix time. This second transaction is then broadcast, where it will become a valid transaction after the specified time.

[0086] Therefore if a competing transaction to spend the deposit quantity of cryptocurrency (B1) from the common address is broadcast before the specified time, that competing transaction will be the valid transaction. It is in the interest of the second user 7 to broadcast a valid competing transaction before the specified time, after which the deposit quantity of cryptocurrency (B1) will be refunded back to the first user (5). In the present example, these competing transactions are called payment transactions 27, 27′, 27″ as they represent transactions where the second user 7 could receive payment.

[0087] A brief example of how distributing the digital content, including creating the payment transaction 27, will now be described with reference to FIG. 3 that shows the respective methods 100, 200 performed by the first node 15 and second node 17.

[0088] The first user 5, upon wanting to receive an episode of digital content from a series of digital content, uses the first node 15 to make a request for digital content. The first node 15 (which may be a computer, a mobile communication device, a television, etc.) includes a first processing device 23 that sends 110, over the communications network 8, the request to the second node 15 to provide the episode of digital content.

[0089] The first node 15 also determines 120 a payment transaction (E.sub.i) 27 to transfer from the common address (23) a payment quantity of cryptocurrency (B2) to the second user 7. The payment quantity (B2) is based on a quantity of episodes of digital content in the series of digital content requested by the first user 5. This may include the episodes that have been requested previously (and received) but where payment has not been received by the second user 7. In a simplified example, the second payment quantity (B2) may be the number of episodes requested (i) multiplied by the price of each episode (p).

[0090] The first node 15 then signs 130, with the first private key (V.sub.1), the payment transaction (E.sub.i) 27. The payment transaction (E.sub.i) 27 is then sent to the second node 17. Since the payment transaction (E.sub.i) has only been signed with the first private key (V.sub.1), this is not yet a valid transaction as it requires the second node 17 to sign with the second private key (V.sub.2).

[0091] Turning now to the second node 17 associated with the second user 7, the second node has a second processing device 23′ that may include a mainframe computer, desktop computer, etc. The second processing device of the second node 17 receives 210, over the communications network 8, the request from the first node 15 to provide the episode of digital content and the payment transaction (E.sub.i) signed with the first private key (V.sub.1).

[0092] Before the second node 17 makes the episode of digital content available to the first node 15 and first user 5, the second node 17 needs to determine that the second user 17 will be able to receive payment. Accordingly, the second node 17 then verifies 220 the payment transaction (E.sub.i) 27, which includes verifying that the payment transaction (E.sub.i) 27 includes the payment quantity of cryptocurrency (B2) to the second user 7. In practical examples, this may include determining the correct amount of cryptocurrency as well as the correct destination.

[0093] Based on verifying the payment transaction (E.sub.i) (i.e. in particular that the second user 7 will be paid) the second node 17 then provides access 230, over the communications network 8, the episode of digital content to be available to the first node 15. In turn, this allows the first node to access 140 the episode of digital content.

[0094] To give effect to the payment transaction (E.sub.i) 27, the second node 17 then co-signs 240, with the second private key (V.sub.2) of the second user 5, the payment transaction (E.sub.i) 27 and sends the co-signed payment transaction to the blockchain 9. Thus the payment quantity of cryptocurrency (B2) will be transferred from the common address (23) that had the deposit quantity of cryptocurrency (B1).

[0095] In some examples, the first user 5 may have the opportunity to request and receive further episodes. Thus the second user 17 may have the opportunity to receive more payment (from the further episodes provided to the first user 5) and may therefore defer the step of co-signing 240 and sending the co-signed payment transaction to the blockchain 9 until a time closer to the specified time to refund the deposit of the second transaction 25. An example of distributing the next episode will now be described.

[0096] The first node 15 makes a request for the next episode of digital content from the series of digital content by repeating steps 110, 120, and 130 as described above but for the next episode. Importantly, the payment quantity of cryptocurrency will be adjusted to take into account the next episode (and previous episodes in the series where payment has not been made). The second node 17 similarly receives the request and distributes the next episode of digital content by repeating steps 210 to 230 as described above.

[0097] Thus the second node 17 has two payment transactions: a first payment transaction (E.sub.i) 27 that includes payment quantity of cryptocurrency up to the episode of digital content, and a second payment transaction (E.sub.i+1) 27′ that includes a payment quantity of cryptocurrency up to and including the next episode of digital content. Since the second user 7 will be interested in receiving the maximum amount of payment, the second node 17 should only sign 240 and send the co-signed payment transaction 27′ than includes the payment inclusive of that of the next episode—i.e. the second payment transaction (E.sub.i+1) 27′. Therefore the first payment transaction (E.sub.i) 27 may be abandoned by the second node 17.

[0098] The present disclosure may provide a system of communicating, transmitting and/or distributing digital content where the level of trust may be lower. For example, the level of exposure of either the first user 5 and/or second user 7 from deceitful conduct can be minimised. In one example, if the second user 7 fails to meet their obligation, the exposure (e.g. potential loss) to the first user would be the price of one episode of digital content (since the remaining amounts will be refunded).

[0099] The present disclosure may also provide a system that does not rely on other third parties, such as certificate authorities and hierarchies that may have single points of failure and vulnerable to attack. The use of cryptographic techniques enhances the security of the transmission/control arrangement provided by the invention.

[0100] A detailed example will now be described for the purposes of illustration.

Initialisation—Encryption Protocol

[0101] The first node 5 and second node 7 establish secure communication 101, 201, over the communications network 8, with one another. This may include encrypting communications with a shared symmetric encryption key (S). In some examples, the symmetric encryption key is based on a shared common secret. A technique for determining this common secret may be as follows: [0102] determining a first node second private key based on at least a first node master private key and a generator value; [0103] determining a second node second private key based on at least a second node master private key and the generator value; [0104] wherein: [0105] determining the common secret (CS) at the first node is based on the first node second private key and the second node second public key, and determining the common secret (CS) at the second node is based on the second node second private key and the first node second public key. The first node second public key and the second node second public key are respectively based on at least the first/second node master key and the generator value.

[0106] A method for deriving a key based on a shared common secret is described in more detail later in this description.

Deposit of Cryptocurrency to Common Address

[0107] To make the deposit in the first transaction 21 to the common address, the first node needs to determine the common address. In a pay to script hash (P2SH) system, this may be based on the public keys (corresponding the private keys used for signing). In one example, this includes determining the first public key (P.sub.1) corresponding the first private key (V.sub.1) of the first user 5, which should be known to the first node 5. This also includes determining the second public key (P.sub.2) of the second user 5, which may be determined by receiving the second public key (P.sub.2) from the second node 17, a third party, or from a data store. The second public key (P.sub.2) does not necessarily need to be transmitted in a secure manner, although in some examples the second public key (P.sub.2) may be encrypted with the shared symmetric encryption key (S).

[0108] The deposit quantity of cryptocurrency (B1) may be a quantity mutually agreed upon by the first and second user 5, 7. However, the deposit quantity of cryptocurrency (B1) may desirably be equivalent to the cost of the maximum amount of episodes of digital content in the series of digital content that can be received. This ensures that if the first user 5 decides to receive and watch all episodes, the deposit is sufficient to pay for all the episodes. Therefore if the series has a number of episodes n, and the price per episode is p, then the deposit quantity of cryptocurrency (B1) is n×p.

[0109] An example of the first transaction (A.sub.1) 21 to transfer the deposit quantity of cryptocurrency (B1) is shown below in Table 1 and 2.

TABLE-US-00001 TABLE 1 First transaction (A.sub.1) Transaction identifier A1 Version number Number of inputs 1 Input Previous Hash A.sub.Ø (unlocking) transaction Output index Length of signature script Signature script <Alice's signature> <Alice's public key> Sequence number Number of outputs 1 Output Value np (locking) Length of public key script Public key script OP_HASH16Ø <hash16Ø (redeem script)> OP_EQUAL Locktime 0

TABLE-US-00002 TABLE 2 Redeem script for transaction (A.sub.1) Redeem OP_2 <Alice's public key> <Bob's public key> script OP_2 OP_CHECKMULTISIG

[0110] In this example the first transaction (A.sub.1) 21 has an input from a previous blockchain transaction of the first user (“Alice”) 5 (that requires the first user's signature) an outputs to the common address (23). In this example, the output is to a hash that is based on a redeem script including the first user's public key (P.sub.1, “Alice's public key”) and the second user's public key (P.sub.2, “Bob's public key”). That is, redeeming the output of the first blockchain transaction (A.sub.1) 21 will require the signatures of both the first user 5, with the first private key (V.sub.1), and the second user 7, with the second private key (V.sub.2).

[0111] Recording the above mentioned first transaction (A.sub.1) 21, is shown in the method 100 performed by the first node 5 as shown in FIG. 4 where the first node where the first node 15 sends 103, over the communications network 8, a first data output (O1) to record, on the blockchain 9, a first transaction of the deposit quantity of cryptocurrency from the first user 5 to the common address (23).

Creating a Refund Transaction

[0112] A second blockchain transaction 25 is then created so that the deposit quantity of cryptocurrency (B1) is refunded after an expiry of a specified time.

[0113] This may include the first node 15 creating the second transaction 25 that includes spending the deposit quantity of cryptocurrency (B1) back to the first user 5, but only after a specified time in the future. The specified time may include setting a lock time to the second transaction of d days in the future expressed in Unix time.

[0114] An example of the second transaction (21) 25 to refund the deposit quantity of cryptocurrency (B1) is shown below in Table 3.

TABLE-US-00003 TABLE 3 Second transaction (A.sub.2) Transaction identifier A.sub.2 Version number Number of inputs 1 Input Previous Hash A.sub.1 (unlocking) transaction Output 0 index Length of signature script Signature script OP_Ø <Alice's signature> <Bob's signature> <redeem script> Sequence number Number of outputs 1 Output Value np (locking) Length of public key script Public key script OP_DUP OP_HASH16Ø <hash16Ø(Alice's public key)> OP_EQUALVERIFY OP_CHECKSIG Locktime d days in the future expressed in Unix time (the number of seconds that have elapsed since 00:00:00 UTC 1 Jan. 1970)

[0115] In this example the second transaction (A.sub.2) 25 has an input from the first transaction (A.sub.1) 21. Unlocking the input from the common address (23) 23 requires both the first user's signature with the first private key (V.sub.1) and the second user's signature with the second private key (V.sub.2). In this example, the output refunds the deposit quantity of cryptocurrency (which in this case is np) back to the first user 5, and therefore the output is based on a hash of the first user's public key (P.sub.1, “Alice's public key”) only. That is, redeeming the output of the first transaction (A.sub.1) 21 will only require the signature of the first user 5, with the first private key (V.sub.1) as the first user 5 should be free to spend their own refunded cryptocurrency.

[0116] Importantly, the second transaction (A.sub.2) 25 is only valid after a specified time, which in this case is achieved by the locktime function where the transaction is only valid after the specified time. For examples, d days (expressed in Unix time).

[0117] Recording the second transaction (A.sub.2) 25 is shown in FIG. 4 as steps 105, 107 performed by the first node 15 and steps 203, 205, 207 performed by the second node 17. The first node 15 co-signs 105, with the first private key (V.sub.1) of the first user 5, the second transaction. This second transaction (A.sub.2) 25 is then sent 107, over the communications network 8, to the second node 17 to be signed with second private key (V.sub.2). In turn, the second node 17 receives 203 the second transaction (A.sub.2) 25, and the second node 17 further co-signs 205 the second transaction (A.sub.2) 25 with the second private key (V.sub.2) of the second user 7. The second transaction (A.sub.2) 25, now signed with both private keys is then sent 207, over the communications network 8, to the blockchain 9 where it will be valid after the specified time to refund the deposit quantity of cryptocurrency (B1) if no other valid transactions (such as a payment transaction 27) are sent before that specified time.

[0118] It is to be appreciated that these steps may be performed in other orders. For example, the second node 17 may sign the second transaction first, and send it to the first node 15 to sign second. It is to be appreciated that either nodes can create the second transaction (before signing) and either node can send the co-signed transaction to the blockchain 9. In other examples, the first and second nodes 15, 17 may send the transaction to other intermediate nodes that in turn send it to other nodes and/or the blockchain 9.

Requesting Digital Content and Determining a Payment Transaction

[0119] The method of requesting digital content and creating a payment transaction will now be described with reference to FIG. 5.

[0120] The second node 17 determines, for each episode (i) of digital content, a corresponding episode secret (S.sub.i). The episode secret (S.sub.i) can be used to identify the episode (i) for those who know the secret, in particular the first user 5 and the second user 7. This can be useful to maintain privacy where information is sent to the blockchain 9.

[0121] The second node 17 sends 208 an episode secret (S.sub.i) for a first episode of digital content in the series of digital content to the first node 17. In this example, only the episode secret of the following episode that is available to the first user 5 and first node 15 is sent. The subsequent episode secrets are withheld until the first node 15 accesses the first episode. This ensures that the episodes are accessed in order.

[0122] When sending 208 the episode secret (S.sub.i), the second node 17 may create and send an encrypted message by encrypting the episode secret (S.sub.i) with the shared symmetric encryption key (S) to maintain secrecy of the episode secret (S.sub.i). The first node 15 then receives 108 the encrypted message, including the episode secret (S.sub.i), from the second node 17. The first node 15 then decrypts the encrypted message with the shared symmetric encryption key (S) to obtain the episode secret (S.sub.i).

[0123] The first node 15 may store the episode secret (S.sub.i) in a data store until the first user 5 decides to access the first episode of digital content. Assuming that the specified time has not expired (i.e. it is before d day), the method 100 at the first node 15 includes sending 110, over a communications network 8, a request to the second node 17 to provide the first episode of digital content. This request is accompanied by a payment transaction 27 for the first episode determined 120 at the first node which will be described below.

Determining the Payment Transaction

[0124] The payment transaction (E.sub.i) 27, if valid, will spend from the common address (23) (and in particular the deposit quantity of cryptocurrency (B1) therefrom) and accordingly requires the signature of both the first user 5 and second user 7. Therefore after determining the payment transaction (E.sub.i) 27, the first node 15 will need to sign the payment transaction (E.sub.i) 27 and send it to the second node 17 for co-signing before sending to the blockchain 9.

[0125] The first node 15 first determines 121 an episode secret hash (H.sub.i) from the episode secret (S.sub.i). This may include using a hash function such as OP_HASH 160 (where the input is hashed twice—with SHA-256 and subsequently with RIPEMD-160). It is to be appreciated that other hash functions may also be suitable.

[0126] The payment transaction (E.sub.i) 27, in this example, is in the form of a P2SH. Therefore determining the payment transaction (E.sub.i) 27 also includes determining a redeem script, which in this case is a payment redeem script (RS1) that is based on: the episode secret hash (H.sub.i); and the second public key (P.sub.2) of the second user 7. Including the episode secret hash (H.sub.i) in the redeem script may be used as proof that this particular payment transaction is related to access of the particular episode (associated with the episode secret hash (H.sub.i) and the episode secret (S.sub.i)). Secondly, the second public key (P.sub.2) of the second user 7 ensures that only the second user 7, having the corresponding second private key (V.sub.1), can spend that payment.

[0127] Determining 120 the payment transaction (E.sub.i) 27 also includes determining the payment quantity of cryptocurrency (B2) to the second user 7. In the case of the first episode, this payment quantity will be the price of that first episode. However as the first user 5 makes further requests for subsequent episodes, the payment quantity of cryptocurrency (B2) will change based on episodes that have been requested. In a simplified example, this may be the quantity of episodes multiplied by the price per episode.

[0128] In addition to an output to the second user 7, the payment transaction (E.sub.i) 27 may include another output back to the first user 5. This output back to the first user 5 may be representative of the change of the deposit quantity of cryptocurrency (B1) back to the first user. In one example, the change quantity of cryptocurrency (B3) to the first user 5 may be based on the deposit quantity of cryptocurrency (B1) less the payment quantity of cryptocurrency (B2).

[0129] The method 100 then includes signing 130, with the first private key (V.sub.1), the payment transaction (E.sub.i) 27 and subsequently sending the payment transaction (E.sub.i) 27 to the second node 17 to cause the second node 17 to verify the payment transaction.

[0130] An example of the payment transaction (E.sub.i) is shown below in Table 4 and 5.

TABLE-US-00004 TABLE 4 Payment transaction (E.sub.i) Transaction identifier E.sub.i Version number Number of inputs 1 Input Previous Hash A.sub.1 (unlocking) trans. Output index Ø Length of signature script Signature script <Alice's signature> <Bob's signature> <redeem script> Sequence number Number of outputs 2 Output 1 Value ip (locking) Length of public key script Public key script OP_HASH16Ø <hash16Ø (redeem script)> OP_EQUAL Output 2 Value (n − i)p (locking) Length of public key script Public key script OP_DUP OP_HASH16Ø <hash16Ø (Alice's public key)> OP_EQUALVERIFY OP_CHECKSIG Locktime Ø

TABLE-US-00005 TABLE 5 Output 1 redeem script of payment transaction (E.sub.i) Redeem OP_HASH16Ø <h.sub.i> OP_EQUALVERIFY script <Bob's public key> OP_CHECKSIG

[0131] The input to this transaction includes an unlocking script that requires the both the signatures of the first private key (V.sub.1) of the first user 5 (“Alice's signature”) and the second private key (V.sub.2) of the second user 7 (“Bob's signature”) as the payment transaction is spending from the common address (23).

[0132] “Output 1” shows the output of the payment quantity of cryptocurrency (B2) to the second user 7. This output can be redeemed by payment redeem script (RS1) shown in Table 5 which is based on the episode secret hash (H.sub.i) and the second user public key (P.sub.2) (“Bob's public key”) as described above.

[0133] “Output 2” shows the output that is the change quantity of cryptocurrency (B3) back to the second user 7. Note that the output script is based on the first user's public key P.sub.1 (Alice's public key) as the first user should be free to spend this change quantity of cryptocurrency (B3).

Verifying the Payment Transaction

[0134] The second node 17 receives 210, over the communications network 8, the request to provide the first episode of digital content. Accordingly the second node 17 will also expect to receive the payment transaction (E.sub.i) 27, signed with the first private key (V.sub.1), from the first node 15.

[0135] Before agreeing to the request to provide the episode of digital content, the second node will verify the payment transaction (E.sub.i) so that the first user 7 can have confidence that they will receive payment.

[0136] The second node 17 determines 121 the episode secret hash (H.sub.i) from the episode secret (S.sub.i). This may include using a hash function in the same way as the first node 15. The second node then verifies 220 the payment transaction (E.sub.i) that was received includes the payment quantity of cryptocurrency (B2) to the second user 7. This may include verifying the output value (such as output value in “Output 1” of Table 4) is the correct value by verifying the value is equal to the quantity of episodes request multiplied by the price.

[0137] Verifying 220 may also include verifying that the payment redeem script (RS1) is based on the episode secret hash (a) and the second public key (P.sub.2). This may be achieved by comparing the output script (which is based on the redeem script) in the received payment transaction (E.sub.i) with a corresponding hash of the known (or derivable) values of the episode secret hash (H.sub.i) and the second public key (P.sub.2). If this comparison shows that the output script matches the expected redeem script having the correct episode secret hash (a) and the second public key (P.sub.2), then the second node 17 (and the second user 7) can have confidence of the bona fide of the received payment transaction (E.sub.i).

[0138] Although the second node 17 may sign the payment transaction (E.sub.i) 27 and immediately send it to the blockchain 9, the second user 7 is not motivated to do so until closer towards the specified time as the first user 5 may make further requests for more episodes of digital content.

[0139] After successful verification, the second node 17 then provides access to the requested episode to the first node 15 as well as the next episode secret to the first node to allow the first node to request further content (being the next episode).

Determine the Next Episode Secret

[0140] The second node 17 then determines 221 the next episode secret (S.sub.i+1) for the next episode i+1 (which is the episode after episode (i) to be provided) in the series of digital content unless there are no more episodes in the series. This may include retrieving the next episode secret (S.sub.i+1) from the data store 18, or generating a new secret. The next episode secret (S.sub.i+1) is used to determine the next episode secret hash (H.sub.i+1) which in turn is used in the next payment transaction if the first user 5 decides to make a request for the next episode in the future.

[0141] The next episode secret (S.sub.i+1) may be provided to the first node 15 at the same time the second node provides access to the present requested episode of digital content.

Providing Access to Digital Content

[0142] Once the payment transaction (E.sub.i) 27 has been verified, the second node 17 provides access 230 to the episode of digital content to the first node 15. This may be achieved in a number of ways. In one example, the second node 17 may encrypt the episode of digital content with the shared symmetric encryption key (S) and send the encrypted episode of digital content, over the communications network 8, to the first node 15. In another example, the second node may provide the encrypted episode of digital content at a data store 11 associated with a content server 3, whereby the first node 15 may receive the encrypted episode from the data store 11 at a suitable time for the first node 15. In yet another example, the second node 15 may provide an episode specific encryption key to decrypt the episode.

[0143] In one example, the episode (i) of digital content that was requested may be concatenated with the next episode secret (S.sub.i+1). The concatenation may then be encrypted with the shared symmetric encryption key and the second node 17 then provides access to the encrypted concatenation.

[0144] The second node 17 may then send, over the communications network 8, a notification to the first node 15 indicating that the requested episode (i) of digital content is available to be accessed.

[0145] In turn, the first node 15 then accesses 140 the encrypted concatenation (e.g. by downloading from the data store 11 or directly from the second node 17, etc.) and decrypts it with the shared symmetric encryption key. This provides, at the first node 15, the episode of digital content (i) as well as the next episode secret (S.sub.i+1). Importantly, this provides the first user the episode of digital content for consumption as well as a means (i.e. the next episode secret (S.sub.i+1)) to obtain the next episode. The first node 15 may store 141 the next episode secret (S.sub.i+1) for later use.

[0146] It is to be appreciated that in some alternatives, the next episode secret may be sent 223 from the second node 17 to the first node 15 at other times and not concatenated with the episodes of digital content. This may include sending the next episode secret (S.sub.i+1) as a separate encrypted message over the communications network.

Requesting the Next Episode

[0147] If the first user 5 wishes to watch the next episode i+1, the first node 15 may then repeat the above steps of sending 110 a request for an episode of digital content, determining 120 a next payment transaction and signing 130 the next payment transaction. This can be done with the next episode secret (S.sub.i+1) and a corresponding determined next episode secret hash (H.sub.i+1). In turn, the second node 15 will repeat the steps of receiving 210 the request and next payment transaction, verifying 220 the next payment transaction and providing access 230 to the next episode.

[0148] The above can be repeated until all the episodes of digital content have been accessed by the first node 15 or when it is close to, or at, the expiry of the specified time d days. In these situations, the second node 15 will then perform the following steps to effect the payment to the second user 7.

Co-Signing the Payment Transaction

[0149] When all the episodes in the series of digital content have been accessed by the first node 15, the second user 7 will be motivated to co-sign the latest payment transaction (E.sub.i) 27″ to receive payment as there will be no further payment transactions 27″. Alternatively, if the expiry period of the specified time is approaching, the second user 7 will be motivated to co-sign the latest payment transaction (E.sub.i) 27″ as it would be unlikely that the first user 5 will make any further requests. More importantly, the payment transaction (E.sub.i) must be co-signed and sent to the blockchain 9 before the specified time to ensure it is recorded before the second transaction (refund transaction) is valid.

[0150] Thus the method 200 includes the second node 17 co-signing 240, with the second private key (V.sub.2), the latest payment transaction (E.sub.i) 27″ and sending the co-signed payment transaction to the blockchain 9.

[0151] When the second user 7 wishes to spend the payment quantity of cryptocurrency (B2), the second node 17 will unlock the transaction by signing the redeem script shown in Table 5 by signing with the second user private key (V.sub.2) and the episode secret (S.sub.i) corresponding to the episode secret hash (H.sub.i) in the payment transaction (E.sub.i). This is shown in the unlocking script in Table 6 below. Please note that the redeem script, in the format as shown in Table 5, can be determined by the second node 17 based on the second user public key (P.sub.2) and the episode secret (S.sub.i), wherein the episode secret (S.sub.i) is used to derive the episode secret hash (H.sub.i).

TABLE-US-00006 TABLE 6 The second user spending the payment quantity of cryptocurrency Transaction identifier B Version number Number of inputs 1 Input Previous Hash E.sub.i (unlocking) transaction Output index Ø Length of signature script Signature script <Bob's signature> <s.sub.i> <redeem script> Sequence number Number of outputs Output Value ip (locking) Length of [Dependent on how public key script Bob decides to spend] Public key script [Dependent on how Bob decides to spend]

Variations

[0152] 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.

[0153] In one example variation, each payment transaction (E.sub.i) may itself have a respective payment specified time before it is valid. For example, the payment specified time may be a time (e.g. d−1 day) before the specified time (e.g. d days) of the second transaction (i.e. the refund transaction) so that the payment transaction (E.sub.i) is the valid transaction before the second transaction.

[0154] Therefore in this variation, the second node 17, upon verifying the payment transaction may immediately co-sign and send the payment transaction (Tx) to the blockchain 9.

[0155] For subsequent payment transactions, these subsequent payment transactions have a respective specified time (e.g. d−2 days) that is earlier than the specified time of the preceding payment transaction (e.g. d−1 days). Thus the subsequent payment transactions, once co-signed and sent to the blockchain 9 will precede and be valid over the earlier payment transactions and the second (refund) transaction. An advantage of this variation is that if the second node 17 has a failure at a time close to the specified time for the second (refund) transaction, the second user 7 will still receive payment as the payment transactions have already been co-signed and sent to the blockchain 9.

Shared Symmetric Key Based on a Shared Common Secret

[0156] A method of generating a common secret between two nodes is now described. The common secret can be used in the generation of a cryptographic key.

Determining a Common Secret

[0157] The method allows for the generation of a common secret between two nodes without requiring the common secret to be sent to and/or from either one of the nodes. Each node has a respective asymmetric cryptography pair (such as an elliptic curve cryptography pair), each pair including a master private key and a master public key. For example the first node may have a master private key (V.sub.1P) and a master public key (P.sub.1P), and the second node may have a master private key (V.sub.1E) and a master public key (P.sub.1E). Respective second private and public keys of each node may be determined based on the master private key, master public key and a generator value. The generator value (or a message used to derive the generator value) is communicated to and/or from the nodes.

[0158] A common secret may be determined at each of the nodes based on the second private and public keys. An example of determining a common secret between a first node and a second node will now be described. Both the first and second nodes determine a generator value that is common to both nodes. The generator value may be received by a message, or derived from a message.

[0159] At the first node, the common secret (CS) is based on:

[0160] (i) a first node second private key (V.sub.2P) based on the first node master private key (V.sub.1P) and the generator value (GV); and

[0161] (ii) a second node second public key (P.sub.2E) based on the second node master public key (P.sub.1E) and the generator value (GV).

[0162] At the second node, the same common secret (CS) can be determined based on:

[0163] (iii) a first node second public key (Pap) based on the first node master public key (P.sub.1P) and the generator value (GV); and

[0164] (iv) a second node second private key (V.sub.2E) based on the second node master private key (V.sub.1E) and the generator value (GV).

[0165] Thus the common secret is:

Common secret(CS)=(V.sub.2P×P.sub.2E)=(P.sub.2P×V.sub.2E)

Securely Transmitting Information

[0166] The common secret may be used to encrypt information for secure transmission. For example, a symmetric key may be based on the common secret. Since both nodes have the same common secret, they can determine the same symmetric key which can be used for encrypting and decrypting information transmitted (for example over an unsecure network) between the two nodes.

Processing Device

[0167] As noted above, the first user 5 and second user 7 are associated with respective first node 15 and second node 17. The first node 15 and second node 17 may be an electronic device, such as a computer, tablet computer, mobile communication device, computer server, computer terminal, etc. Such an electronic device may include a processing device, and accordingly, the first node 15 has a first processing device 23 and the second node 17 has a second processing device 23″. The electronic device may also be associated with a data store 11, 18 and a user interface. Examples of a user interface include a keyboard, mouse, monitor, touchscreen display, etc. The blockchain 9 may also be associated with multiple processing devices 19.

[0168] FIG. 6 illustrates an example of a processing device 19, 23. The processing device 19, 23 includes a processor 1510, a memory 1520 and an interface device 1540 that communicate with each other via a bus 1530. The memory 1520 stores instructions and data for implementing the method 100, 200 described above, and the processor 1510 performs the instructions (such as a computer program) from the memory 1520 to implement the methods 100, 200. The interface device 1540 may include a communications module that facilitates communication with the communications network 8 and, in some examples, with the user interface and peripherals such as data store 11, 18. It should be noted that although the processing device 1510 may be independent network elements, the processing device 1510 may also be part of another network element. Further, some functions performed by the processing device 19, 23 may be distributed between multiple network elements. For example, the first user 5 may be associated with multiple processing devices 23 (such as those of the first user's mobile communication device, tablet, desktop computer, home media player, television, etc.) and steps of the method 100 may be performed, and distributed, across more than one of these devices.