Blockchain-based Message Journalling

Abstract

A computer-implemented method of journaling messages sent by and / or to a first party, the method comprising: determining a first message to be journaled, wherein the first message is sent by or to the first party; generating a first journaled message, wherein the first journaled message comprises a copy of the first message; storing the first journaled message and / or an encrypted version of the first journaled message at a storage location; causing a first blockchain transaction to be recorded on a blockchain, wherein the first blockchain transaction comprises a first hash generated by hashing at least the first journaled message.

Description

Technical Field

[0001] The present disclosure relates to a method of journaling (i.e., archiving) messages using a blockchain.

Background Art

[0002] A blockchain refers to a form of distributed data structure, and replicas of the blockchain are maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and are widely publicized. The blockchain comprises a chain of data blocks, and each block comprises one or more transactions. Each transaction other than a so-called "coinbase transaction" refers to a preceding transaction in a sequence that can span one or more blocks back to one or more coinbase transactions. The coinbase transaction is further discussed below. Transactions issued to the blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves each of a plurality of nodes competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a defined set of unprocessed transactions that are ordered and validated and waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of a block can be achieved by the publication of only the block header.

[0003] Transactions in a blockchain can be used for one or more of the purposes of carrying digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtual ledger or register, receiving and processing timestamp entries, and / or ordering index pointers in time. The blockchain can also be utilized to layer additional functionality on top of the blockchain. For example, the blockchain protocol may enable the storage of additional user data or an index to data in a transaction. Since there is no predefined limit to the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents, or audio or video data within the blockchain.

[0004] Nodes in a blockchain network (often referred to as "miners") perform a distributed process of registering and validating transactions, which will be explained in more detail later. In summary, during this process, the nodes verify the transactions, insert them into a block template, and the nodes attempt to find a valid proof-of-work solution for that block template. When a valid solution is found, a new block is disseminated to other nodes in the network, enabling each node to record the new block in the blockchain. To get a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends it to one of the nodes in the network so that the transaction can be disseminated. Nodes that receive the transaction compete to find a proof-of-work solution that can incorporate the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither disseminated nor incorporated into a block. Assuming that a transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes within the blockchain network as an immutable public record.

[0005] Nodes that succeed in solving the proof-of-work puzzle to create the latest block are typically rewarded by a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., a certain number of tokens. The detection and rejection of invalid transactions are carried out by competing nodes that have an incentive to act as agents of the network, reporting and preventing fraud. By publicly disclosing information, users can continuously audit the performance of nodes. By only publishing the block headers, participants can ensure that the integrity of the blockchain remains ongoing.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every spendable output comprises an element that specifies an amount of digital assets that can be derived from a previous sequence of transactions. Spendable outputs are sometimes called UTXOs (Unspent Transaction Outputs). An output may further comprise a locking script that specifies conditions for further exchange of the output. The locking script is a statement that defines the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a previous transaction and may further comprise an unlocking script for unlocking the locking script of the indicated output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output that specifies an amount of digital assets and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input that comprises a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the criteria for validity applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds that the target transaction is invalid according to any of these conditions will not propagate the transaction (or, in some cases, will not propagate it as a valid transaction to register an invalid transaction), and will not include the transaction in the new block to be recorded on the blockchain.

[0008] An alternative type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXO of a preceding transaction in the sequence of past transactions. The current state of all accounts is stored by the nodes separately from the blockchain and updated periodically. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0009] There are legal regulations that require companies to journal (i.e., archive) messages, including emails and other electronic messages, during their transmission. For example, for banks and financial institutions, it is important to journal various messages for audit, reporting, litigation, and compliance purposes. Similarly, in the retail sector, it is important to journal emails or messages between employees and customers for the sale of goods.

[0010] Existing measures typically rely on cloud storage servers to achieve the scalability and completeness required for journaled messages. However, companies using journaling services need to trust cloud-based servers that are responsible for the completeness of journaled messages. As a result, the integrity features of cloud-based journaling systems face the issue of trust. There arises the problem that it is difficult to prove that a journaled message has not been tampered with, for example, by an administrator, a cloud service provider, or other parties.

[0011] Therefore, it is necessary to be able to prove the integrity of the journaled message.

Means for Solving the Problem

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for journaling messages sent by and / or from a first party, the method comprising: determining a first message to be journaled, wherein the first message is sent by or from the first party; generating a first journaled message, wherein the first journaled message comprises a copy of the first message; storing the first journaled message and / or an encrypted version of the first journaled message in a storage location; and causing a first blockchain transaction to be recorded on a blockchain, the first blockchain transaction comprising a first hash generated by hashing at least the first journaled message.

[0013] This disclosure describes a blockchain-based journaling strategy that utilizes the immutability of the blockchain to maintain the integrity of journaled (i.e., archived) messages. This strategy can be seamlessly integrated with existing journaling systems without changing their basic architecture.

[0014] A journaling service is configured to detect when a message sent to or from a particular party (e.g., a user's email account) should be journaled (i.e., archived) for later access. The journaling service generates a copy of the message. The journaled message may include other data in addition to the message, such as, for example, the sender and / or recipient of the message, and the time the message was sent and / or received. The journaled message is stored in a database. In some examples, the journaled message is stored in its raw form. In other examples, the journaled message is stored in an encrypted form. In some examples, both the raw version and the encrypted version may be stored. Additionally, a hash of the journaled message is stored on the blockchain. Storing the hash of the journaled message on the blockchain provides proof that the message was correctly stored and not tampered with. This is because a third party can later verify that hashing the journaled message (including the copy of the message) results in the same hash that is stored on the blockchain. This mechanism eliminates the need to trust third parties.

[0015] For the purpose of assisting in the understanding of the embodiments of this disclosure and showing how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Mode for Carrying Out the Invention

[0017] 1. Overview of the Exemplary System FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet switching network 101, which is typically a wide area internetwork such as the Internet. The packet switching network 101 includes a plurality of blockchain nodes 104 that can be arranged to form a peer-to-peer (P2P) network 106 within the packet switching network 101. Although not shown, the blockchain nodes 104 can be arranged as a quasi-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0018] Each blockchain node 104 comprises a peer computer device, and different nodes 104 belong to different peers. Each blockchain node 104 comprises a processing device that includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises a memory, i.e., a computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units that utilize one or more memory media, such as magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROM, and / or optical media such as high-capacity disk drives.

[0019] The blockchain 150 comprises a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed network or blockchain network 101. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can be pruned of data as long as each blockchain node 150 stores the block headers (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where in this context a transaction refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses a single specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output designates as property an amount representing a quantity of digital assets, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution for unlocking and redeeming or spending). Each input refers to an output of a previous transaction 152, thereby connecting those transactions.

[0020] Each block 151 also includes a block pointer 155 that indicates a previously created block 151 in the chain to define a sequential order for the block 151. Each transaction 152 (other than the coinbase transaction) includes a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 goes back to the genesis block (Gb) 153 that was the first block in the chain. One or more of the initial original transactions 152 of the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0021] Each of the blockchain nodes 104 is configured to transfer a transaction 152 to other blockchain nodes 104, thereby spreading the transaction 152 throughout the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 that are waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "memory pool". This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and is not obligated to accept other transactions that attempt to consume the same output.

[0022] In a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which designates that this output will be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily imply a transfer of financial assets, although that is of course one common application. More generally, consumption can be described as expending the output or allocating the output to one or more outputs in another, subsequent transaction. In general, the preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the current transaction 152i is created or even when it is transmitted to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Thus, "preceding" as used herein refers to that which precedes in the logical sequence linked by the pointer and does not necessarily refer to the time of creation or transmission in chronological order, and thus does not necessarily preclude the transactions 152i, 152j from being created or transmitted out of order (see the following discussion of orphan transactions). The preceding transaction 152i may similarly be referred to as an ancestor transaction or a predecessor transaction.

[0023] The input of the current transaction 152j also comprises an input approval, for example, the signature of user 103a for which the output of the preceding transaction 152i is locked. And the output of the current transaction 152j can be encrypted and locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, transaction 152 can have multiple outputs to divide the amount of the input among multiple users or entities, one of which can be the original user or entity 103a to provide the remaining amount. In some cases, the transaction can also have multiple inputs to gather together the amounts from multiple outputs of one or more preceding transactions to redistribute one or more outputs of the current transaction.

[0024] According to an output-based transaction protocol such as Bitcoin, when a stakeholder 103 such as an individual user or organization desires to define a new transaction 152j (either manually or via an automated process utilized by the stakeholder), the defining stakeholder sends the new transaction from their computer terminal 102 to the recipient. The defining stakeholder or the recipient ultimately sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which are typically servers or data centers today, but could in principle be other user terminals). It is not excluded that the stakeholder 103 implementing the new transaction 152j can send the transaction directly to one or more of the blockchain nodes 104 and, in some instances, not to the recipient. The blockchain node 104 receiving the transaction verifies whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain node 104 to confirm that the cryptographic signature in the new transaction 152j matches the expected signature, and the expected signature depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may involve ensuring that the cryptographic signature or other approval of the stakeholder 103 included in the input of the new transaction 152j matches the conditions defined in the output of the preceding transaction 152i that the new transaction consumes (or "allocates"), and this condition typically involves at least ensuring that the cryptographic signature or other approval in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is connected. This condition may be at least partially defined by a script included in the output of the preceding transaction 152i.Alternatively, it may be fixed solely by the blockchain node protocol, or it may be by a combination of these. In any case, if the new transaction 152j is valid, the blockchain node 104 transfers it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and transfer the new transaction 152j to one or more further nodes 104, and so on. In this way, new transactions are spread across the network of blockchain nodes 104.

