Blockchain-based method and system for specifying the recipient of an electronic communication

Abstract

The invention provides a method and corresponding system for controlling a blockchain transaction output and/or specifying the recipient of the output. It also provides a method of controlling and/or generating an electronic communication. The invention is a blockchain-implemented solution, which may or may not be the Bitcoin blockchain. In a preferred embodiment of the invention, the method may comprise the step of sending an electronic notification to a notification address which is provided as metadata within an unlocking script of an input of a transaction (Txi) on a blockchain. The unlocking script is provided in order to spend an output from a further transaction (Tx2) on the blockchain. The input of the transaction (Txi) and/or the output of the further transaction (Tx2) may be associated with a tokenised asset represented on, or referenced via, the blockchain. The notification address may be associated with an asset or resource represented on the blockchain, or a controller of an asset or resource represented on the blockchain. The notification address may be a network address, a cryptographic key, a uniform resource locator (URI), email address or any other address or identifier which can be represented in the metadata of a transaction script and used as a destination for an electronic communication.

Claims

1. An electronic communication or notification method, the method comprising the steps: traversing a blockchain to obtain a notification address provided as metadata within an unlocking script of an input of a transaction (Tx.sub.1) on the blockchain wherein the notification address is an identifier of an off-blockchain destination for an electronic communication; and sending an off-blockchain electronic notification to the notification address.

2. A method according to claim 1, wherein: the unlocking script is arranged and/or provided in order to spend an output from a further transaction (Tx.sub.2) on the blockchain.

3. A method according to claim 1, wherein: the input of the transaction (Tx1) and/or an output of a further transaction (Tx2) is associated with a tokenised asset represented on, or referenced via, the blockchain.

4. A method according to claim 1, wherein: the off-blockchain electronic notification comprises: an incomplete or complete blockchain transaction, and/or information relating to a location of, or means of access to, an incomplete blockchain transaction; and/or information relating to an incomplete or complete blockchain transaction.

5. A method according to claim 1, wherein: the notification address is associated with an asset or resource represented on the blockchain, or a controller of an asset or resource represented on the blockchain.

6. A method according to claim 1, further comprising the step of: traversing the blockchain to identify the transaction (Tx.sub.1) or further transaction (Tx.sub.2).

7. A method according to claim 1, further comprising the step of: submitting a transaction to a blockchain, wherein the transaction (Tx.sub.1) comprises an unspent output (UTXO) which includes a redeem script that requires the provision of a notification address within the metadata of an unlocking script in order to spend an output (UTXO); wherein: the unspent output (UTXO) transfers ownership or control of, or otherwise relates to, a tokenised asset represented on, or referenced via, the blockchain.

8. A method according to claim 1, wherein: the notification address is provided as a parameter in the unlocking script of the transaction (Tx.sub.1).

9. A method according to claim 1, further comprising the step of: using a redeem script to ensure that a notification address has been provided in the unlocking script.

10. A method according to claim 9, wherein the redeem script comprises: a value indicating how many notification addresses must be supplied by the unlocking script.

11. A method according to claim 1, wherein: a plurality of notification addresses is provided within the unlocking script.

12. A method according to claim 1, wherein: the notification address is a cryptographic key, a uniform resource locator (URI), email address or any other address or identifier which can be represented in the metadata of a script and used as a destination for an electronic communication.

13. A method according to claim 1, wherein: at least one step of any preceding is performed by an automated computing resource or agent.

14. A method according to claim 1, further comprising the steps: detecting a designated or predetermined event; and sending the off-blockchain electronic notification in response to detection of the predetermined event.

15. A method according to claim 1, wherein the notification address is provided in addition to a wallet address provided in the unlocking script.

16. A computer-implemented system comprising a processor and memory, the memory storing computer executable instructions, that when executed, cause the processor to: traverse a blockchain to obtain a notification address provided as metadata within an unlocking script of an input of a transaction (Tx.sub.1) on the blockchain, wherein the notification address is an identifier of an off-blockchain destination for an electronic communication; and send an off-blockchain electronic notification to the notification address.

