Method and system for sequenced data logging - Patents.com

Abstract

In one aspect, the present disclosure proposes a method, device, system, and data structure for implementing an ordered append-only data logging system. Specifically, the method includes creating a first type transaction having an input related to a transaction output from a most recent transaction in a set of transactions. Then, creating a second type transaction. Finally, publishing both the second type transaction and the first type transaction to a blockchain.

Description

[Technical field]

[0001] The present disclosure relates to methods, devices, systems, and data structures for storing data using a distributed ledger, or blockchain. More specifically, the present disclosure provides storage for ordered, append-only data items. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the preceding transaction in the sequence, which may span one or more blocks, up to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated outstanding transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at the nodes, and publication of blocks may be accomplished by publishing only the block headers.

[0003] A transaction in a blockchain is used to perform one or more of the following: carry digital assets (i.e., a number of digital tokens), order a set of journal entries in a virtualized ledger or register, receive and process timestamp entries, and / or time order index pointers. A blockchain may also be utilized to overlay additional functionality onto the blockchain. Blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. Since there is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

[0004] Nodes of a blockchain network (often called "miners") perform a decentralized transaction registration and validation process, which is described in detail below. In summary, during this process, nodes validate transactions and insert them into a block template, and the nodes attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, a new block is disseminated to other nodes in the network, thus allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends it to one of the nodes of the network for it to be disseminated. Nodes receiving a transaction can compete to find a proof-of-work solution that will 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 not disseminated or incorporated into a block. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes referred to as 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 a digital asset that is derivable from a preceding sequence of transactions. A spendable output may be referred to as a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies a condition for further redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, which we call a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one validity criterion 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 the target transaction invalid according to any of these conditions will not disseminate the transaction (possibly not disseminate the invalid transaction as a valid transaction in order to register it) and will not include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by a node separate from the blockchain.

[0009] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are exploring the use of both the cryptographic security system that Bitcoin relies on, and the data that can be stored on the blockchain to implement new systems. It would be extremely advantageous to be able to use the blockchain for automated tasks and processes that are not limited to the cryptocurrency world. Such a solution could take advantage of the benefits of the blockchain (e.g., a permanent and tamper-resistant record of events, decentralized processing, etc.) while making its uses more diverse.

[0010] One area of ​​current research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of machine-readable contracts or terms of agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs with rules that can process inputs to produce outcomes, and the rules allow actions to be performed depending on those outcomes. Another area of ​​blockchain-related interest is the use of "tokens" (or "colored coins") to represent and transfer real-world entities through the blockchain. Potentially sensitive or secret items can be represented by tokens, which have no discernible meaning or value. Thus, tokens act as identifiers that allow real-world items to be referenced from the blockchain. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] UK Patent Application No. 2002285.1 [Patent Document 2] UK Patent Application No. 2007597.4 [Patent Document 3] UK Patent Application No. 2020279.2 Summary of the Invention [Problem to be solved by the invention]

[0012] The above mentioned examples or scenarios require the client to include or implement software and / or hardware for implementing Elliptic Curve Digital Signature Algorithm (ECDSA) cryptographic keys, functions for managing digital assets, being able to perform blockchain transaction construction, and having access to blockchain libraries, while utilizing the benefits of blockchain to provide a permanent and tamper-resistant record of events. UK Patent Application No. 2002285.1 (filed on February 19, 2020 in the name of nChain Holdings Limited) describes a platform for one or more services related to blockchain, according to which data or information related to a client may be written to or retrieved from the blockchain easily, securely, and instantly by methods, devices, and systems that provide application programming interfaces (APIs) for one or more services related to blockchain, without the need for such client to perform any process or function to use blockchain, while still being able to utilize all the benefits related to blockchain. For such a platform, it is also necessary to ensure that once data is entered into the blockchain using or through the platform, the data cannot be tampered with or altered, and can be independently audited. Accordingly, this disclosure describes one or more techniques for ensuring that sequences of events based on data associated with or provided through the platform, and / or any sequence of data items provided from any client, are tamper-resistant and can be independently investigated and verified. [Means for solving the problem]

[0013] In a first aspect, the present disclosure proposes methods, devices, data structures, and systems for implementing ordered append-only data storage. A data structure according to the present aspect comprising a first transaction and a second transaction. The first transaction comprising a first output and a representation of a first data item. The second transaction comprising a further representation of the first data item, a representation of the second data item, a first input related to the first output, and a second input.

[0014] 2. A method relating to a set of transactions in a blockchain system according to a first aspect, comprising the steps of: receiving a request, the request triggering a representation of a data item to be stored in the blockchain; obtaining a latest transaction in the set of transactions; creating a new blockchain transaction comprising inputs related to outputs from the latest transaction, outputs, a representation of the data item to be stored in the blockchain, and a reference to the latest transaction; and submitting the transaction to the blockchain.

[0015] In a second aspect, the present disclosure proposes a method, device, data structure, and system for implementing ordered append-only data storage. The method according to the second aspect comprises creating a first type transaction comprising an input related to a transaction output from a latest transaction in a set of transactions, creating a second type transaction, submitting the second type transaction to a blockchain, and submitting the first type transaction to the blockchain.

[0016] A data structure according to a second aspect comprising a first type of transaction having an output comprising a first reference to a second type of transaction, and a second type of transaction.

[0017] A method according to a second aspect for searching forward through a set of transactions comprising: (a) obtaining a current transaction in a chain of transactions; (b) determining that the current transaction is a first type transaction, and based on this determination, (i) obtaining a reference to a second type transaction based on the first type transaction, (ii) obtaining the second type transaction based on the reference to the second type transaction, and (iii) performing the steps following step (c) with the second type transaction as the current transaction; (c) obtaining a current transaction identifier; (d) obtaining a further transaction that references the current transaction identifier; and (e) performing steps (b), (c), (d), and (e) starting with the further transaction as the current transaction, creating a loop.

[0018] A second aspect optionally including features of the first aspect.

[0019] In a third aspect, the present disclosure proposes a method, device, data structure, and system for implementing ordered append-only data storage. The method according to the third aspect comprises the steps of creating a second type transaction, submitting the second type transaction to a blockchain, creating a first type transaction comprising an input related to a transaction output from a latest transaction in a set of transactions and a reference to the second type transaction, and submitting the first type transaction to the blockchain after the second type transaction is confirmed on the blockchain.

[0020] The third aspect optionally includes features of the first and second aspects.

[0021] In a fourth aspect, the present disclosure proposes a method, device, data structure, and system for implementing ordered append-only data storage: a data structure comprising a first type transaction and a second type transaction, the second type transaction comprising at least one input; a first type transaction comprising a reference to a second type transaction, the reference being based on at least one of the at least one input.

[0022] The fourth aspect optionally includes features of the first, second and third aspects.

[0023] In a fifth aspect, the present disclosure proposes a method, device, data structure, and system for implementing ordered append-only data storage. The data structure according to the fifth aspect comprises a first type transaction comprising a first reference to a second type transaction, and a second type transaction comprising a second reference to the first type transaction and at least one input. Preferably, the first reference is based on the at least one input to the second type transaction. Preferably, the second reference is a transaction id of the first type transaction.

[0024] A method according to a fifth aspect for walking backwards through a data structure according to the fifth aspect, comprising the steps of: (a) obtaining a current transaction in a chain of transactions; (b) determining that the current transaction is a second type transaction, and based on this determination, (i) obtaining a reference to a first type transaction based on the second type transaction, (ii) obtaining the first type transaction based on the reference to the first type transaction, and (iii) performing the steps following step (c) with the first type transaction as the current transaction; (c) obtaining a transaction identifier of a preceding transaction from the current transaction; (d) obtaining the preceding transaction based on the transaction identifier of the preceding transaction; and (e) performing steps (b), (c), (d), and (e) starting with the preceding transaction as the current transaction, thereby creating a loop.

[0025] The fifth aspect optionally includes features of the first, second, third and fourth aspects.

[0026] In a sixth aspect, the present disclosure proposes a method, device, data structure, and system for implementing ordered append-only data storage. The data structure according to the sixth aspect comprises a first type of transaction comprising a first reference to a change-in transaction and a second type of transaction comprising a second reference to the first type of transaction. The first reference is based on at least one of the at least one input of the second type of transaction. The second reference is based on at least one of the at least one input of the first type of transaction.

[0027] The sixth aspect optionally includes features of the first aspect, the second aspect, the third aspect, the fourth aspect, and / or the fifth aspect.

[0028] In a seventh aspect, the present disclosure proposes a method for implementing ordered append-only data storage comprising a third type of transaction. Optionally, the third type being a rendezvous transaction.

[0029] 11. A method for searching forward through a set of blockchain transactions comprising: (a) obtaining a current transaction in the set of transactions; (b) determining that the current transaction is a third type transaction, and based on this determination, (i) obtaining an index for an input having a reference to a prior transaction, (ii) obtaining an output associated with the input having a reference to the prior transaction, (iii) obtaining a next transaction based on the obtained output, and (iv) performing steps following step (c) with the next transaction as the current transaction; (c) obtaining a current transaction identifier; (d) obtaining a further transaction that references the current transaction identifier; and (e) performing steps (b), (c), (d), and (e) beginning with the further transaction as the current transaction to create a loop.

[0030] 11. A method for walking backwards through a set of blockchain transactions, comprising: (a) obtaining a current transaction in the set of transactions; (b) determining that the current transaction is a third type transaction, and based on this determination, (i) obtaining an index for the input of the current transaction; (ii) obtaining a reference to a preceding transaction based on the obtained input of the current transaction; (iii) obtaining the preceding transaction based on the reference; and (iv) performing the steps following step (c) with the preceding transaction as the current transaction; (c) obtaining a transaction identifier of the preceding transaction from the current transaction; (d) obtaining the preceding transaction based on the transaction identifier of the preceding transaction; and (e) performing steps (b), (c), (d), and (e) starting with the preceding transaction as the current transaction to create a loop.

[0031] A seventh aspect, optionally including features of the first, second, third, fourth, fifth and sixth aspects. Preferably, the seventh aspect also comprises embodiments relating to forward and backward probing methods associated with aspects 2, 3, 4, 5 and 6.

[0032] Aspects and embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0033] [Figure 1] FIG. 1 is a schematic diagram illustrating an exemplary system for implementing a blockchain. [Diagram 2] FIG. 1 is a schematic diagram illustrating an exemplary transaction used in the blockchain system. [Figure 3A] FIG. 1 illustrates an exemplary wallet system and user interface. [Figure 3B] FIG. 1 illustrates an exemplary wallet system and user interface. [Figure 4] FIG. 1 is a schematic diagram illustrating an exemplary blockchain node with software modules. [Diagram 5] FIG. 2 is a schematic diagram illustrating an overview of a chain of transactions storing log entries and corresponding log entries according to a first embodiment; [Figure 6A] FIG. 2 is a schematic diagram showing a data structure according to a first embodiment; [Figure 6B] FIG. 2 is a schematic diagram showing a data structure according to a first embodiment; [Figure 6C] FIG. 2 is a schematic diagram showing a data structure according to a first embodiment; [Figure 6D] 1 is a flow diagram illustrating a method for implementing an ordered append-only data storage system according to a first embodiment. [Figure 7A] FIG. 4 is a schematic diagram showing a data structure according to a second embodiment; [Figure 7B] FIG. 4 is a schematic diagram showing a data structure according to a second embodiment; [Figure 8] 11 is a flow diagram illustrating a method for implementing an ordered append-only data storage system according to a second embodiment. [Figure 9] 4 is a flow diagram method for exploring an ordered append-only data storage structure according to a second embodiment. [Figure 10] FIG. 13 is a schematic diagram illustrating a data structure for ordered append-only data storage according to a third embodiment. [Figure 11] FIG. 13 is a schematic diagram illustrating a data structure for ordered append-only data storage according to a fourth embodiment. [Figure 12] FIG. 13 is a schematic diagram illustrating a data structure for ordered append-only data storage according to a fifth embodiment. [Figure 13] 11 is a flow diagram method for exploring an ordered append-only data storage structure according to a fifth aspect. [Figure 14]FIG. 13 is a schematic diagram illustrating a data structure for ordered append-only data storage according to a sixth embodiment. [Figure 15] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple blockchain-related services, according to an embodiment. [Figure 16] FIG. 1 is a schematic diagram illustrating components of a platform for multiple blockchain-related services, according to an embodiment. [Figure 17] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure may be implemented. [Figure 18] FIG. 13 is a schematic diagram illustrating a data structure for ordered append-only data storage according to an eighth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] Certain specific components and embodiments of the disclosed method will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numerals refer to like features and in which:

[0035] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may consist of a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a number of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0036] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. The memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as high-value disk drives.

[0037] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple 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 blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain 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 one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as assets, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions together.

[0038] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has 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 diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0039] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 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 that the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0040] For 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 specifies that this output is to be redeemed or "consumed" in the current transaction 152j. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by the pointer, and does not necessarily refer to the time of creation or transmission in the temporal order, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below on orphan transactions). The preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

[0041] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an 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, the transaction 152j 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 give the remaining amount). In some cases, the transaction can also have multiple inputs to collect together amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0042] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as a user or a machine, wants to perform a new transaction 152j, it sends the new transaction from its computer terminal 102 to a recipient. The entity or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the entity 103 performing the new transaction 152j can send it to one or more of the blockchain nodes 104 and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may comprise verifying that a cryptographic signature or other authorization of entity 103 included in the input of new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that a cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of a previous transaction 152i to which the input of the new transaction is chained. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.

[0043] Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be by a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

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

[0045] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work", in a process commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by trying to solve a cryptographic puzzle. Typically, this comprises looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain number of leading zeros. Note that this is just one specific type of proof of work puzzle, other types are not excluded. The nature of a hash function is that it has an unpredictable output with respect to its input. This search therefore consumes a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle, as it can only be performed by brute force.

[0046] A first blockchain node 104 that attempts to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that the output of the hash thereby satisfies the conditions). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 then becomes 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. The large amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution is an indication of the first node's 104 intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0047] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the ordered set of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current set of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined outstanding ordered set of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may arise, which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, resulting in conflicting views of the blockchain being disseminated between the nodes 104. That is, whichever tip of the fork has grown longer will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0048] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an allowable amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction", but can also be called an "initiation transaction". It usually forms the first transaction of a new block 151n. The 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 redeemed later. The blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) 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.