[0025] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "consumed") is whether it has already been validly redeemed by the input of another previous transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that the transaction attempts to allocate or redeem has not yet been redeemed by another transaction. Again, if not valid, the transaction 152j is not spread in the blockchain 150 (unless flagged as invalid and spread for warning purposes) or recorded. This protects against double-spending, such as when a trader attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model protects against double-spending by maintaining account balances. Again, since there is a defined order of transactions, the account balance has a single defined state at any given time.

[0026] In addition to validating transactions, blockchain node 104 also competes to first create a block of transactions in a process commonly called mining, which is assisted by "proof of work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that do not yet appear in block 151 recorded in blockchain 150. Then, the blockchain node assembles a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a nonce value such that when the "nonce" is concatenated with the representation of the ordered pool 154 of unprocessed transactions and hashed, the output of the hash meets a predetermined condition. For example, the predetermined condition could be that the output of the hash has a certain number of leading zeros. It should be noted that this is just one specific type of proof of work puzzle and other types are not excluded. The nature of the hash function is such that it has an output that is unpredictable with respect to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0027] The first blockchain node 104 attempting to solve the puzzle notifies this to the network 106 and provides a solution as a proof that can be easily verified by other blockchain nodes 104 in the network (it is straightforward to verify that when a solution to the hash is given, the output of the hash thereby meets the condition). The first blockchain node 104 spreads the block to the threshold consensus of other nodes that accept the block and thus enforce the protocol rules. The ordered set of transactions 154 then comes to be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. This large amount of effort, for example in the form of a hash, required to create the proof of work indicates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or assigns the same output as a previously validated transaction (this is otherwise known as double spending). Once created, the block 151 cannot be modified, as it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order on the blocks 151. Since the transactions 152 are recorded in the blocks ordered at each of the blockchain nodes 104 in the network 106, this provides an immutable public ledger of the transactions.

[0028] At any given time, different blockchain nodes 104 competing to solve the puzzle may be competing to solve the puzzle based on different snapshots of the pool of yet-unpublished transactions 154 at any given time, depending on when those blockchain nodes started searching for a solution or the order in which transactions were received. Note that the first to solve each puzzle defines which transactions 152 are included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any possible "forks", which is a situation where two blockchain nodes 104 solve the puzzle within a very short time of each other, resulting in conflicting views of the blockchain being spread among the nodes 104. That is, the tip of the fork that grows longer becomes the final blockchain 150. Note that this should not affect the users or agents of the network since the same transactions appear in both forks.

[0029] In the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to newly allocate an additional amount of acceptable digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (not an agent - to - agent or user - to - user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction", but may also be called a "genesis transaction" or "generation transaction". It typically forms the first transaction of a new block 151n. Proof - of - work indicates the intention of the node constructing the new block to follow the protocol rules that allow this special transaction to be later redeemed. The blockchain protocol rules may require a maturation period, for example 100 blocks, before this special transaction can be redeemed. Often, a normal (non - generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is discussed below.

[0030] The resources involved in validating and publishing transactions typically take the form of a server, which typically has at least one or more physical server units per blockchain node 104, or even in the form of an entire data center. However, in principle, any given blockchain node 104 could take the form of a group of network - connected user terminals or a group of user terminals together.

[0031] The memory of each blockchain node 104 stores software that is configured to execute on the processing device of the blockchain node 104 to perform their respective roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any activities arising from this specification with respect to the blockchain node 104 can be implemented by software executed on the processing device of each computer device. The node software can be implemented in one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer, or any combination thereof.

[0032] Each computer device 102 of the plurality of stakeholders 103 that play the role of consuming users is also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in transaction verification or block construction. Some of these users or agents 103 can act as senders or receivers in a transaction. Other users can interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some stakeholders can act as storage entities that store a copy of the blockchain 150 (e.g., obtained a copy of the blockchain from the blockchain node 104).

[0033] Some or all of the stakeholders 103 may be connected as part of a network that overlays a different network, such as the blockchain network 106. Users of the blockchain network (often referred to as "clients") are sometimes said to be part of the system that includes the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the roles required of blockchain nodes. Instead, each stakeholder 103 can utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. Two stakeholders 103 and their respective devices 102, namely the first stakeholder 103a and its respective computer device 102a, and the second stakeholder 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such stakeholders 103 and their respective computer devices 102 may exist and participate in the system 100, but they are not shown for simplicity. Each stakeholder 103 can be an individual or an organization. By way of pure example, the first stakeholder 103a is referred to herein as Alice, and the second stakeholder 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob can be replaced with "the first stakeholder" and "the second stakeholder", respectively.

[0034] The computer device 102 of each stakeholder 103 includes a respective processing device that includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each stakeholder 103 further includes a memory in the form of a non-transitory computer-readable medium, i.e., computer-readable storage. This memory may include one or more memory units that utilize one or more memory media, such as magnetic media like hard disks, SSDs, flash memory, or electronic media like EEPROMs, and / or optical media like optical disk drives. The memory of the computer device 102 of each stakeholder 103 stores software that includes respective instances of at least one client application 105 to be executed on the processing device. It will be understood that any activity arising from this specification for a given stakeholder 103 may be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each stakeholder 103 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device like a smartwatch. The computer device 102 of a given stakeholder 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via the user terminal.

[0035] The client application 105 may first be provided to the computer device 102 of any given stakeholder 103 on a suitable computer-readable storage medium, such as being downloaded from a server, for example, or being provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0036] The client application 105 comprises at least a "wallet" function. This has two main functions. One of these is to enable each stakeholder 103 to create, approve (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is spread across the network of blockchain nodes 104 and included in the blockchain 150. The other is to report to each stakeholder the amount of digital assets that each stakeholder currently owns. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to the stakeholder in question.

[0037] Note: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead, any client function described herein may be implemented in a series of two or more separate applications, e.g., interfacing via an API, or in that one is a plugin to the other. More generally, client functions may be implemented in the application layer, or in a lower layer such as an operating system, or any combination thereof. The following is described with respect to the client application 105, but it will be understood that this is not limiting.

[0038] Instances of client applications or software 105 on each computer device 102 are operably coupled to at least one of the blockchain nodes 104 of network 106. This enables the wallet function of client 105 to send transaction 152 to network 106. Client 105 can also contact blockchain nodes 104 to query blockchain 150 for any transaction where each stakeholder 103 is the recipient (or, in an embodiment, since blockchain 150 is a public institution that lends credibility to some transactions by being a public entity, actually investigate the transactions of other stakeholders in blockchain 150). The wallet function of each computer device 102 is configured to compose and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software that is configured to validate transaction 152 according to a blockchain node protocol and transfer them to spread transaction 152 across blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0039] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, she composes the new transaction according to the relevant transaction protocol (using the wallet function of her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be a blockchain node 104 that is optimally connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, the blockchain node 104 processes the new transaction 152j according to the blockchain node protocol and its respective role. This involves first ascertaining whether the newly received transaction 152j meets any conditions for it to be "valid", examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity confirmation may be configurable per transaction by the script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or defined by a combination of the script and the node protocol.

[0040] Under the condition that the newly received transaction 152j passes the test so as to be regarded as valid (i.e., the condition under which it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained by that blockchain node 104. Further, every blockchain node 104 that receives the transaction 152j spreads the transactions after the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming that the transaction 152j is valid, this means that it will soon be spread throughout the entire network 106.

[0041] Given permission to use the ordered pool 154 of unprocessed transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152 (although other blockchain nodes 104 may be trying to solve the puzzle based on different ordered sets 154 of transactions, recall that the first to arrive defines the set of transactions included in the latest block 1511. Eventually, the blockchain node 104 solves the puzzle for a portion of the ordered pool 154 that includes Alice's transaction 152j). When the proof-of-work is done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0042] Different blockchain nodes 104 first receive different instances of a given transaction, so there may be conflicting views as to which instance is "valid" before a given instance is published in a new block 151. At the point when it is published, all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance is recorded in the blockchain 150, that blockchain node 104 accepts this and discards (i.e., treats as invalid) the first instance accepted (i.e., the instance not published in block 151).

[0043] Alternative types of transaction protocols employed by some blockchain networks are sometimes referred to as "account-based" protocols as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXOs of preceding transactions in the sequence of past transactions. The current state of all accounts is stored and periodically updated by the nodes of the network separately from the blockchain. In such a system, transactions are ordered using the transaction tally (also called the "position") of the account during execution of the transaction. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be part of the signed transaction. This data field may refer to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0044] 2. UTXO - based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following is described with reference to an output-based or "UTXO" - based protocol. However, this is not a limitation to all possible embodiments. The exemplary UTXO-based protocol is described with reference to Bitcoin, but it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0045] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure with one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not been redeemed yet). A UTXO contains a value that specifies the amount of digital assets. This represents a certain set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include an indicator of the sizes of the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 issued to the node 104.