17. A system according to claim 16, wherein the system further comprises: at least one autonomous computing agent arranged and configured to: traverse the blockchain; and/or generate and/or send the off-blockchain electronic notification.

Description

(1) An embodiment of the present invention will now be described, by way of example only, and with reference to the accompany drawings, in which:

(2) FIG. 1 provides an overview of an illustrative embodiment of the invention.

(3) FIG. 2 provides an illustration of the traversal logic which is employed when iterating over the blockchain to determine the current ownership of the asset(s).

(4) FIG. 3 provides an illustration of the transaction output which is required in accordance with an embodiment of the invention.

(5) FIG. 4 provides an illustration of the construction of the initial, incomplete blockchain transaction.

(6) FIG. 5 provides an illustration of the incomplete transaction of FIG. 4 after it has been amended and completed by the asset controller.

(7) FIG. 6 provides an illustration of an embodiment of the invention, in which a notification is sent to the asset controller to inform them that there is an incomplete transaction which needs their attention and modification.

(8) FIG. 7 shows an illustration of a use case model in accordance with an embodiment of the invention.

(9) FIG. 8 provides blockchain transaction number 100.10 which, in relation to the example provided below, could be used to generate shares in the asset represented on the blockchain.

(10) FIG. 9 provides blockchain transaction number 100.120 which, in relation to the example provided below, could be used to issue shares of the asset to a recipient. Note that the notification address is specified as a requirement in the ScriptSig. This forces the recipient (i.e. the asset owner or controller) to provide a notification address as metadata in an unlocking script when “claiming” the shares via an input in a subsequent transaction.

(11) FIG. 10 provides blockchain transaction number 150.10 which could be used to transfer ownership of part of the asset to a recipient. In this case, the current asset controller retains part of the asset and assigns or transfers the other portion to one or more other parties.

(12) FIG. 11 provides incomplete blockchain transaction number 400.1 which could be generated in relation to the example provided below.

(13) FIG. 12 provides blockchain transaction number 400.10 which is the completed version of the incomplete transaction shown in FIG. 11, as modified by the asset controller.

(14) The present invention provides a generic solution that allows the control of secure transfers of digital entities via inputs and outputs of blockchain transactions. In the examples provided herein, the invention is discussed for illustrative purposes in the context of paying income or accrued costs against a blockchain-registered asset according to the terms of an underlying investment contract e.g. in direct proportion to how the ownership of that asset has been split. For example, if an asset has been split into 100 shares, then the income to be paid would be calculated per share.

(15) However, it is important to note that the invention is not limited to such use case scenarios and provides a more generic transfer-control solution and notification solution which can be utilised to advantage in a variety of applications and contexts.

KEY TERMS

(16) This technical specification uses the following terms throughout to define key concepts and components.

(17) TABLE-US-00001 Name Type Asset The asset is an actor that represents something that can apportion ownership to one of more Asset holders in variable amounts. The Asset is both a private key plus an agent as defined below. These amounts can be simple percentages (e.g. 5%) or units (e.g. 100 units). Agent/oracle The ‘agent’ is a software-implemented resource which performs automated actions on behalf of the asset. The agent may be referred to as an “oracle” or a “bot”. Essentially, the agent is a software component which is programmed to implement the terms of the smart contract, respond appropriately to pre-defined triggers, evaluate conditions using inputs from sources which may be off-chain etc. As such agents are known in the art and readily understood by the skilled person, and are not the focus of the present invention, their implementation are not described in detail herein. Asset Holder The asset holder is an actor that represents something that currently holds a proportion of an Asset. The holder may be referred to as a “controller” or “owner” Secondary The secondary asset holder is an actor that represents something that holds a Asset Holder proportion of an Asset which is gained from a transaction other than the original issuance transaction (e.g. the on-sell of the asset). Repository The repository is an actor that represents the entity responsible for the storage (and potentially on-going maintenance) of the Contract document defining the payment schedule associated with the asset. Contract The Contract is the document that contains the formal definition for how to determine the payments, and the schedule associated with the payments for this asset. This is a smart contract, as is known in the art. It may also (depending on the implementation method used) hold detailed of the current ownership of the asset.

