Method and system for controlling transfers through a blockchain

Abstract

The invention provides a method and corresponding system for controlling the generation of a blockchain transaction and / or the recipient of a transaction output. The method comprises the step of identifying at least one transaction (Tx) on a blockchain, the transaction comprising: an unspent transaction output (UTXO) relating to a tokenised asset associated with an asset controller; and an input spending an output of a previous transaction locked by a redeem script hash. For each identified transaction (Tx) an uncompleted blockchain transaction is generated comprising: a first output comprising a copy of the redeem script hash; and a second output which is modifiable such that only the asset controller can specify a recipient for the second output. The uncompleted blockchain transaction is transmitted to the controller of the asset. The uncompleted blockchain transaction is uncompleted due to the lack of a required cryptographic signature. Payment of proceeds relating to the asset can therefore be redirected by the controller to a destination of their choice.

Description

[0001] This application is a divisional of application No. 201780066045.0 (corresponding to PCT International Application No. PCT / IB2017 / 056583), filed on October 24, 2017, the priority date of which is claimed in this application. TECHNICAL FIELD

[0002] The present invention relates generally to distributed ledgers and blockchain technology, and more specifically to systems for implementing automated control of computer-executed processes using blockchain technology. The present invention also relates to electronic communication and notification technology. Embodiments of the present invention provide solutions for recording and controlling ownership or control of electronic assets via a blockchain, and generating and implementing blockchain transactions in response to current ownership data. The present invention also provides novel and advantageous solutions for controlling and implementing transmission of electronic communications to recipients. It utilizes blockchain technology to facilitate storage of recipient addresses or identifiers such that privacy and / or security can be enhanced, and such that recipients can specify and / or alter notification addresses stored on the blockchain.

[0003] In this document, we use the term 'blockchain' to include all forms of electronic, computer-based distributed ledgers, including but not limited to blockchain and transaction chain technology, permissioned and un-permissioned ledgers, shared ledgers, and variants thereof. It should be noted that alternative blockchain implementations and protocols fall within the scope of the present invention. BACKGROUND

[0004] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system made up of blocks, which in turn are made up of transactions. Each transaction includes at least one input and at least one output. Each block contains a hash of the previous block, such that blocks are linked together to create a permanent, unalterable record of all transactions that have been written to the blockchain since its inception. Transactions include small programs, called scripts, embedded into their inputs and outputs, which specify how and by whom the outputs of the transactions can be accessed. These scripts are written using a stack-based scripting language.

[0005] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. The software client installed on the nodes performs this validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, then the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, i) it must be validated by the first node that receives the transaction - if the transaction is validated, then the node relays it to other nodes in the network; and ii) the transaction must be added to a new block being built; and iii) the transaction must be mined, i.e. added to the public ledger of past transactions.

[0006] Digital entrepreneurs have begun to explore the use of both cryptographically secure systems and data that can be stored on a blockchain to implement new systems. It would be highly advantageous if a blockchain could be used for automated tasks and processes. Such a solution would be able to leverage the benefits of a blockchain (e.g. a permanent, tamper-proof record of events, distributed processing, etc.) while being more versatile in its applications.

[0007] One area of current research is the use of blockchains to implement "smart contracts". These smart contracts are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike a traditional contract written in natural language, a smart contract is a machine-executable program comprising rules that can process inputs in order to generate results, which can then cause actions to be performed depending on those results.

[0008] Another area of interest relating to blockchains is the use of 'tokens' to represent and transfer real-world entities through a blockchain. Potentially sensitive or confidential terms can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow reference to real-world items from the blockchain.

[0009] There is a need to register, track and record data relating to smart contracts. For example, it is necessary to record data relating to the owners of assets managed by a smart contract. This is particularly important for smart contracts relating to assets owned by several entities, where ownership is split into several shares. In this case, there is a need to record ownership transfers in a secure manner. It is also important that, for assets and / or income generated and paid from them, the relevant costs can be added. Another important consideration is that it is often desirable to protect the identities of the real-world parties involved.

[0010] In general, holding a tokenized asset on a blockchain means that there is a UTXO (unspent transaction output) assigned to the current asset holder that determines the size of the asset holder's current holding. This is encapsulated in the redeem script required to transfer the asset, and typically takes the following form:

[0011] XOP CHECKMULTISIG (metadata-A metadata-B public key-A) Y

[0012] However, the information kept within the blockchain is not this script, but a hash of the script. This means that the critical public key information is not available for public inspection.

