BLOCKCHAIN IMPLEMENTED METHOD AND SYSTEM

Abstract

The invention relates to computer-based, electronic ledgers, and in particular distributed ledgers known as “blockchains”. The invention is suited for use with the Bitcoin blockchain and associated protocol, but is not limited in this regard and can be deployed using other blockchain platforms. The invention provides a novel and advantageous technique for executing a micropayment channel in which the number of transactions (TXs) that need to be submitted to the blockchain can be greatly reduced. An initial transaction (Tx) can be replaced by one or more subsequent transactions which another party can hold onto until a selected transaction is completed (signed) and submitted to the network. In one embodiment, the invention provides a computer-implemented method for performing an exchange via a blockchain, comprising the step of submitting a funding transaction to the blockchain network, wherein the funding transaction i) comprises a tokenised contract relating to an asset to be transferred from a second user to a first user; and ii) is signed by the first user. It also comprises the step of sending, from the first user to the second user, one or more subsequent transactions wherein each said subsequent transaction spends an output of the funding transaction and is signed by the first user. It includes the step of submitting one of the subsequent transactions to the blockchain network, the submitted transaction having been signed by the second user.

Claims

1. A computer implemented method for transferring at least one asset between a first user and a second user by means of a blockchain, the method comprising: generating a first blockchain transaction comprising at least one first input representing a respective first asset transferrable from the second user to the first user, and at least one first output representing a respective second asset, the second asset redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; generating a second blockchain transaction having at least one second input representing a respective said second asset, and at least one second output representing a respective third asset transferrable from the first user to the second user, wherein said third asset is exchanged for a respective said first asset, and wherein said third asset is redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; and repeating generation of said second blockchain transaction to update value of said third asset.

2. A method according to claim 1, wherein the second blockchain transaction has at least one third output representing a respective said first asset.

3. A method according to claim 1, wherein at least one said first input contains control data for generating a third blockchain transaction.

4. A method according to claim 1, wherein at least one said second asset is redeemable as a result of non-redemption of a said third asset, by providing the cryptographic signature of the first user.

5. A method according to claim 1, wherein at least one said second asset is redeemable, after expiry of a first locktime, by providing the cryptographic signature of the first user.

6. A computer implemented method for transferring at least one asset between a first user and a second user by means of a blockchain, the method comprising: generating a fourth blockchain transaction having at least one fourth output representing a respective first asset transferrable from the second user to the first user and corresponding to a respective first input of a first blockchain transaction; receiving a first blockchain transaction comprising at least one first input representing a respective said first asset, and at least one first output representing a respective second asset, the second asset being redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; submitting said first blockchain transaction to the blockchain; receiving a plurality of second blockchain transactions, each said second blockchain transaction comprising at least one respective second input representing a respective said second asset, and at least one respective second output representing a respective third asset transferrable from the first user to the second user, wherein said third asset is exchanged for a respective said first asset, wherein said third asset is redeemable by providing a cryptographic signature of the first user and a cryptographic signature of the second user; and submitting a said second blockchain transaction to the blockchain.

7. A method according to claim 6, further comprising submitting said fourth blockchain transaction to the blockchain.

8. A method according to claim 6, wherein the first blockchain transaction comprises at least one fifth output representing a respective fourth asset redeemable by providing the cryptographic signature of the second user.

9. A method according to claim 8, wherein the fourth asset is redeemable as a result of non-redemption of a said third asset, by providing the cryptographic signature of the second user.

10. A method according to claim 8, wherein the fourth asset is redeemable after expiry of a second locktime, by providing the cryptographic signature of the second user.

11. A method according to claim 6, wherein at least one said first and/or third asset comprises machine-executable code.

12. A computer-implemented method for performing an exchange or executing a contract via a blockchain, the method comprising the steps: submitting a funding transaction to a blockchain network, wherein the funding transaction: i) comprises a tokenised (smart) contract relating to an asset to be transferred from a second user to a first user; and ii) is signed by the first user; sending, from the first user to the second user, one or more subsequent transactions wherein each said subsequent transaction spends an output of the funding transaction and is signed by the first user; and submitting one of the subsequent transactions to the blockchain network, the submitted transaction having been signed by the second user.