(18) As shown herein, the invention provides an automated, secure and robust mechanism which allows at least the following: the ability to determine the current ownership of an asset from a blockchain (such as, for example, the Bitcoin blockchain); the ability to control transmission of electronic communications to unknown parties relevant to the asset; and the ability to pay income generated by the asset in proportion to the current ownership of the asset.

(19) In the latter two cases, this process can used to advantage where the asset maintains a separate database of ownership, or where the ownership is hidden by the blockchain via the use of (payment) addresses.

(20) The invention provides at least two advantageous aspects: 1. The ability to make payments via a blockchain to owners of an asset where the owner remains unknown and anonymous to the asset 2. The ability to notify anonymous owners using information stored within a sequence of blockchain transactions. This aspect is the focus of the present application.

Determining Current Ownership of an Asset Represented on a Blockchain

(21) In order to apportion costs/income against an asset represented on the blockchain, it is essential to be able to determine the current ownership of that asset. There are two mechanisms one could use to achieve this: The ownership can be maintained in a separate register off-chain maintained by the asset (and updated by forcing transfers to be counter-signed by the asset). This mechanism is ideal for regulated assets where formal “Know Your Customer” rules apply. The ownership can be determined by scanning the transactions on the blockchain to dynamically generate the current ownership list. It should be noted that this approach does not determine the ownership per se but rather it identifies the Bitcoin addresses that are responsible for the asset. This may be referred to as the “asset controller”, which may or may not be the actual owner. This blockchain-traversal technique is used by the present invention.

Generating Ownership-Related Actions: E.g. Calculating and Paying Income

(22) In order to pay income from the asset in proportion to the current ownership of the asset: the asset must have the ability to determine the current ownership; the asset must be able to record the total income for a given period; the asset must be capable of dividing the income between the current ownership; the asset must be capable of netting costs from the income; the asset must be capable of holding income where previous costs have not been paid; and the asset must be capable of triggering the payment of the income such to the current asset holders.

(23) This income can be rolled up 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 would allow for pro-rata payment of income with some contracts only allowing payment for a period to the current holder.

Technical Solution

(24) The technical solution provided by the invention provides a mechanism by which the controller of an investment or asset, via an agent and a smart contract, can generate a set of payment transactions to both re-coup its costs or pay income. The solution relies on an automated oracle process (or multiple oracle processes depending on the structure of the underlying contract) being triggered by an off-chain condition. For example, this condition might be a date on which to pay returns. Once this trigger condition trips the oracle will: calculate the total payment amount for the asset as a whole; calculate the individual payments across the current ownership split for the asset based on the payment rules (for example, pro-rata); and create payment transactions for each of the individual asset holders.

(25) FIG. 1 shows the basic flow of how the technical solution determines the individual payments to make.

(26) The steps in the flowchart of FIG. 1 are defined in more detail in the subsequent sections:

(27) TABLE-US-00002 Step Details 1 Find ‘anchor’ transaction This specifies to the oracle the point to start the traversal of the transaction history to determine the current ownership of the assets. The anchor may also be referred to as the “issuance transaction” See section ‘Traversing from the issuance transaction’ for more information. 2 Traverse transaction history to determine current UTXO set This looks for all the “spends” of the assets, starting from the point of issuance, to determine the current unspent output UTXO (which determines the current location/ownership of the assets). See section ‘Traversing from the issuance transaction’ for more information. 3 For each UTXO, create distribution transaction This step simply ensures that steps 3 through 6 are repeated for each UTXO discovered in step 2 above. A ‘raw’ distribution transaction is created and broadcast in an incomplete state (it is missing a key transaction signature). The distribution transaction will ultimately be used to transfer funds to the specified recipient, once the distribution transaction has been completed. See section ‘Creating the distribution payment’ for more information. 4 Broadcast distribution transaction This steps broadcasts the incomplete transaction to interested parties. Since it is known that only the current controller/owner of the asset can complete the transaction and claim the funds (because of the requirements specified in the locking script of the output), this can be published through any open channel. However, it cannot be broadcast through the blockchain itself, for reasons explained below. 5 Asset owner re-directs distribution to their select key This step allows the current asset controller/owner to re-direct the funds from the broadcast transaction to their selected private key. See section ‘Re-directing the distribution payments’ for more details. 6 Distribution transaction published to the blockchain This final step locks the completed and re-directed transaction to the blockchain in the normal manner.

