TECHNICAL FIELD

[0001] The present disclosure relates to methods and systems for recording linked event data and, in particular, methods and systems for compactly and immutably recording data to enable recovery and verification of linked event data.

BACKGROUND

[0002] In many situations, a custodial entity, such as a financial institution, retailer, government entity, or service provider, may obtain or collect event-related data regarding another entity, such as an individual, corporation, or other entity. That event-related data may include a set or collection of consecutive or linked events relating to the entity or an account or the like associated with the entity. The custodial entity may be obliged, by contract or regulation, to maintain accurate and complete records of those events.

[0003] At the same time, the information relating to an entities events may be highly confidential. For instance, an individual’s health records and information regarding their interactions with health providers or pharmaceutical prescriptions may be private and sensitive. Likewise, records of financial transactions, records of travel or movement, and other such records may be private and confidential. Accordingly, the custodial entity must take care to guard against disclosure of event records.

[0004] There may arise situations in which a set of event records must be audited or investigated. Because the storage and maintenance of those records is entrusted to a private or public custodial entity and those records are confidential, it is difficult to determine whether they are accurate or have been tampered with. It would be advantageous to provide for a system and method of recording verifiable linked event data and, in particular, one which minimizes or reduced the storage cost and delay associated with storing such records in a private yet immutable and auditable form.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application and in which:

[0006] FIG. 1 shows a simplified example system for recording linked event records;

[0007] FIG. 2 illustrates an example chain of event hashes;

[0008] FIG. 3 illustrates a second example chain of event hashes;

[0009] FIG. 4 illustrates an example event hash tree;

[0010] FIG. 5 shows, in flowchart form, one example method of recording linked event records; and

[0011] FIG. 6 shows, in flowchart form, another example method of recording linked event records.

[0012] Like reference numerals are used in the drawings to denote like elements and features.

DETAILED DESCRIPTION OF EXAMPLES

[0013] In one aspect, there may be provided a computer-implemented method of confidentially recording verifiable immutable event data. The method may include hashing, by a first custodial computing system, a first preimage to produce a first hash, the first preimage including a first identifier and first event metadata. It may further include securely storing the first preimage in association with the first hash in a private database at the first custodial computing system; publicly recording the first hash on a blockchain in a first transaction that includes an output unlockable by the first custodial computing system; and, in response to receiving data regarding a second event including the first identifier, determining that the output of the first transaction is unspent. On the basis that the output is unspent, the method includes hashing a second preimage to produce a second hash, wherein the second preimage includes the first identifier, second event metadata, and the first hash; securely storing the second preimage in association with the second hash in the private database; and publicly recording the second hash on the blockchain in a second transaction.

[0014] In some implementations, the method may further include generating the first preimage by concatenating the first identifier and the first event metadata, and generating the second preimage by concatenating the first identifier, the second event metadata, and the first hash.

[0015] In some implementations, the first custodial computing system stores a first custodial identifier, and first preimage and the second preimage include the first custodial identifier. In some cases, the second event corresponds to a transfer event involving a resource transfer from the first identifier to a second identifier, the second preimage further includes the second identifier, a second custodial identifier associated with the second identifier, and a resource value relating to the resource transfer.

[0016] In some implementations, the method includes first receiving data regarding a first event including the first identifier and determining that the private database does not contain records associated with the first identifier before producing the first hash.

[0017] In some implementations, the method further includes, after receiving the data regarding the second event, searching the private database to identify a most-recent previous event associated with the first identifier; and identifying the first hash and the first preimage as relating to the most-recent previous event associated with the first identifier. [0018] In some implementations, the second transaction is not publicly linked to the first transaction on the blockchain.

[0019] In some implementations, the publicly recording the second hash further includes spending the output of the first transaction in a spend transaction. In some cases, spending the output includes transferring a nominal value to an address associated with the first custodial computing system. In some cases, the spend transaction is a separate transaction not publicly linked to the second transaction. In some cases, the second transaction and the spend transaction are implemented within a single batch transaction containing a plurality of spending operations and a plurality of event hash recordal operations.

[0020] In some implementations, the first identifier includes a first digital identifier recorded with and signed by a certificate authority.