13. A method according to claim 12 wherein the method is a method of implementing and/or executing a micropayment channel on a blockchain.

14. A computer-implemented system arranged to perform a method according to claim 1, the system comprising: a blockchain network; and at least one computing-based resource arranged to generate a blockchain transaction and/or submit a blockchain transaction to a blockchain network.

15. A method according to claim 1, wherein at least one said first and/or third asset comprises machine-executable code.

16. A computer-implemented system arranged to perform a method according to claim 6, the system comprising: a blockchain network; and at least one computing-based resource arranged to generate a blockchain transaction and/or submit a blockchain transaction to a blockchain network.

17. A computer-implemented system arranged to perform a method according to claim 12, the system comprising: a blockchain network; and at least one computing-based resource arranged to generate a blockchain transaction and/or submit a blockchain transaction to a blockchain network.

Description

[0056] FIG. 1 is a schematic diagram showing operation of a known unidirectional micro payment channel;

[0057] FIG. 2 is a schematic diagram showing operation of a unidirectional micropayment channel embodying the present invention;

[0058] FIG. 3 shows a blockchain tokenisation process used in the method of FIG. 2;

[0059] FIGS. 4A to 8B show blockchain transactions used in the micropayment channel of FIG. 2; and

[0060] FIGS. 9A to 11B show blockchain transactions used in Example 1.

[0061] With reference to the Figures, we show an illustrative use case which relates to the purchase of a service. However, it is important to note that the invention is not limited in this regard. Embodiments of the invention may be arranged to facilitate the exchange of any asset. This asset may be referred to as a “transfer asset”. The transfer asset may be a digital asset, and may represent an entity of any type e.g. physical, electronic, digital or abstract. In the following description, references to the first, second, third and fourth blockchain transactions, and to the first, second, third and fourth assets, have the same meaning as in the claims.

[0062] It is also important to note that the example provided herein relates to a scenario in which a purchase is made. Therefore, the terms “customer” and “merchant” may be used to refer to participants in the exchange. However, the invention is not intended to be limited to retail-oriented applications. Instead, the invention is equally applicable to applications where no goods or services are purchased. Transfer of digital assets (funds) made by blockchain transactions may serve purely to facilitate the blockchain-related implementation, as all blockchain transactions (Txs) must have an input and an output.

[0063] Referring to FIG. 2, a micropayment channel embodying the present invention is shown. The micropayment channel may be referred to as a “unidirectional micropayment channel”. The micropayment channel is arranged to enable a participating party (hereafter a “customer”) to pay another participating party (hereafter “a merchant”) for an online, time-dependent digital asset such as internet access by means of a payment transaction which can be updated one or more times. This enables an output of the micropayment channel which represents payment for a time-dependent asset to be updated as more of the asset it transferred over time. This may be referred to as the “transfer asset” because it is the asset which is being provided from one user to another. The invention therefore provides a technical mechanism for controlling the way in which the transfer asset is transferred. The blockchain transactions provide the technical vehicle for determining whether or not the asset can be transferred between the parties, and how and when this transfer is to be performed.

[0064] An important advantage of the invention is that the exchange process can be fully automated, thus removing the need for manual participation once the process has been initiated. The system can be arranged such that computing agents can determine how and when transactions are to be generated and/or submitted to the blockchain.

[0065] Initially, a merchant creates a number C of contracts for services or assets in step S101. Preferably, the contracts are machine executable smart contracts which define certain details, such as the deposit size, payment amount and payment frequency. Thus, by utilising smart contracts the invention enables the asset provider (e.g. merchant) to have some input into the micropayment process. This is an advantage over the prior art arrangements, and the invention provides an alternative, technical mechanism for controlling how the micropayment channel is executed. A greater degree of granularity or conditionality is introduced into the execution via the smart contract. For example, the asset provider can also use smart contracts to physically control access to an asset such as internet access.

[0066] The merchant then generates a fourth blockchain transaction in the form of a minting blockchain transaction (“minting Tx”) in step S102 having an input representing funds provided by the merchant, and a series of C outputs, each of which pays part of the funds to a script or token representing a respective first asset forming part of a contract between the merchant and a customer. It will be appreciated by persons skilled in the art that the party generating the minting transaction (“the minter”) need not be the merchant. For example, a merchant may choose to contract generation of the minting transaction to a third party, or use software supplied for this purpose by a third party.