Traversing The Blockchain From the Issuance Transaction

(28) In order to determine the current location (ownership) of the shares within the asset, the relevant oracle needs to be able to traverse the blockchain, starting from the original issuance transaction to determine where the shares of the current asset currently reside. The issuance transaction is referred to as the “anchor transaction” in FIG. 1. FIG. 2 shows a sample chain of transactions which might be used during such a traversal. Essentially, this process involves moving from transaction to transaction on the blockchain, following a trail, until the oracle finds a UTXO relating to the asset. As this output has not been spent, it indicates that the asset controller that spent the last input on the asset must still be the controller. Therefore, the traversal process can halt at this transaction.

(29) Each individual Issue or Transfer transaction output has an associated Redeem Script. From the fact that the transaction output is unspent, the oracle can determine which Redeem Script was used to spend the output from the previous transaction and therefore ‘owns’ which proportion of the asset at any point in time.

Creating the Distribution Payments

(30) By knowing the redeem script, the income distribution transaction can make use of the SIGHASH_NONE capability to allow the output to be redirected, but only in a manner that the controller of the Redeem Script can change. To do this, the distribution transaction needs to be constructed as illustrated in FIG. 3.

(31) The distribution transaction will have two outputs: 1. an output which transfers (re-issues) back to the current controller so that next time the traversal process is performed, the same controller is determined to be the current one; and 2. an output which transfers some electronic funds to the controller.

(32) The re-issuance output can be constructed since it can simply replay (i.e. copy) the Redeem Script hash from the previous issuance/transfer transaction.

(33) However, it is impossible to construct the distribution transaction in one step based on the number of signatures that are required and because, at the point of construction, the locking script for the Income Payment to A cannot be constructed.

(34) To solve this, the distribution transaction is originally constructed and broadcast in the format shown in FIG. 4.

(35) By setting the signature hash on the inputs to SIGHASH_NONE, then either one of the outputs can be changed. However, by locking in the last issuance transaction, only the legitimate owner of the asset can make the change since they are required to sign the input (and would obviously not do so unless it was in their interests). It should be noted that there is no necessity for any signature to be supplied on the Last Asset Issue/Transfer to A Transaction. It is shown in FIG. 4 on the assumption that the asset issuer is a counter-signatory for any transfer transaction; if they are not then this transaction is simply bound using the signature on the Income for Distribution which achieves the same effect.

Re-Directing the Distribution Payments

(36) When the current Asset owner picks up the incomplete, template transaction, they determine that it is in their best interests to complete the transaction which they do by signing the Last Asset Issue/Transfer to A Transaction input after changing the income payment transaction to pay this income to themselves. This amended, complete transaction is illustrated in FIG. 5. As the transaction is now complete it can be mined.

(37) Thus, the outcome has been achieved without there being any requirement for the Asset to know anything about the underlying owner of the asset other than their ownership share that was contained within the blockchain record itself.

The Need For Notification

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

(39) However, the incomplete transaction cannot be broadcast via the blockchain itself. This is because, by default, the blockchain propagation nodes will not propagate incomplete transactions across the network. As the original version of the distribution transaction is incomplete (it is missing a signature), it is unlikely that the controller/owner will be able to pick up the incomplete transaction and apply a signature prior to it being dropped by the network. Whilst this does not impact the ownership of the asset, it does mean that the relevant parties do not get paid the income that they are owed.

(40) To resolve this, there needs to be a channel that can be used to broadcast the incomplete transaction to interested parties (or at least make them aware of its existence and/or location). However,