[0013] In some cases, the income distribution is paid via the same tokenized good as the original asset, for example when additional shares of a company are issued as a dividend. In such cases, the unavailability of the public key is not a problem, as the income distribution can simply be paid to the same redeem script hash as the original issuance transaction.

[0014] However, in the more common case where the income distribution is paid as an alternative asset (e.g. a BTC dividend for shares), then the absence of the public key information means that, according to the current state of the art, a separate off-chain database of public keys associated with each issuance transaction must be maintained. While such a solution is obviously workable, it means that there are two systems (the blockchain and the off-chain database) that are maintaining the asset register. This adds complexity to the solution, and the two databases can become out of sync with each other. It also requires additional storage resources.

[0015] There is therefore a need to provide a solution that at least:

[0016] • facilitates or enables control, influence or direction of the secure transfer to anonymous parties through the blockchain

[0017] • removes the need for this second database, and thus the risks it brings, by enabling automatic determination of where the transfer should be made (e.g. where the income should be paid)

[0018] • enables the payment of the income in a way that ensures that only the current asset holder can claim these funds

[0019] • provides a general mechanism to generate actions and technical responses proportional to the current ownership of assets represented and / or referenced via the blockchain (e.g. in response to income generation)

[0020] • uses blockchain transactions to allow secure, automatic transfer of assets, and records those transfers and payments on the blockchain, thus providing benefits such as tamper-proof records of events and data

[0021] • Enabling the protection of the identity of'real world' parties, e.g. asset owners; the solution should enable or facilitate anonymity

[0022] • Providing a solution for implementing and controlling electronic communications that need to be sent to 'unknown' parties SUMMARY

[0023] Such improved solutions have now been devised. The invention provides at least the technical effects discussed above.

[0024] The appended claims define the invention. Thus, according to the invention, a control method and corresponding system can be provided.

[0025] The method can be a method of controlling the transfer of an entity or item, or a part thereof. It can be transferred electronically, preferably over a blockchain. For convenience, the entity or item can be referred to as an asset or a part of an asset, and the entity or item can be represented, tokenized and / or referenced on a blockchain. Additionally or alternatively, it can be a method of controlling the generation of a blockchain transaction. It can provide an automated solution - the operation of which does not require human intervention.

[0026] Additionally or alternatively, it can be described as a method of controlling and / or specifying the recipient of a blockchain transaction output. It can be described as a method of controlling, directing and / or influencing a transfer over a blockchain. The transfer can be related to an asset, or a part of funds, and / or some other resource, over a blockchain. It can be a transfer of control of such an item from an output of one transaction to an input of another transaction. It can be a method of redirecting such a transfer.

[0027] The blockchain transaction can be related to or associated with an asset represented on a blockchain. The asset can be a tokenized asset. The asset can be associated with a (smart) contract.

[0028] The method can comprise the steps of:

[0029] identifying at least one transaction (Tx) on a blockchain, the at least one transaction comprising:

[0030] an unspent transaction output (UTXO) related to a tokenized asset, the tokenized asset being associated with an asset controller; and

[0031] an input that spends an output of a previous transaction locked by a redeem script hash.

[0032] The method can comprise the steps of:

[0033] for each identified transaction (Tx), generating an uncompleted blockchain transaction, the uncompleted blockchain transaction comprising:

[0034] a first output comprising a copy of the redeem script hash; and

[0035] a second output which can be modified so that only the asset controller can specify a recipient for the second output.

[0036] The asset controller can be the owner or some other entity associated with the asset. The asset controller can be a computing resource representing a real-world controller or owner. The computing resource can be an automated agent. The asset can be represented on the blockchain as a token provided within the metadata of a transaction script.

[0037] The recipient can be specified using a cryptographic key.

[0038] The blockchain can be an alternative implementation of an electronic distributed ledger.

[0039] The method can further comprise the steps of:

[0040] sending the uncompleted blockchain transaction to the controller of the asset.

[0041] The uncompleted reason for the uncompleted blockchain transaction can be that a required cryptographic signature is missing.

[0042] The uncompleted transaction can further comprise:

[0043] an input that spends an unspent transaction output (UTXO); and / or

[0044] an input that spends an output of another transaction in order to transfer an amount of value or currency to the asset controller.

[0045] The method can comprise the steps of:

[0046] modifying the second output of the uncompleted transaction to include the cryptographic signature. This step of modifying can be performed by the asset controller.

[0047] The step of identifying at least one transaction (Tx) can involve or comprise traversing the blockchain to reach a blockchain transaction that includes an unspent output (UTXO) associated with the asset.

[0048] At least one step of the method can be performed by an autonomous computing agent.

[0049] The method can further comprise the steps of:

[0050] Completing and / or modifying the uncompleted transaction by specifying a recipient for the second output. Additionally or alternatively, it can comprise the step of submitting the completed transaction to the blockchain.

[0051] The uncompleted transaction can be arranged such that the output can be modified. The uncompleted transaction can comprise a signature type that requires signing of all inputs and no signing of all outputs. The signature type can be a SIGHASH_NONE signature type or a functional equivalent thereof in another blockchain protocol, such that the signature type facilitates or enables modification of the transaction output.

[0052] The method can further comprise the steps of:

[0053] spending an unspent transaction output (UTXO) to transfer the tokenised asset to an address of the recipient.

[0054] The method can further comprise the steps of:

[0055] spending an output of a previous transaction to transfer or reissue ownership of the asset.

[0056] The quantity associated with the second output can be calculated by the computing resource in accordance with rules provided in the smart contract.

[0057] The second output of the uncompleted transaction can, when spent, transfer a quantity of currency or value to the recipient. The currency or value can be any type of resource. For example, it can be some tokenised funds or other commodity.

[0058] The invention also provides a corresponding system. The system can be arranged to perform the steps of any of the claims.

[0059] The system can comprise:

[0060] a blockchain;

[0061] at least one autonomous computing agent arranged and configured to:

[0062] traverse the blockchain; and / or

[0063] generate the uncompleted transaction; and / or

[0064] send the uncompleted transaction to the recipient.

[0065] Additionally or alternatively, the invention can comprise one or more steps arranged to control, direct or influence the transmission of electronic communications. The method of the invention can therefore be described as a method of establishing an electronic communications channel between two or more parties.

[0066] Additionally or alternatively, the invention can be configured to facilitate and / or enable the completion of an uncompleted blockchain transaction. The invention can therefore be described as a method of controlling or influencing the validity and / or propagation of a blockchain transaction on a blockchain network.

[0067] In this document, the terms "communication", "notification" and "alert" are used interchangeably.

[0068] The present invention can therefore provide a method of controlling and / or generating electronic communications. Additionally or alternatively, the present invention can provide a solution for determining a destination or recipient of an electronic communication / transfer. It can be a blockchain-implemented solution. The present invention can be a method / system arranged to enable (electronic, off-blockchain) communication with an anonymous or pseudo-anonymous recipient. This recipient may, for example, be an asset owner or controller, although the present invention is not limited in this respect. The communication can be sent using information stored or "embedded" within a sequence of blockchain transactions. The present invention can be described as a method of specifying and / or determining a destination of an electronic communication via a blockchain.

[0069] The method can comprise the step of sending a signal to an address. This address can be a notification address. The signal can be referred to or function as an (electronic) notification or communication.

[0070] The present invention is not limited in respect of the context, purpose or content of the notification.

[0071] The notification can be provided as metadata within an unlocking script associated with an input of a transaction (Tx1) on a blockchain. The term "identifier" can be used interchangeably with the term "address". This step of transmission can be triggered by an event. The event can be specified, determined or influenced by a smart contract. The transmission (sending) of the notification can be performed by a computer-based resource. It can be performed as at least partially automated processing.

[0072] The notification can function as a request and / or trigger for completing an uncompleted transaction. The method can comprise the step of completing an uncompleted transaction. The completion can comprise providing a cryptographic signature.

[0073] An unlocking script can be provided so as to spend an output from another transaction (Tx2) on the blockchain. (In the sense that an input of the transaction Tx1 can spend an output of the transaction Tx2, this can be a "preceding" transaction on the blockchain).

[0074] The present invention can therefore comprise the step of requiring a notification address to be provided in an unlocking script so as to unlock a locking script. This step can be repeated. A series of notification addresses can therefore be required and supplied. A notification address can be required so as to spend each output in a chain of blockchain transactions. This allows different addresses to be provided over time. The present invention therefore enables and facilitates a change of recipient address for a notification.

[0075] An input of the transaction (Tx1) and / or an output of the other transaction (Tx2) can be associated with a tokenised asset represented on or referenced via the blockchain.

[0076] The electronic notification can comprise:

[0077] an uncompleted blockchain transaction or a completed blockchain transaction, and / or

[0078] information relating to the uncompleted blockchain transaction or the completed blockchain transaction.

[0079] In the sense that it is missing required data, it can be uncompleted.

[0080] It can include information relating to the location of the completed transaction / uncompleted transaction or how to access it.

[0081] The notification address can be associated with an asset or resource represented on a blockchain or a controller of an asset or resource represented on the blockchain. The controller can be the same or a different entity to the actual ("real world") owner of the asset.