[0021] In some implementations, the method may further include receiving data regarding a third event including the first identifier, determining that an output of the second transaction is unspent and, on that basis, hashing a third preimage to produce a third hash, wherein the third preimage includes the first identifier, third event metadata, and the second hash; securely storing the third preimage in association with the third hash in the private database; and publicly recording the third hash on the blockchain in a third transaction.

[0022] In another aspect, there may be provided a computing device including one or more processors, memory and computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processors to carry out the operations of one or more of the methods described herein.

[0023] In yet another aspect, there may be provided a computer-readable medium storing processor-executable instructions, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processors to carry out at least one of the methods described herein. [0024] Other example embodiments of the present disclosure will be apparent to those of ordinary skill in the art from a review of the following detailed description in conjunction with the drawings.

[0025] In the present application, the term “and/or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

[0026] In the present application, the phrase “at least one of... or...” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

[0027] Many situations arise in which a computing system is required to store records of events and those records are to be available in case of auditing or investigation. The need to audit or investigate may be imposed by regulation or contractual requirement. In such situations, the computing system may be structured so as to retain event records and linkages between event records. This can arise, for example, in the case of financial transactions, such as with regard to a particular individual person, or a particular account, or a particular company. The events may reflect changes in an account or transactions involving an account or an account holder. In some cases, it may arise in the context of the health system, such as with regard to medical records. The events on that case may involve records of interactions with health providers and/or pharmaceutical providers. In could arise in the case of academic endeavours, such as with regard to a particular student’s academic results or records, where events may involve event records in connection with a course or an academic institution, such as test results, submitted assignments, or the like. It may arise in connection with travel, such as records of events like border crossings, travel visas granted, records of flights, or the like.

[0028] In many situations, the data being recorded may be private or sensitive data. For example, financial data, personal health data, travel records, and/or academic results are usually sensitive confidential information that needs to be stored securely to protect from malicious or inadvertent public disclosure. A custodial entity that stores event records may therefore store the records in a secure private database. However, trusting a custodial entity to store the records involves the possibility that the custodial entity might subsequently alter the event records or linkages between events. Accordingly, it may be very difficult for a third party regulator, for example, to verify authenticity and originality of records created and maintained privately by a custodian regarding a linked chain of events.

[0029] The custodial entity could record the event data on a public blockchain, but recording the data publicly creates privacy problems. Even if the event data were to be obscured in some manner, linkages between events reveal data regarding the events and/or the person involved in the events.

[0030] The present application provides for methods and system of recording verifiable linked event data in a format that protects confidentiality of the event data and linkage between events, and that is fully auditable and immutable. Moreover, whilst the present application describes methods and systems that involve recordal of data on a blockchain, these methods and system avoid recordal of full event data or linkages between event data in a way that minimizes the quantity of data that needs to be recorded on chain, thereby improving throughput, reducing cost, and/or speeding the recordal process.

[0031] The present application’s methods and system ensure that the event data is verifiable through publicly recorded immutable blockchain-based records, while ensuring that those records do not expose data regarding the events, the person involved, or any linkages between those events. To record an event, a preimage is generated that contains the event data, such as an identifier of the individual or account involved, details of the event, an identifier of the custodial entity, and other such information. The preimage also contains the event hash of the most recent recorded event in relation to that person or account. The preimage is then hashed to create an event hash and the event hash is recorded on a public blockchain. In some instances, the output of the transaction used to record the previous most-recent event relating to that person or account is also spent so as to signal that it is no longer a most-recent recorded event hash relating to a person/account.

[0032] To audit or verify the event data, a custodial entity must provide one or more of its privately and securely stored preimages relating to a requested individual and/or account. Those preimages contain event data and, when hashed, must produce a corresponding event hash that matches what is recorded on the blockchain. Because a preimage contains an event hash for the previously -recorded event in connection with that person/account, the auditor may identify the event hash/trans action on chain that corresponds to the previous-event and request its preimage if not already provided. Similarly, if the transaction on chain has a spent output, then auditor knows there is a subsequent event recorded that involves that person/account and can request that event preimage and/or event hash. The recording of event hashes on chain ensures the preimage data is original and unaltered on the basis that when hashed it corresponds to the publicly-recorded event hashes. The preimage data reveals links between events that cannot be obtained from looking at the on-chain recorded event hashes alone.