[0046] Suppose Alice 103a wishes to create a transaction 152j to transfer a targeted amount of digital assets to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx" 1 ". Tx 1takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx 0 " in Figure 2. Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction of the blockchain 151, nor does it mean that Tx 1 is the very next transaction in the pool 154. Tx 1 may refer to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0047] The preceding transaction Tx 0 may already have been validated and included in the block 151 of the blockchain 150 when Alice creates a new transaction Tx 1 , or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the ordered set 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 may be created together and sent to the network 106, or, if the node protocol allows buffering of "orphan" transactions, Tx 0 is Tx 1It may even be sent after. The terms "preceding" and "succeeding" as used herein in the context of the sequence of transactions refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They may be equivalently replaced by "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, the order in which they are sent to the network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a succeeding transaction (descendant transaction or "child") that refers to a preceding transaction (ancestor transaction or "parent") is not validated until the parent transaction is validated and is not validated unless the parent is validated. A child that reaches the blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for some time while waiting for its parent, depending on the node protocol and / or node behavior.

[0048] Preceding transaction Tx 0 One of one or more outputs 203 thereof is here the specific UTXO 0 labeled as. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script defining the conditions that must be satisfied by the unlocking script in the input 202 of a succeeding transaction in order for the succeeding transaction to be validated and thus for the exchange of the UTXO to succeed. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction containing the locking script). That is, the locking script defines unlocking conditions, which typically include the condition that the unlocking script in the input of a succeeding transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.