[0049] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal or a group of user terminals networked together.

[0050] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any activity attributable to this specification for the blockchain nodes 104 may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0051] Also connected to the network 101 are computer devices 102 of each of a number of participants 103 acting as consuming users. These users may interact with the blockchain network but do not participate in the validation, construction, or propagation of transactions and blocks. Some of these users or agents 103 may act as senders or recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0052] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system including the blockchain network. However, these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) the blockchain nodes 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0053] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises a memory in the form of a non-transitory computer readable medium, i.e. computer readable storage. This memory may comprise one or more memory units utilizing one or more memory media, e.g. magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing device. It will be understood that any activity attributable to this specification for a given participant 103 may be performed using software executed on the processing device of the respective computing device 102. The computing device 102 of each participant 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

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

[0056] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example interfacing via an API or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described with respect to client application 105, but it will be understood that this is not limiting.

[0057] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective participant 103 is a recipient (or in an embodiment, actually investigate the transactions of other participants in the blockchain 150, since the blockchain 150 is a public entity that provides credit for some transactions by virtue of its public presence). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward them to disseminate the transactions 152 throughout the 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, and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0058] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the new transaction 152j according to the blockchain node protocol and its respective role. This comprises first verifying whether the newly received transaction 152j satisfies some condition for being "valid", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0059] Provided that the newly received transaction 152j passes the test to be considered as valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained by that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j disseminates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be disseminated throughout the network 106.

[0060] Once granted access to the ordered set of transactions 154 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 ordered set 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different ordered sets 154 of transactions, but whoever gets there first defines the ordered set of transactions contained in the latest block 1511. Eventually, the blockchain nodes 104 solve the puzzle for the part of the ordered set 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the ordered set 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0061] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point 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 has been recorded in the blockchain 150, it accepts it and discards (i.e., treats as invalid) the instance it first accepted (i.e., the instance not published in block 151).

[0062] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, the optional data field may also be the signed transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0063] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a basic data structure of the blockchain 150 (each block 151 comprises 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. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0064] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO comprises a value that specifies an amount of a digital asset. It represents a set number of tokens on the distributed ledger. The UTXO may also comprise, among other information, a transaction ID for the transaction from which the UTXO originates. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a 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.

[0065] Suppose Alice 103a wants to create a transaction 152j that transfers a target amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". Tx1 takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may point to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0066] The predecessor transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates the new transaction Tx1, or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or even Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (such as which transaction points to which other transaction). They may be equally 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, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or node behavior.

[0067] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labelled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the following transaction in order for the following transaction to be validated, and thus for the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the following transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

[0068] A 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 called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume the transaction output 203, e.g., requirements for Alice's signature. An unlocking script appears in the output of a transaction. An unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0069] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 is provided with a locking script [Checksig PA] that requires Alice's signature SIG PA in order for UTXO0 to be redeemed (or more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). [Checksig PA] includes a representation (i.e., a hash) of the public key PA from Alice's public-private key pair. Input 202 of Tx1 is provided with a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 is provided with an index that identifies UTXO0 within Tx0 in order to identify UTXO0 among all other possible outputs of Tx0. Input 202 of Tx1 is further provided with an unlocking script that comprises Alice's cryptographic signature, which is created by Alice applying her private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography).<Sig PA> The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0070] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script satisfies the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig PA> <pa>||[Checksig PA] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function contained in the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. In either case, when executed together, the scripts use Alice's public key PA, as contained in the locking script in the output of Tx0, to authenticate that the unlocking script in the input of Tx1 contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

[0071] The details of public-private cryptographic authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as the signature onto the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., in embodiments means signing a hash of that data or transaction piece.

[0072] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered set of transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that it is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines the UTXO0 from Tx0 as being consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to ascertain whether a referenced UTXO in a prior transaction Tx0 has already been spent (i.e., whether it has already formed valid inputs into another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for the blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent therein, but ultimately what defines whether a UTXO is spent is whether the UTXO has already formed valid inputs into another valid transaction in the blockchain 150.

[0073] 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 is also grounds for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0074] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as being spent while another part is being spent. However, the amount from the UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTX0s in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give the remaining amount of the second output of Tx1 to herself or to pay another party.

[0075] In practice, Alice is usually required to include a fee for the Bitcoin node that publishes her transaction 104. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus not disseminated and included in the blockchain 150, even though it is technically valid (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to do so). In some protocols, the transaction fee does not require a unique separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to 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, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that publishes the block containing UTXO1. However, it is not necessarily precluded that, alternatively or in addition, a transaction fee may be explicitly specified in its own UTXO 203 of transaction 152.

[0076] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, the assets of a given party 103 are spread across the UTXOs of various transactions 152 across the blockchain 150. There is no one number stored anywhere on the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function of the client application 150 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0077] Note that script code is often expressed generally (i.e., without using a strict language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, produces a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0078] Using OP_RETURN in this manner is a specific example of using provably non-spendable script for use on a Bitcoin-based blockchain system. Those skilled in the art will appreciate that different blockchain systems have different mechanisms and data formats for ensuring that script is non-spendable and / or for storing data in transactions.

[0079] Typically, the input of a transaction includes a digital signature corresponding to the public key PA. 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 some of the transaction inputs, and some or all of the transaction outputs. The specific parts of the outputs to sign depend on the SIGHASH flag, which is typically a 4-byte code included at the end of the signature (and thus fixed at the time of signing) to select which outputs are signed.

[0080] A locking script is sometimes referred to as a "scriptPubKey", referring to the fact that the locking script typically comprises the public key of the party for which the respective transaction is locked. An unlocking script is sometimes referred to as a "scriptSig", referring to the fact that the unlocking script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for allowing a UTXO to be redeemed comprises authenticating a signature. More generally, the scripting language may be used to define any condition or conditions. Thus, the more general terms "locking script" and "unlocking script" are sometimes preferred.

[0081] As shown in FIG. 1, the client applications of each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of a third party) a separate side channel 160 with Bob 103b. The side channel 160 allows for the exchange of data apart from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transactions 152 being registered (yet) in the blockchain network 106 or progressing towards the chain 150 until one of them chooses to broadcast the transactions 152 to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 160 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0082] The side channel 160 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 160 may be established over 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. In general, the side channel 160 referred to elsewhere herein may comprise any one or more links, over one or more networking technologies or communication media, for exchanging data "off-chain," i.e., separately from the blockchain network 106. If more than one link is used, the bundle or collection of off-chain links may be referred to as a side channel 160 as a whole. Thus, when Alice and Bob are said to exchange some information or data, etc., over the side channel 160, this does not necessarily imply that all these data must be transmitted over exactly the same links, or even over the same type of network.

[0083] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the schemes disclosed herein. The client application 105 comprises a transaction engine 301 and a user interface (UI) layer 302. The transaction engine 301 is configured to implement transaction-related functions behind the client 105, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via side channels 160, and / or sending transactions to one or more nodes 104 for dissemination through the blockchain network 106, according to the schemes discussed above and as will be discussed in more detail shortly.

[0084] The UI layer 302 is configured to render a user interface via user input / output (I / O) means of the computing device 102 of each user, including outputting information to each user 103 via user output means of the device 102 and receiving input from each user 103 via user input means of the device 102. For example, the user output means may comprise one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may comprise, for example, an input array of one or more touch screens (same or different as used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0085] Note: although various functions are sometimes described herein as being integrated into the same client application 105, this is not necessarily limiting and instead they may be implemented in a series of two or more separate applications, e.g. one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 301 may be implemented in a separate application from the UI layer 302, or the functionality of a given module such as the transaction engine 301 may be split between more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is merely an example and that more generally the described functionality may be implemented in any form of software.

[0086] 3B provides a mock-up of an example of a user interface (UI) 600 that may be rendered by the UI layer 302 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b on Bob's device 102b, or any other participant's device.

[0087] 3B shows a UI 350 from Alice's perspective. The UI 350 may comprise one or more UI elements 351, 352, 352 that are rendered as separate UI elements via user output means.

[0088] For example, the UI elements may comprise one or more user selectable elements 351, which may be various on-screen buttons, or various options in a menu, etc. User input means are adapted to allow the user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to using hands). The options allow the user (Alice) to...

[0089] Alternatively or additionally, the UI element may comprise one or more data entry fields 352 through which the user can.... These data entry fields may be rendered via a user output means, e.g. on a screen, and data may be entered into the fields via a user input means, e.g. a keyboard or touch screen. Alternatively, data may be received verbally, e.g. based on speech recognition.

[0090] Alternatively or additionally, the UI element may comprise one or more output information elements 353 for outputting information to the user. For example, this / these may be rendered on a screen or audibly.

[0091] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not tangible. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 350 shown in FIG. 3 is only a schematic mockup, and that in practice it may comprise one or more additional UI elements, which are not shown for the sake of brevity.

[0092] Node Software FIG. 4 illustrates an example of node software 450 executed at each blockchain node 104 of the network 106 in the example of the UTXO-based or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 of the network 106, i.e., without performing the activities required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UXTO) of transaction 152j (Tx j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in Tx j Based on the pointer in the input of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i , may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Tx i locates the locking script in the referenced output of and passes it to the script engine 452.

[0093] Therefore, the script engine 452 executes the Tx i Locking script and Tx i For example, Tx 0 and Tx 1 2, the same can apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes putting data onto and popping data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0094] By executing the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script "unlocks" the output in which the locking script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns the result "true". Otherwise, it returns the result "false".

[0095] In an output-based model, a "true" result from the script engine 452 is one of the conditions for a transaction to be valid. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied. j the total value of the Digital Assets specified in the output of Tx will not exceed the total value indicated by the input; i The protocol engine 451 evaluates the results from the script engine 452 together with one or more protocol-level conditions and starts the transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is actually validated, the decision engine 454 determines whether Tx j The consensus module 455C may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to Tx for incorporation into block 151. j 4 to the respective ordered sets 154 of the transaction nodes, and a propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before invoking either or both of these functions. For example, the decision engine may choose to publish a transaction only under the condition that the transaction is valid and has sufficient transaction fees remaining.

[0096] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where both individual outcomes are true, the overall outcome is considered to indicate true).

[0097] Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0098] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 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 references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0099] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) performing only one or some but not all of these functions, i.e., network entities may perform the functions of disseminating and / or storing blocks without creating and publishing them (it is not to be recalled that these entities are not considered to be preferred Bitcoin network 106 nodes).

[0100] In non-preferred embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not precluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but not store and / or disseminate those blocks 151 to other nodes.

[0101] Also more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with respect to the blockchain node 104.

[0102] Also more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with respect to the blockchain node 104.

[0103] Ordered, append-only data storage The use of blockchain for high-volume, data-oriented applications has grown significantly in recent years. This growth has commensurately increased the demand for robust Layer 2 protocols for structuring, encoding, and formatting data payloads published to the blockchain. Here, Layer 2 refers to secondary protocols, frameworks, data structures, etc. that are built on top of existing blockchain systems. The aspects described herein are considered to be Layer 2 protocols. Layer 1 refers to the blockchain technology behind Bitcoin, Bitcoin SV, or others.

[0104] Blockchain-based applications involving large amounts of data typically require a data schema or structuring mechanism that allows many data-carrying transactions to be chained together. This is particularly relevant in applications (e.g., in a supply chain) where many events and / or data may need to be chained together in a linearized sequence.

[0105] Unique references can assist in maintaining and tracking sequences of events and / or ordered data items, such that one data-carrying transaction can explicitly reference another transaction to ensure that the two transactions are associated with each other by a blockchain overseer.

[0106] Event Streams and Chains of Dust FIG. 5 illustrates the basic data structure and paradigm of an ordered, append-only data storage system for a first aspect of the disclosure. This may also be described as a data logging system. The particular system illustrated in FIG. 5 is an Event Stream system for logging events. As an example, Event Stream is used throughout for illustrative purposes, but those skilled in the art will understand that the proposed systems and aspects described herein may be used with data items in general, and with ordered, append-only data item logging or storage systems. A data item may refer to the complete form of data, for example, sensor data or a document. Alternatively, a data item may refer to a hash of the actual data. Advantageously, using a hash instead of the data itself provides proof of existence of the data without requiring the data (which may be large, even too large for a transaction) to be stored in the transaction.

[0107] Each event 502 in the append-only log is associated with a blockchain transaction 504, and the sequence of blockchain transactions is ordered and chained together using a "chain of dust" (506). Data related to each event is stored in a payload (described below) as part of each transaction. The data payload is held in the transaction's non-consumable OP_RETURN output, which is a Script opcode that can be used to write arbitrary data to the blockchain and also to mark a transaction output as invalid. As another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that can store data, such as metadata, within the transaction, thereby immutably recording the metadata on the blockchain.

[0108] A chain of dust is an unbroken chain of Bitcoin inputs and outputs, which is used here to impose a spending dependency of each blockchain transaction in a sequence on the transaction immediately preceding it. "Dust" in the context of blockchain transactions in this disclosure is understood to be a spendable transaction of a digital asset or cryptocurrency whose output is of low or nominal value, i.e., its value can be much less the fee for mining the output in the blockchain.

[0109] The use of dust outputs in transactions is advantageous and important to maintain an immutable, sequential record of all transactions as they occur for an ordered, append-only data storage system such as an Event Stream. The reason is that by posting a transaction to the blockchain, all blockchain transactions are time-stamped and remain in a particular order when confirmed on or added to the blockchain, but this does not guarantee the preservation of their sequential order. This is because transactions may be mined into blocks at different times and / or the transactions may be out of order even within the same block. The use of dust outputs that are consumed by the first input of the next transaction in the sequence advantageously ensures that the order of transactions is tracked over time, creating a tamper-resistant record of both the events themselves and the sequential order of the events. This is because, once mined into a block, the payment of dust from a previous transaction to a next transaction in a sequence ensures that the sequence of embedded data-carrying elements, called payloads and discussed below, cannot be reordered and no insertion or deletion can occur according to Bitcoin protocol rules, which could change the sequence without it being immediately apparent that the event stream has been compromised. In some embodiments, the double-spend prevention mechanism inherent in the Bitcoin protocol ensures that the movement of cryptocurrency (e.g., dust) between different transaction inputs and outputs remains in topological order. The chaining of dust transactions exploits the topological ordering to result in the preservation of the order of transactions (and thus associated events and data) between and within blocks. This therefore increases the integrity of the ordered append-only data item storage.