[0082] The method can further comprise the steps of:

[0083] traversing the blockchain to identify the transaction (Tx1) or another transaction (Tx2). The skilled person will understand how to perform this traversal in accordance with known techniques.

[0084] The method can comprise the steps of:

[0085] submitting a transaction to a blockchain, wherein the transaction (Tx1) comprises an unspent output (UTXO) comprising a redeem script requiring a notification address to be provided within the metadata of the unlocking script in order to spend the output (UTXO).

[0086] The unspent output (UTXO) can transfer ownership of or otherwise be associated with a tokenised asset represented on or referenced via the blockchain.

[0087] The notification address can be provided as a parameter in the unlocking script of the transaction (Tx1). It can be provided as a second parameter.

[0088] The method can comprise the step of using a redeem script to ensure that a notification address has been provided in the unlocking script. The redeem script can comprise a value indicating the number of notification addresses that must be supplied by the unlocking script.

[0089] A plurality of notification addresses can be provided within the unlocking script.

[0090] The notification address can be a network address, a cryptographic key, a uniform resource identifier (URI), an email address or any other address or identifier that can be represented in the metadata of the script and used as a destination for electronic communications. Thus, the notification address can act as an identifier of the recipient of the notification / communication.

[0091] At least one step of the method can be performed by an automated computing resource or agent. This can be referred to as a "bot" or "oracle".

[0092] The method and / or system can be substantially as described below in the section entitled "Notified address embedded within a blockchain".

[0093] The invention can also provide a computer-implemented system arranged and configured to perform the steps of any embodiment of the method described herein.

[0094] The system can comprise:

[0095] a blockchain;

[0096] at least one autonomous computing agent arranged and configured to:

[0097] traverse the blockchain; and / or

[0098] generate and / or send an electronic notification.

[0099] Any feature described with respect to the method can be applicable to the system, and vice versa. Any feature described above in relation to one embodiment or aspect can be present in any other embodiment or aspect of the invention. BRIEF DESCRIPTION OF DRAWINGS

[0100] The invention can be substantially as described in the illustrative embodiments described in the following examples, description and drawings. These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described herein, and illustrated in the accompanying drawings.

[0101] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

[0102] Figure 1 An overview of an exemplary embodiment of the invention is provided.

[0103] Figure 2 A diagram of the traversal logic employed in determining the current ownership of an asset when iterating over a blockchain is provided.

[0104] Figure 3 A diagram of the transaction outputs required in accordance with an embodiment of the invention is provided.

[0105] Figure 4 A diagram of the construction of an initial, uncompleted blockchain transaction is provided.

[0106] Figure 5 A diagram of the uncompleted transaction of Figure 4 after it has been amended and completed by an asset controller is provided.

[0107] Figure 6 A diagram is provided of an embodiment of the present invention in which a notification is sent to an asset controller to notify them of an outstanding transaction that requires their attention and modification.

[0108] Figure 7 A diagram is shown of a use case model according to an embodiment of the present invention.

[0109] Figure 8 A blockchain transaction number 100.10 is provided, which can be used in connection with the example provided below, to generate a share in an asset represented on a blockchain.

[0110] Figure 9 A blockchain transaction number 100.120 is provided, which can be used in connection with the example provided below, to issue a share of an asset to a recipient. Note that the notification address is specified as a requirement in ScriptSig. This forces the recipient (i.e. the asset owner or controller) to provide the notification address as metadata in the unlocking script when “claiming” the share via an input in a subsequent transaction.

[0111] Figure 10 A blockchain transaction number 150.10 is provided, which can be used to transfer ownership of a portion of an asset to a recipient. In this case, the current asset controller retains a portion of the asset and assigns or transfers another portion to one or more other parties.

[0112] Figure 11 An outstanding blockchain transaction number 400.1 is provided, which can be generated in connection with the example provided below.

[0113] Figure 12 A blockchain transaction number 400.10 is provided, which is a completed version of the outstanding transaction shown in Figure 11 as modified by the asset controller. DETAILED DESCRIPTION

[0114] The present invention provides a general solution that allows for the secure transfer of digital entities via inputs and outputs of blockchain transactions. In the examples provided herein, the invention is discussed in the context of a blockchain-registered asset paying out income or accrual costs in accordance with the terms of an underlying investment contract, for illustrative purposes only, e.g. in proportion to how ownership of the asset is distributed. For example, if an asset has been split into 100 shares, then the income to be paid out will be calculated per share.

[0115] However, it is important to note that the present invention is not limited to this use case scenario, and provides a more general transfer control solution and notification solution that can be used in a variety of applications and contexts.