[0049] The locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is what is called "Script" (with a capital S) used by the blockchain network. The locking script specifies what information is required to consume the transaction output 203, for example, the requirements for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it may include Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0050] Thus, in the example shown, for the UTXO 0 in the output 203 of Tx 0 to be redeemable (strictly speaking, for the subsequent transaction attempting to redeem the UTXO 0 to be valid), it has a locking script [Checksig P 0 that requires Alice's signature Sig P A . [Checksig P A includes the representation (i.e., hash) of the public key P A from Alice's public-private key pair. The input 202 of Tx A has a pointer that indicates Tx 1 (for example, indicated by its transaction ID TxID 1 , where in an embodiment TxID 0 is the hash of the entire transaction Tx 0 ). The input 202 of Tx 0 is within Tx 1 to identify the UTXO 0 from among any other possible outputs of Tx 0 and the UTXO within Tx 0 ​0 has an index for identifying Tx 1 The input 202 of further includes an unlocking script <Sig P A > created by applying Alice's private key from the key pair to a predetermined portion of the data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the locking script, or by the node protocol, or by a combination of these.

[0051] When the new transaction Tx 1 reaches the blockchain node 104, the node applies the node protocol. This involves executing the locking script and the unlocking script together to determine whether the unlocking script meets the conditions defined in the locking script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A ><P A >||[Checksig P A Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included in the locking script (in this example, a stack-based language). Equivalently, instead of concatenating the scripts, the scripts may be executed one after another using a common stack. In any case, when executed together, the scripts authenticate that the unlocking script in the input of Tx 0 contains Alice's signature that signs the expected portion of the data using the public key P A of Alice included in the locking script in the output of Tx 1 . The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data is Tx 1 ​comprises the whole of (thus, there is no need for a separate element to specify the signed part of the data in plain text, as it was already there).

[0052] Details of authentication by public - private cryptography are familiar to those skilled in the art. Basically, when Alice signs a message using her private key, given the plain - text Alice's public key and the message, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing usually involves hashing the message, signing the hash, and tagging this as the signature to the message, enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference in this specification to signing a particular data or part of a transaction, in embodiments, means signing the hash of that data or part of the transaction.

[0053] Tx 1 The unlocking script in Tx 0 satisfies one or more conditions specified in the locking script of Tx 1 (thus, in the example shown, when Alice's signature is provided and authenticated in Tx 1 ), the blockchain node 104 considers Tx 1 to be valid. This means that the blockchain node 104 adds Tx 1 to the ordered pool 154 of unprocessed transactions. The blockchain node 104 also transfers the transaction Tx 1 to one or more other blockchain nodes 104 in the network 106, so it spreads throughout the network 106. When Tx 1 is validated and included in the blockchain 150, this defines the UTXO 0 from Tx 0 1Note that it can only be valid when consuming an unspent transaction output 203. If attempting to consume an output that has already been consumed by another transaction 152, Tx 1 will be invalid even if all other conditions are met. Thus, the blockchain node 104 also needs to ascertain whether the referenced UTXO in a previous transaction Tx 0 has already been consumed (i.e., whether a valid input has already been formed into another valid transaction in the blockchain). This is one reason why imposing the order defined in transaction 152 is important for the blockchain 150. In practice, a given blockchain node 104 may maintain a separate database marking which UTXO203 has been consumed in the transaction 152 in which it was consumed, but ultimately, what defines whether a UTXO has been consumed is whether the UTXO has already formed a valid input into another valid transaction in the blockchain 150.

[0054] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this also serves as a basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in block 151.

[0055] Note that in a UTXO-based transaction model, a given UTXO needs to be consumed in its entirety. It is not possible to "leave behind" part of the amount defined in the UTXO as being consumed while another part is not consumed. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in the UTXO 0 in Tx 0 can be split among multiple UTXOs in Tx 1 . Thus, if Alice has a UTXO 0If she does not want to give Bob all the amounts defined in, she can use a reminder to give herself the balance of the second output of Tx 1 or pay it to another party.

[0056] In practice, Alice usually also needs to include the fees for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such fees, Tx 0 may be rejected by the blockchain node 104, and thus, even if technically valid, may not be spread and may not be included in the blockchain 150 (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require a separate unique output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, if a pointer to a UTXO 0 is the only input to Tx 1 and Tx 1 has the only output UTXO 1 Let's assume. If the amount of the digital asset specified in the UTXO 0 is greater than the amount specified in the UTXO 1 , that difference can be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create a block containing the UTXO 1 . However, it is not necessarily excluded that, alternatively or in addition, the transaction fee can be explicitly specified in its own UTXO among the UTXOs 203 of the transaction 152.

[0057] The digital assets of Alice and Bob consist of UTXOs locked to them in any transaction 152 somewhere on the blockchain 150. Thus, typically, the assets of a given party 103 are dispersed across all the UTXOs of all the various transactions 152 across the entire blockchain 150. There is no single number defining the total balance of a given party 103 that is stored anywhere on the blockchain 150. It is the role of the wallet function of the client application 150 to collate together the values of all the various UTXOs that are locked to each party and that have not yet been consumed in some subsequent transaction. That wallet function can do this by querying a copy of the blockchain 150, such as is stored on any of the Bitcoin nodes 104.

[0058] Note that script code is often expressed schematically (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent certain functions. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that produces a non-consumable output of a transaction that can store data within the transaction if OP_FALSE precedes it at the start of the locking script, thereby immutably recording the data on the blockchain 150. For example, the data may comprise a document that it is desired to store on the blockchain.

[0059] Normally, the input of a transaction is the public key P AIt includes a digital signature corresponding thereto. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs part of the transaction input and part or all of the transaction output. The specific part of the output to be signed depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of the signature (and thus fixed at the time of signature) to select which output is signed.

[0060] The locking script is sometimes called the "scriptPubKey" and refers to the fact that the locking script usually contains the public key of the party to whom each transaction is locked. The unlocking script is sometimes called the "scriptSig" and refers to the fact that the unlocking script usually supplies the corresponding signature. However, more generally, it is not essential in all applications of the blockchain 150 for the conditions for redeeming the UTXO to include authenticating the signature. More generally, the scripting language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0061] 3. Side Channel As shown in FIG. 1, each client application of Alice's computer device 102a and Bob's computer device 102b may have additional communication capabilities. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the recommendation of any party or third party). The side channel 107 enables data exchange separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without (yet) being registered on the blockchain network 106 or reaching the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data such as keys, negotiated amounts or conditions, data content, etc.

[0062] Side channel 107 can be established via the same packet - switched network 101 as the blockchain network 106. As an alternative or in addition, side channel 301 can be established via a different network, such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, the side channel 107 referred to anywhere in this specification is "off - chain", that is, it can comprise any one or more links via one or more networking technologies or communication media for exchanging data separately from the blockchain network 106. If more than one link is used, a bundle or aggregate of off - chain links may be referred to as side channel 107 as a whole. Thus, when it is said that Alice and Bob exchange some information or data etc. via side channel 107, it should be noted that this does not necessarily imply that all of this data must be transmitted via exactly the same link, or even via the same type of network.

[0063] 4. Message Journalling Message journalling typically refers to the process of creating copies of incoming and / or outgoing messages during their transmission. Journalled messages contain a copy of the actual message content and usually include relevant metadata such as the time, date, and the sender / receiver addresses involved in the communication.

[0064] Typical features of a message journalling system are as follows. · Real - time: Messages are continuously captured, and journalled messages are created and sent to a storage system simultaneously with the transmission of the actual message. · Selective based on rules: A set of journal rules is set by an administrator who determines who journals, what is journaled, and where the journaled messages are stored. The journaled messages are sent to a predetermined mailbox. · Indexed: An identifier indicates that the email that sends the journaled message to a predetermined mailbox is part of the journaling protocol rather than ordinary email communication. · Searchable: The journaled messages can be searched by an index.

[0065] The journaling system usually works on the following principles. · Data integrity: The data must be kept in its original state without being tampered with or deleted. · Data security: The information stored is protected from threats such as unauthorized access, spyware, and virus attacks. · Data auditability: The information is auditable, easily accessible, and verifiable by authorized personnel.

[0066] Currently available message journaling systems provide cloud-based storage and typically journal messages in real time. Organizations can define journal rules, rule scopes, journal recipients, and journaling mailboxes to ensure compliance with regulatory and legal requirements. Journaling reports are generated by the journaling service and automatically sent to the journaling mailbox in real time as messages are sent and received by the user's mailbox. A journaling report is a specific message that saves the original journaled message as an attachment. If the journaling mailbox is not available to receive the journaling report, an alternative journaling mailbox is used to receive the outstanding report. Typically, the alternative journaling mailbox is provided by an on-premises or third-party archiving system rather than the primary journaling system.

[0067] Existing journaling methods claim that they are immutable and can maintain the integrity of the journaled data, but this claim can be doubted due to their off-chain nature. Currently, there is no way to verify whether a journaled message has been modified or deleted, so users have to trust the message journaling system.

[0068] 5. Blockchain-based Message Journaling Embodiments of the present disclosure relate to a blockchain-based message journaling system and protocol. FIG. 3 shows an exemplary system 300 for implementing such an embodiment. System 300 includes a journaling service 302 and two or more parties. The journaling service 302 is connected to and configured to communicate with a blockchain network 106. The journaling service 302 operates with a computer device that includes a processing device including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). The computer device of the journaling service 302 also includes a memory, i.e., a computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory units utilizing one or more memory media, such as magnetic media such as a hard disk, solid state drive (SSD), flash memory, or electronic media such as EEPROM, and / or optical media such as an optical disk drive.

[0069] In the example of FIG. 3, the parties are shown as users Alice 103a and Bob 103b. However, in general, the parties can take any form, such as, for example, individual users, groups of users, companies, organizations, universities, government agencies, etc. Moreover, although the parties are described with respect to Alice 103a and Bob 103b, the parties themselves (or rather, their respective computer devices) do not need to have any blockchain-related capabilities. In that regard, it will be understood that any activity described as being performed by Alice 103a or Bob 103b is actually performed by their respective computer devices.

[0070] System 300 also includes a storage location 304. The storage location 304 is shown separately from the journaling service 302 in FIG. 3, and the journaling service 302 is connected to the storage location 304 (e.g., via a wired connection or a wireless connection). For example, the journaling service 302 can be connected to the storage location 304 via the Internet. In other examples, the journaling service includes the storage location 304. The storage location 304 can be a dedicated memory operated by the journaling service 302. In other examples, the storage location 304 can be cloud-based and can be composed of one or more servers. Note that the storage location 304 is not the blockchain 150.

[0071] System 300 further includes a requesting party 306. Generally, the requesting party 306 can take any form (e.g., a user, an organization, a company, etc.). In some examples, the requesting party 306 is an auditor. Although not shown in FIG. 3, the requesting party 306 can be connected to and configured to communicate with the blockchain network 106.

[0072] The journaling service 302 is configured to journal messages sent to and / or from Alice 103 and / or Bob 103b. For simplicity, the embodiments are mainly described with respect to journaling messages sent to or from Alice 103a. As used herein, "journaled message" is interpreted to mean data that includes at least a copy of the message. Thus, "journaling a message" is interpreted to mean saving a copy of the message and, optionally, metadata about the copied message.

[0073] The journaling service 302 first determines that the messages sent or received by Alice 103a should be journaled. In some examples, all messages sent or received by Alice 103a should be journaled. In other examples, only some types of messages, such as messages sent to and / or from certain parties (e.g., messages sent to and / or from Bob 103b), messages sent and / or received during certain time frames, messages containing certain content (e.g., keywords), etc., should be journaled. The journaling service 302 may determine whether a message meets one or more criteria before journaling the message.

[0074] When it is determined that a message (the "first message") should be journaled, the journaling service 302 generates a journaled message (the "first journaled message"). Here, "first" is used only as a distinguishing label and does not necessarily imply order. That is, the first message does not necessarily have to be the first message to be journaled. The first journaled message comprises a copy of the first message. In some examples, the first journaled message consists of the first message. In other examples, the first journaled message comprises additional metadata. For example, the first journaled message may comprise the sender of the first message (e.g., Alice 103a) and / or the recipient of the first message (e.g., Bob 103b). Other metadata, such as a timestamp, message type, priority, etc., may be included as part of the first journaled message.

[0075] The journaling service 302 stores a first journaled message at the storage location 304. As described below, the first journaled message may be encrypted, and the encrypted version may be stored in addition to or instead of the plaintext version of the first journaled message. Depending on the type of storage, storing the first journaled message may comprise the journaling service 302 storing the first journaled message in internal memory or sending the first journaled message to remote storage, such as cloud storage.

[0076] In some examples, the journaled message is encrypted before being stored at the storage location 304. For example, the first journaled message may be encrypted before being stored. That is, the journaling service 302 may encrypt the first journaled message to generate a first encrypted journaled message and store the first encrypted journaled message at the storage location 304 (instead of the plaintext first journaled message). Any suitable encryption method may be used, including symmetric and asymmetric encryption.

[0077] In addition, the journaling service 302 generates a hash of the first journaled message ("the first hash"). The first hash is generated by hashing at least the first journaled message using a hash function, such as a cryptographic hash function based on SHA, such as SHA256. Other types of hash functions may be used. The journaling service 302 issues a transaction ("the first transaction") to the blockchain network 106, and the first transaction includes the first hash. The first transaction may be signed by the journaling service 302.

[0078] The first transaction has a transaction identifier (the "first transaction identifier" or first TxID). The journaling service 302 may store the journaled message at a storage location 304 associated with the first TxID. That is, a data pair comprising the first journaled message and the first TxID may be stored at the storage location 304. The first journaled message and TxID may be stored in a database at the storage location. When the first transaction is accepted on the blockchain, the block number of the block in which the first transaction is recorded is obtained and may be associated with the first transaction stored at the storage location 304. The first journaled message may be associated with either the first TxID, or both the first TxID and the block number.

[0079] In some examples, the first message may have a message index (the "first message index"). The first message index may be generated by the journaling service 302. Generally, the journaling service 302 may journal multiple messages, and the message index indicates the location of a particular journaled message in the order of the journaled messages. The journaling service 302 may store the first journaled message at a storage location mapped to the first message index, in addition to, for example, the first TxID and / or the block number.

[0080] Note that the hashed journaled message (e.g., the first hash of the first journaled message) is the hash of the plain text journaled message and not the hash of the encrypted journaled message.

[0081] In some examples, the journaling service 302 may generate and maintain a hierarchical key structure (e.g., a hierarchical deterministic (HD) wallet of keys) such that each key is associated with a master key. An exemplary structure is shown in FIG. 5. The key structure may include a first branch of keys, and at least some of the keys in the first branch are to be used to encrypt journaled messages. Each key in the branch (the "encryption branch") is associated with a master encryption key (e.g., key k in FIG. 5 E ). Note that although called the encryption branch, not all keys in that branch need to be used for message encryption. For example, some keys may only be used to derive child keys within the key structure. The encryption branch includes keys in some layers of the structure. Each key has its own index. The encryption branch includes a layer of message keys (or message index keys). The encryption branch may include other layers such as a function layer, a party layer, and a mailbox layer. Each message key is associated with a respective journaled message. For example, message key k in FIG. 5 ES1 is associated with the first journaled message. The journaling service may use a key ("encryption key") derived from the message key associated with the first journaled message to encrypt the first journaled message. For example, encryption key k in FIG. 5 ES11 may be used to encrypt the first journaled message for the first time, and encryption key k in FIG. 5 ES12 may be used for a second encryption of the first journaled message (re-encryption is discussed below).

[0082] Returning to the on-chain storage of the hashed and journaled messages. The first hash of the first journaled message can be stored in either the spendable output or the unspendable output of the first transaction. In any case, the first transaction includes at least one spendable output (which may or may not include the first hash). The spendable output is locked to the payment public key generated by the journaling service 302. In some examples, the hierarchical key structure may include a second branch of the key (the "payment branch"). The public key used to lock the spendable output may occupy a location within the payment branch corresponding to the cryptographic key used to encrypt the first journaled message. An example of a key structure including an encryption branch and a payment branch is shown in FIG. 6. The payment key k PS11 in FIG. 6 can be used to derive the payment public key to which the spendable output of the first transaction is locked. Further details regarding the key structure are provided below in Section 6.

[0083] As mentioned above, the journaling service 302 can journal many messages. The journaling service 302 uses a process similar to that described for each journaled message. That is, for each respective message to be journaled, the journaling service 302 generates a respective journaled message with a copy of the respective message and stores the respective journaled message (or its encrypted version) in the storage location 304. The journaling service 302 also generates a respective hash of the journaled message and stores the respective hash in the blockchain 150 in each respective transaction. When encrypting each message, the journaling service 302 can use respective encryption keys from the same hierarchical key structure. Each encryption key is derived from a message key associated with the respective journaled message (i.e., the message key has an index corresponding to the index of the respective journaled message). For example, if the message key k ES1 is associated with the first journaled message, the second journaled message may be associated with the message key k ES2 and the third journaled message may be associated with the message key k ES3 and so on. Similarly, the spendable outputs of each respective transaction can be locked with respective payment keys from the same hierarchical key structure. Each payment key is derived from a message key associated with the respective journaled message (i.e., the message key has an index corresponding to the index of the respective journaled message). For example, if the message key k PS1 is associated with the first journaled message, the second journaled message may be associated with the message key k PS2 and the third journaled message may be associated with the message key k ES3It may be associated therewith, and the same applies hereinafter.

[0084] Here, the process moves to the requester 306 verifying the integrity of the journaled message. The requester 306 may request access to the journaled message, such as the first journaled message. In response, the journaling service 302 retrieves the encrypted journaled message from the storage location 304, decrypts the encrypted journaled message, and sends the decrypted journaled message (i.e., the first journaled message) to the requester 306. In an example where the journaled message is not stored in an encrypted form, the journaling service 302 retrieves the first journaled message from the storage location 304 and proves the first journaled message to the requester 306. The requester 306 may then verify that the first journaled message hashes to the same first hash that was stored in the blockchain 150 in the first transaction. In some examples, the journaling service 302 provides the first TxID to the requester 306. The block number and / or message index associated with the first journaled message may also be provided to the requester 306.

[0085] In some examples, when a journaled message is accessed by (i.e., provided to) a requesting party 402, the journaling service 302 issues a transaction to the blockchain network 106 that includes at least a double hash of the journaled message (the “second transaction”). If the journaled message is accessed again, a third transaction that includes a triple hash of the journaled message may be sent to the blockchain network 106, and so on. The preimage may include other data, such as the name of the requesting party 402, a timestamp at which the journaled message was accessed, etc. Each time a new transaction is generated to store a new hash value (e.g., the double hash of the journaled message), the TxID of the new transaction map may be appended to the previous TxID associated with the journaled message at the storage location 402. This creates a record, or history, of the chain of transactions associated with a particular journaled message.

[0086] Note that in an example where the next transaction in the chain consumes a spendable output from a previous transaction, the connection between the transactions is obvious on-chain. In this case, the history of the transaction chain need not necessarily be explicitly recorded at the storage location 402.

[0087] In an example where there is no consumption connection between the first transaction, the second transaction, etc. (i.e., there are independent transactions authenticating each access), the transaction chain may be written to the storage location 402.

[0088] The journalled message is stored in an encrypted form at memory location 402, and in an example where decryption is requested to make the journalled message accessible, the journaling service 302 may re-encrypt the journalled message using a new encrypted key each time the journalled message is accessed, and store the re-encrypted journalled message at memory location 304. The encryption key used for the second encryption of the journalled message may be a second key derived from the same message key. For example, the encryption key k ES12 may be used for the second encryption of the first journalled message. If the first journalled message is accessed a third time, it may be re-encrypted using a third encryption key, e.g., k ES13 .

[0089] Similarly, each new transaction used to store an updated hash of the journalled message may have a spendable output locked with a new payment public key. The payment public key may be derived from a payment key in the payment branch of the key structure, and the location of the payment key corresponds to the location of the encryption key used to re-encrypt the first journalled message. For example, the second transaction that stores the double hash of the first journalled message may have an output locked with the payment key k PS12 .

[0090] Figure 4 shows a more detailed version of the message journaling system 300 described above, and illustrates an exemplary process for journalling and accessing a message

[0091]

Number

[0092] sent from Alice 103a to Bob 103b. In step 1, Alice 103a sends a message

[0093]

Number

[0094] is sent to Bob 103b. In step 2, the journaling service 302 copies the message

[0095]

Number

[0096] and incorporates it into the journaled message

[0097]

Number

[0098] to generate.

[0099] Here, the journaling process is described. The lines with solid arrows are referred to. In step 3a, the journaled message

[0100]

Number

[0101] is encrypted to generate the encrypted journaled message

[0102]

Number

[0103] In step 3b, the journaled message

[0104]

Number

[0105] A hash is generated, and in steps 4 and 5, a transaction having a transaction identifier TxID S1 is created and stored in the blockchain 150. The encrypted journaled message

[0106]

Number

[0107] is stored in the journaling database together with the transaction identifier TxID S1 A Here, the access process is described. The line with a dashed arrow is referred to. In this example, the claimant 306 is an auditor. In step 1, the auditor 306 sends an access request to the journaling service 302. In step 2a, the journaling service 302 decrypts the encrypted journaled message

[0108] to obtain the journaled message

[0109]

Number

[0110] and in step 2b, the journaled message

[0111]

Number

[0112] is obtained, and in step 2b, the journaled message

[0113]

Number

[0114] is sent to the auditor 306. In step 3a, the journaled message

[0115]

Number

[0116] is re-encrypted. In step 3b, the journaled message

[0117]

Number

[0118] has its double hash generated, and in steps 4b and 5b, the transaction identifier

[0119]

Number

[0120] of the transaction having it is stored in the blockchain 150. Here, n refers to how many times (the nth time) the journaled message is accessed. From the auditor's perspective, in step 3c, the auditor 306 hashes the journaled message

[0121]

Number

[0122] and in step 4b, the auditor retrieves the transaction having the transaction identifier TxID S1 A and verifies that the hash included in the transaction matches the hash of the journaled message. If the hashes match, the auditor 306 can be confident that the journaled message has not been tampered with or otherwise changed.

[0123] Note that the step labeling / numbering in FIG. 4 is for illustrative purposes only. In some examples, some steps may be performed in a different order. Similarly, some steps may be performed in parallel.

[0124] 6. Exemplary Implementations This section describes specific implementations of the blockchain-based message journaling protocol described above, including the journaling process and the access chain protocol. The access chain makes it possible to record the order and timestamp of each access on the blockchain. This protocol achieves at least two goals. · Maintaining the integrity of the journaled message · Managing access control to the journaled message

[0125] 6.1 Definitions and Characteristics A journaled message can be defined, for example, as a copy of the original message including the original message itself, the name and address of the sender, the name and address of the recipient, and the corresponding timestamp. Additional metadata can also be included in the journaled message, for example, based on the preferences of the organization. When the original message conforms to the journaling rules, the message text and associated metadata are automatically incorporated when the message is sent to the journaling destination during transport.

[0126] The journaling destination can be a mailbox or another storage server. In this exemplary journaling protocol, the journaling destination is an on-premises storage server managed by the organization's administrator. The journaled messages are encrypted and stored on this on-premises server. This allows the organization to flexibly select an encryption method that meets the organization's requirements and further manage access control that requires a decryption key. However, note that this local server is optional and may be mirrored in real time to a cloud server, backed up regularly to it, or even replaced by it. Cloud services typically encrypt the stored data (and automatically decrypt it at the time of user access), but this is independent of the encryption performed by the journaling system and there are no compatibility constraints regarding different encryption formats.

[0127] The journaling protocol journals messages in real time, i.e., journal messages are created at the time the message is sent or received by the user's mailbox. At the same time, a hash of the journal message (including the original message text and metadata) is published on the blockchain. This provides a time-stamped and immutable record of the journaled message, which can be used at any time to verify the integrity of the copy on the server.

[0128] The parties involved in the message journaling protocol are the message sender, message recipient, administrator, and auditor. Among them, the sender and recipient of the journaled message are called the journaled parties.

[0129] Some features of this exemplary message journaling protocol are as follows. · Encrypted - All journaled messages are encrypted, and only administrators and / or auditors can access the encrypted copies. Journaled parties cannot access them. · Verifiable - The integrity of journaled messages can be verified against the immutable and time - stamped hash of the messages stored on the blockchain. This maintains data privacy while enabling proof of integrity. · Searchable - Journaled messages are searchable by transaction ID. · Explainable - Journaled parties are aware that they are being journaled and can use their original messages to verify the hash values of their journaled messages published on the blockchain.

[0130] 6.2 Encryption Encryption is performed by the administrator, and there is no interaction between the administrator and the parties being journaled during encryption. Therefore, a symmetric encryption method is sufficient for encrypting journaled messages.

[0131] Encryption keys for different parties being journaled are managed through a hierarchical structure (see Figure 5 for example). The hierarchical structure enables the administrator to track and manage all encryption keys.

[0132]

Number

[0133] Let be the administrator's master secret key (level 0 in Figure 5). According to BIP43 and 44, the secret key k E (level 1) is for encryption purposes

[0134]

Number

[0135] It is derived from. For the sake of brevity, assume that there are two journalled parties, Alice and Bob, in the journaling protocol. Level 2 is the child secret keys for the journalled messages of Alice and Bob respectively

[0136]

Number

[0137] and

[0138]

Number

[0139] have. Level 3 is

[0140]

Number

[0141] and

[0142]

Number

[0143] created, which correspond to Alice's sent mailbox vs received mailbox

[0144]

Number

[0145] derived from. From each key at that level, a series of child keys (level 4) are derived to represent each message in the mailbox. For example,

[0146]

Number

[0147] From which, for Alice's first transmitted message

[0148]

Number

[0149] Deriving, for Alice's second transmitted message

[0150]

Number

[0151] Deriving, and so on. Note that the keys at levels 0 to 4 are only used to create a tree structure. Level 5 contains the keys used for encryption. As the lowest level of the key hierarchy, these keys cannot be used to derive the values of other keys in the structure, so even if there is a vulnerability in a single key, the attack is limited to a single record. Each time a message is accessed, it is re-encrypted. This enables strict access control and monitoring of each access. When a message is journaled for the first time, it is encrypted using the first child key. For example, Alice's first transmitted message is first encrypted using the key

[0152]

Number

[0153] If accessed, the message is re-encrypted using the key

[0154]

Number

[0155]

[0156] ​ In some examples, note that while all secret keys are managed by an administrator, these keys can be generated and derived by software. This enables processes such as key generation and management, encryption, decryption, and signature and transaction generation to be automated and run in the background.

[0157] 6.3 Process For the sake of brevity, the following is assumed. · JM is a journaled message, i.e., a copy of the original message and its metadata. · H is the hash of JM and is published on the blockchain via a blockchain transaction. · EM is the encrypted JM and is stored at the journaling destination. This location can be an on-premises server prepared by the administrator.

[0158] When a message meets the journaling rules, it is journaled, encrypted, and stored at the journaling destination in a data structure called the journaling database. The hash of the journaled message is published on the blockchain, for example, using OP_RETURN in the output of a transaction. Note that the journaling rules should be known to the parties being journaled, including what information is incorporated in the journaling process.

[0159] 6.4 Journaling Protocol Assume that Alice 103a is an internal user and all of Alice's sent messages are required to be journaled. Alice sends a message to Bob 103b, and Bob can be either an internal or external party. If Bob is an internal user and targeted as a person to be journaled, as described in the following section, the journaling process is applied to the messages received by Bob. If Bob is an external user, the journaling process is applied only to Alice's sent messages.

[0160] First, the process of message journaling is described from the perspective of the sender (Alice). 1. As Alice's message is sent, it is copied and created in the journaling system

[0161]

Number

[0162] to create. 2.

[0163]

Number

[0164] is encrypted using the private key

[0165]

Number

[0166] as shown in Figure 5. 3. The encrypted

[0167]

Number

[0168] is

[0169]

Number

[0170] It is denoted as and stored in the journaling database. 4.

[0171]

Number

[0172] Hash value of

[0173]

Number

[0174] is calculated and stored in the transaction published on the blockchain using the script OP_RETURN in the output of. Transaction ID

[0175]

Number

[0176] is stored using the script OP_RETURN in the output of. Transaction ID

[0177]

Number

[0178] is stored in the journaling database as shown in Table 1 below,

[0179]

Number

[0180] and used as a link to.

[0181] The hash value stored on-chain is the hash of the (raw) journaled message and not the hash of the encrypted message. This allows the journaled party to verify the integrity of the on-chain hash using their original message without access to the encryption key, and it preserves the user's privacy since the raw message data is not stored on-chain.

[0182] Here, assume that Bob is an internal user and the messages that Bob receives from Alice as described above are journaled. The journaling process is similar to the above and is as follows. 1. Bob's message from Alice is copied as it is received by Bob's mailbox server and in the journaling system

[0183]

Number

[0184] to create. 2.

[0185]

Number

[0186] is the private key

[0187]

Number

[0188] is encrypted using. 3. The encrypted

[0189]

Number

[0190] is

[0191]

Number

[0192] is denoted as and stored in the journaling database. 4.

[0193]

Number

[0194] hash value

[0195]

Number

[0196] is calculated and published on the blockchain as a Bitcoin transaction

[0197]

Number

[0198] is stored in the OP_RETURN output. Transaction ID

[0199]

Number

[0200] is stored in the journaling database as shown in Table 1 (Table 1) and

[0201]

Number

[0202] is associated with.

[0203] The message sent from Alice to Bob is, on Alice's side

[0204]

Number

[0205] and is denoted as, and on Bob's side

[0206]

Number

[0207] It is valuable to note that. The original message has the same content, but the journaled versions have different timestamps and possibly different journaling metadata (for example, Alice and Bob are internal users of different companies with different journaling rules), and as a result, their

[0208]

Number

[0209] and

[0210]

Number

[0211] have different values. Note that two versions of the journaled message are authenticated in separate transactions on the blockchain.

[0212] 6.5 Journaling Database Journaled messages are stored on the server in a data structure, which is called a journaling database. The format of this structure is not formally defined herein, but it stores encrypted message data and can associate each encrypted message with its message index and transaction ID and the block number of the on-chain hash commitment. Other optional fields such as the journaled parties, mailboxes, and timestamps may be included to assist with the search function, and details of the access request history (such as access index, requesting party, time, date, etc.) may also be recorded if necessary.

[0213] The journaling database is directly accessible by the administrator but not directly accessible by the journaled parties or auditors. The administrator can prepare a lookup table for each journaled party that allows the journaled party to view only the records in the journaling database corresponding to their messages. Similarly, the auditor can view a subset of the records that meet their audit criteria. Note that the content of the messages is always encrypted in the database, and access to the decryption key is managed by the administrator and implemented by the journaling system.

[0214] Table 1. Example of a journaling database that associates journaled message indices, encrypted message ciphertexts, and corresponding TxIDs. Sample entries are provided for illustration.

[0215] [Table 1]

[0216] 6.6 Blockchain Transaction Format and Payment Key When a transaction is created on the blockchain, the output (where the journaled message hash can be stored therein) is locked to the public key. Each time the journaled message hash is stored on-chain, a new public / private key pair is generated. This can be automatically performed by the journaling system. A payment key derivation system based on a secret key derived from the master secret key in a branch executed in parallel with the cryptographic keys

[0217]

Number

[0218] is used. This enables the key index within the payment branch to match the index in the encryption branch.

[0219] First, as shown in FIG. 6, the master secret key

[0220]

Number

[0221] is used to derive the secret key k P for payment. Each time an encrypted secret key for Alice's journaled message is generated, a parallel payment secret key is also created. For example, as shown in FIG. 6,

[0222]

Number

[0223] is generated to encrypt

[0224]

Number

[0225] , and the payment secret key

[0226] [Number]

[0227] also

[0228] [Number]

[0229] is generated for use in.

[0230] Table 2 (Table 2) shows an exemplary blockchain transaction created when a message is first journaled. For brevity, inputs and outputs that may be necessary to cover transaction fees and change are omitted. The hash value

[0231] [Number]

[0232] is stored in the output of the transaction via the OP_RETURN code. The remaining locking script is a standard P2PKH script based on the public key associated with the newly generated payment key, i.e.,

[0233] [Number]

[0234] where "*" denotes elliptic curve scalar multiplication and G is the elliptic curve generator point.

[0235] Table 2 (Table 2). Exemplary blockchain transaction for initial journaling of a message. The input UTXO is any UTXO managed by an administrator or the journaling system. The output is the payment key

[0236]

Number

[0237] is locked to the public key hash of. The journaled message hash is embedded in the output via the OP_RETURN code.

[0238]

Table 2

[0239] 6.7 Verification The message journaling system enables the integrity of the journaled messages to be verifiable. This is achieved by comparing the journaled message or the original message with the time-recorded immutable hash published on the blockchain.

[0240] The auditor requests access to the journaled messages from the administrator and receives access to the decrypted journaled messages. This process is described below. Each transaction ID of one or more blockchain transactions containing the respective hash of the journaled message may be associated with each journaled message in the journaling database, enabling the auditor to find the respective hash of the journaled message on the blockchain. The auditor can then hash the decrypted journaled message and compare the two hash values to determine whether the integrity of the journaled message is maintained.

[0241] An auditor may wish to prove that the version they currently have access to is the same as the message when it was first journaled (and time-stamped on the chain). In this case, the auditor needs the TXID of the first transaction in the access chain. As another example, an auditor may wish to audit the access chain (e.g., to confirm that only authorized individuals have accessed the data), in which case the auditor needs to view the access chain record and all corresponding transactions.

[0242] Journaling parties may also wish to confirm that a copy of the journaled message is identical to its original message. The journaling party can use their lookup table to find the associated transaction ID and locate the hash on the chain. Since the journaling party has access to the original message, there is no need to decrypt the journaled copy. Instead, the journaled message can be reconstructed and hashed based on the journaling format rules. If the hash values match, the user knows that the message has been journaled accurately.

[0243] 6.8 Access Chain The hash value of the journaled message is recorded on the blockchain to maintain the integrity of the journaled message. Each time a stakeholder (such as an auditor) requests a decryption key for the journaled message, the access request can be recorded on the blockchain by creating a new transaction that consumes the UTXO from the current transaction associated with that journaled message. Thus, all transactions corresponding to access to a single journaled message are linked on the blockchain via UTXO consumption, which is called an access chain. The access request also updates the access chain of the transaction and is reflected in the journaling database by re-encrypting the journaled message. This enables the administrator and journaled stakeholders to track and verify the access history of the journaled message by the corresponding transactions.

[0244] 6.9 Key Management When a new decryption request is initiated (by an auditor or administrator), two new keys are generated within the key structure. One is the key within the encryption branch (e.g.,

[0245]

Number

[0246] ), and the other is the key within the payment branch (e.g.,

[0247]

Number

[0248] ). The key generation follows the structure described above. The second numerical index (i.e.,

[0249]

Number

[0250] Note that the index j) for is incremented for each access. This is shown at level 5 in FIGS. 5 and 6. The access index (FIG. 5) is derived from the number of TxIDs enumerated for each journaled message or may be explicitly included in the journaling database.

[0251] Public key used for a new transaction

[0252]

Number

[0253] To generate, the payment key is used as the private key. Encryption key

[0254]

Number

[0255] is

[0256]

Number

[0257] is used to re-encrypt. This ensures that a new decryption key request must be made every time a journaled message is decrypted, providing a comprehensive access history that is reflected in the blockchain and the journaling database. It also aids in security against theft or leakage of encryption keys.

[0258] As described in the initial encryption section, during the access process, key generation and derivation can be performed by software within the journaling system. Similarly, the software can automatically execute the steps of the protocol described below to decrypt and re-encrypt data using the key and perform an access log.

[0259] 6.10 Blockchain Transaction Format When a decryption request occurs for a journaled message, such as

[0260]

Number

[0261] when it occurs, the associated transaction

[0262]

Number

[0263] the UTXO in is consumed. The new transaction

[0264]

Number

[0265] (Table 3) refers to

[0266]

Number

[0267] as input and the private key

[0268]

Number

[0269] requires a signature generated using. The output is a new public key

[0270]

Number

[0271] is a UTXO locked to, and also includes the double hash of the journaled message in the OP_RETURN locking script.

[0272] Table 3. Exemplary blockchain transaction for logging the first access of a journaled message. The input references the first transaction associated with JM, and the output is locked to the public key hash of a new payment key generated upon access. The double hash of the journaled message is embedded in the output via the OP_RETURN code.

[0273]

Table 3

[0274] Note that this transaction includes the double hash value of the journaled message instead of the single hash used in the previous transaction. This makes it more difficult to identify the connection between the data payloads of the transactions, thus helping to protect the privacy of the parties involved in the journaling. In this case, each access to the same journaled message updates the hash value on the blockchain by hashing the previous hash value.

[0275] The access chain formed by access transactions provides an immutable record of how many times a record has been accessed and when this access occurred. Additional metadata such as who has viewed the record can be recorded in the journaling database and authenticated on the chain. For example, an auditor may be required to provide a digital signature that signs each request to review a record. This can be included in the access transaction on the chain, along with a certificate that associates the public key with identification information, current affiliation, and professional authentication information. This can be implemented in several ways. For example, the hash of the access metadata may be concatenated with the previous hash of the JM before the second hash is applied (e.g.,

[0276] [Number]

[0277] ), where data is the metadata related to the access. In this case, for the journaled parties to verify against the access chain, they need to have access to the raw metadata for each access. Alternatively, the metadata related to the access chain is represented in a separate hash, either after the JM hash in OP_RETURN or in a separate output.

[0278] 6.11 Access Protocol Each time an auditor requests access to a record, the auditor must issue an access request. The access request can be processed manually by an administrator or automatically by software after requesting the auditor to provide authentication information.

[0279] Here, using an example of access to a single journaled message, the complete protocol that occurs when an access request is granted is described, but in reality, multiple requests can occur simultaneously during an audit. When the auditor

[0280]

Number

[0281] When accessing a journalled message of Alice such as, the journaling system performs the following steps. 1.

[0282]

Number

[0283] using

[0284]

Number

[0285] decodes and enables the auditor to view the decoded

[0286]

Number

[0287] as well as the corresponding records such as the journalled party "Alice" and the mailbox "Sent" in the journaling database. The auditor should note that the corresponding records are used to

[0288]

Number

[0289] identify. The auditor

[0290]

Number

[0291] hashes it, compares it with the hash value on the chain, and verifies its integrity. 2. New cryptographic secret

[0292]

Number

[0293] from

[0294]

Number

[0295] derive and the parallel payment private key

[0296]

Number

[0297] from

[0298]

Number

[0299] derive. 3. Associated payment public key

[0300]

Number

[0301] calculate. 4.

[0302]

Number

[0303] consume the UTXO of

[0304]

Number

[0305] A new transaction to pay

[0306]

Number

[0307] Create. (Optional) Add metadata about the access request to the transaction. 5. As shown in Table 4, add a new

[0308]

Number

[0309] to the entry of the journaled message in the journaling database. 6.

[0310]

Number

[0311] Use to

[0312]

Number

[0313] Re-encrypt and store in the journaling database (note that this should overwrite the previous encrypted message ciphertext to ensure that the old decryption key cannot be reused). 7. (Optional) Update the journaling database with additional information about the access request, such as access index, requestor, access date and time.

[0314] Table 4. Updates to the journaling database indicate cases where journaled messages were accessed.

[0315] [Table 4]

[0316] 6.12 Overview and Features Figure 4 shows an overview of the processes that occur during the journaling of initial messages and access to exemplary messages

[0317] [Number]

[0318] to access.

[0319] The features of the access chain are summarized as follows. · High level of user data privacy - Personal data is not stored directly on the chain and is authenticated via hash commitments that can be used to verify the integrity of the data stored in the journaling database. Additionally, there is a chain of transactions showing the access history of each journaled message, but the hash values stored in each subsequent transaction are different. This is because another round of the hash function is applied to the data within OP_RETURN after each access (e.g., double hash → triple hash). This helps to obfuscate any connections between transactions, providing a certain level of privacy for the access history, which otherwise could be inferred by searching for transactions containing a specific hash value. · One-time access - The cryptographic private key can be used only to access the encrypted journaled messages from the journaling database once. The encryption of the journaled messages is updated with a new cryptographic secret when decrypted. If an auditor wishes to access the journaled messages again, the auditor needs to obtain a new decryption key from the administrator. This helps in managing access after the administrator has passed the decryption key to the auditor. · On-chain access record - Each access from the journaling database is recorded on the blockchain via a transaction. In this case, it is not possible to tamper with the timestamp and order of each access. · Traceable access - New transaction IDs are updated in the journaling database. This simplifies searching and tracing each access through these transaction IDs.

[0320] 7. Further Findings Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, rather than the described embodiments.

[0321] For example, some of the above embodiments have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any of the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may be replaced, respectively, with respect to a blockchain network 106, a blockchain 150, and a blockchain node 104. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0322] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, spreading, and storing the block 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the function of spreading and / or storing a block without creating and publishing the block (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0323] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may execute at least one or some, rather than all, of the functions of creating, publishing, spreading, and storing the blocks 151 of the blockchain 150. For example, in those other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and publish the blocks 151 but not store those blocks 151 and / or spread them to other nodes.

[0324] Even more generally, any reference to the term "Bitcoin node" 104 above may be replaced with the term "network entity" or "network element", and such entity / element is configured to perform some or all of the roles of creating, publishing, spreading, and storing blocks. The functions of such network entity / element may be implemented in hardware in the same manner as described above for the blockchain node 104.

[0325] Some embodiments have been described with respect to a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general embodiments, any suitable type of consensus mechanism, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time, may be used. A particular exemplary proof-of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The selected nodes are often referred to as validators. A blockchain node can lock its tokens for a period of time in order to have an opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the highest probability of becoming the next validator.

[0326] It will be understood that the above-described embodiments are merely illustrative examples. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0327] Statement 1. A computer-implemented method of journaling a message transmitted to and / or from a first party, the method comprising: determining a first message to be journaled, the first message being transmitted to or from the first party; generating a first journaled message, the first journaled message comprising a copy of the first message; storing the first journaled message and / or an encrypted version of the first journaled message in a storage location; A method comprising the step of causing a first blockchain transaction to be recorded on a blockchain, the first blockchain transaction being sent to a blockchain network, the first blockchain transaction comprising a first hash generated by hashing at least a first journaled message.