[0110] In this way, blockchain transactions 504 form a directed graph of transactions. Note that the direction of the graph can be considered to be unidirectional, from the previous transaction to the next transaction in the sequence, as indicated by edges 506. Although the arrows on edges 506 in FIG. 5 indicate a transaction pointing to a next transaction, the consumption relationships in Bitcoin transactions are actually relationships from one transaction to a preceding transaction. The graph is created by the consumption relationships between transactions. These consumption relationships can be considered to be a type of reference.

[0111] Backreferences in chains of dust FIG 6A relates to a first aspect of the disclosure and shows a chain of transactions 600. The chain of transactions comprises several transactions 602, 604a, 604b, 604c that are related to each other. The first transaction 602 is Tx 0 and comprises metadata about the chain and a seed number. The chain also comprises several additional transactions 604a, 604b, 604c, which preferably comprise data items to be included in the blockchain. Preferably, the data items are stored as part of the payload described below. The additional transactions 604a, 604b, 604c also comprise inputs related to outputs from transactions preceding them, thus establishing consumption relationships 606a, 606b, 606c, 606d. The inputs consume transaction outputs from previous transactions. As an example, with respect to the Bitcoin protocol, as described above under the heading "UTXO-based model" and with reference to FIG. 2, the outputs are unspent transaction outputs (UTXOs) and the inputs comprise references to UTXOs. Thus, each transaction (except the first) comprises a back-reference 606a, 606b, 606c, 606d to the previous transaction in the chain of dust via a consumption relationship. The initial transaction comprises an input with a back-reference to a funding UTXO, as described below with reference to Figure 6C. This funding UTXO is not considered to be part of the Dust chain because it does not store any data or metadata regarding the Dust chain.

[0112] Optionally, two further back references are included in the additional transactions 604a, 604b, 604c. The second back reference 608 to the first transaction is indicated in FIG. 6A by an arrow on the left hand side. Preferably, this reference takes the form of the transaction id of the first transaction. The third back reference 610, 612a-c takes two forms depending on where the transaction is in the chain. For the second transaction 604a in the chain, the third back reference 610 is a seed present in the first transaction. For all other transactions after the second transaction, the references 612a-c take the form of a hash of a preimage of the data in the preceding transaction.

[0113] The third back references 610, 612a-c are intended to protect payloads from modification by ensuring that each payload depends on a section of the previous payload. Specifically, each payload comprises a stream digest of the preceding payload. This also has the effect of creating back references that allow a user to track the stream of events backwards by following these stream digest references. These third back references 610, 612a-c refer to the same object (the same preceding transaction) as the consumption references 606a-d, but use different reference objects.

[0114] The payload of the add transaction 604a, 604b, 604c is optional. n =[preimage n ][streamDigest n ][...] where a lowercase letter n is used to represent the current transaction and n-1 is the previous transaction.

[0115] Preferably, the payload is OP_FALSE OP_RETURN OP_PUSHDATA1 <preimage> 0x20 <streamdigest>[0x20 <data digest> | OP_PUSHDATAN <data>] is stored in the transaction output script.

[0116] The pre-image comprises metadata of the current and previous transactions. The pre-image optionally comprises any one or more of the following fields: txidcreate: a reference 608 to the first transaction in the chain, preferably the transaction id of the first transaction in the chain index: index of the data or event whenRecorded: The time associated with the creation of the transaction and / or data item. DataDigest n : a hash of the data, optionally stored in the event data representation section ([...]) of the payload, or optionally stored off-chain ·streamDigest n-1 : a hash 612a, 612b, 612c of the preimage of the preceding transaction (also described as the stream digest, or stream digest reference, of the preceding transaction) or the seed 610 of the first transaction (if the transaction is the second transaction in the chain since the first transaction does not have a streamDigest). As discussed above, this can serve as a third reference to the preceding transaction.

[0117] The stream digest is a hash of the preimage.

[0118] The event data representation section ([...]) of the payload optionally comprises data items to be stored in the blockchain. The data items include: The data itself to be stored on the blockchain, hashing of data, A subsection of the data to be stored on the blockchain, or Nothing and / or Empty It can be one of the following:

[0119] The event data representation section of the payload can be empty if the data item to be stored is a hash of some data and the transaction has no intention of storing the data itself: the data item (the hash of the data) in this case is already stored in the dataDigest part of the preimage.

[0120] The hash 612a, 612b, 612c of the preimage of the preceding transaction may be considered a further reference to the preceding transaction, which may be used to follow the chain of transactions and / or validate the preceding transaction.

[0121] If the data to be stored in the blockchain is too large for a payload and / or would make a transaction too large for the blockchain system, the data can be split into subsections. Thus, the data is stored across several payloads (and therefore transactions). The preimage optionally comprises further fields to keep track of the total number of subsections and the index of the current subsection present in the event data representation section. Other ways of managing splitting data across multiple transactions are known. A first alternative may use a unique ID for the data, so that every chunk of data can all use the same ID to indicate that they are related. A second alternative may use a pointer to another location where (the rest of) the data is stored, for example one Tx that stores half of the data may include the TxID of another Tx that stores the other half and may include this TxID in its [...] or vice versa. Those skilled in the art will understand that further ways of splitting data across transactions are possible.

[0122] 6B and 6C, exemplary blockchain transaction formats are shown for data append transactions 640a, 640b, initial transaction 660, and final transaction 662. As these are blockchain transactions, they are similar in structure to transactions 152i, 152j described with reference to FIG. 2, but with certain components relevant to this aspect of the invention. The exact order of inputs and outputs is not specific and alternative orders may be used. This order is preferably consistent on a given chain.

[0123] 6B shows two data append transactions 640a, 640b. These exemplary data append transactions 640a, 640b arrive one after the other in time and in a chain of dust. The dust output 644a of the first transaction 640a is referenced in (i.e., consumed by) the dust input 646b of the second transaction 640b. The dust input 646b of the reference of the second transaction 640b to the dust output 644a of the first transaction 640a comprises both the transaction id 648a of the first transaction and the index of the UTXO, which in this exemplary case is 0 (because it is the first in the list and zero indexing is used).