[0067] The token may represent a smart contract, which can be stored on a computer-based resource e.g. a server. The smart contract is written in a machine executable form and thus can be read, executed and/or enforced by automated agents (which may be called “bots”). The contract may, for example, be stored in a Distributed Hash Table (DHT) which is provided off-block. Tokens may be minted or melted by the minter at any time.

[0068] The token (or “coloured coin”) which represents the contract may be provided as metadata in the script. The token can enable the contract to be accessed. For example, the token may provide the location or URI of where the smart contract is stored, or a hash of the location.

[0069] The merchant then submits the minting transaction to the blockchain in Step S103. Details of the minting transaction are shown in FIG. 4A, and details of the input and output of the transaction and the script to which an output of the minting transaction pays its funds are shown in FIG. 4B.

[0070] Details of the input and output of the transaction and the script to which an output of the minting transaction pays its funds are as follows: [0071] Input 1—funds by Merchant to mint the token [0072] Funds amount and unlocking script is arbitrary [0073] Output 1—pays funds to <script_hash_token> which is Hash160 of the script:

TABLE-US-00001 Script OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG where metadata1 & metadata2 are pretend compressed public keys containing information about the contract

[0074] After the minting transaction has been submitted to the blockchain in Step S103, the merchant publishes the scripts of the tokens and details of the contracts on a platform accessible to the customer in step S104. Steps S101 to S104 can be carried out at any time, enabling the merchant to add new tokens to the list, and tokens can be melted (i.e. deleted or re-used) by the merchant at any time.

[0075] FIG. 3 shows an example of a token minting transaction, which can be the minting transaction of step S102 of FIG. 2, and a token transfer transaction, which can be the transfer transaction forming the output of the replaceable transaction of step S108 of FIG. 2. The minting transaction is generated by the token minter in step S201 and has an input representing funds provided by the minter and a single output paying funds to a script hash, being the hash of multi-signature script including metadata pointing to an electronic certificate. The script is of the following form:

Script

[0076] <NumSigs Metadata1 Metadata2 . . . PubKey1 PubKey2 . . . NumKeys OP_CHECKMULTISIG>

[0077] Where Metadata1 . . . etc. are pretend compressed public keys (32 bytes). An example of metadata format can be seen below:

TABLE-US-00002 Field Sub-field Bytes Value Comments Metadata1 ContractType 4 Coded value indicates type of contract. ContractPointer 16 IPv6 address of the actual contract file location ContractTypeData1 12 Format depends on value of ContractType. Padded with zeros Metadata2 ContractHash 20 RIPEMD-160(SHA256(actual contract file addressed by ContractPointer)) ContractTypeData2 12 Format depends on value of ContractType. Padded with zeros

[0078] PubK1 . . . are true public keys.

[0079] The token can be redeemed by the script containing the minter's public key as shown in FIG. 2.

[0080] A token transferring transaction is generated in step S202 and has an input spending the token and its associated funds, and an output paying the funds to a hash of a script representing the token being owned by party A.

[0081] Referring back to FIG. 2, the micropayment channel is then initially created when a customer then browses the contracts and creates a first blockchain transaction in the form of a funding transaction in step S105 for a contract he wishes to enter. The funding transaction has a first input representing a deposit of funds by the customer, and a second input representing a first asset represented by the second input containing the script comprising the token provided by the merchant. The funding transaction has an output representing a second asset by paying an amount X to the customer, which is redeemable by providing the customer's signature and the merchant's signature, or by providing the customer's signature only after expiry of a locktime N, and an output representing a third asset by paying an amount Y to the merchant, which is redeemable by providing the customer's signature and the merchant's signature, or by providing the merchant's signature only after expiry of the locktime N. The amount X could typically be the full amount of the deposit, representing a full refund of the deposit to the customer, and Y could represent a full refund of the token value to the merchant. However, it is also possible to set X to a smaller value, and Y to a larger value, representing payment of a non-refundable deposit to the merchant.