[0116] Key terms

[0117] The present technical specification uses the following terms throughout to define key concepts and components.

[0118]

[0119] As shown herein, the present invention provides an automatic, secure and robust mechanism that allows at least the following:

[0120] - the ability to determine the current ownership of an asset from the blockchain;

[0121] - the ability to control the transmission of electronic communications with unknown parties related to the asset; and

[0122] - the ability to pay income generated from the asset proportionally to the current asset ownership.

[0123] In the latter two cases, this process can be advantageously used in cases where the asset maintains a separate ownership database, or where the ownership is hidden by the blockchain through the use of (payment) addresses.

[0124] The present invention provides at least two advantageous aspects:

[0125] 1. the ability to make payments to the asset owner via the blockchain, where the owner remains unknown and anonymous to the asset;

[0126] 2. the ability to notify anonymous owners using information stored in the sequence of blockchain transactions.

[0127] Determining current ownership of assets represented on a blockchain

[0128] To apportion costs / income for assets represented on the blockchain, it is necessary to be able to determine the current ownership of said assets. There are two mechanisms that can be used to achieve this:

[0129] - Ownership can be maintained outside of the separate register chain maintained by the asset (and updated by re-signing by the asset with a forced transfer). This mechanism is ideal for managed assets where formal "know your customer" rules apply.

[0130] - Ownership can be determined by dynamically generating a list of current owners by scanning transactions on the blockchain. It should be noted that this method does not determine ownership itself, but rather identifies the address responsible for the asset. This can be referred to as the "asset controller", which can or can not be the actual owner. The present invention uses this blockchain traversal technique.

[0131] Generating actions related to ownership: e.g. calculating and paying out revenue

[0132] To pay income from the asset proportionally to the current ownership of the asset:

[0133] - the asset must have the ability to determine the current ownership;

[0134] - the asset must be able to record the total revenue for a given period;

[0135] - the asset must be able to split the revenue between the current owners;

[0136] - the asset must be able to deduct costs from the revenue;

[0137] - the asset must be able to hold the revenue without paying previous costs; and

[0138] - the asset must be able to trigger the payment of the revenue to the current asset holder.

[0139] This revenue can be aggregated at the end of a time period (e.g. every six months) or as it is generated (e.g. immediately). Depending on the nature of the contract, the same conditions will allow for the payment of the revenue proportionally, while some contracts will only allow for the payment to the current holder for a period of time.

[0140] Technical solution

[0141] The technical solution provided by the present invention provides a mechanism by which the controller of an investment or asset can generate a set of payment transactions via agents and smart contracts to recover its costs or pay out revenue. The solution relies on an automated oracle process (or multiple oracle processes, depending on the structure of the underlying contract) that is triggered by off-chain conditions. By way of example, this condition can be the date of payment return. Once this trigger condition is met, the oracle process will:

[0142] • calculate the total payment amount for the entire asset;

[0143] • calculate individual payments in the current ownership distribution of the asset based on the payment rules (e.g. proportionally); and

[0144] • create a payment transaction for each of the individual asset holders.

[0145] Figure 1 The basic flow of how the technical solution determines the individual payments to be made is illustrated.

[0146] Figure 1 The steps in the flowchart of

[0147]

[0148] Traversing a blockchain from an issuance transaction

[0149] To determine the current location (ownership) of a share within an asset, the relevant oracle process needs to be able to traverse the blockchain from the original issuance transaction to determine where the share in the current asset is currently located. The issuance transaction is referred to as the "anchor transaction" in Figure 1 . Figure 2 A sample chain of transactions that can be used during such a traversal is shown. Essentially, this process involves moving along a path on the blockchain from transaction to transaction until the oracle process finds a UTXO that is relevant to the asset. Since this output has not yet been spent, it indicates that the controller of the asset that last spent on the asset must still be the controller. The traversal process can therefore stop at this transaction.

[0150] Each individual issuance or transfer transaction has an associated redeem script associated with it. Based on the fact that the transaction output has not been spent, the oracle process can determine which redeem script was used to spend the output of the previous transaction, and therefore determine the proportion of the asset that is 'owned' at any point in time.

[0151] Creating an allocation payment

[0152] By knowing the redeem script, the revenue distribution transaction can make use of the SIGHASH_NONE capability to allow the output to be redirected, but only in a way that the controller of the redeem script can change. To do this, the distribution transaction needs to be constructed as shown in Figure 3 .

[0153] The distribution transaction will have two outputs:

[0154] 1. A transfer (re-issuance) back to the current controller, so that the same controller is determined to be the current controller when the traversal process is next performed; and