[0124] All of the transactions 640a, 640b, 660, 662 comprise funding inputs 648a, 648b, 648c, 648d. These funding inputs 648a, 648b, 648c, 648d are provided by a computing device that manages, creates, and submits these transactions to the blockchain. The computing device is optionally a funding service, part of a service as described with reference to FIG. 16. The total value of the funding input is selected to include a transaction fee (sometimes called a miner's fee) to help miners ensure that they pick the transaction and include it in a block. The funding service may provide one or more inputs to ensure that the total value is sufficient for the input. The transaction fee is variable and depends on the load of the network. The transaction fee may be in units of satoshis (or any coin / token used by the blockchain system) per byte (a satoshi is 1 / 100 millionth of a bitcoin). Thus, if the payload is large, the fee must be large and the funding input is adjusted accordingly. As a result of the UTXO model, the overall fee paid depends on the value of both the UTXO referenced in the input and the UTXO of the output. Optionally, the balance from including the transaction fee is returned to the same computing device that manages, creates, and submits these transactions to the blockchain. Funding inputs and any remaining amounts attributable to said funding inputs act as floating balances and are managed by the Funding Service.

[0125] The first transaction 660 and the last transaction 662 also comprise stream metadata 664, 666. The first stream metadata comprises a seed as described with reference to Figure 6B, among other values ​​related to maintaining the chain of dust. The metadata 666 of the last transaction 662 comprises information to indicate that this transaction is the last in the chain. Preferably, the metadata 666 of the last transaction also comprises the transaction id 648c of the first transaction 660.

[0126] Both data append transactions 640a and 640b each comprise a payload 642a, 642b, respectively, as described above. The payload 642b of the second transaction 640b comprises a reference to the payload 642a of the preceding transaction 642a.

[0127] In the chain of blockchain transactions 600 of Figures 5, 6A, 6B, 6C, and 6D, it is not explicitly necessary for a transaction to reference the next transaction in the sequence, since it is sufficient for the consuming relationships in the transaction graph to always trace the sequence forward from one transaction to the next.

[0128] Alternatively, a transaction comprises a forward reference to the next transaction in the sequence. Optionally, this is done by requiring that the next data item in the sequence and / or part of the append transaction are known at the time of creating the current append transaction. For example, the first transaction Tx 1 is the sequence Tx 2 If you need to look up the next transaction in Tx 1 In the hash H(Tx 2 ) is included. This is 1 At the time of creating Tx 2 requires knowledge of the complete data, which may not always be possible.

[0129] Referring to FIG. 6D, a method 680 for adding an additional transaction to a set of transactions is shown.

[0130] First, a data item for storage in the blockchain is received (682). The data may be received as part of a request that includes further metadata, such as which chain the data pertains to. Alternatively, the application already knows the relevant chain from a previous request and / or configuration. The data item may be data for storage in the event data representation section. Alternatively, the data item may be a hash of the data, or the data item may be a dataDigest of the transaction. n are stored in the section.

[0131] The most recent transaction in the set of transactions is obtained 684. Optionally, the most recent transaction is obtained by retrieving it from memory.

[0132] A new transaction is created (686). The new transaction comprises at least an input, a dust output, a data item associated with an output from the latest transaction, and a reference to the latest transaction. Preferably, it is the dust output from the latest transaction. Preferably, the reference to the latest transaction comprises a hash of a section of the latest transaction. More preferably, the reference is a hash of a preimage of the latest transaction.

[0133] The new transaction is then published to the blockchain (688).

[0134] Ancestry Restrictions In many implementations of the Bitcoin protocol, there is a concept known as the ancestor limit. The ancestor limit places a maximum on the largest chain of unconfirmed transactions along with successive spend dependencies that can be processed in a single inter-block interval. At the time of writing, this limit is set to 25 unconfirmed ancestors in Bitcoin and 1000 in Bitcoin SV (previously it was 50, and before that it was 25). It will be understood that aspects and embodiments of the present disclosure are not limited to this value.

[0135] The existence of the ancestor limit becomes an issue in any application that seeks to create a chain of high-frequency, consumption-dependent transactions. The ordered, append-only data storage system described herein is one such example, as this issue limits streams that need to log more than 25 events in a single inter-block period, since all transactions in the stream are consumption-dependent by design.

[0136] In some examples, a new Bitcoin block is produced (on average) every 10 minutes, etc. Thus, an ordered, append-only data storage system according to the embodiments described with reference to Figures 5, 6A, 6B, and 6C operating on the Bitcoin network may store, for example, 25 data items every 10 minutes before encountering an ancestor limit.

[0137] Overcoming ancestry restrictions In a first aspect of the invention as described with reference to Figures 5, 6A, 6B, and 6C, a Dust Protocol chain ensures that each data payload is included in an on-chain transaction in a sequence of chained transactions. The transactions are then chained together sequentially by consuming Dust outputs from one transaction to the next, creating an on-chain transaction consumption graph.

[0138] However, taking into account the ancestry limit, either data cannot be added to the blockchain more frequently than the ancestry limit during any one blockchain creation period (thus imposing constraints on data writers and / or systems that wish to store data on the blockchain), or breaks must be introduced in the transaction consumption graph while still allowing the complete set of transactions in the chain to be efficiently examined.

[0139] The challenge is to ensure that sequences of data elements / payloads can be examined in a sequence that uses a transaction frame, despite the ancestor restrictions introducing breaks in the transaction consumption graph.

[0140] 7A, 7B, 8, and 9 relate to a second aspect of the disclosure and describe data structures 700, 714, 716, a method 800 for adding data items to a chain of dust and conditionally creating a new chain of dust, and a method 900 for forward probing a chain of dust. Optionally, the aspects described here may be used in addition to the aspects described with reference to Figures 5, 6A, 6B, and 6C. The aspects may be used with other blockchain systems to build sequences of transactions with certain consumption relationships and overcome ancestry limitations.

[0141] Referring to FIG. 7A, an overview of the chain of dust data structure 700 used in the second embodiment is shown. A set of transactions is shown with two subsets of transactions, the subsets being chains of dust 720, 722. Each chain of dust with some additional transactions 704a-d. The first chain of dust 720 ends with a change-out transaction 714, and the second chain of dust 722 starts with a change-in transaction 716. There is no consumption relationship between the change-in transaction 716 and the change-out transaction 714, thus overcoming the problem of the ancestor limit. This can be described as "hopping" of dust to a new chain.

[0142] Chain hopping occurs when the number of transactions in a subset approaches the ancestor limit. Preferably, the total number of transactions in the current chain is one less than the ancestor limit, and a new chain must be used. Thus, if a pair of change-out transaction 714 and change-in transaction 716 is created, Tx n-2 Transaction 704c and Tx n-1 It is inserted between transaction 704d and n, where n is the ancestor limit, to allow for the first transaction 702, 716 in the new chain (whether it is the initial transaction 702 or the change-in transaction 716) to leave space for the change-out transaction 714 to also be included in the dust chain.

[0143] Alternatively, chain hopping occurs when the number of unconfirmed transactions in a chain approaches an ancestry limit. In this way, the subset of transactions relevant for chain hopping is defined by whether each transaction has been confirmed or not.

[0144] A subset of transactions is not a proper subset, so if there is only one chain of dust, the members of the subset are the same as the set of transactions.

[0145] The change-in transaction 716 also comprises a chain reference 724 to a preceding chain. Specifically, the chain reference 724 references a chain by referencing a transaction in the preceding chain. Preferably, the chain reference 724 is to a first transaction 702 in a first chain 720. The first transaction 702 in the first chain 720 is an initial transaction or Tx 0 Alternatively, the chain reference 724 may be to the first transaction in the predecessor chain, i.e., the change-in transaction of the predecessor chain (this is not shown in FIG. 7 since the predecessor chain is also the first chain).

[0146] Each additional transaction 704a-d comprises a reference 706a-f to a preceding transaction in the chain of streams. This reference 706a-f comprises at least a consume relationship 606 as described with reference to Figures 5, 6A and 6B. Optionally, the transactions 604a-d may further comprise a third back reference (streamDigest n-1 Also illustrated in FIG. 6 are reference numerals 610, 612a-c.

[0147] The change-out transaction 714 comprises a forward reference 718 to the change-in transaction 716. In this example, this reference 718 is to the transaction id of the change-in transaction 716. Because the reference 718 is or comprises a hash of the transaction 716, the change-in transaction 716 must be created first. This does not require that the change-in transaction 716 be published or submitted to the blockchain first.

[0148] This forward reference 718 allows parties wishing to extract information stored in this data storage system to look forward up the chain.

[0149] Although FIG. 7A shows only two chains of dust 720, 722, one skilled in the art will appreciate that chains may be added to one another using the same techniques described herein.

[0150] Referring to Figure 7B, an exemplary blockchain transaction format is shown for a change-out transaction 714 and a change-in transaction 716. These transactions have many of the same or similar features as transactions 604a-d described with reference to Figures 6B and 6C. Where features are the same or similar, the same or similar names are used.

[0151] The dust input 732 of the changeout transaction 714 comprises a reference to the dust output of the last add transaction in the dust's predecessor chain. The changeout transaction 714 comprises as part of its output a reference to the changein transaction 716. Specifically, the changeout transaction 714 comprises the transaction id 730b of the changein transaction 716.

[0152] The add transactions 704a-d of this embodiment have a format very similar to the add transactions 640a, 640b described with reference to Figure 6B, except that the dust inputs 646a, 646b do not always reference the dust outputs 644a, 644b of the previous add transaction. When the change-out transaction 714 and the change-in transaction 716 are used as described with reference to Figure 8, the next add transaction 704d follows the change-in transaction. That is, the dust inputs 646a / 646b in the form of the next add transaction 704d consume the dust outputs 734 of the change-in transaction.

[0153] Referring to Figure 8, a computer-implemented method 800 for adding data items to a chain of dust and conditionally creating new chains of dust according to structure 700, as described with reference to Figure 7. Although the steps are discussed and shown as sequential steps, many of them may be performed in any order, in parallel, or simultaneously. For example, the first three steps 802, 804, and 806 may be in any order.

[0154] First, a data item is received for storage in the blockchain (802). The data may be received as part of a request that includes further metadata, such as which chain the data pertains to. Alternatively, the application already knows the relevant chain from a previous request and / or configuration.

[0155] Next, the maximum unconfirmed chain length is obtained (804). This value may be accessed via a variable preconfigured and stored in memory, recalled from storage, or obtained from a third party. This maximum unconfirmed chain length is the ancestor limit as discussed above. Preferably, this step is performed once, unless the ancestor limit changes, and not each time a request to store data is received.

[0156] The transaction id of the latest transaction in the current chain is obtained. The transaction id is used to associate the input to the next transaction in the chain with the output of the latest transaction. Preferably, the transaction id is kept from when the latest transaction was put into the blockchain. Alternatively, the latest transaction is obtained by optionally looking up to the latest transaction in the chain. The transaction id is then determined by hashing the latest transaction.

[0157] The length of the current chain is then determined (806). Preferably, this value is stored as a variable in memory for quick retrieval. Additionally or alternatively, if the latest transaction in the current chain is known, the transaction's index is read from the preimage data of said transaction's payload. As a further alternative, the entire length of the chain is counted each time this step is performed. Optionally, the length of the current chain represents the number of unconfirmed transactions in the current chain.

[0158] As an alternative to determining the length of the current chain, the number of transactions in the current chain that have not been included in a block on the blockchain is instead determined, and method 800 continues as normal by using this as the "current chain length."

[0159] As a further alternative to determining the length of the current chain, the number of transactions in the current chain that have not been "confirmed" on the blockchain is instead determined. The definition of "confirmed" depends on the blockchain in question. As an example, many Bitcoin-related applications consider a block to be considered "confirmed" once six blocks have been added after it.

[0160] The advantage of using the length of the current chain over the number of unconfirmed transactions in the current chain is that there is inherent resilience to forking of the blockchain, where transactions that were part of mined blocks and / or are considered "confirmed" in the blockchain are no longer part of the blockchain. This comes at the cost of potentially using change-in and change-out transactions when not necessarily necessary. These alternatives can be selected and switched depending on the nature and frequency of data put onto the blockchain.

[0161] A determination 808 is made whether the length of the current chain is greater than or equal to a threshold number. Preferably, the threshold number is chosen such that at least one unconfirmed transaction is permitted to remain in the chain of unconfirmed transactions such that change-in-out transactions are still permitted. Preferably, the threshold number is one less than the maximum unconfirmed chain length.

[0162] If the length of the current chain is less than the threshold, a transaction is created (810) according to the transaction as described with reference to Figures 6A and 6B, i.e., the newly created transaction has an input that references the output of the most recent transaction in the chain.

[0163] The transaction is submitted (812) to the blockchain so that other computing devices can mine the transaction and add it to the blockchain.

[0164] Optionally, if the current chain length is stored, the current chain length is incremented (814).

[0165] If the length of the current chain is greater than or equal to a threshold, a change-out transaction and a change-in transaction are created.

[0166] First, a change-in transaction is created (816) as discussed with reference to Figures 7A and 7B.

[0167] A change-out transaction is then created (818) as discussed with reference to Figures 7A and 7B. The change-out transaction comprises a forward reference to the change-in transaction. The forward reference comprises or is the transaction id of the change-in transaction.

[0168] A new transaction is created 820 comprising the data to be put on the blockchain. The new transaction comprises inputs that are related to the outputs of the change-in transaction. The new transaction also comprises the data to be put on the blockchain.

[0169] Optionally, if the length of the current chain is stored, the length of the current chain is set to 2 since the current chain comprises a change-in transaction and an add transaction.

[0170] Optionally, the new transaction also comprises a reference to the most recent transaction in the current chain, in the form of a third backreference 610, 612a-c as described with reference to Figures 6A and 6B.

[0171] Those skilled in the art will appreciate that steps 816, 818, 820, 822, 824 relating to creating change-out and change-in transactions, including checking whether the length of the current chain is less than a threshold (808), may also be performed after issuing an add transaction (812) and / or incrementing the length of the current chain (814). In this way, a new dust chain is already established for the next add transaction.

[0172] Referring to Figure 9, a method 900 for looking forward through a chain of dust for a structure created using the method as described with reference to Figures 7A, 7B, and 7C and with reference to Figure 8. Looking forward means moving in the direction of increasing sequence or index numbers. This can also be seen as moving from older data items to newer data items. The use of back references in add transactions and forward references in change-out transactions to change-in transactions enables this looking forward.

[0173] Advantageously, the method of investigation 900 does not require any hidden knowledge to investigate transactions other than the format of the transactions on the blockchain. All references used in the investigation are published on the blockchain along with the data items. Thus, third parties can also investigate the chain of dust and retrieve, store, verify, and / or otherwise use data items stored in the blockchain without private or proprietary services. Notably, due to the nature of the blockchain and current data writing systems and methods, any operations performed on data stored in the blockchain are read-only. It is not practical to modify data stored in the blockchain.

[0174] The first transaction is obtained (902). This is the transaction from which to look forward.

[0175] Optionally, the seed (if this is the first transaction in the chain of dust) or the stream digest (if this is an additional transaction) is obtained and stored for later verification (904).

[0176] Next, the first transaction is hashed to obtain its transaction id (906).

[0177] The transaction id of the first transaction is used to find the transaction in the dust chain that references this transaction id in the input (908). This is the next transaction in the dust chain. The next transaction is assigned as the current transaction for the next step, 910.

[0178] The step of finding the transaction (908) optionally involves iterating through all of the blocks in the blockchain to find it (starting from the block where the current transaction is, since it will not be located in a previous block given that we are looking forwards, and vice versa if we are looking backwards).

[0179] Alternatively or additionally, the step of finding the transaction comprises consulting an off-chain log or database that replicates the dust chain or stores metadata associated with each transaction in the dust chain.

[0180] In some embodiments, the off-chain log or database associates each transaction that is part of the chain of dust with the block header or at least the block id of which the transaction is a part. In this way, using the transaction reference (optionally the transaction id, or in some aspects the PrevOut funding input), the block with the transaction of interest is obtained and then searched for the transaction. This embodiment saves at least some of the finding steps compared to iterating over every single block of the blockchain to find the appropriate transaction.

[0181] A platform processor operating as part of a platform service such as that described with reference to Figures 15 and 16 optionally maintains this log or database.

[0182] In some embodiments, there is a channel service as described with reference to UK Patent Application No. 2007597.4 (filed on May 21, 2020 in the name of nChain Holdings Limited). This channel service provides notifications to third parties when a transaction is confirmed on the blockchain. The notifications comprise details such as the block header and transaction id of the block in which the transaction was confirmed. Third parties who subscribe to these notifications can use the retrieved notifications to find the transaction on the blockchain in a similar manner as above by navigating directly to the correct block.

[0183] Then, the current transaction (Tx in Figure 9) i ) in the chain. The first step in the loop is to see if the current transaction is the last transaction (908). If the current transaction is not the last transaction, the method continues to the next step 912. If it is the last transaction, the loop and method 900 end. Alternatively, if the last transaction comprises a reference to the first transaction, method 900 can optionally return to the beginning of the set of transactions and continue walking the chain if necessary. This may be needed, for example, if the method does not start with the first transaction of the dust chain and the user walking the chain wishes to walk all of the transactions. In this case, the loop ends when the walk reaches the transaction where it started again (i.e., the loop returns to the start and all of the transactions in the chain have been walked).

[0184] The step of determining whether the transaction is the last transaction (910) is based on whether the transaction comprises metadata. Alternatively, the last transaction comprises a flag to indicate that it is the last transaction. Further alternatives to determining whether the last transaction is the last transaction are based on whether the transaction comprises an unconsumed dust output and whether the transaction comprises no reference to a change-in transaction (otherwise the transaction is likely to be a change-out transaction).

[0185] Next, a determination (912) is made as to whether the transaction is of type current. Optionally, this is verified as part of verifying whether the current transaction is the last transaction. If the transaction has a payload, it is considered to be an add transaction. If the transaction does not have a payload, it is considered to be a change-out transaction. Alternatively, if the transaction has a reference to the next change-in transaction, it is a change-out transaction.

[0186] If the transaction is an add transaction, optional actions are taken on the payload 914. The optional actions taken depend on the configuration provided by the researcher.

[0187] Preferably, the action is to validate a previous transaction. This validation is based on the third back reference 610, 612a-c as described with reference to Figures 6A and 6B. The stream digest of the current payload is stored for validation in the next loop iteration. The stream digest of the previous transaction stored in the payload of the current transaction is used to compare with a previous stream digest or seed stored from a previous loop iteration or optional step 904 of obtaining and storing said value.

[0188] Additionally or alternatively, the data items of the payload are stored for later use. Additionally or alternatively, a callback provided by the researcher is invoked, thereby allowing any action to be taken on the payload by the researcher.

[0189] The current transaction is hashed (916) to obtain the transaction id of the current transaction.

[0190] The next transaction is found by looking for a transaction that has an input that references the transaction id of the current transaction (918).

[0191] The loop repeats and the next transaction is assigned as the current transaction 920. The loop begins with a step 910 of determining whether the current transaction is the last transaction.

[0192] Returning to the step of determining the type of transaction (912), if the current transaction is a change-out transaction, a reference to the change-in transaction is obtained, preferably by extracting (922) the reference from the change-out transaction in which it is stored.

[0193] The change-in transaction is found (924) by a reference to the change-in transaction. In this embodiment, the change-in transaction is the transaction id of the change-in transaction. The change-in transaction may be found on the blockchain if it has been confirmed, or in the memory pool of the blockchain network node if the transaction has not yet been confirmed.

[0194] The change-in transaction is hashed 926 to obtain the transaction id of the change-in transaction. The next transaction in the chain of dust will have a back-reference to the change-in transaction in the form of the change-in transaction id. Specifically, the next transaction will consume the output associated with the change-in transaction.

[0195] The next transaction is obtained using the transaction id of the change-in transaction (928).

[0196] The loop repeats and the next transaction is assigned as the current transaction 920. The loop begins with a step 910 of determining whether the current transaction is the last transaction (which is also the point at which the loop can end, as explained above).

[0197] Method 900 is described as starting with the first transaction in a set of transactions, however, one skilled in the art will appreciate that method 900 can also be used with any transaction as a starting point by starting at the start of a loop 910.

[0198] The step of determining the transaction type (912) is preferably based on the contents of the current transaction. Preferably, the size of the outputs of the current transaction is used to determine whether it is an add transaction or a change-in transaction. If the current transaction is a change-in transaction, one of the outputs is a change-in transaction.<PrevOut(s)> Alternatively, the presence of the pre-image, streamDigest, and event data representation sections as described with reference to the first aspect are used to determine whether the transaction is an add transaction.<PrevOut(s)> The presence of the field is used to determine if the transaction is a change-in (or a change-out in a forward lookup). Alternatively, the number of fields in the output of the current transaction is used to determine the type of transaction, since there are more fields in an add transaction payload. Alternatively, the absence of a dust output of the current transaction is used to indicate that the current transaction is a change-out transaction. Alternatively, the number of outputs is used to determine the type of transaction, since a change-out has one less output than an add transaction. Alternatively, all templates of possible structures the current transaction can take are used to pattern match with the current transaction to determine its type.

[0199] Transaction Malleability The concept of transaction malleability relates to the phenomenon that parts of a valid transaction (e.g., a Bitcoin transaction) can be modified without invalidating the transaction. Usually, a transaction id is used to reference a transaction, and the transaction id is a hash of the entire transaction. Thus, problems arise when referencing a transaction, because any modification to any part of the transaction can change the hash of the transaction, which invalidates any reference to said transaction.

[0200] In general, there are broadly two types of malleability in blockchain transactions, both of which allow the contents of a transaction to be altered without invalidating the signatures provided in or through the inputs.

[0201] In this example, in both cases it is assumed that the initial transaction Tx has one input, one signature among its inputs, and one output.

[0202] Type 1: Script-level malleability This type of malleability exploits the fact that Bitcoin signatures that are to be verified using the script opcode OP_CHECKSIG do not sign the scriptSig field of any input in the transaction that contains the signature.

[0203] This fact makes it possible to generate a signature for transaction Tx, modify the input script such that transaction Tx' is not identical to Tx, and still have both Tx and Tx' be considered valid transaction messages signed by the same signature under the blockchain consensus rules.

[0204] Type 2: Malleability of input and output levels This type of malleability relies on the use of a SIGHASH flag other than SIGHAS_ALL being utilized in the transaction.

[0205] If transaction Tx has an input signature that uses any of the five other SIGHASH flag combinations, then either the input or the output can be added to create a transaction Tx' that is not identical, and so both are considered valid transaction messages according to consensus, without the need to change the signature.

[0206] Therefore, every single transaction of the embodiments described herein preferably uses the SIGHASH_ALL flag to overcome this malleability.

[0207] Advantageously, the following third, fourth, fifth and sixth aspects comprise data structures and associated methods that provide further and / or alternative techniques for ensuring referential immutability.

[0208] The term "immutable reference" to a transaction means a valid reference to a transaction that is based on data in the transaction that cannot be altered (i.e., is immutable) once the transaction is published to the Bitcoin network.

[0209] The term "immutable reference" to a transaction usually means the transaction ID of a confirmed transaction, which cannot be changed with a high degree of certainty. An immutable reference can be an immutable reference.

[0210] If any part of the change-in transaction is altered between the inclusion of the change-in transaction's transaction id in the change-out transaction's payload and the inclusion of the change-in transaction on the blockchain (also known as confirmation), the transaction id of the change-in transaction will differ between the one stored in the change-out transaction and the one stored in the blockchain, thereby breaking the reference connecting the two dust chains.

[0211] In other words, a forward reference in a change-out transaction may be to an incorrect change-in transaction id, when it should be pointing to a new transaction id based on the modified transaction id. If such a modification occurs, this defeats the entire purpose of including the reference, since it no longer points to the correct on-chain transaction to continue walking the event stream.

[0212] There is a non-zero risk of an attack occurring in which a malicious miner or eavesdropper successfully modifies a transaction before it is propagated to the majority of the Bitcoin network, so it is desirable to find a robust solution to this problem.

[0213] Add transaction malleability does not arise due to non-malleable consuming references, as discussed above under the heading "Transaction Malleability": change-out and change-in transactions cannot have such consuming connections (otherwise they cannot be used to overcome the ancestor restriction).

[0214] Verifying change-in transactions on the blockchain 10, a data structure 1000 according to a third embodiment is shown for creating an immutable change-in transaction 1016 and an immutable and immutable reference 1018 to the change-in transaction 1014. The immutable change-in transaction allows for the creation of an immutable reference to the change-in transaction, thereby overcoming the malleability problem of the change-in transaction as discussed above under the heading "Malleability of Transactions."

[0215] Figure 10 presents a different data structure than the previous figures in that it is shown in chronological order (earlier transactions appear higher on the page) and describes which blocks in the blockchain comprise which transactions. Which blocks 1050, 1052 comprise which transactions is important in this aspect.

[0216] Figure 10 includes like reference numbers and names for features that are similar to those of the second embodiment. For example, each add transaction 1004a-d and last transaction 1026 includes a backward consume reference 1006a-f to the preceding transaction. This is similar to the add transactions 704a-d and last transaction 726 as shown in Figure 7A, which also includes a backward consume reference 706a to the preceding transaction.

[0217] This embodiment optionally includes the second back reference (608) feature of the first embodiment and the third back reference (610, 612a-c) feature.

[0218] In this embodiment, the change-in transaction 1016 is confirmed on the blockchain at block 1050 before the change-out transaction 1014 references it. Once a change-in transaction is executed on the blockchain, it is practically impossible for a malicious miner to change the transaction, and therefore the transaction id. Thus, the reference 1018 is immutable, in that the reference is valid and will always be valid. No modification of the reference or the transaction is possible.

[0219] The output of the change-in transaction can still be consumed, so that the next add transaction 1004c can reference the change-in transaction 1016 without having to wait for it to be confirmed in a block. Thus, add transactions can still be issued without waiting for the change-in to be confirmed. The resulting data structure 1000 at the dust level chain of abstraction looks and behaves in the same way as described with reference to Figures 7A, 7B, and 9.

[0220] The method for adding data items to a chain of dust and conditionally creating a new chain of dust as described in the second embodiment operates substantially the same in this embodiment, except that step 818 of creating and issuing a change-out transaction 1014 is delayed until the change-in transaction is included in a block on the blockchain. This step 818 may be performed asynchronously with respect to the rest of the method, since no other transactions in this embodiment reference the change-out transaction 1014. Once the change-in transaction 1016 has been issued to the blockchain where its outputs can be consumed, the method continues as usual.

[0221] The change-in transaction comprises a chain reference 1024 to a preceding chain similar to the chain reference 724 as described in the second embodiment with reference to FIG. 7A.

[0222] The method of searching the data structure 1000 is substantially the same as that described with reference to FIG. 9 in the second embodiment.

[0223] Non-malleable forward change-in references Referring to FIG. 11, a data structure 1100 according to a fourth embodiment for creating an immutable reference 1118 to a change-in transaction 1116 is shown.

[0224] The fourth embodiment comprises a forward reference 1118 from the change-out transaction 1114 to the change-in transaction 1116 similar to those in the second and third embodiments, but instead of the forward reference 718 being the transaction id of the change-in transaction 1116, the reference comprises at least one of the inputs of the change-in transaction 1116. Preferably, the reference to at least one of the inputs is in the form of a transaction output point, such that the transaction output point comprises the transaction id of which it comprises an output and an index of said output. Preferably, the reference 1118 comprises a set of previous transaction outputs consumed by the change-in transaction 1116. The set of previous transaction outputs is referred to as PrevOuts change-in It is called. change-in An exemplary format for PreviousOuts change-in ={PrevOut 1 :(TxID Prev,1 ,vout 1 ),PrevOut 2 :(TxID Prev,2 ,vout 2 )} It is.

[0225] TxID Prev,n is the transaction id of the transaction with the output being consumed, and vout n where is the index of the output in the transaction. Prev,n ,vout n ) is a transaction output point. Each PrevOut in the set of PrevOuts for a transaction is itself unique, since each is a transaction output on the blockchain, and these are unique. Thus, the set of PrevOuts is also unique.