[0033] In some situations, the custodial entity may be compelled by regulation and/or possible sanctions to preserve and produce valid preimage data. A custodian that fails to produce valid preimage data may have violated their contractual or regulatory obligations, fraudulently or negligently, and suitable enforcement action may then be taken with regard to the custodial entity.

[0034] A set of events relating to an identifier (e.g. an individual personal identifier, a corporate identifier, an account identifier, or another such linking identifier) form a linked set of events; but those links are ideally not publicly accessible on the blockchain. Moreover the ID or other identifier is also not publicly revealed on the blockchain. The “links” between events are revealed by the preimages’ inclusion of an event hash from an earlier event.

[0035] To avoid publicly linking event hashes, the ‘spending’ of the output of the most recent previous transaction involving an ID may occur in a different transaction from the transaction that records the current event hash. [0036] If a sufficiently large number of events are occurring and being recorded, the custodial entity may elect to batch record multiple event hashes in a single transaction. This may be more efficient in terms of both speed of recordal and cost. In some cases, the custodial entity may record a large batch of event hashes in one transaction and may implement a large batch of output spends in a different transaction. In some cases, if the quantity of events is sufficiently large, it may be acceptable to both spend and record in one large batch transaction since the quantity provides sufficient obfuscation to avoid publicly linking event hashes.

[0037] The present approach ensures auditability, immutability, and privacy, whilst minimizing the quantity of data that needs to be recorded on-chain. On some blockchains, the quantity of data may be of lesser importance, such as with Bitcoin SV™ chain, which is configured to permit large blocks/transactions and low cost. However, with some blockchains, it may be expensive to record a large quantity of data or may involve significant delays in completing the recordals due to the need to use multiple transactions. Accordingly, the present application minimizes data quantity recorded on chain through only requiring recordal of an event hash.

[0038] FIG. 1 shows a simplified example system 100 that includes a first custodial entity 102, a second custodial entity 104, and a computer network 106. At least a portion of the computer network 106 includes a blockchain network made up of a plurality of highly interconnected nodes each configured to carry out the functions of a blockchain node. The blockchain nodes secure the blockchain network in accordance with the governing blockchain protocol. The blockchain nodes may validate and propagate transactions and blocks. Some of the blockchain nodes may maintain a full copy of the blockchain, a portion of which is indicated by reference numeral 108. Some of the blockchain nodes may engage in mining operations. The blockchain 108 may be a public blockchain governed by a blockchain protocol, such as Bitcoin, Ethereum, or the like.

[0039] The first custodial entity 102 is a computing system connected for digital communication with other systems via the computer network. The computing system may be one or a plurality of interconnected computing devices, such as servers, having processors and memory and executing stored program instructions to cause the processors to carry out functions. The first custodial entity 102 may maintain a first private database 110, which may include more than one database and may be implemented using or more physical database servers. The first private database 110 stores a plurality of records including records containing a first set of preimages 114. The preimages 114 contain event data, such as an identifier associated with the event data, event metadata, a first custodial entity ID, and other data regarding the event. The preimage 114 may contain an event hash associated with a previous most-recent event recorded in connection with the identifier. The preimages 114 stored in the first private database 110 are preimages created by the first custodial entity 102 regarding events that relate to individuals, companies, or accounts transacting or carrying out operations via the first custodial entity 102.

[0040] The second custodial entity 104 is also a computing system connected for digital communication with other systems via the computer network. It may have features similar to the first custodial entity 102 and maintains a second private database 112 that stores second set of preimages 116. The preimages 116 stored in the second private database 112 are preimages created by the second custodial entity 104 regarding events that relate to individuals, companies, or accounts transacting or carrying out operations via the second custodial entity 104.

[0041] In some cases the same event may result in an event record in both the first private database 110 and the second private database 112. For example, an individual holding an account at the first custodial entity 102 may transfer a resource to another individual having an account at the second custodial entity 104.