[0328] Statement 2. The method of statement 1, wherein the first blockchain transaction has a first transaction identifier, and the first journaled message and / or its encrypted version is associated with the first transaction identifier at a storage location.

[0329] Statement 3. The method of statement 2, wherein the first blockchain transaction is recorded in a first block of the blockchain, the first block has a first block number, and the first journaled message and / or its encrypted version is associated with the first block number at a storage location.

[0330] Statement 4. The method of any preceding statement, wherein the first message has a first message index, and the first journaled message and / or its encrypted version is associated with the first message index at a storage location.

[0331] Statement 5. The method of any preceding statement, wherein the first journaled message comprises first metadata associated with the first message.

[0332] Statement 6. The method of statement 5, wherein the first metadata comprises one or more of a sender of the first message, a recipient of the first message, a timestamp, and a message type.

[0333] Statement 7. A step of encrypting the first journaled message to generate an encrypted version of the first journaled message. A method of any preceding statement, comprising storing an encrypted version of a first journaled message at a memory location.

[0334] Statement 8. A method of any preceding statement, wherein an encrypted version of a first journaled message is generated using a symmetric encryption scheme.

[0335] Statement 9. The first journaled message has a first journaled message index, and the method comprises: generating a hierarchical key structure comprising one or more layers of keys, each layer comprising one or more respective keys having respective key indices, the hierarchical key structure comprising a first branch of keys, and encrypting the first journaled message comprising using a first encryption key derived from a first message key in the first branch of keys and having a first key index corresponding to the first journaled message index, the method of Statement 7 or Statement 8.