[0226] Preferably, the forward reference is stored in the script section of the output of the changeout transaction in the following format: OP_FALSE OP_RETURN 0x20 <TxID Prev1 > <index length><vout 1 >

[0227] If more than one funding input is used to fund a change-in transaction, additional inputs are added as such to the above format. <TxID Prevn > <index length><vout n >

[0228] More preferably, the script should call 0x20 after OP_RETURN and before the PrevOut(s) reference. <txid create >Equipped with.

[0229] Thus, the reference 1118 to the change-in transaction is not based on the transaction id or on any other malleable section or aspect of the change-in transaction 1116. In this way, even if a malicious miner modifies the transaction, the reference 1118 remains valid, thereby overcoming the malleability issue of the change-in transaction as discussed above under the heading "Malleability of the change-in transaction."

[0230] If a transaction is finalized (i.e., valid and all of its signatures use the appropriate flags that do not allow new inputs / outputs to be added), which can be assumed to be the case for any transaction of the aspects described herein (all input signatures should use the SIGHASH_ALL flag as discussed above), the only part of the transaction that can be modified is the unlocking script field. The locking script in an output cannot be changed, since the input must contain a signature that transfers the output. Any modification of the output invalidates these signatures. PrevOuts change-in As long as reference 1118 appears in the output of changeout transaction 1114, reference 1118 cannot be modified because it is located in the output script. Even if someone modifies the input script of the transaction, the PrevOut reference will remain the same and will lead us to the correct transaction when examining the dust chain.

[0231] 11 includes similar feature reference numbers and names as in the second and / or third aspects. For example, each add transaction 1104ba-d and last transaction 1126 includes a backward consume reference 1106a-f to a preceding transaction. This is similar to the add transactions 704a-d and last transaction 726 as shown in FIG. 7A, which also include backward consume references 706a-f to preceding transactions.

[0232] The method of forward probing the data structure 1100 as described in this embodiment is substantially the same as the method 900 described with reference to FIG. 9 in the second embodiment, except for the differences outlined below. In this embodiment, the reference extracted in step 922 is the PrevOuts transaction id rather than the transaction id of the change-in transaction. change-in The change-in transaction 1116 is found based on this reference 1118. The change-in transaction 1116 is found by looking for the transaction PrevOuts change-in With at least a subset of the outputs as input, the change-in transaction 1116 is then hashed to obtain a transaction id, and the method 900 continues as normal by finding 928 the next additional transaction based on the change-in transaction id.

[0233] This embodiment optionally waits and validates the change-in transaction 1116 for additional security. This embodiment optionally includes the second reference (608) feature of the first embodiment and / or the third back reference (610, 612a-c) feature.

[0234] The methods for adding data items to a chain of dust and conditionally creating new chains of dust described in the second embodiment operate substantially the same in this embodiment, except that different references are used.

[0235] Optionally, an immutable forward reference 1118 is used in addition to the forward references 718, 1018 as described in embodiments 2 and 3.

[0236] It will be appreciated that although the complete set of inputs of the change-in transaction is used in this embodiment, a subset of PrevOuts may also be used. For example, if a change-in transaction comprises two inputs such as: PreviousOuts change-in ={PrevOut 1 :(TxID Prev,1 ,vout 1 ),PrevOut 2 :(TxID prev,2 ,vout 2 )} A reference to a change-in transaction is based on only one of those two. Nevertheless, it is a unique reference to a change-in transaction because once this transaction is published to the Bitcoin network, the first-seeking rule and the fact that an output point can only be spent once on-chain ensure that this output can never be consumed by an alternative transaction. Note that "alternative" here refers to the structure of the transaction, i.e., its inputs, outputs, and value exchanges, preventing the transaction from undergoing non-functional changes through malleability.

[0237] Whether or not such malleability occurs, the final form of a transaction can always be uniquely identified by ascertaining which transactions consumed this output point.

[0238] Using only one reference can be preferable in that only a single output is needed to create a unique input-based (or PrevOut-based) reference, which greatly reduces the overall size of the reference, and this in turn reduces the transaction fee cost of including the reference in an on-chain transaction. The minimum size of a prevOut-based reference in Bitcoin can be as small as 36 bytes (32-byte TxID and 4-byte Vout), so the size of the reference also scales by an order of magnitude with the number of inputs of the referenced transaction.

[0239] Thus, the PrevOut reference may comprise at least one of the at least one input to the change-in transaction, and preferably the PrevOut reference comprises only one of the at least one input to the change-in transaction.

[0240] Backreference to changeout Two-way referencing allows pairs of transactions to indicate their relationship to one another. Furthermore, it allows the connection between the two to be specified independently of the transaction that is taken as the starting point, i.e., it allows forward and backward looking when the sequence of events or data items is linear.

[0241] However, in practice, achieving such a two-way reference is difficult due to the fact that each reference must generally exhibit uniqueness. Achieving the uniqueness property can be difficult due to circular references. The use of hash functions is a common method for assigning unique identifiers to data. However, it is not possible to create a two-way hash-based reference between two blockchain transactions, as this would create a circular reference.

[0242] 12 and 13, a data structure 1200 and a method 1300 for inspecting a data structure according to a fifth aspect are shown. The data structure 1200 comprises an immutable forward reference 1218 from the change-out transaction 1214 to the change-in transaction 1216 and a back reference 1224 from the change-in transaction 1216 to the change-out transaction 1214.

[0243] 12 includes like reference numbers and names for features similar to those of the second, third, and / or fourth aspects. For example, each add transaction 1204ba-d and last transaction 1226 includes a backward consume reference 1206a-f to a preceding transaction. This is similar to the add transactions 704a-d and last transaction 726 as shown in FIG. 7A, which also include backward consume references 706a-f to preceding transactions. The immutable forward reference 1218 is constructed and functions in the same or similar manner as the immutable forward reference 1118 as described with reference to FIG. 11.

[0244] The back reference 1224 comprises the transaction id of the change-out transaction 1224. This is possible because the back reference 1218 is no longer dependent on the transaction id of the change-in transaction 1216, thereby avoiding the problem of circular hash references as described above.

[0245] Using back references 1224, it is possible to look backwards in the dust chain through any change-out / change-in transactions. The computer-implemented method 1300 of the lookup, shown in Figure 13, begins at the last transaction 1226 in the dust chain. Those skilled in the art will appreciate that the method can optionally begin at any point in the dust chain by starting at the first step 1308 of the loop.

[0246] Like the method of backward investigation 900, advantageously, the method of investigation 1300 does not require hidden knowledge to investigate transactions other than the format of the transactions on the blockchain. All references used in the investigation are publicly available along with the data items on the blockchain. Thus, third parties can also investigate the chain of dust and retrieve, store, verify, and / or otherwise use data items stored in the blockchain without private or proprietary services. Notably, due to the nature of the blockchain and current data writing systems and methods, any operations performed on data stored in the blockchain are read-only. It is not practical to modify data stored in the blockchain.

[0247] The first step 1302 is to get the last transaction, from which the method walks backwards through the dust chain.

[0248] Optionally, the transaction id of the first transaction in the dust chain is stored in the last transaction. The transaction id of the initial transaction is stored for future reference.

[0249] The transaction id of the last transaction is extracted by hashing the last transaction 1306. The transaction id is assigned as the current transaction id. The method then enters a loop that operates on the current transaction.

[0250] The first step of the loop is to determine whether the current transaction id points to an initial transaction (1308). Optionally, this is done by comparing the transaction id of the current transaction with that of the initial transaction id stored in the second step 1304. Alternatively, this determination 1308 is made after the transaction is obtained (1310). The determination 1308 is then based on data and / or metadata stored in the transaction. For example, as described in the second aspect with reference to FIG. 6C, it may be possible to determine that a transaction is an initial transaction if it comprises a seed in the metadata.