[0155] 2. A transfer of some electronic funds to the controller.

[0156] The re-issuance output can be constructed since it can simply replay (i.e. copy) the redeem script hash from the previous issue / transfer transaction.

[0157] However, the distribution transaction cannot be constructed in one step based on the number of signatures required, since at the point of construction, the locking script for the revenue payment to A cannot be constructed.

[0158] To solve this problem, the distribution transaction is initially constructed and broadcast in the format shown in Figure 4 .

[0159] By setting the signature hash on the input to SIGHASH_NONE, any of the outputs can then be changed. (Note: the point is that the outputs are set to be modifiable.) However, by locking the last issuance transaction, only the rightful owner of the asset can make the change, as it requires signing the input (which obviously won't do unless it is in its interest to do so). Note that there is no need to supply any signature at the time of the last asset issuance / transfer transaction to A. As Figure 4 shown, assume that the asset issuer is the corresponding signer of any transfer transaction; if not, this transaction is only bound using the signature on the income distribution, achieving the same effect.

[0160] Redirecting an allocation payment

[0161] When the current asset owner elects to complete the template transaction, they determine that it is in their best interest to do so by signing the last asset issuance / transfer transaction input to A after changing the income payment transaction to pay this income to themselves. This revised completed transaction is as Figure 5 shown. Since the transaction is now complete, it can be mined.

[0162] Thus, the result has been achieved without requiring the asset to know anything about the underlying owner of the asset other than the share of ownership contained in the blockchain record itself.

[0163] The need for notifications

[0164] As described above, the payment distribution transaction is initially created in an incomplete form. It then needs to be communicated to the asset controller in some way so that they are aware of its existence and can make the necessary modifications to complete it and submit it to the blockchain.

[0165] However, incomplete transactions cannot be broadcast via the blockchain itself. This is because, by default, blockchain propagation nodes do not propagate incomplete transactions on the network. Since the original version of the distribution transaction is incomplete (it is missing a signature), it is unlikely that the controller / owner will pick up the incomplete transaction and apply the signature before it is discarded by the network. While this does not affect the ownership of the asset, it does mean that the relevant parties do not get the income they are due.

[0166] Thus, there is a technical problem that needs to be overcome, namely how to communicate an incomplete blockchain transaction (Tx) (or the fact of its existence) to a recipient where the identity and / or other information of the recipient is not known. To solve this problem, there needs to be a channel available to broadcast the incomplete transaction to the relevant parties, or at least make them aware of its existence and / or location.

[0167] There are various possible ways to solve this problem, including:

[0168] • The contract can publish a 'broadcast' channel as part of the contract, all outstanding transactions will be broadcast with the owners of the assets listening to the channel to determine transactions of interest and react to them. This publish / subscribe mechanism is a standard IT feature.

[0169] • On sale or other transfer of an asset, the new asset owner / controller will lock a notification address to the sale transaction. This enables a communication channel to be established without needing to know any other information about the asset owner / controller. The asset will then use this private channel to send outstanding transactions to the current owner, or inform them that the transaction is available from an accessible location, such as for download and subsequent completion.

[0170] These solutions do not impinge or impact the first aspect of the invention as described above, in that the asset remains unaware of its own ownership, other than information held on the blockchain itself. In the following example, the transaction makes use of the second option for transaction notification. This notification technique forms a second novel aspect of the invention and provides privacy or anonymity of transaction information.

[0171] A notification address embedded within a blockchain

[0172] This aspect of the invention provides a solution to the above propagation problem by enabling a notification address to be embedded in a blockchain transaction. The notification address can then be used for subsequent notification. This section describes how this model operates.

[0173] The notification can take any suitable form, such as an email. In such a case, the email will be sent to the email address that has been embedded in the previous transaction. However, other forms of electronic communication known in the art also fall within the scope of the invention. Essentially, the identifier captured in the initial transaction acts as an address or location to which a notification will be sent.

[0174] It should be noted that this notification technique can independently be of benefit in solving the technical problem independently of the first aspect of the invention described above, and can be used in a variety of contexts and applications.

[0175] However, in this example, the role of the notification address is to ensure that the relevant interested participant can be notified to apply their signature (and make other modifications) to a given target transaction, as the author of that target transaction has no other information about the signature.

[0176] This solution means that a communication can be sent to a recipient without the need to provide or know any other information. Thus, the invention provides an enhanced alert, notification or communication technology that preserves or enhances privacy and security. No additional information about the recipient is required other than the address provided in and then extracted from the transaction script. This facilitates implementation by automated processes such as bots.

[0177] The transmission of the notification to the specified address can be triggered by an event. The event can be specified in or influenced by a smart contract.

[0178] The notification can simply be a signal sent to the address and / or can contain predetermined content. Thus, a desired, informative message can be sent. Additionally or alternatively, the receipt of the notification can be used as a signal for an automated process and thus trigger a predetermined or programmed response, for example to provide a signature for a transaction or to perform some other operation.

[0179] The invention does not limit the content of the notification message that is scheduled to the embedded address. In some cases, the notification can comprise a copy of an uncompleted transaction. However, in this example, the role of the notification address is to ensure that the relevant interested participant (which can be a human or computer-based resource) can be notified or alerted that their signature needs to be applied to a given transaction (and other modifications made) as the author of the target transaction has no other information about them. Then, in effect, the invention enables, completes a future blockchain transaction. After the necessary signatures are provided, the partially invalid transaction is converted into a viable valid transaction that can be received by the blockchain. Thus, the invention addresses the problem of how to control, facilitate and / or enable the validity of blockchain transactions and their propagation on the blockchain network.

[0180] To do this, a'seed' transaction needs to be created that forces the capture of the notification address in all subsequent transactions. This is typically done prior to the issuance transaction (for a standard tokenisation transaction). This issuance or'source' transaction now needs to provide other properties on the unlocking script that contains the notification address. The full flow of this process is shown in Figure 6 .

[0181] A notification redeem script

[0182] The key format of the unlocking script is as follows:

[0183] Count of notification addresses

[0184] Notification address #1

[0185] Notification address #2

[0186] …

[0187] Notification address #n

[0188]

[0189] From the above structure, it can be seen that the elements shown in the box represent standard script inputs, but the prefix is novel. This prefix takes the form shown here:

[0190]

[0191]

[0192] This particular instance implies that the <count of notification addresses> can be in the range 1 to 4, but the structure can be extended to support different maximum values if required. This script prefix effectively discards the relevant notification addresses from the stack, and then checks to ensure that the number of notification addresses matches the number that should be present.

[0193] Use case model

[0194] The model provided in the shows the key use cases involved in the non-debt lending model. Figure 7

[0195]

[100] Issuance of shares The asset needs to issue shares to the appropriate asset holder, ensuring that it captures the notification addresses of the entity during the issuance. The main actor in this regard is the asset.

[0196] Main success scenarios:

[0197] This step is only required if the notification details of the current holder are maintained on the blockchain itself.

[0198]

[0199] The share generation transaction is shown in as transaction 100.10

[0200] Figure 8 The complete redeem script for output 1 of transaction 100.10 is shown below.

[0201] The complete redeem script for output 1 of transaction 100.10 is shown below.

[0202]

[0203] The share issuance transaction is shown in as transaction 100.20 Figure 9 The complete redeem script for output 1 of transaction 100.20 is shown below.

[0204] The complete redeem script for output 1 of transaction 100.20 is shown below.

[0205]

[0206]

[0207] This example redeem script allows for a subsequent sale to transfer ownership to up to four new buyers. If the purchase involves more than four buyers, multiple transactions are required. Note that it is obviously possible to extend (or limit) the potential number of new buyers by repeating (or reducing) the 'if' block in the script above.

[0208]

[150] Sale of shares

[0209] The asset holder needs to sell a portion of their holdings to another party. The primary actor in this regard is the asset holder.

[0210] Primary success scenarios:

[0211]

[0212] This creates many of the key features necessary to support a basic income distribution.

[0213] • There can be a maximum of four new holders (e.g. four output transactions, but could be any number between 1 and 4).

[0214] • If the sale includes a retained portion, only three new holders can be supported as only one position is reassigned back to the current holder.

[0215] Transaction 150.10

[0216] In the example transaction 150.10 provided in Figure 10 , the transaction implements a partial sale where the current asset holder retains ownership and sells one other ownership to a new holder. In Figure 10 , this is ignored in the template for transaction 150.10 to improve readability.

[0217] The redeem script for output 1 of transaction 150.10 ( Figure 10 ) is essentially the same as the redeem script for transaction 100.20 ( Figure 9 ) with the exception that the public key is:

[0218] <pubk-secondaryassetholder>and <pubk-asset>.

[0219] The output 2 of transaction 150.10( Figure 10 ) is redeemed with this redeem script. Figure 9

[0220]

[200] Determination of ownership The asset needs to determine how to distribute the payment income to the current asset holders, even without knowing their identity. The main actor in this action is the asset.

[0221] Main success scenario:

[0222]

[0223]

[0224]

[300] Calculation of payments

[0225] Here, the asset wants to calculate the amount of income that should be paid to its current owners. The main actor of this action is the asset.

[0226] Main success scenario:

[0227]

[0228]

[400] Payment of revenue

[0229] Here, the asset wants to pay the income to its owners in proportion to their ownership. The main actor is the asset.

[0230] Main success scenario:

[0231]

[0232] Transaction 400.10 (intermediate (incomplete) transaction) is shown in Figure 11 Transaction 400.10 (final (completed transaction)) is shown in Figure 12 In Figure 12 , the modifications are shown in bold for clarity.

[0233] Example scenario: asset equity

[0234] The main scenario type supported by this model is traditional equity of an asset, e.g. a company. The company (NewCo plc) will issue a fixed number of shares (1,000) that are freely tradable, and will pay income periodically (every year). Since the income distribution represents the profits of the company, there is no need to support the collection of costs from asset holders (profits already have costs deducted from them).

[0235] Key benefits of the invention include: ​

[0236] The present invention enables autonomous activity with respect to a blockchain, allowing entities created in circumstances where income / costs can be paid, without having to maintain (except for regulatory reasons) separate off-chain databases of ownership.

[0237] The present invention enables a notification address or identifier to be embedded in a transaction, and in particular, within the script of a transaction.

[0238] The present invention therefore provides enhanced privacy, security and communication. It is particularly advantageous in applications involving control and recordation of asset and / or funds transfers via a blockchain.

[0239] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in any claim or specification. In the present specification, the word "comprising" means "including or comprising". A singular reference of an element does not exclude the presence of plural elements. A reference to an element by the indefinite article "a" does not exclude the presence of two or more such elements. The invention can be implemented by means of both hardware and software, and any combination thereof. In a device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. An apparatus for controlling transfers via a blockchain, the apparatus comprising: identifying means for identifying at least one transaction on a blockchain, the at least one transaction comprising: an unspent transaction output relating to an asset, the asset being represented via the blockchain and being associated with an asset controller; and an input spending an output of a previous transaction locked by a redeem script hash; generating means for, for each identified transaction, generating an uncompleted blockchain transaction, the uncompleted blockchain transaction comprising: a first output comprising a copy of the redeem script hash; and a second output, the second output being modifiable such that only the asset controller can specify a recipient for the second output; and broadcasting the uncompleted blockchain transaction to a channel.

2. The apparatus of claim 1, further comprising: sending means for sending the uncompleted blockchain transaction to the asset controller.

3. The apparatus of claim 1 or 2, wherein: the uncompleted blockchain transaction is uncompleted because it lacks a required cryptographic signature.

4. The apparatus of claim 1, wherein: the uncompleted transaction further comprises: an input spending the unspent transaction output; and / or an input spending an output of a further transaction in order to transfer an amount of value or currency to the asset controller.

5. The apparatus of claim 1, further comprising: modifying means for modifying the second output of the uncompleted transaction to include a cryptographic signature.

6. The apparatus of claim 1, wherein: identifying the at least one transaction involves traversing the blockchain to reach a blockchain transaction comprising an unspent output relating to the asset.

7. The apparatus of claim 1, wherein, the apparatus is an autonomous computing agent.

8. A system for controlling transfers via a blockchain, comprising: a processor; and a memory for storing instructions executable by the processor, wherein the processor is configured to execute the instructions stored in the memory to perform a method for controlling transfers via a blockchain, the system being configured to: identify at least one transaction on a blockchain, the at least one transaction comprising: an unspent transaction output relating to an asset, the asset being represented via the blockchain and being associated with an asset controller; and an input spending an output of a previous transaction locked by a redeem script hash; for each identified transaction, generate an uncompleted blockchain transaction, the uncompleted blockchain transaction comprising: a first output comprising a copy of the redeem script hash; and a second output, the second output being modifiable such that only the asset controller can specify a recipient for the second output; and broadcast the uncompleted blockchain transaction to a channel.

9. A computer readable storage medium having stored thereon a computer program, which, when executed by a computer, causes the computer to perform a method for controlling transfers via a blockchain, the method comprising the steps of: identifying at least one transaction on a blockchain, the at least one transaction comprising: an unspent transaction output relating to an asset, the asset being represented via the blockchain and being associated with an asset controller; and an input spending an output of a previous transaction locked by a redeem script hash; ​ For each identified transaction, generating an uncompleted blockchain transaction, the uncompleted blockchain transaction comprising: a first output comprising a copy of the redeem script hash; and a second output, the second output being modifiable such that only the asset controller can specify a recipient for the second output; and broadcasting the uncompleted blockchain transaction to the channel.

Images