[0336] Statement 10. The first blockchain transaction comprises a first spendable output locked to a first payment public key, the hierarchical key structure comprises a second branch of keys, the first payment public key is derived from a first payment key, the first payment key is derived from a first message key in the second branch of keys, and the method of Statement 9, the first payment key having a first key index corresponding to the first journaled message index.

[0337] Statement 11. The method of Statement 10, wherein a first hash value is stored at the first spendable output.

[0338] Statement 12. The method of Statement 10, wherein a first hash value is stored at an output other than the first spendable output.

[0339] Statement 13. The method of any preceding statement, wherein the determining step comprises determining whether a first message meets one or more conditions for journaling a message.

[0340] Statement 14. A step of determining each of a plurality of messages to be journaled, and a step of generating each of a plurality of journaled messages, each of the journaled messages comprising a copy of a respective message, a step of storing in a storage location each of the plurality of journaled messages and / or each encrypted version of a respective journaled message, for each of the plurality of journaled messages, a step of causing a respective blockchain transaction to be recorded on a blockchain such that the respective blockchain transaction comprises a respective hash generated by hashing at least the respective journaled message, the method of any preceding statement.

[0341] Statement 15. A step of encrypting each of the journaled messages to generate an encrypted version of each of the journaled messages, and a step of storing in a storage location each encrypted version of each of the journaled messages, the method of Statement 14.