[0251] If the current transaction is the initial transaction, the loop ends. Optionally, based on a supplied transaction id, the loop ends with another transaction.

[0252] The current transaction is retrieved 1310 based on the current transaction id (as part of determining if the current transaction was an initial transaction, unless the transaction has already been retrieved).

[0253] If the current transaction is an add transaction, then operation 1314 is optionally performed on the payload of the transaction, as determined 1312 based on the presence of a payload as described in the first aspect.

[0254] Preferably, the action is to validate the current transaction. The validation is based on the third back reference 610, 612a-c as described with reference to Figures 6A and 6B. The stream digest of the current payload is stored for validation in the next loop iteration, together with the stream digest for the next payload in the loop. If there is already a stream digest stored in a previous iteration in the loop, the stream digest of the current transaction is compared to said stored previous stream digest to validate that the stream digest is correct.

[0255] Additionally or alternatively, the data items of the payload are stored for later use. Additionally or alternatively, a callback provided by the researcher is invoked, thereby allowing any action to be taken on the payload by the researcher.

[0256] The transaction id of the next transaction in the chain is extracted from the current transaction 1316. The transaction id of the next transaction in the chain is stored as an input to the current transaction.

[0257] The next transaction id is stored as the current transaction id (1318) and the loop restarts at the top of the loop 1318.

[0258] Returning to determining 1312 the type of transaction, if the transaction is a change-in transaction, a reference to the change-out transaction is obtained. Preferably, the reference is obtained by extracting 1320 the reference from the change-in transaction in which it is stored. In this embodiment, the reference to the change-out transaction is the transaction id of the change-out transaction.

[0259] The changeout transaction is then retrieved 1322 using the transaction id.

[0260] The transaction id of the next transaction in the chain is extracted from the current transaction 1324. The transaction id of the next transaction in the chain is stored as an input to the changeout transaction.

[0261] The next transaction id is stored as the current transaction id (1326) and the loop resumes at the top of the loop 1318.

[0262] The method for adding data items to a chain of dust and conditionally creating new chains of dust in this embodiment operates in substantially the same manner as the second embodiment, except that different references are used between change-ins and change-outs.

[0263] The method for forward walking the data structure 1200 of the present embodiment operates in substantially the same manner as the fourth embodiment, since it has the same forward references from change-out to change-in.

[0264] Those skilled in the art will appreciate that the references may also be used in reverse, such that the change-out transaction comprises the transaction id of the change-in transaction, and the change-in transaction comprises a reference to the input of the change-out transaction.

[0265] Step 1312 of determining the transaction type (add or change-in) is performed in the same or similar manner as described with reference to the forward lookup method, except that a change-in transaction is determined rather than a change-out transaction (because the backward lookup encounters the change-in lookup first). Alternatively, the absence of a dust input in the current transaction is used to indicate that the current transaction is a change-in transaction. Alternatively, since a change-in has one less output than an add transaction, the number of inputs is used to determine the type of transaction.

[0266] Non-malleable rear changeout reference Referring to FIG. 14 , a data structure 1400 according to a sixth aspect for creating an immutable forward reference 1418 from a change-out transaction 1414 to a change-in transaction 1416 and an immutable back reference 1424 from the change-in transaction 1416 to the change-out transaction 1414.

[0267] 14 includes similar reference numbers and names for features as in the second, third, fourth, and / or fifth aspects. For example, each add transaction 1404ba-d and last transaction 1426 includes a backward consume reference 1406a-f to a preceding transaction. This is similar to the add transactions 704a-d and last transaction 726 as shown in FIG. 7A, which also include backward consume references 706a-f to preceding transactions.

[0268] The forward reference 1418 from the change-out transaction 1414 to the change-in transaction 1416 is formed and operates in substantially the same manner as the forward reference 1218 described in the fifth aspect.

[0269] A back reference 1424 from the change-in transaction 1416 to the change-out transaction 1414 is change-out Based on the set. change-out Set PrevOuts change-in The set is constructed in the same way as described in the fourth embodiment, but using transaction outputs consumed by changeout transactions. Using a similar method to the references in the fourth embodiment provides the same benefits, especially with regard to immutability. change-out The set optionally comprises only one of the at least one input.

[0270] Chasing back references 1424 is done in much the same way. change-out Find the transaction that is in the set and consumes the index. This transaction is the change-out transaction.

[0271] Thus, the method of looking forward or backward operates in substantially the same manner as described in the fifth aspect, except that when looking backward, the transaction id of the changeout transaction is not used, and PrevOuts change-out The references are used as explained above.

[0272] The method for adding data items to a chain of dust and conditionally creating new chains of dust as described in the second embodiment operates substantially the same as in this embodiment, except that different references are used.

[0273] Rendezvous Transactions According to a seventh aspect, the Dust chain further comprises a rendezvous transaction. Further details of the rendezvous transaction are described in UK Patent Application No. 2020279.2 (filed on December 21, 2020 in the name of nChain Holdings Limited), which is incorporated herein by reference.

[0274] Dust chaining works substantially the same as adding a new data item (as described with reference to FIG. 8), except that the presence of rendezvous transactions needs to be considered with respect to ancestor restrictions.

[0275] The dust chain operates substantially in the same way with respect to investigating the dust chain (as described with reference to FIG. 9 and FIG. 13), except that an additional check is made in transaction type confirmation step 912, 1312. Now, if the current transaction is determined to be a rendezvous transaction, it is similarly repeated for the additional transaction, since it has the same dust reference as the additional transaction. The current transaction is identified as a rendezvous transaction based on the presence of multiple payloads, as described with reference to the first aspect. A rendezvous transaction has multiple dust inputs and outputs associated with different chains, and the correct dust output is selected to continue the investigation. A data layout 1800 of the dust chain with a rendezvous transaction 1802 is provided in FIG. 18. Since there are multiple payloads, they are indexed in the rendezvous transaction by "r", and the associated outputs are provided in 2r and 2r+1.

[0276] If the dust chain and rendezvous transaction are found by searching forward, the method 900 as described with reference to FIG. 9 additionally comprises the following steps.

[0277] These steps occur as a result of determining that the current transaction is a rendezvous transaction 912. The associated outputs of the rendezvous transaction are needed to continue walking the chain.

[0278] First, an index "r" is determined by finding the input that consumes the dust output point of the preceding transaction. The output that stores the data is then located at 2r+1, and the chain of dust outputs is located at 2r.

[0279] Then, when the chain of dust outputs is found, the next transaction is found. The next transaction is the output point (TxID rendezvous ,2r), and TxID is the transaction id of the rendezvous transaction and is obtained by hashing the rendezvous transaction.

[0280] This next transaction is used as the current transaction at the beginning of loop 910 of method 900 and the method continues.

[0281] Optionally, the data stored in 2r+1 has operations performed on it, such as described with respect to performing the operation step 914 of the method 900 of FIG.

[0282] As an example, if chain L in Figure 18 is being looked at forward, the outputs associated with the L chain are located at positions 4 and 5, the data is stored at 5, and the dust chain is stored at 4, i.e. r=2. r is determined by looking at the dust output (the 0th output) of the L+2 transaction (the transaction preceding the rendezvous transaction) and finding which input consumes said output. In this case, the input is at index 2 of the rendezvous transaction. Once it is determined that r=2, the associated outputs of the rendezvous transaction are at 2r=4 and 2r+1=5. To continue the lookup into the L+4 transaction, the rendezvous transaction is hashed and the output (TxID rendezvous The transaction that consumes L,4) is L+4.

[0283] If a chain of dust and a rendezvous transaction are found by looking backwards, the method 1300 as described with reference to Figure 13 additionally comprises the following steps: These additional steps are similar to the steps of looking forward, except in reverse.

[0284] TxID i =TxID i-1 In addition to the final step of assigning i =k i-1 The index portion of the dust output point (herein called "k") is also stored at each loop iteration (and initial step) so as to additionally assign

[0285] These steps occur as a result of determining that the current transaction is a rendezvous transaction 1312. The associated inputs of the rendezvous transaction are needed to continue traversing the chain.

[0286] First, "r" is k i / 2. The "r" index gets the entry at index "r" of the rendezvous transaction. The entry is the TxID i-1 Equipped with.

[0287] TxID i =TxID i-1 After assigning , the loop continues from the start step 1308.

[0288] Optionally, 2r+1 (or as alternatively described, k i+1 ) has operations performed on it, as described with respect to performing the operational step 1314 of the method 1300 of FIG.

[0289] As an example, if chain L of FIG. 18 is traversed backwards, it will determine that the current transaction is rendezvous transaction 1802. From the previous iteration, index k i are already known and stored (from the consumed output points of the previous iteration). i is 4, which we divide by 2 to get r=2. Therefore, the relevant input of the rendezvous transaction is at index 2. The transaction id of the output point consumed by the input at index 2 is TxID i-1 To continue the investigation, transaction L+2 is added with transaction id TxID i-1 Can be found using.

[0290] Optionally, any data associated with the rendezvous transaction is captured and stored for use by the researcher.

[0291] Malleability of PrevOut transactions According to an eighth embodiment, a method is described to overcome malleability of PrevOut inputs. Transactions that fund (and are used as references and referred to in this embodiment as "funding transactions") change-in and change-out transactions as described in embodiments 4 and 6 suffer from the same malleability problems as described throughout this description. If the funding transaction is modified between when it is used as a reference and when it is confirmed as a reference, the chain can break irreversibly in at least one direction, preventing investigation of the chain of dust.

[0292] Furthermore, if these funding transactions are not confirmed on the blockchain, they contribute to the unconfirmed ancestry count.

[0293] To overcome this malleability problem, a solution similar to that described with reference to aspect 3 is implemented: before approaching the ancestry limit (and therefore before it becomes necessary to use the funding transaction in change-in and change-out transactions), the funding transaction is submitted to the blockchain and confirmed. By having the funding transactions already confirmed on the blockchain, they become immutable.

[0294] Preferably, the change-out transaction is not put on the blockchain until the funding transaction for the change-in transaction is confirmed. Preferably, the change-in transaction is not put on the blockchain until the funding transaction for the change-out transaction is confirmed.

[0295] This has the added benefit that the funding transaction does not contribute to the unconfirmed ancestry limit. Alternatively or additionally, the threshold number to consider this funding transaction is 2 less than the maximum unconfirmed ancestry limit.

[0296] Optionally, submitting the change-in funding transaction so that it is confirmed and immutable on the blockchain is performed by a funding service associated with the service as described with reference to Figure 16. The funding service optionally maintains some funding transactions that have already been confirmed on the blockchain and are ready for the data writing service to use.

[0297] Data writing service According to a further aspect, any one or more of the data structures and methods of the preceding aspects may be used in conjunction with a platform processor as described below to provide at least the ordered append-only data storage as described above. This further aspect may be a Platform as a Service (Paas) and Software as a Service (Saas) offering that advantageously enables rapid real-world useful business and technology applications, such as management of software-controlled technology systems or smart contracts, using a blockchain network such as the BSV blockchain.

[0298] An overview of the Platform Services can be seen in Figure 15, which shows a high level schematic diagram of the system. The Platform Services has a platform processor 1500 that provides an API 1508 through which the services can be accessed by one or more clients.

[0299] The platform services 1500 as shown in this figure consist of three groups of services, which aim to enable users and organizations to easily and securely take advantage of the benefits provided by the inherent properties of blockchain without actually implementing any blockchain-based software, knowledge, or libraries on the client side. - A data service 1502 aimed at simplifying the use of the chain as a commodity data ledger. Preferably, the data service uses the data structures and methods provided herein to implement writing and reading of data to and from the blockchain. - Computation services 1504 aimed at providing a generalized computation network backed by digital assets such as Bitcoin SV. - Commerce services that provide enterprise-class capabilities to conduct transactions using digital assets such as Bitcoin SV1506. Since the API is implemented as a web service, requests may be received from clients at the API via or using the HTTPS protocol. The requested service is then implemented by one or more service modules or processing resources 1502-1506 using background software 1510 for implementing implementations of resources, libraries, and / or key management wallets related to the blockchain, i.e., for creating, processing, and submitting transactions related to the blockchain. Once processed, the transactions may be submitted to the blockchain network 1512 (on behalf of a client implementing any such functionality or transaction library). At most, the client may or can implement a digital wallet or the like related to cryptocurrency or some other digital asset, although this is not required since the platform services 1500 may also be capable of providing and managing digital assets for the client.

[0300] FIG. 16 provides a more coarse schematic diagram of a number of services related to the blockchain, which may be implemented by a platform 1600 associated with an API through which one or more of the services offered may be accessed. As seen in this figure, the data service 1602 may include a data write service 1602a and a data read service 1602b. The data write service and the data read service preferably use data structures as described in the sixth aspect. Alternatively, any one or more of the other aspects described herein may be used. An exemplary use of the data write service 1602a is an event stream as briefly discussed above. Further details of the event stream are discussed with reference to FIGS. 4 to 8 of UK Patent Application No. 2002285.1 (filed in the name of nChain Holdings Limited on February 19, 2020), which is incorporated herein by reference. The data write service 1602a allows clients to write data to the blockchain in a simple, secure and optimized manner. The data reading service 302b allows clients to submit queries that return data stored in the blockchain. This can be using filtered streams such that clients can pre-define the type of data they want to read from the blockchain ad-hoc or periodically, i.e., within a certain time frame, or the type of data related to related or unrelated events or documents being processed in the blockchain 1610. A data archiving function allows access to logs of previous transactions for a specified event or contract.

[0301] Computation services 1606 of platform 1600 include smart contract related applications 1606a and frameworks 1606b, which in some embodiments may be represented as state machines in a blockchain 1610. Computation services 1606 interact with data services 1602 because data needs to be input and results need to be provided to clients for any such computation.