[0082] The customer then signs the funding transaction and sends it to the merchant at step S106. The merchant signs the funding transaction and submits it to the blockchain in step S107. Details of the funding transaction are shown in FIG. 5A, and details of the inputs and the outputs of the funding transaction and the scripts for unlocking the inputs and outputs of the funding transaction are shown in FIG. 5B.

[0083] Details of the inputs and the outputs of the funding transaction and the scripts for unlocking the inputs and outputs of the funding transaction are as follows: [0084] Input 1—deposit by the Customer as required by contract [0085] The deposit amount and unlocking method is arbitrary [0086] Input 2—token by Merchant, Customer copies this from a platform where the Merchant publishes the contract and token script. <script_serialized_token> is serialized token script:

TABLE-US-00003 Script OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG where metadata1 & metadata2 contain information about the contract [0087] Output 1—pays X amount to <script_hash_customer> which is a Hash160 of:

TABLE-US-00004 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0088] <script_hash_customer> can be unlocked by: [0089] OP_1<Sig_Customer> <serialized script customer> with Locktime N; or [0090] OP_0<Sig_Customer> <Sig Merchant> <serialized script customer> [0091] X amount paid (450,000 here) is adjustable depending on contract terms. i.e. how much is refunded to Customer if no Replaceable Transaction is submitted to the blockchain before time N [0092] Output 2—pays Y amount to <script_hash_merchant> which is a Hash160 of:

TABLE-US-00005 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0093] <script_hash_merchant> can be unlocked by: [0094] OP_1<Sig Merchant> <serialized script merchant> with Locktime N; or [0095] OP_0<Sig_Customer> <Sig Merchant> <serialized script merchant> [0096] Y amount paid (50,000 here) is adjustable depending on contract terms. i.e. how much is paid to Merchant if no Replaceable Transaction is submitted to the blockchain before time N

[0097] Referring again to FIG. 2, when a payment is to be made, the customer generates a second blockchain transaction in the form of a replaceable blockchain transaction in step S108. The replaceable transaction has inputs spending amounts X and Y from the funding transaction respectively, and an output paying the token value to the script of the token, an output representing a third asset by paying an amount due to the merchant, and an output paying the remaining funds to the customer. The customer signs the replaceable transaction and sends it to the merchant in step S109. It should be noted that the replaceable transactions are not submitted to the blockchain. Instead, they are signed by the customer, sent to the merchant who can choose which replaceable transaction to sign and submit to the blockchain, and when.

[0098] In order to redeem each of the outputs of the replaceable transaction, the customer's signature and the merchant's signature are required. When a subsequent payment becomes due, steps S108 and S109 are repeated, incrementing the amount due to the merchant and decrementing the amount to be repaid to the customer.

[0099] Finally, the merchant signs both inputs of the latest replaceable transaction and submits the transaction to the blockchain in step S110 to redeem the amount due to the merchant. Details of the replaceable transaction are shown in FIG. 6A, and details of the inputs and outputs of the transaction and scripts for unlocking inputs and outputs of the replaceable transaction are shown in FIG. 6B.

[0100] Details of the inputs and outputs of the transaction and scripts for unlocking inputs and outputs of the replaceable transaction are as follows: [0101] Input 1—spends Output 1 of Funding Tx using Customer & Merchant sig to unlock <serialized script customer>:

TABLE-US-00006 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0102] Input 2—spends Output 2 of Funding Tx using Customer & Merchant sig to unlock <serialized script merchant>:

TABLE-US-00007 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0103] Output 1 pays funds to <script_hash_token> which is Hash160 of the script:

TABLE-US-00008 Script OP_1 <Metadata1> <Metadata2> <PubKey_Merchant> OP_3 OP_CHECKMULTISIG where metadata1 & metadata2 are pretend compressed public keys contain information about the contract [0104] This sends the token back to the Merchant [0105] Output 2—pays amount owed to Merchant [0106] This amount should be monotonically increasing with each new Replaceable Tx [0107] Output 3—pays remainder of deposit to Customer

[0108] If no replaceable transaction has been received by expiry of locktime N, customer and merchant refund blockchain transactions are executed. In particular, the customer refund transaction generated at step S111 has a single input spending funds X from the funding transaction of step S105 and pays the amount X to an address specified by the customer.