[0042] The preimages 114, 116, are hashed by the respective custodial entity 102, 104, and are recorded on the blockchain 108.

[0043] To illustrate by way of example, reference will now be made to FIG. 2, which diagrammatically shows a linked set of events. In these illustrations, an event E is an event involving an identifiable individual, corporation or account. The individual, corporation or account has an identifier ID. In these examples, for ease of understanding, it is presumed that the event is a financial transaction involving an individual, Alice, having identifier IDA. The event may involve a transfer event, such a transfer of resources. The resources may be financial resources, such as currency, cryptocurrency, shares, bonds, or other instruments. The resources may be fungible or non-fungible non-financial resources in some cases.

[0044] A hash of data x is indicated as h = H (x). An event hash is the hash of a preimage formed from the event E and another event hash h' related to IDA hi = (Eil/zo). In this example, the event hash ho is event hash of the preimage of an earlier event involving IDA- In many implementations, the earlier event is the most-recent preceding event involving IDA- The hash may be any suitable hash function, such as SHA-256. Other hashing functions may be used in some implementations. In one example, a double SHA-256 hash operation may be used as the hash function, for example to guard against a length extension attack.

[0045] Two event hashes are connected if one is in the preimage of the other. An event hash can be in the preimages of multiple event hashes. No more than one event hash can be in the preimage of an event hash. All connected event hashes form an event hash tree. The root of the tree is the first hash of which preimage contains no other event hash.

[0046] The root event may involve recording of the identifier IDA in some cases. The identifier may be itself generated by hashing a defined concatenation of specific data. For instance, an identifier for an individual may be generated by hashing some personal data, such as name (in a defined format), birthdate, place of birth, social insurance number, or other such personally-identifying data. The preimage to the hash may further include an identifier of the custodial entity or other such data. In some cases, the identifier may be generated by, or signed by, a third-party certification authority.

[0047] In one example the root event EQ may be given by: E _o = Alice\I D _A \CiistodialEntity\Date) , and its event hash is h ₀ = H^Eo). The CustodialEntity may be a custodial identifier or other unique identifier of the entity recording the event hash. The hash value h ₀ can be made public or communicated with other relevant entities. The preimage of h ₀ is stored in the private database of the custodial entity and will only be made available to authorised parties. Because there is no prior event, the root event preimage does not contain an event hash of the previous event.

[0048] The event hash ho is recorded on the blockchain. Depending on the specific blockchain protocol used, the event hash ho may be stored in the metadata or payload of a transaction or other state record. In the example case of Bitcoin, the event hash ho may be recorded by placing in an OPRETURN field, which is a type of field useful for recording data that does not result in stack operations.

[0049] An example bitcoin transaction, TxIDo, for recording the root event hash may be structured as follows:

[0050] The locking script in the transaction may vary depending on the implementation. This example uses [P2PKH CE1], which is a pay-to-public-key operation referencing the public key of the first custodial entity, CE1. In another example, it may be [P2PKH CE1 or Alice]. The main idea is to enforce conditions that reflect the access right to update the event. While the public keys for C 1 may be publicly identifiable, the public key for Alice may be pseudo anonymous. That is, it may be different each time, but each public key can be identified as Alice’s with additional information from the first custodial entity or Alice herself.

[0051] The second event, Ei, involving Alice may be her depositing funds to the new account established with CE1. This may be recorded as event hash hi, as shown in FIG. 2. The link with the previous event hash comes in preimage used in the hashing operation where hi = H(Ei\ho). In this manner, the custodial entity may build a chain of linked event records relating to Alice (or Alice’s account with the custodial entity).

[0052] Referring now to FIG. 3, it will be noted that an event may occur that involves starting (or building on) a separate chain of events. In one example, Alice may transfer resources to Bob, where Bob has an account at the same or a different custodial entity. In such an example, the transfer operation would be recorded as event hash /z2 on Alice’s chain and the event may be record on Bob’s chain as event hash h’j. If Bob’s account is with a different custodial entity, then that other custodial entity builds a preimage reflecting the event details and hashes it to create h'j. In some cases, the same custodial entity may manage both accounts, but it will build separate preimages to reflect Alice’s event data and Bob’s event data and will record the corresponding event hashes.