[0302] The commerce services 1604 are responsible for providing enterprise-class capabilities via the enterprise wallet 1604a to explore the blockchain 1610 based on best-in-class security practices and technologies. For example, in some embodiments, the enterprise wallet may implement functionality to enable blockchain transaction processing when more than one person or user or account may need to approve a transaction that meets defined criteria, i.e., criteria related to large value cryptocurrencies that exceed predefined limits. The enterprise wallet may also include functionality to implement a threshold number of signatures and / or types of signatures for transferring large amounts of digital assets, such as cryptocurrencies or tokens that represent another resource. Transfers of these assets may then be represented on the blockchain according to criteria-based processing applied by such enterprise wallet implementations.

[0303] SPV service 1608 (simplified payment verification) is an example application that does not run a miner node and therefore requires information from the blockchain but does not include a direct link to it. Such an SPV service 1608 allows lightweight clients to verify that a transaction is included in the blockchain without downloading the entire blockchain 1610.

[0304] Data writing device Turning now to FIG. 17, an exemplary simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems shown and described above. For example, the computing device 2600 may be configured to be used as one or more components of the DBMS of the figure, or the computing device 2600 may be configured to be a client entity associated with a given user, where the client entity makes database requests to a database managed by the DBMS of FIG. 9. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 17, the computing device 2600 may include one or more processors with one or more levels of cache memory and a memory controller (collectively labeled 2602), which may be configured to communicate with a storage subsystem 2606, including a main memory 2608 and persistent storage 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information, such as details related to transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0305] The processor 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0306] The bus subsystem 2604 may provide a mechanism for allowing various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0307] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and transmitting data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician may be able to transmit data to and receive data from the device while at a remote location, such as a data center.

[0308] The user interface input devices 2612 may include one or more user input devices such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0309] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection, or other display device. In general, use of the term "output device" is intended to include any possible type of device and mechanism for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used to present a user interface, for example, to aid in user interaction with applications that execute the described processes and variations thereof, when such interaction may be appropriate.

[0310] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives with associated removable media (e.g., CD-ROM or DVD or Blue-Ray), and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data related to transactions and blocks as described in this disclosure.

[0311] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 16 is intended only as a specific example intended to illustrate a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 16.

[0312] The various methods described above may be implemented by a computer program. The computer program may include computer code adapted to instruct a computer to perform one or more functions of the various methods described above. The computer program and / or code for performing such methods may be provided to an apparatus such as a computer in one or more computer readable media, or more generally in a computer program product. The computer readable medium may be transitory or non-transitory. The one or more computer readable media may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system or propagation medium for data transmission, for example, for downloading code via the Internet. Alternatively, the one or more computer readable media may take the form of one or more physical computer readable media, such as a semiconductor or solid state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk such as a CD-ROM, a CD-R / W, or a DVD.

[0313] Unless specifically stated otherwise, and as will be apparent from the discussion that follows, throughout the description, discussions utilizing words such as "determining," "providing," "calculating," "calculating," "identifying," "combining," "establishing," "transmitting," "receiving," "storing," "estimating," "ascertaining," "obtaining," and the like will be understood to refer to the activities and processing of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electrical) quantities in the computer system's registers and memory into other data that is similarly represented as physical quantities in the computer system's memory or registers or other such information storage, transmission, or display device.

[0314] The present disclosure will now be discussed based on the following clauses related to the above aspects, which are provided herein as exemplary embodiments for better explanation, description, and understanding of the aspects and embodiments.

[0315] 1. A computer-implemented data structure relating to a blockchain, comprising: A first output; a representation of the first data item; A first transaction comprising: a further representation of the first data item; and a representation of a second data item; and a first input associated with a first output; The second output and and a second transaction.

[0316] 2. The computer-implemented data structure according to clause 1, wherein the first data item is metadata and a seed.

[0317] 3. A computer-implemented data structure according to clause 2, wherein the representation of the first item comprises metadata that comprises the seed.

[0318] 4. A computer-implemented data structure according to clause 2 or 3, wherein the further representation of the first item comprises a seed.

[0319] 5. The computer-implemented data structure according to clause 1, wherein the first representation of the first data item comprises a hash of the data item.

[0320] 6. A computer-implemented data structure according to clause 1, wherein the first representation of the first data item comprises the data item.

[0321] 7. A computer-implemented data structure according to clause 5 or 6, wherein the first transaction comprises a preimage comprising a first representation of the first data item.

[0322] 8. The computer-implemented data structure according to clause 7, wherein a further representation of the first data structure comprises a hash of a preimage of the first transaction.

[0323] 9. A computer-implemented data structure according to any one or more of clauses 1 to 8, wherein the second transaction further comprises a reference to the first transaction.

[0324] 10. A transaction of a first type comprising a first reference to a transaction of a second type; The second type of transaction 10. The computer-implemented data structure according to any one or more of clauses 1 to 9, further comprising:

[0325] 11. The computer-implemented data structure according to clause 10, wherein the first reference is stored to an output of a transaction of the first type.

[0326] 12. A transaction of a first type having an output with a first reference to a transaction of a second type; The second type of transaction A computer-implemented data structure relating to a blockchain comprising:

[0327] 13. A computer-implemented data structure according to any one or more of clauses 10 to 12, wherein the first reference is an immutable reference.

[0328] 14. A computer-implemented data structure according to clause 13, wherein the first reference is based on an immutable characteristic of a transaction of the second type.

[0329] 15. A computer-implemented data structure according to any one or more of clauses 10 to 14, wherein the first reference comprises a transaction id of a transaction of the second type.

[0330] 16. A computer-implemented data structure according to any one or more of clauses 10 to 15, wherein the second type of transaction comprises at least one input, and the first reference is based on at least one of the at least one input to the second type of transaction.

[0331] 17. A computer-implemented data structure according to any one or more of clauses 10 to 16, wherein a second type of transaction comprises a second reference.

[0332] 18. A computer-implemented data structure according to clause 17, wherein a second reference is stored to an output of a transaction of a second type.

[0333] 19. A computer implemented method according to clause 17 or 18, wherein the second reference comprises a transaction id of a transaction of the first type.

[0334] 20. A computer-implemented data structure according to clause 17 or 18, wherein the second reference is an immutable reference.

[0335] 21. A computer-implemented data structure according to clause 20, wherein the second reference is based on an immutable characteristic of the first type of transaction.

[0336] 22. A computer-implemented data structure according to any one or more of clauses 17, 18, 20, or 21, wherein the first type of transaction comprises at least one input, and the second reference is based on at least one of the inputs of the at least one transaction of the first type.

[0337] 23. A computer-implemented data structure according to clause 16 or 22, wherein the reference with at least one input is in the form of a transaction output point.

[0338] 24. A computer-implemented data structure relating to a blockchain, comprising: a first reference to a transaction of a second type; At least one input and a first type of transaction comprising: a second reference to a transaction of the first type; At least one input and and a second type of transaction comprising: A computer-implemented data structure, wherein the first reference is based on at least one of the at least one input to the second type of transaction and the second reference is based on at least one of the at least one input to the first type of transaction.

[0339] 25. A computer-implemented data structure relating to a blockchain, comprising: a first reference to a transaction of a second type; At least one input and A first type of transaction comprising: a second reference to a transaction of the first type; At least one input and and a second type of transaction comprising: A computer-implemented data structure, wherein the first reference comprises a transaction id of a transaction of a second type, and the second reference is based on at least one of the at least one input to the transaction of the first type.

[0340] 26. A computer-implemented data structure relating to a blockchain, comprising: a first reference to a transaction of a second type; At least one input and A first type of transaction comprising: a second reference to a transaction of the first type; At least one input and and a second type of transaction comprising: A computer-implemented data structure, wherein the first reference is based on at least one of the at least one input to a transaction of a second type, and the second reference comprises a transaction id of the transaction of the first type.

[0341] 27. A computer-implemented method relating to a set of transactions in a blockchain system, comprising: receiving a request, the request triggering a representation of the data item to be stored in the blockchain; obtaining a most recent transaction in a set of transactions; An input that is related to an output from the most recent transaction; and Output, A representation of the data items to be stored in the blockchain; and A reference to the most recent transaction and Creating a new blockchain transaction comprising: and submitting the transaction to a blockchain.

[0342] 28. The computer-implemented method according to clause 27, wherein the reference to the most recent transaction is a hash of an immutable feature of the most recent transaction.

[0343] 29. The computer-implemented method according to clause 28, wherein the most recent transaction has a preimage and the reference to the most recent transaction is a hash of the preimage of the most recent transaction.

[0344] 30. A computer-implemented method according to any one or more of clauses 27 to 29, wherein the new blockchain transaction further comprises a reference to an initial transaction in the set of transactions.

[0345] 31. The computer-implemented method according to clause 30, wherein the reference to an initial transaction in the set of transactions is based on the initial transaction.

[0346] 32. The computer-implemented method according to clause 30 or 31, wherein the reference to the initial transaction is a hash of the initial transaction.

[0347] 33. Creating a second type of transaction; creating a first type of transaction having an input related to a transaction output from a most recent transaction in the set of transactions; submitting a second type of transaction to the blockchain; 33. The computer-implemented method according to any one or more of clauses 27 to 32, further comprising submitting the first type transaction to the blockchain.

[0348] 34. A computer-implemented method relating to a set of transactions in a blockchain system, comprising: creating a second type of transaction; creating a first type transaction comprising at least one input related to an output from a most recent transaction in the set of transactions; submitting a second type of transaction to the blockchain; and submitting the first type of transaction to a blockchain.

[0349] 35. Determining a total number of transactions in a subset of the set of transactions; and determining whether a total number of transactions in the subset of transactions is greater than or equal to a threshold.

[0350] 36. The computer-implemented method according to clause 35, in which membership of a subset of transactions is defined by whether the transaction has been confirmed on the blockchain.

[0351] 37. The computer-implemented method according to clause 35 or 36, wherein membership in the subset of transactions is defined by a consumption relationship with any transaction in the set of transactions.

[0352] 38. The computer-implemented method according to clause 35 or 36, wherein membership of the subset of transactions is additionally defined by a threshold value.

[0353] 39. A computer-implemented method according to any one or more of clauses 35 to 38, wherein the subset of transactions comprises a first chain of transactions.

[0354] 40. The computer-implemented method according to clause 39, wherein the subset of transactions is a first chain of transactions.

[0355] 41. The computer-implemented method according to clause 39 or 40, wherein a first chain of transactions is constructed such that each transaction except for the first transaction in the subset comprises a reference to the previous transaction in the chain.

[0356] 42. A computer-implemented method according to clause 41, in which the reference to the previous transaction is an input that relates to a transaction output from the previous transaction.

[0357] 43. A computer-implemented method according to any one or more of clauses 40 to 42, wherein the set of transactions comprises a plurality of subsets of transactions.

[0358] 44. The computer-implemented method according to clause 43, wherein the set of transactions comprises a further chain of transactions.

[0359] 45. A computer-implemented method according to any one or more of clauses 35 to 44, in which the threshold is based on an ancestry restriction.

[0360] 46. ​​A computer-implemented method according to clause 45, wherein the threshold is one less than the ancestry limit.

[0361] 47. A computer-implemented method according to any one or more of clauses 35 to 46, wherein the step of creating and issuing the second type of transactions and the first type of transactions is based on a comparison of a total number of transactions in the subset of transactions to a threshold value.

[0362] 48. The computer-implemented method according to clause 47, wherein the step of creating and issuing the second type of transactions and the first type of transactions is performed based on whether a total number of transactions in the subset of transactions is greater than or equal to a threshold.

[0363] 49. A computer-implemented method according to any one or more of clauses 33 to 48, wherein a transaction of a first type comprises a first reference to a transaction of a second type.

[0364] 50. The computer-implemented method according to clause 49, wherein the first reference is an immutable reference.

[0365] 51. The computer-implemented method according to clause 50, wherein the first reference is based on an immutable characteristic of the second type of transaction.

[0366] 52. A computer-implemented method according to any one or more of clauses 49 to 51, wherein the first reference comprises a transaction id of a transaction of the second type.

[0367] 53. A computer-implemented method according to any one or more of clauses 33 to 52, wherein the second type transaction is confirmed on the blockchain before issuing the first type transaction.

[0368] 54. A computer-implemented method according to any one or more of clauses 49 to 53, wherein the second type of transaction comprises at least one input, and the first reference is based on at least one of the inputs of the at least one transaction of the second type.

[0369] 55. A computer-implemented method according to any one or more of clauses 33 to 54, wherein the second type of transaction comprises a second reference to a transaction in the set of transactions.

[0370] 56. The computer-implemented method according to clause 55, wherein the second reference is a reference to an initial transaction in the set of transactions.

[0371] 57. The computer-implemented method according to clause 56, wherein the reference to the initial transaction comprises a transaction id of the initial transaction.

[0372] 58. A computer-implemented method according to any one or more of clauses 55 to 57, wherein the second reference is an immutable reference.

[0373] 59. The computer-implemented method according to clause 58, wherein the second reference is based on an immutable characteristic of the first type of transaction.

[0374] 60. A computer-implemented method according to any one or more of clauses 55 to 59, wherein the second reference comprises a transaction id of a transaction of the first type.

[0375] 61. A computer-implemented method according to clause 58 or 59, wherein the second reference is based on at least one of the inputs of at least one transaction of the first type.

[0376] 62. A computer-implemented method according to clause 54 or 61, wherein the reference based on at least one of the at least one input is in the form of a transaction output point.

[0377] 63. A computer-implemented method for forward searching a set of blockchain transactions, comprising: (a) obtaining a current transaction in a set of transactions; (b) determining that the current transaction is a transaction of the first type, and based on this determination, i. obtaining a reference to a transaction of a second type based on the transaction of a first type; ii. obtaining a transaction of the second type based on a reference to the transaction of the second type; and iii. Following step (c) with the second type of transaction as the current transaction. and (c) obtaining a current transaction identifier; (d) obtaining a further transaction that references the current transaction identifier; (e) starting the further transaction as a current transaction to perform steps (b), (c), (d), and (e) to create a loop.

[0378] 64. The computer-implemented method according to clause 63, wherein a reference to a transaction of the second type is stored in a transaction of the first type, and the reference is obtained by extracting the reference from the transaction of the first type.

[0379] 65. If the reference to the second type transaction comprises a transaction id of the second type transaction, the step of obtaining the second type transaction comprises: 65. The computer-implemented method according to clause 63 or 64, comprising finding a transaction in the blockchain or in a blockchain network node with a transaction id that is the same as the transaction id of the second type of transaction.