[0109] The output of the customer refund transaction only requires the customer's signature. The customer signs the transaction and submits it to the blockchain in Step S112. Details of the customer refund transaction are shown in FIG. 7A, and details of the input and output of the customer refund transaction and scripts for unlocking inputs and outputs of the customer refund transaction are shown in FIG. 7B.

[0110] Similarly, the merchant refund transaction generated at step S113 has a single input spending funds Y from the funding transaction of step S105 and pays the amount Y to an address specified by the customer. The output of the merchant refund transaction only requires the merchant's signature. The merchant signs the transaction and submits it to the blockchain in Step S114. Details of the merchant refund transaction are shown in FIG. 8A, and details of the input and output of the merchant refund transaction and scripts for unlocking inputs and outputs of the merchant refund transaction are shown in FIG. 8B.

[0111] Details of the input and output of the customer refund transaction and scripts for unlocking inputs and outputs of the customer refund transaction are as follows: [0112] Input 1—spends Output 1 of Funding Tx using Customer sig to unlock <serialized script customer>:

TABLE-US-00009 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Customer> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0113] Note that the Sequence Number is not 0xFFFFFFFF which signals for Locktime N to be checked [0114] Output 1—pays the amount in Funding Tx Output 1 to whatever addresses Customer chooses to nominate

[0115] Details of the input and output of the merchant refund transaction and scripts for unlocking inputs and outputs of the merchant refund transaction are as follows: [0116] Input 1—spends Output 1 of Funding Tx using Merchant sig to unlock <serialized script merchant>:

TABLE-US-00010 Script OP_IF <now + time N> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey_Merchant> OP_CHECKSIGVERIFY OP_ELSE <PubKey_Customer> <PubKey_Merchant> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF [0117] Note that the Sequence Number is not 0xFFFFFFFF which signals for Locktime N to be checked [0118] Output 1—pays the amount in Funding Tx Output 2 to whatever addresses Merchant chooses to nominate [0119] Merchant can choose to use one of the outputs to remint the token

EXAMPLE 1

[0120] In the following example, the Merchant is a Hotel which offers internet access, and the Customer is a guest of the Hotel wanting to purchase internet access.

[0121] The Hotel has a router management software which allows it to set a bandwidth, download, and time limit to different IP/MAC addresses. To monetize the internet access, the Hotel offers the following services to its guests:

TABLE-US-00011 Service Bandwidth Download Time No. Limit Limit Limit Locked Deposit* Minimum Payment* Rate* 1 30 Mbps 2 GB 24 hrs 4,500,000 (~$18) 2,250,000 (~$9) 1,125/MB (~$0.0045) 2 30 Mbps 1 GB 24 hrs 2,500,000 (~$10) 1,250,000 (~$5) 1,250/MB (~$0.005) 3 10 Mbps Unlimited 2 hr 6,000,000 (~$24) 3,000,000 (~$12) 25,000/min (~$0.1) 4 10 Mbps Unlimited 1 hr 3,750,000 (~$15) 1,875,000 (~$7.5) 31,250/min (~$0.125) *The unit is Satoshi. $ value is estimated with $400/BTC

Other Setup Details

[0122] Hotel owns private/public key H which has 1 BTC (100,000,000 Satoshi) [0123] Guest owns private/public key G which has 0.06 BTC (6,000,000 Satoshi) [0124] Hotel has a server where it stores the tokens/contracts. It also has an intranet site which it uses to display the available tokens/contracts

Steps

[0125] 1. Hotel creates a Contract for each of its 4 services. It saves them as pdfs and stores them on its server [0126] 2. Hotel creates metadata1 and metadata2 for each of its 4 Contracts. The format is as follows:

TABLE-US-00012 No. of Field Name bytes Description metadata1 Contract 32 32 character link to the contract Link metadata2* Contract 20 RIPEMD(SHA256(contract file)) Hash *the remaining 12 bytes of metadata2 are just zeros [0127] 3. Hotel creates a Minting Transaction which tokenizes the 5 Contracts. [0128] a. Note that only 4 tokens are created here for simplicity. In practice multiples of each service/token can be created

[0129] Details of the minting transaction are shown in FIG. 9A, and details of the input and output of the transaction and the script to which an output of the minting transaction pays its funds are shown in FIG. 9B.