[0053] In another example, the h'j event may involve Alice opening a new account at a separate custodial entity. In this example, it is assumed that the custodial entities are not obliged to alert each other as to the creation of new accounts involving Alice, so there is no discernible connection between the event hashes. In this case, the new custodial entity will generate a new root event establishing Alice’s identifier credentials with that new custodial entity.

[0054] FIG. 4 shows an example in which the chain of events for Alice at the first custodial entity branches. In one example, Alice may open a second account at the first custodial entity, such as a different type of account like an investment account or retirement account, and the creation of that second account may be reflected in a branching of the event records associated with Alice, as shown by h'3. Event hash may be a corresponding record regarding the creation and/or funding of the separate account; or event hash hj, may be the next event to occur in relation to the original account after event hash h . Events that follow from h'?, are events relating to the new account.

[0055] In another example, the branching may relate to Alice establishing a new identifier and account at a second custodial entity, under circumstance in which custodial entities are obliged to notify each other regarding the creation of new accounts involving an individual. All events in Alice’s event tree after the branching are handled by the respective custodial entity associated with that branch, and the details of which may be unknown and unavailable to the other custodial entity.

[0056] Returning to the case of transfer of resources between two individuals, as an illustrative example, Alice may send $ 1000 USD to Bob in the third event Ez. Bob has an identifier, IDB, and an account with a second custodial entity CE2. Both the custodial entities involves in the funds transfer collect the identifiers for the two individuals (or accounts) involved, IDA and IDB, the quantity or value of resources involved in the transfer v, and other event metadata m. The event metadata m may include information regarding the event, such as an account identifier or number, a timestamp, a type or category of event, and/or one or more custodial identifiers specifying the entities recording the events. The event data generated by the first custodial entity may be E = v|m. The event hash created by the first custodial entity may be given by, h ₂ =

[0057] In some implementations, the event data generated by the second custodial entity may be identical to the event data generated by the first custodial entity: E _± = ID _A \ID _B \v\m. However, the event hashes will differ since the preimage created by the second custodial entity may involve a previous event hash relating to the last event associated with Bob’s account, rather than a previous event hash relating to the last event associated with Alice’s account.

[0058] In some implementations, the event data generated by the second custodial entity may be different. For instance, it may have Bob’s identifier before Alice’s identifier, the metadata may differ in some respects in terms of the code or term used for receiving funds versus sending funds, and/or the metadata may include respective identifiers or signatures of the custodial entity creating the event data. [0059] As noted above, in order to speed recordal of an event hash and minimize the cost and/or delay associated with recordal on the blockchain, the custodial entity may batch record a plurality of event hashes in a single transaction. The custodial entity may further spend a plurality of outputs of prior recorded event hashes where those event hashes are no longer the most recent event hash in their respective chains. There is no requirement that any of the spent outputs relate to the same chains of events as the recorded event hashes so it cannot be inferred that a spent transaction output in a certain batch transaction must necessarily be related to one of the recorded event hashes in that batch transaction. In fact, in one implementation, the custodial entity may process recordals so as to ensure each batch transaction only includes spent outputs relating to linked event chains other than chains associated with the event hashes being recorded.

[0060] One example of a batch transaction, T ZDbatch is shown below: [0061] In the above example, the set of outputs includes spending of the outpoint of TxIDo, and includes the recordal of the next event in that chain as [P2PKH CE1] OP_RETURN < h >. It will be noted that the recordal of /zi is in the same transaction as the spending of the outpoint of the previously recorded event hash, ho, although any linkage is obscured by the fact there are 499 other possible event hashes to which ho may relate. Moreover, as noted above, the custodial entity may mix the spending outpoints and recordal of event hashes across multiple batch transactions so as to further obscure any linkage.