(41) There are various possible methods to resolve this, including: The contract could publish a ‘broadcast’ channel as part of the contract upon which all incomplete transactions will be broadcast with owners of the assets listening to that channel to determine transactions of interest and reacting to them. This publish/subscribe mechanism is a standard IT feature. Upon sale or other transfer of the asset, the new asset owner/controller locks a notification address into the sale transaction. This enables a communication channel to be set up without any other information being known about the asset owner/controller. The asset will then use this private channel to send the incomplete transaction to the current owner, or notify them that the transaction is available from an accessible location e.g. for download and subsequent completion.

(42) Neither of these solutions impact or affect the first aspect of the invention as described above, in that the asset is still unaware of the ownership of itself other than from information held upon the blockchain itself. In the following example, the transactions make use of the second option for transaction notification. This notification technique forms a second, novel aspect of the invention and offers privacy or anonymity of the transaction information.

Notification Address Embedded Within the Blockchain

(43) This novel and advantageous aspect of the invention provides a solution to the propagation problem identified above by enabling the ability to embed a notification address within the blockchain transaction. The notification address can then be used for subsequent notifications.

(44) The notification can take any suitable form, such as for example an email. In such cases, the email would be sent to the email address that has been embedded in the previous transaction. However, other forms of electronic communications known in the art also fall within the scope of the invention. Essentially, the identifier which is captured in the initial transaction serves as the address or location to which notifications will be sent.

(45) This section explains how this model operates and is the focus of the present application. It should be noted that this notification technique can be used to advantage as a solution to a problem in its own right, and in respect of a wide variety of contexts and applications, independently from the first aspect of the invention described above.

(46) This solution means that a communication can be sent to a recipient without the need for any further information to be supplied or known. The invention therefore provides an enhanced alert, notification or communication technique which preserves or enhances privacy and security. No additional information about the recipient is required other than the address that is provided in, and then extracted from, the transaction script. This lends itself to being implemented by an automated process such as a bot.

(47) Transmission of the notification to the specified address may be triggered by an event. The event may be specified in, or influenced by, a smart contract.

(48) The notification can simply be a signal sent to the address, and/or may contain predetermined content. Thus, a desired, informative message can be transmitted. Additionally or alternatively, receipt of the notification may serve as a signal to an automated process and thus trigger a pre-determined or programmed response e.g. to supply a signature to the transaction, or perform some other action.

(49) The invention is not limited with regard to the content of the notification message that is dispatched to the embedded address. The notification may, in some cases, include a copy of the incomplete transaction. In the present example, though, the role of the notification address is to ensure that the relevant interested actors—which may be a human or computer-based resource—can be notified or alerted to the need to apply their signatures (and make other amendments) to a given target transaction as the author of that target transaction has no other information about them. In effect, then, the invention enables the fulfilment, completion of a future blockchain transaction. Upon provision of the necessary signature(s), the partial, invalid transaction is converted into a viable, valid transaction that can be accepted by the blockchain. Therefore, the invention solves the problem of how to control, facilitate and/or enable the validity of a blockchain transaction and its propagation on a blockchain network.

(50) In order to do this, a ‘seed’ transaction needs to be created that forces the capture of notification address in all subsequent transactions. This would usually be prior to an issuance transaction (for a standard tokenised transaction). This issuance or ‘source’ transaction now requires additional attributes to be supplied on the unlocking script that contain the notification addresses. The full flow of this process is shown in FIG. 6.

Notification Redeem Script

(51) The key format for the unlocking script is as follows:

(52) TABLE-US-00003 <count of notification addresses> <notification address #1> <notification address #2> . . . <notification address #n> <signature #1> . . . <signature #n>

(53) As can be seen from the above structure, the elements shown in the box represent a standard script input, but the prefix is novel. This prefix takes the form shown here:

(54) TABLE-US-00004 OP_DUP OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_ENDIF OP_VERIFY <Script remainder e.g. signature verification>

(55) This particular example means that the <Count of notification addresses> can range from 1 to 4, but the structure can be extended to support a different maximum if required. This script prefix effectively drops the relevant notification addresses from the stack, and then checks to make sure that the number of notification addresses matches the number that should have been there.