[0130] Details of the input and output of the transaction and the script to which an output of the minting transaction pays its funds are as follows:

[0131] Output 1—P2PKH. Pays the remaining funds back to Hotel's address H

[0132] Output 2—P2SH (Token 1). Pays 1,000 Satoshi to the hash of the script <script_hash_token3>:

TABLE-US-00013 Script OP_1 <Metadata1> <Metadata2> <PubKey H> OP_3 OP_CHECKMULTISIG where metadata1 & metadata2 are pretend compressed public keys contain information about contract 1

[0133] Output 3-5 P2SH. Same as Output 2, except the metadata points to different contracts [0134] 4. Hotel submits the Minting Transaction to the blockchain [0135] 5. Hotel displays the tokens and contracts on its intranet site for guests to browse [0136] 6. Guest of the Hotel browses the intranet for internet access options and decides to go with service 3. It takes Token 3 and creates a Funding Transaction as per the associated Contract 3. [0137] Details of the funding transaction are shown in FIG. 10A, and details of the inputs and the outputs of the funding transaction and the scripts for unlocking the inputs and outputs of the funding transaction are shown in FIG. 10B.

[0138] Details of the inputs and the outputs of the funding transaction and the scripts for unlocking the inputs and outputs of the funding transaction are as follows:

[0139] Input 2—Copy of the token details on Hotel's intranet site. Requires the Hotel's signature to be complete

[0140] Output 1—P2SH. Pays 3,000,000 to the hash of the script <script_hash_guest>:

TABLE-US-00014 Script OP_IF <now + 48hrs> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey G> OP_CHECKSIGVERIFY OP_ELSE <PubKey G> <PubKey H> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF

[0141] The locked funds can be claimed by the Guest in 48 hours time if not spent.

[0142] Output 2—P2SH. Pays 3,001,000 to the hash of the script <script_hash_hotel>:

TABLE-US-00015 Script OP_IF <now + 48hrs> OP_CHECKLOCKTIMEVERIFY OP_DROP <PubKey H> OP_CHECKSIGVERIFY OP_ELSE <PubKey G> <PubKey H> OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF

[0143] The locked funds can be claimed by the Hotel in 48 hours time. This is the minimum payment due as per Contract 3 and the value of the token itself [0144] 7. Guest sends Funding Transaction to the Hotel through a form on the intranet site [0145] 8. Hotel checks the Funding Transaction, approves it by signing, and submits it to the blockchain [0146] 9. Hotel provides the Guest the details to access the internet. Alternatively, the token may contain machine executable instructions for automatically enabling and terminating access to the internet. [0147] 10. Guest starts to use the internet. The connection time and download amount is tracked by the router management software [0148] 11. The router management software detects that the connection has been used for 1 min. It sends the Guest a request for payment. Guest creates a Replaceable Transaction which it sends to the Hotel: [0149] Details of the replaceable transaction are shown in FIG. 11A, and details of the inputs and outputs of the transaction and scripts for unlocking inputs and outputs of the replaceable transaction are shown in FIG. 11B.

[0150] Details of the inputs and outputs of the transaction and scripts for unlocking inputs and outputs of the replaceable transaction are as follows:

[0151] Input 1-2—Spends the Funding Transaction outputs. Requires the Hotel's signature to be complete

[0152] Output 1—P2SH. Sends the token back to Hotel. Pays 1,000 to the hash of script <script_hash_token3>

[0153] Output 2—P2PKH. Payment owed to Hotel 3,000,000+25,000/min×1 min

[0154] Output 3—P2PKH. Change back to Guest 6,000,000−payment to Hotel [0155] 12. While the Guest is connected to the internet, the router management software continues to increment the connection timer and sends a payment request for every minute. Guest simply updates Output 2 & 3 of Replaceable Transaction to the latest amount and sends to the Hotel. [0156] 13. At the end of the 2 hours as per Contract 3, the Hotel signs the latest Replaceable Transaction and submits to the blockchain. In total the Guest has used 70 minutes, so Output 2 is 4,750,000 and Output 3 is 1,250,000.

[0157] It will be appreciated by persons skilled in the art that the above embodiment has been described by way of example only and not in any limitative sense, and that various alterations and modifications are possible without departure from the scope of the invention as defined by the appended claims.