[0062] Reference is now made to FIG. 5, which shows, in flowchart form, one example method 500 for compactly and confidentially recording an immutable chain of events on a blockchain. The method 500 may be implemented by a computing device, such as a network- connected computing device having a processor and suitable program instructions that, when executed by the processor, cause the computing device to carry out the described operations. The computing device may operate under the control of a custodial entity charged with maintaining auditable records of events in connection with an individual, an account, a corporation, or another entity. In some examples, the program instructions may be embodied in an application or program stored on the computing device for managing the recording of event hashes in blockchain transactions and the secure storage of corresponding event details in a secure private database.

[0063] The method 500 may begin with a custodial entity computing system determining whether an event associated with an identifier corresponds to an existing known identifier, as indicated by operation 502. If the identifier is not known then in operation 504 the system may generate a digital identifier, such as IDA. Various operations may be involved in generating a digital identifier, such as obtaining further identifying data, assembling the data into an identity preimage, hashing the identity preimage, digitally signing the preimage or some portion thereof, or obtaining a certificate from a certificate authority, among other things. In some cases, the first event recorded using the method 500 may be the issuance and/or registration of a digital identity.

[0064] In operation 506 the system may assess whether an event is a root event, e.g. relating to a newly-created digital identity for example, or whether it is a subsequent event in an existing chain of events. If new, then in operation 508 the root event may be generated by the system. This may include obtaining event metadata, which may include the digital identity and/or other identifying information, such as account data and an identifier of the custodial entity, and generating a first preimage.

[0065] If the event is not a root event, then in operation 510 the system identifies the most- recent previous event in the chain of events. In some cases, this may include querying the private database of the custodial entity based on the digital identifier associated with the event, e.g. IDA- The private database stores event data regarding the digital identifier, including a set of preimages relating to previously-recorded events and their corresponding event hashes. Based on the obtained information, the system can identify the last-in-sequence of the previous events and retrieve its event hash. It then, in operation 512, generates a preimage that includes the identifier, event metadata, and the previous event hash, /z ₍ .i.

[0066] In operation 514, the preimage generated in operation 508 or operation 512 is then hashed to obtain the event hash, hi.

[0067] The event hash hi is recorded on the blockchain in operation 516. In the case of a Bitcoin-based blockchain, this may include recording the event hash in an OPRETURN field within a transaction in a mined block. In the case of Ethereum, this may include invoking a smart contract or other on-chain code to record the event hash in the updated state of the Ethereum virtual machine. In other blockchains the recordal may occur through some other mechanism. Irrespective of the mechanics of the individual blockchain protocols, the event hash is immutably recorded on- chain, without also recording the event metadata, digital identifier, or other identifying data regarding the event or the individual, company, entity, or account involved.

[0068] If applicable, in operation 518, an output of the most-recent transaction recording the immediately preceding event hash in the associated chain of events, i.e. hi-i, is spent. The spending of that event hash may be to a public key associated with the custodial entity. The “spending” of that output signals that the event hash recorded in that transaction output is no longer the last in its associated chain of event hashes. Operation 518 may be implemented using a transaction separate from the transaction used to record the event hash in operation 516 or may be implemented in the same transaction in some cases.

[0069] In operation 520, the event hash hi and its preimage are stored in the custodial entity computing system’s private database. The preimage is stored in association with the event hash such that should the custodial entity computing system be queried regarding the event hash as part of an audit operation, it is capable of returning the corresponding preimage, which contains all the relevant event metadata.

[0070] It will be appreciated that various operations described above may occur concurrently or in a different order, depending on the implementation. For example, operation 520 could occur prior to operation 516. Operation 518 may occur at the same time as operation 516, or prior to it. Other possibilities will be appreciated by those ordinarily skilled in the art.

[0071] Reference will now be made to FIG. 6, which shows, in flowchart form, another example method 600 of recording an immutable chain of events on a blockchain. As noted above, method 600 may be implemented by a suitably programmed network-enabled computing device, such as a custodial entity computing device.

[0072] The method 600 may include receiving event data and an identifier, such as ID A, in operation 602. The system then searches for a most-recent event associated with the identifier. The search may be conducted in the system’s private database or databases that store event data associated with identifiers. The database may store a sequence of preimages associated with an identifier, such that is it readily apparent from associated timestamp information which of the preimages is the most recent. In the case of a branched set of events, further information may be used to identifier the relevant branch, such as an account number or the like, and thus the most- recent event in that branch associated with the identifier. The corresponding preimage and event hash for the relevant most-recent event may then be retrieved by the system.