Use Case Model

(56) The model provided in FIG. 7 shows the key use cases involved within the non-debt lending model.

[100] Issuance of Shares

(57) The Asset needs to issue shares in itself to the appropriate Asset Holder, ensuring that it captures the notification address for that entity during the issuance. The primary actor in this is the Asset.

(58) Main success scenario:

(59) This step is required only where the current holder's notification details are maintained on the blockchain itself.

(60) TABLE-US-00005 Step Details 100.10 Shares Generated In this step, the Asset splits their stock of BTC into UTXO's of the correct amount for subsequent issuance to an individual Asset Holder (the step performed in 100.20 below). The transaction is made to a pay to script hash address controlled by the Asset but which allows the injection in step 100.20 of the new Asset Holder's notification address. 100.20 Shares Issued In this step, the Asset takes each individual fragment generated in step 100.10 above and issues it to the appropriate Asset Holder locking that holder's notification address into the issuance instruction within a second parameter to the unlocking script.

(61) The Share Generation transaction is shown in FIG. 8 as Transaction 100.10

(62) The full redeem script for Output 1 of transaction 100.10 is shown below.

(63) TABLE-US-00006 OP_DROP OP_CHECKSIG

(64) The Share Issuance transaction is shown in FIG. 9 as Transaction 100.20

(65) The full redeem script for Output 1 of transaction 100.20 is shown below.

(66) TABLE-US-00007 OP_DUP OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_DUP OP_ENDIF OP_IF   OP_1SUB   OP_SWAP   OP_DROP   OP_ENDIF OP_VERIFY OP_CHECKMULTISIG OP_2 <PubK-AssetHolder> <PubK-Asset> OP_2

(67) This example redeem script allows a subsequent on-sell to transfer ownership to up to four buyers. If the purchase relates to more than four buyers, then multiple transactions would be required. It should be noted that it is clearly possible to extend (or restrict) the potential number of new purchasers by repeating (or reducing) the ‘if’ block within the above script.

[150] On-Sell of Shares

(68) The Asset Holder needs to on-sell a proportion of its holdings to another interested party. The primary actor in this is the Asset Holder.

(69) Main success scenario:

(70) TABLE-US-00008 Step Details 150.10 Capture notification address for each purchaser The current asset holder captures the notification address for the new purchaser through any mechanism that they choose. 150.20 Create re-sell transaction template The current asset holder constructs a re-sell transaction and captures the order of the transaction outputs. The order of the created transaction outputs is used to structure the unlocking script as follows: <Number of transaction outputs> Notification Address for TxOut-0> Notification Address for TxOut-1> // if required Notification Address for TxOut-2> // if required Notification Address for TxOut-3> // if required <Sig-AssetHolder> 150.30 Asset counter-signs template transaction The Asset provides the second signature to the re-issuance transaction. 150.40 Transaction published & mined The transaction is then published to the blockchain and subsequently mined into a block.

(71) This creates a number of key features that are necessary to support the underlying income distribution. The sale can only be to a maximum of four new holders (e.g. a four output transaction, but can be any number from 1 to 4). If the sale includes the retention of some of the shares, then only three new holders can be supported since only of the slots is taken for the re-allocation back to the current holder

Transaction 150.10

(72) In example transaction 150.10 provided in FIG. 10, the transaction implements a partial sell with the current asset holder retaining a stake and selling one other stake to a new holder. It should be noted that in a real-world scenario it is possible that an additional input to cover the mining fee may be required. This has been ignored in the template of FIG. 10, transaction 150.10 to improve readability.

(73) The redeem script for output 1 of transaction 150.10 (FIG. 10) is the same as that for transaction 100.20 (FIG. 9) with the exception that the public keys are:

(74) <PubK-SecondaryAssetHolder> and <PubK-Asset>.

(75) This redeem script for output 2 of transaction 150.10 (FIG. 10) is completely identical as that for transaction 100.20 (FIG. 9).

[200] Determination of Ownership

(76) The Asset needs to determine how to allocate the income for payment to the current asset holders even though it is unaware of their identity. The primary actor in this action is the Asset.