[0342] Statement 16. The method of Statements 9 and 15, wherein the step of encrypting each of the journaled messages comprises using an encryption key having a respective key index corresponding to a respective journaled message index and derived from a respective message key within a first branch of a key.

[0343] Statement 17. The method of Statements 10 and 16, each blockchain transaction having a respective spendable output locked to a respective payment public key, each payment public key being derived from a respective payment key, each payment key being derived from a respective message key within a second branch of keys, and having a respective key index corresponding to each journaled message index.

[0344] Statement 18. The method of any preceding statement, comprising receiving from a requester a request to access a first journaled message; and sending the first journaled message to the requester.

[0345] Statement 19. The method of Statements 7 and 18, comprising decrypting an encrypted version of the first journaled message in response to receiving the request.

[0346] Statement 20. The method of Statement 18 or 19, comprising providing a first transaction identifier to the requester.

[0347] Statement 21. The method of any of Statements 18 to 20, comprising causing a second blockchain transaction to be recorded on the blockchain, the second blockchain transaction having a second hash generated by double-hashing at least the first journaled message, the second blockchain transaction to be sent to the blockchain network.

[0348] Statement 22. The method of any of Statements 18 to 21, comprising re-encrypting the first journaled message to produce a re-encrypted version of the first journaled message; Storing in a memory location the first journaled re-encrypted version, wherein the step of re-encrypting the first journaled message comprises using a second encryption key derived from a first message key in a first branch of a key having a first key index corresponding to the first journaled message index, the method of any of statements 18 to 21 when dependent on statement 9.