[0380] 66. If the reference to the second type transaction comprises a set of at least one input to the second type transaction, obtaining the second type transaction comprises: The computer-implemented method according to clause 63 or 64, comprising finding a transaction in the blockchain or within a blockchain network node with at least one input of the set of inputs as included in a reference to a transaction of the second type.

[0381] 67. A computer-implemented method according to any one or more of clauses 63 to 66, further comprising the step of determining that the current transaction is not a transaction of the second type and, based on this determination, performing an action on a data payload associated with the current transaction, followed by step (c).

[0382] 68. A computer-implemented method according to any one or more of clauses 63 to 67, wherein the current transaction is determined to not be a transaction of the first type based on content of the current transaction.

[0383] 69. The computer-implemented method according to clause 68, wherein the current transaction is determined to not be a first type transaction based on a size of the output of the current transaction.

[0384] 70. The step of performing an operation on a data payload comprises: storing a hash based on a data payload of a preceding transaction; extracting from the current transaction a reference to a data payload of a prior transaction; and verifying that the hash based on the data payload of the preceding transaction and the reference to the data payload of the preceding transaction are valid.

[0385] 71. The computer-implemented method according to clause 70, wherein the reference to the prior transaction is a further hash of the payload of the prior transaction.

[0386] 72. The computer-implemented method according to clause 70 or 71, wherein the verifying step comprises determining whether a hash of the data payload of the preceding transaction and a reference to the data payload of the preceding transaction are the same.

[0387] 73. To be performed before step (a), obtaining an initial transaction in a set of transactions; verifying that the initial transaction comprises a seed value; hashing the initial transaction to obtain an initial transaction identifier; obtaining a second transaction that references the first transaction identifier; verifying that the second transaction comprises a seed value that is the same as the seed value of the first transaction; hashing the second transaction to obtain a second transaction identifier; obtaining a third transaction that references the second transaction identifier; moving to step (b) with the third transaction as the current transaction; and 73. The computer-implemented method according to any one or more of clauses 63 to 72, further comprising:

[0388] 74. To be performed after step (a), A computer-implemented method according to any one or more of clauses 63 to 73, further comprising the step of terminating the investigation based on whether the current transaction is the last transaction, wherein the step of determining whether the current transaction is the last transaction is based on data included in the current transaction.

[0389] 75. To be carried out after step (a), determining that the current transaction is a third type transaction, and based on this determination, i. obtaining an index for an input that comprises a reference to a preceding transaction; ii. obtaining an output associated with an input that comprises a reference to a previous transaction; iii. obtaining a next transaction based on the obtained output; and iv. Continue with step (c) with the next transaction as the current transaction. 75. A computer-implemented method according to any one or more of clauses 63 to 74, further comprising the step of:

[0390] 76. A computer-implemented method for backward-tracing a set of blockchain transactions, comprising: (a) obtaining a current transaction in a set of transactions; (b) determining that the current transaction is a transaction of a second type, and based on this determination, i. obtaining a reference to a first type transaction based on a second type transaction; ii. obtaining a transaction of the first type based on a reference to the transaction of the first type; and iii. continuing with step (c) with the first type of transaction as the current transaction; and (c) obtaining a transaction identifier of a preceding transaction from the current transaction; (d) obtaining the preceding transaction based on a transaction identifier of the preceding transaction; (e) performing steps (b), (c), (d), and (e) starting with the previous transaction as a current transaction to create a loop.

[0391] 77. The computer-implemented method according to clause 76, wherein a reference to a transaction of the first type is stored in a transaction of the second type, and the reference is obtained by extracting the reference from the transaction of the second type.

[0392] 78. If the reference to the first type transaction comprises a transaction id of the first type transaction, obtaining the first type transaction comprises: 78. The computer-implemented method according to clause 76 or 77, comprising finding a transaction in the blockchain or within a blockchain node with a transaction id that is the same as the transaction id of the first type of transaction.

[0393] 79. If the reference to the first type transaction comprises a set of at least one input to the first type transaction, obtaining the first type transaction comprises: 78. The computer-implemented method according to clause 76 or 77, comprising finding a transaction in the blockchain or within a blockchain node with at least one input of the set of inputs as included in a reference to a transaction of the first type.

[0394] 80. A computer-implemented method according to any one or more of clauses 76 to 79, further comprising the step of determining that the current transaction is not a transaction of the first type and, based on this determination, performing an action on a data payload associated with the current transaction, followed by step (c).

[0395] 81. A computer-implemented method according to any one or more of clauses 76 to 80, in which a current transaction is determined to not be a transaction of the second type based on the content of the current transaction.

[0396] 82. The computer-implemented method according to clause 81, wherein the current transaction is determined to be not a change-in transaction based on whether the current transaction has a data payload that comprises a pre-image.

[0397] 83. The step of performing an operation on a data payload comprises: storing a hash based on a data payload of a preceding transaction; extracting from the current transaction a reference to a data payload of a prior transaction; and verifying that the hash based on the data payload of the preceding transaction and the reference to the data payload of the preceding transaction are valid.

[0398] 84. The computer-implemented method according to clause 83, wherein the reference to the prior transaction is a further hash of the payload of the prior transaction.

[0399] 85. The computer-implemented method according to clause 83 or 84, wherein the verifying step comprises determining whether a hash of the data payload of the preceding transaction and a reference to the data payload of the preceding transaction are the same.

[0400] 86. To be performed before step (a), obtaining a last transaction in a set of transactions; obtaining the transaction id of the first transaction in the set of transactions from the last transaction; hashing the last transaction to obtain a last transaction identifier; obtaining a second transaction that references the last transaction identifier; and moving to step (b) with the second transaction as the current transaction.

[0401] 87. To be performed after step (a), The computer-implemented method according to clause 86, further comprising terminating the search based on whether the transaction id of the current transaction is equal to the initial transaction id.

[0402] 88. To be performed after step (a), A computer-implemented method according to any one or more of clauses 76 to 87, further comprising terminating the investigation based on whether the current transaction is initial / the initial transaction, wherein determining whether the current transaction is an initial transaction is based on data included in the data payload of the current transaction.

[0403] 89. To be performed after step (a), determining that the current transaction is a third type transaction, and based on this determination, i. obtaining an index for the input of the current transaction; ii. obtaining a reference to a previous transaction based on the obtained input of the current transaction; iii. obtaining a preceding transaction based on the reference; and iv. Following step (c) with the preceding transaction as the current transaction. 89. The computer-implemented method according to any one or more of clauses 76 to 88, further comprising the step of:

[0404] 90. A computer-implemented method for forward searching a set of blockchain transactions, comprising: (a) obtaining a current transaction in a set of transactions; (b) determining that the current transaction is a third type transaction, and based on this determination, i. obtaining an index for an input that comprises a reference to a previous transaction; ii. obtaining an output associated with an input that comprises a reference to a previous transaction; iii. obtaining a next transaction based on the obtained output; and iv. The next transaction is treated as the current transaction and the steps following step (c) are performed. and (c) obtaining a current transaction identifier; (d) obtaining a further transaction that references the current transaction identifier; (e) starting the further transaction as a current transaction to perform steps (b), (c), (d), and (e) to create a loop.

[0405] 91. A computer-implemented method for backward-tracing a set of blockchain transactions, comprising: (a) obtaining a current transaction in a set of transactions; (b) determining that the current transaction is a third type transaction, and based on this determination, i. obtaining an index for the input of the current transaction; ii. obtaining a reference to a previous transaction based on the obtained input of the current transaction; iii. obtaining a preceding transaction based on the reference; iv. The steps following step (c) are performed with the preceding transaction as the current transaction. and (c) obtaining a transaction identifier of a preceding transaction from the current transaction; (d) obtaining the preceding transaction based on a transaction identifier of the preceding transaction; (e) performing steps (b), (c), (d), and (e) starting with the previous transaction as a current transaction to create a loop.

[0406] 92. A computing device comprising a processor and a memory, the memory including executable instructions which, upon execution by the processor, cause the device to perform a computer-implemented method as set forth in any one or more of clauses 27 to 62.

[0407] 93. A data writing device according to clause 92; and a computing device configured to issue a request to a data writing device to provide the data.

[0408] 94. A computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer, cause the computer to perform any one or more of the methods of clauses 27 to 62.

[0409] 95. A computing device comprising a processor and a memory, the memory including executable instructions which, upon execution by the processor, cause the device to perform a computer-implemented method as set forth in any one or more of clauses 63 to 75.

[0410] 96. A computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer, cause the computer to perform any one or more of the methods of clauses 63 to 75.

[0411] 97. A computing device comprising a processor and a memory, the memory including executable instructions which, upon execution by the processor, cause the device to perform a computer-implemented method described in any one or more of clauses 76 to 91.

[0412] 98. A computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer, cause the computer to perform any one or more of the methods of clauses 76 to 91.

[0413] The term "comprising" as used in this specification and the claims means "consisting at least in part of." When interpreting each statement in this specification and the claims that includes the term "comprising," features other than those following the term may also be present. Related terms such as "comprise" and "comprises" should be interpreted in the same manner.

[0414] As used herein, the term "and / or" means "and" or "or" or both. As used herein, "(s)" after a noun means the plural and / or the singular of the noun. The reference of an element in the singular does not exclude the reference of such element in the plural and vice versa.

[0415] It should be understood that the above description is intended to be illustrative, not restrictive. Many other implementations will become apparent to those skilled in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to certain exemplary implementations, it will be recognized that the present disclosure is not limited to the described implementations, but can be practiced with modifications and alterations within the scope of the appended claims. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. The scope of the present disclosure should therefore be determined in conjunction with the appended claims, along with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0416] 101 Blockchain Network 103 users 104 Blockchain nodes 105 Client Applications 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 160 Side Channel 201 Header 202 Input Field 203 Output Fields 301 Transaction Engine 302 UI layer 350 UI 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 502 Events 504 Blockchain Transactions 1500 Platform Services 1502 Data Services 1504 Calculation Services 1506 Commerce Services 1508 Platform API 1510 Blockchain Node Software 1512 Blockchain Network 1600 Platform 1602 Data Services 1604 Commerce Services 1606 Computational Services 1608 SPV Service 1610 Blockchain Network 2602 Processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Memory Subsystem 2610 File Storage Subsystem 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface 2618 RAM 2620 ROM 2624 Clock< / data> < / streamdigest> < / preimage> < / pa>

Claims

1. 1. A computer-implemented method relating to a set of transactions in a blockchain system, comprising: creating a second transaction; creating a first transaction comprising at least one input related to an output from a most recent transaction in the set of transactions and a first reference to the second transaction; submitting the second transaction to the blockchain; submitting the first transaction to the blockchain; The computer-implemented method, wherein the second transaction comprises a second reference to a transaction in the set of transactions.

2. determining a total number of transactions in a subset of said set of transactions; and determining whether the total number of transactions in the subset of transactions is greater than or equal to a threshold.

3. 3. The computer-implemented method of claim 2, wherein membership in the subset of transactions is defined by at least one of: whether the transaction has been confirmed on the blockchain and a consumption relationship with any transaction in the set of transactions.

4. The computer-implemented method of claim 3 , wherein membership of the subset of transactions is additionally defined by the threshold value.

5. 3. The computer-implemented method of claim 2, wherein the subset of transactions comprises a first chain of transactions.

6. 6. The computer-implemented method of claim 5, wherein the subset of transactions is the first chain of transactions.

7. 7. The computer-implemented method of claim 5 or 6, wherein the first chain of transactions is constructed such that each transaction except for a first transaction in the subset comprises a reference to a previous transaction in the chain.

8. 8. The computer-implemented method of claim 7, wherein the reference to the previous transaction is an input related to a transaction output from the previous transaction.

9. 7. The computer-implemented method of claim 6, wherein the set of transactions comprises a plurality of subsets of transactions.

10. 10. The computer-implemented method of claim 9, wherein the set of transactions comprises a further chain of transactions.

11. The computer-implemented method of claim 2 , wherein the threshold is based on an ancestry restriction.

12. 12. The computer-implemented method of claim 11, wherein the threshold is one less than the ancestry limit.

13. 3. The computer-implemented method of claim 2, wherein creating and issuing the second transaction and the first transaction is performed based on a comparison of the total number of transactions in the subset of transactions to the threshold.

14. 14. The computer-implemented method of claim 13, wherein creating and issuing the second transaction and the first transaction occurs based on whether the total number of transactions in the subset of transactions is greater than or equal to the threshold.

15. 2. The computer-implemented method of claim 1, wherein the first reference is an immutable reference.

16. 16. The computer-implemented method of claim 15, wherein the first reference is based on an immutable characteristic of the second transaction.

17. 2. The computer-implemented method of claim 1, wherein the first reference comprises a transaction id of the second transaction.

18. 2. The computer-implemented method of claim 1, wherein the second transaction is confirmed on the blockchain prior to issuing the first transaction.

19. 2. The computer-implemented method of claim 1, wherein the second of the transactions comprises at least one input, and the first reference is based on at least one of the at least one input of the second of the transactions.

20. 2. The computer-implemented method of claim 1, wherein the second reference is a reference to an earlier transaction in the set of transactions.

21. 21. The computer-implemented method of claim 20, wherein the reference to the initial transaction comprises a transaction id of the initial transaction.

22. 2. The computer-implemented method of claim 1, wherein the second reference is an immutable reference.

23. 23. The computer-implemented method of claim 22, wherein the second reference is based on an immutable characteristic of the transaction of the first type.

24. The computer-implemented method of claim 1 , wherein the second reference comprises a transaction id of the first transaction.

25. 24. The computer-implemented method of claim 22 or 23, wherein the second reference is based on at least one of the at least one input of the first transaction.

26. 26. The computer-implemented method of claim 19 or 25, wherein the reference based on at least one of the at least one input is in the form of a transaction output point.

27. A computing device comprising a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the computing device to perform the computer-implemented method of claim 1.

28. A data writing device according to claim 27; a computing device configured to issue a request comprising data to the data writing device.

29. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer, cause the computer to perform the method of claim 1.

Images