[0073] The system may then identify the transaction on the blockchain in which the event hash for the most-recent event was recorded. The transaction identifier may be recorded in the private database in association with the other event data and event hash. A query message may be sent to a blockchain node or application regarding the status of the transaction and, in particular, whether a particular output/outpoint of the transaction corresponding to the event hash has been spent or not. In the case of Bitcoin, this may include querying whether the transaction outpoint is in the set of unspent transaction outputs (UTXOs) maintained by blockchain nodes that make up the blockchain network. As indicated by operation 608, if the output is spent, it indicates that the identified event has been flagged as not-the-most-recent through the spending of its output. This may result in an error, as indicated by operation 610, as the custodial entity should be aware of which event is the last in a sequence involving the identifier and any associate account at the custodial entity.

[0074] Assuming that the output is confirmed as unspent in operation 608, then in operation 610 the custodial entity may then generate a preimage corresponding to the newly- received event data, including the identifier and the event hash of the most-recent event. That preimage is hashed to generate a new event hash, which is recorded on chain, as shown by operations 614 and 616, respectively. The output of the transaction corresponding to the most- recent event that was identified earlier is spent by the custodial entity in operation 618. As noted above, this may occur in the same transaction or a different transaction from recordal of the new event hash. The new event data and new event hash are recorded in the private database in association with the identifier, as indicated by operation 620.

[0075] As described above, any branching that occurs will occur from a most-recent event, which would have an unspent transaction output for the transaction that recorded its event hash. However, in some implementations, the generation of a unique identifier for a person or company or other entity may be managed by a third party, such as regulator, government department, or private certification authority, for example. That third party may issue a digital identity, e.g. IDA, to a person or other entity. As an example, the third party may then generate an event, Eo, relating to creation and issuance of the digital identifier:

E _o = ID _A \RegistrarID\Sig _R [0076] In the above expression, RegistrarlD is a unique identifier for the third party registration entity and SigR is a digital signature from that entity. The event may take other forms or structures in other implementations. It may record an event hash ho of Eo on chain.

[0077] Using the financial example, when an independent financial institution intends to open an account for the person or other entity having identifier ID A, it may verify or validate the identifier through the registrar and may provide the registrar with account related data in some cases. The registrar may create branches from ho for each validation from an independent financial institution. In some cases a branch may be created for each institution that seeks authentication of the identifier, and that branch may contain a sequence of events, where each event is successive authentication request from that institution.

[0078] In some cases, the financial institutions may be obliged to provide the registrar with information regarding a new account or the like, and the registrar may generate a branch associated with each new account established. The registrar may not be privy to subsequent events associated with that account, and a separate chain of events may be created and maintained by the financial institution regarding event relating to that account. In some cases, the financial institution may be provided with the root event hash ho when the identifier is authenticated, and the financial institution then generates a first event in its chain regarding establishment of a new account where the preimage of the event includes the root event hash from the registrar. There would be no publicly identifiable linkage between the registrar’s event tree and the financial institution’s event tree, but the financial institution’s event tree may be related to the root event hash ho through its first preimage.

[0079] In another example, the registrar may create an event chain from the root event for each account established by an independent financial institution. In that case, an auditor tracing the activity of an individual back to the root hash event can trace the event chain to see how many accounts were opened by that individual using the digital identifier, and the output spent status of those events may indicate which of them is the last in the chain. [0080] The various embodiments presented above are merely examples and are in no way meant to limit the scope of this application. Variations of the innovations described herein will be apparent to persons of ordinary skill in the art, such variations being within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments including a subcombination of features which may not be explicitly described above. In addition, features from one or more of the above-described example embodiments may be selected and combined to create alternative example embodiments including a combination of features which may not be explicitly described above. Features suitable for such combinations and sub-combinations would be readily apparent to persons skilled in the art upon review of the present application as a whole. The subject matter described herein and in the recited claims intends to cover and embrace all suitable changes in technology.