[0349] Statement 23. The method of statement 21 or 22 when dependent on statement 10, wherein a second blockchain transaction comprises an input that references a first spendable output of a first blockchain transaction, the second blockchain transaction comprises a second spendable output that is locked to a second payment public key, the second payment public key is derived from a second payment key, and the second payment key is derived from a first message key in a second branch of a key having a first key index corresponding to the first journaled message index.

[0350] Statement 24. The second blockchain transaction has a second transaction identifier, and the method comprises adding, together with the second transaction identifier, a first transaction identifier associated with the first journaled message and / or an encrypted version thereof, the method of any of statements 21 to 23 when dependent on statement 2.

[0351] Statement 25. a memory comprising one or more memory units, and a processing device comprising one or more processing units, the memory storing code configured to execute on the processing device, the code configured to perform the method of any of statements 1 to 24 when on the processing device, a computer device.

[0352] Statement 26. A computer program embodied on a computer-readable storage and configured to perform any of the methods of Statements 1 to 24 when executed on one or more processors.

Explanation of Signs

[0353] 101 Packet switching network, Internet 102 Computer terminal, computer device 103 Related person 104 Blockchain node 105 Client application 106 Blockchain network 150 Blockchain 151 Block 152 Transaction 153 Genesis block 154 Ordered set 155 Block pointer 201 Header 202 Input field 203 Output field 302 Journaling service 304 Storage location 306 Requesting related person

Claims

1. A method implemented by a computer for journaling messages sent by and / or to a first party, the method comprising: determining a first message to be journaled, wherein the first message is sent by or to the first party; generating a first journaled message, wherein the first journaled message comprises a copy of the first message; storing the first journaled message and / or an encrypted version of the first journaled message at a storage location; and causing a first blockchain transaction to be recorded on a blockchain, the first blockchain transaction comprising a first hash generated by hashing at least the first journaled message.

2. The method of claim 1, wherein the first blockchain transaction has a first transaction identifier, and the first journaled message and / or its encrypted version are associated with the first transaction identifier at the storage location.

3. The method of claim 2, wherein the first blockchain transaction is recorded in a first block of the blockchain, the first block has a first block number, and the first journaled message and / or its encrypted version are associated with the first block number at the storage location.

4. The method according to any one of claims 1 to 3, wherein the first message has a first message index, and the first journaled message and / or its encrypted version are associated with the first message index at the storage location.

5. The method according to any one of claims 1 to 4, wherein the first journaled message comprises first metadata associated with the first message.

6. The method according to claim 5, wherein the first metadata comprises one or more of a sender of the first message, a recipient of the first message, a timestamp, and a message type.

7. encrypting the first journaled message to generate an encrypted version of the first journaled message; storing the encrypted version of the first journaled message at the storage location, the method according to any one of claims 1 to 6.

8. The method according to any one of claims 1 to 7, wherein the encrypted version of the first journaled message is generated using a symmetric encryption scheme.

9. The first journaled message has a first journaled message index, and the method comprises generating a hierarchical key structure comprising one or more layers of keys, each layer comprising one or more respective keys having respective key indexes, the hierarchical key structure comprising a first branch of keys, and encrypting the first journaled message comprising using a first encryption key having a first key index corresponding to the first journaled message index, the first encryption key being derived from a first message key in the first branch of keys. The method according to claim 7 or 8.

10. The first blockchain transaction comprises a first spendable output locked to a first payment public key, the hierarchical key structure comprises a second branch of keys, the first payment public key is derived from a first payment key, the first payment key is derived from a first message key in the second branch of keys, and the first payment key has a first key index corresponding to the first journaled message index. The method according to claim 9.

11. The method according to claim 10, wherein a first hash value is stored in the first spendable output.

12. The method according to claim 10, wherein a first hash value is stored in an output other than the first spendable output.

13. The method according to any one of claims 1 to 12, wherein the determining step comprises determining whether the first message satisfies one or more conditions for journaling the message.

14. Determining each of a plurality of messages to be journaled; Generating each of a plurality of journaled messages, each journaled message comprising a copy of the respective message; Storing the plurality of journaled messages and / or respective encrypted versions of the journaled messages at the storage location; For each of the plurality of journaled messages, causing a respective blockchain transaction to be transmitted to the blockchain network to be recorded on the blockchain, each blockchain transaction comprising a respective hash generated by hashing at least the respective journaled message, the method according to any one of claims 1 to 13.

15. Encrypting each journaled message to generate a respective encrypted version of the journaled message; Storing each respective encrypted version of the journaled message at the storage location, the method according to claim 14.

16. The method according to claim 9 or 15, wherein the step of encrypting each journaled message comprises using a respective encryption key derived from a respective message key in a first branch of a key and having a respective key index corresponding to the respective journaled message index.

17. Each blockchain transaction has a respective spendable output locked to a respective payment public key, where each of the respective payment public keys is derived from a respective payment key, and each of the respective payment keys is derived from a respective message key in a second branch of keys, and has a respective key index corresponding to a respective journaled message index, the method of claim 10 or 16.

18. Receiving, from the requester, a request to access the first journaled message; Sending the first journaled message to the requester, the method of any of claims 1 to 17.

19. Decrypting the encrypted version of the first journaled message in response to receiving the request, the method of claim 7 or 18.

20. Providing a first transaction identifier to the requester, the method of claim 18 or 19.

21. Causing a second blockchain transaction to be recorded on the blockchain, the second blockchain transaction to be sent to the blockchain network, the second blockchain transaction comprising a second hash generated by double-hashing at least the first journaled message, the method of any of claims 18 to 20.

22. Re-encrypting the first journaled message to produce a re-encrypted version of the first journaled message; Storing the re-encrypted version of the first journaled message in the storage location, the step of re-encrypting the first journaled message comprising using a second encryption key derived from a first message key in a first branch of keys having a first key index corresponding to the first journaled message index, the method of any of claims 18 to 21 when dependent on claim 9.

23. The second blockchain transaction comprises an input that references a first spendable output of the first blockchain transaction, the second blockchain transaction comprises a second spendable output that is locked to a second payment public key, the second payment public key is derived from a second payment key, and the second payment key is derived from a first message key in a second branch of a key having a first key index corresponding to the first journaled message index, the method according to claim 21 or 22 when dependent on claim 10.

24. The second blockchain transaction has a second transaction identifier, and the method comprises adding, together with the second transaction identifier, a first transaction identifier associated with the first journaled message and / or its encrypted version, the method according to any one of claims 21 to 23 when dependent on claim 2.

25. a memory comprising one or more memory units, and a processing device comprising one or more processing units, the memory storing code configured to execute on the processing device, the code being configured to implement the method according to any one of claims 1 to 24 when on the processing device, a computer device.

26. A computer program embodied on a computer-readable storage and configured to implement the method according to any one of claims 1 to 24 when executed on one or more processors.

Images