(77) Main success scenario:

(78) TABLE-US-00009 Step Details 200.10 Determine Current Asset Allocation In this step, the Asset traverses the pool of UTXOs from their original issuance transaction generated by the asset. Where the original UXTO has been spent (i.e. the asset has been transferred again), then the outputs from this new transaction is checked according to step 200.10. In performing this traversal, the notification address from the ‘spent’ input is recorded. Each original issuance UTXO is traversed until a set of current issuance blocks is determined, plus the notification address and redeem script for that output.

[300] Calculate Payment

(79) Here, the Asset wishes to calculate the amount of income that should be paid to its current owners. The primary actor for this action is the Asset.

(80) Main success scenario:

(81) TABLE-US-00010 Step Details 300.10 The Asset pulls in all the information for the period to calculate the income due. Note: this may be zero. Note: the mechanism used will be specific to the nature of the asset itself and formally defined within the associated contract document. 300.20 The outputs from the preceding step is allocated on a per share basis according to the terms of the contract (for example by dividing the output value with the number of shares in existence). The rounding rules will tend to be defined within the associated contract document but will normally be down for income due. 300.30 The per-unit apportionment derived in step 300.20 is now allocated on a per-holding basis through a simple multiplication using the holding allocation derived in use case 200. 300.40 Use case 400 is now performed for each individual holding identified out of step 300.30

[400] Paying the Income

(82) Here, the Asset wishes to pay income to its owners in proportion to their ownership. The primary actor is the Asset.

(83) Main success scenario:

(84) TABLE-US-00011 Step Details 400.10 The Asset generates a transaction with two transaction inputs and two transaction outputs as shown in FIG. 4. The transaction inputs are: Asset issuance transaction (or last asset re-assignment), signed by the Asset with a SIGHASH_NONE flag set Income distribution amount, signed by the Asset with a SIGHASH_NONE flag set This means that there is a signature missing from the first input and allows anyone to change the outputs of this transaction. However, because of the missing signature, this is effectively changed to a model that say that only the remaining signatory has the practical ability to change the output of the transaction. In turn, this has allowed the Asset to create a payment transaction without knowing where to send the payment, but certain that it will only get collected by the authorised recipient. The transaction outputs are: Transaction income distribution input (less the mining fee) paid to the Asset's public key hash Asset issuance transaction, paid back to the same place as the input. 400.20 Using the notification address for this redeem script (as determined during use case 200), the incomplete transaction is pushed to the current Asset Holder. 400.30 Upon receipt, the Asset Holder changes the destination of the second output to the Asset Holder's public key hash (e.g. paid to themselves) and then provides the second signature to the asset issuance transaction with a standard SIGHASH_ALL flag set. Note that the re-direction of the income distribution output can be to any address that the Asset Holder requires and is not restricted to being their public key hash. 400.40 The Asset Holder then publishes this transaction to the blockchain for it to be accepted and mined.

(85) Transaction 400.10—Interim (Incomplete) transaction is shown in FIG. 11. Transaction 400.10—final (complete transaction) is shown in FIG. 12. In FIG. 12, the amendments are shown in bold for clarity.

Example Scenario: Asset Share Capital

(86) The main type of scenario that is supported by this model is the traditional share capital for an asset such as a company. The company (NewCo plc) will issue a fixed amount of shares (1,000) that can be freely traded, with income paid out on a periodic basis (annually). As the income distribution represents the profit of the company, there is no requirement to support the collection of costs from the asset holder base (profit has already had the costs netted off from them).

Key Benefits of the Invention Include

(87) The invention enables autonomous activity against a blockchain, allowing for entities that are created where income/costs can be paid without having to maintain (except for regulatory reasons) a separate off-chain database of ownership.

(88) The invention enables a notification address or identifier to be embedded within a transaction, and specifically within the script of a transaction.

(89) Thus, the invention provides enhanced privacy, security and communication. It is particularly advantageous in applications relating to the control and recordal of a transfer of assets and/or funds via a blockchain.

(90) It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.