Blockchain-related verification method and system

Abstract

A method, system, and program that allows a third party to determine whether a first party and a second party agree on membership in a set of blockchain transactions transacted between the first party and the second party.

Description

[Technical field]

[0001] The present disclosure relates to a method for verifying records of transactions made via a blockchain. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and widely promoted at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). The blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to a preceding transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves each of multiple nodes competing to perform a "proof-of-work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified pending transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be removed at some nodes, and the publication of a block can be achieved through the mere publication of a block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., multiple digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain may also be utilized to layer additional functionality on top of the blockchain. For example, a blockchain protocol may be able to store additional user data or indexes of data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore increasingly complex data can be incorporated. For example, this may be used to store electronic documents on the blockchain, or to store audio or video data.

[0004] The nodes of the blockchain network (often referred to as "miners") conduct a distributed transaction registration and validation process, which is described in more detail below. In summary, during this process, the nodes validate the transaction and insert the transaction into a block template that attempts to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, thus allowing each node to record a new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes of the network for propagation. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not incorporated into a block. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including the user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that 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 enforced by the actions of competing nodes, who act as agents of the network, encouraging them to report and block misconduct. Widely published information allows users to continuously audit node performance. By publishing mere block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (also called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. A usable output comprises an element that specifies the amount of a digital asset derived from the progression sequence of the transaction. A usable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for redemption of the future output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the indicated output. Thus, given a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies the 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 unlock 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 for propagation and recording in the blockchain, one of the validity criteria applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. Any node that determines that the target transaction is invalid according to any of these conditions will not propagate it (as a valid transaction, but to register an invalid transaction) or include it in a new block for recording in the blockchain.

[0008] Another 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 constantly updated by a node separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] It is identified herein that there are many scenarios in which it would be useful for a first party ("Alice") and a second party ("Bob") to decide whether to agree on the membership of a set of blockchain transactions made between Alice and Bob (i.e., agree on which blockchain transactions are part of the set). It is particularly desirable to be able to do this in a way that allows for later reconstruction of evidence if one of the parties misrepresents the set. For example, this would be useful for any institution, such as a tax authority or private auditor, that audits transactions between two parties.

[0010] However, implementing this requires technical considerations. A naive solution would be to simply have Alice and Bob each send off-chain reports of transactions they were involved in to a third party (e.g., tax authorities, auditors, etc.) and have that third party store all the reports. However, this would be burdensome for the third party's centralized storage space. Furthermore, future proofing would also rely on the third party's storage, which assumes that only the third party's records can be trusted as definitive and immutable memories, which may not necessarily be the case (e.g., they may be vulnerable to tampering, malware or data loss). Alternatively, another simple solution would be to simply allow a third party to unilaterally observe Alice's and Bob's on-chain transactions, without requiring Alice or Bob to report to a third party at all. After all, the nature of blockchain is that transactions, once included in a block, are permanently recorded on the chain as an immutable public record. However, relying solely on this approach has another technical drawback: Alice's and Bob's transactions are distributed across the blockchain, and unilaterally searching through all of them would be burdensome in terms of the third party's computing resources. Additionally, parties typically anonymize transactions by using a different key for each transaction. [Means for solving the problem]

[0011] This disclosure provides a more efficient hybrid implementation in which Alice and Bob need to report their transactions to a third party, but each must provide an attestation of the reported transaction in an additional transaction recorded on-chain (these additional transactions are referred to herein as the "first" and "second" transactions, and are separate from the transaction being reported, i.e., the transaction between Alice and Bob). For example, the attestation could be the hash root of a hash tree (sometimes referred to as the Merkle root of a Merkle tree), with transaction IDs, etc. becoming leaves.

[0012] According to one aspect disclosed herein, a computer-implemented method is provided for determining whether a first party and a second party agree on membership of a set of blockchain transactions transacted between the first party and the second party, the method comprising: receiving, by a third party, a first report from the first party comprising an indication of each of a plurality of blockchain transactions involving the first party, including at least the blockchain transactions in the set, the first report comprising one or more report messages transmitted one or more times; and receiving, by a third party, a second report from the second party comprising an indication of each of a plurality of blockchain transactions involving the second party, including at least some or all of the blockchain transactions in the set, the second report comprising one or more report messages transmitted one or more times. The method further comprises the steps of observing, by a third party, on the blockchain a first proof recorded by a first party in at least one first blockchain transaction, the first proof comprising a first proof value derived from the first party applying a first transformation to the instructions reported in the first report, and observing, by a third party, a second proof recorded by a second party in a second blockchain transaction, the second proof comprising a second proof value derived from the second party applying a second transformation to the instructions reported in the second report, the first and second blockchain transactions being distinct from the set. The third party checks that the first report is consistent with the first proof by applying the first transformation to the instructions reported in the first report and comparing it with the first proof from the blockchain, and checks that the second report is consistent with the second proof by applying the second transformation to the instructions reported in the second report and comparing it with the second proof from the blockchain. The third party also determines whether the indications in the first report refer to the same set of members as the indications in the second report.

[0013] While reports inform third parties of the reported transactions, proofs remain on-chain as immutable public records. Third parties check whether reports match the corresponding proofs and whether the reports match each other. If the decision reveals that one of the parties misrepresented the set to the other, the proofs can be used as immutable evidence that one of the parties, say Bob, made a false statement.

[0014] The third party may store the proof or a pointer to the proof for later use as evidence. The third party may store the indication (e.g., transaction ID) of the suspicious transaction, i.e., the transaction that was not reported in both reports. The third party may also store a link to the third party's identity (ID), and in embodiments where the proof comprises the root of a hash tree (Merkle tree), the third party may also store the hash tree path (Merkle path) between the root and the indication (e.g., transaction ID) of the transaction in question. However, the third party does not necessarily need to store the complete first and second reports, or all the indications (e.g., transaction ID) from the first and second reports. Instead, the first and second parties may store their own records of the indication of the transaction in a set. These records of the first and second parties may later be used in combination with on-chain authentication to attest the transactions that they attested. This in itself may be evidence of fraud, since if Alice or Bob destroy the records, they cannot reproduce the proof. In other words, because we have on-chain proofs, if later Alice and Bob are unable to generate a set of TxIDs that satisfy the proofs, this means that they discarded (or, perhaps, lost) some records, but they cannot pretend that they did not report or attest these transactions. All that a third party needs to remember is the proof of wrongdoing, which only requires information about a single transaction.

[0015] For example, consider this scenario: A Tax Authority (TA) collects all transaction IDs over a month in order to identify fraud (only the TA can do this since it keeps records of both Alice and Bob). When the TA identifies a suspicious transaction, it remembers the transaction, the Merkle path, the proof, and a link to Bob's identity (ID) in the transaction. The TA is then free to delete Alice's remaining transactions. The TA is left with only one transaction. This is evidence of fraud, since Bob cannot prove that the proven Merkle tree contains this transaction.

[0016] At the same time, since the publicly recorded proof is not an explicit instruction (e.g., the raw TxID) but a transformation of the set (hopefully an irreversible transformation), this obfuscates the identity of the set, and thus helps protect the privacy of the parties, unless one of them needs to prove that they misreported something. Otherwise, without this measure, we would have a public record of all transactions involving Alice, all transactions involving Bob, etc.

[0017] In an embodiment, Alice's reports may include both transactions involving Bob and transactions involving one or more additional parties (such as Charlie), in which case Alice's proof would be a proof of all these transactions together. For example, perhaps she issues a proof of all transactions with all parties once a month. In such a case, if evidence of Bob's misrepresentations needs to be provided to a fourth party, such as a court or the police, it is desirable to be able to provide this without violating Charlie's privacy by revealing the identity (ID) of Charlie's transactions with Alice (e.g., without revealing the transaction IDs).

[0018] Thus, in an embodiment, the instructions in the first report and / or the second report may further include instructions for each of one or more additional blockchain transactions that transact with one or more additional parties other than the first party, the second party, and the third party, the set being an intersection of transactions involving the first or second party. The first attestation value may comprise a root of a hash tree, and each of the instructions reported in the first report may be a leaf of the hash tree, and the method may comprise, in response to a determination that the first and second reports indicate different memberships of the set, identifying the presence of at least one blockchain transaction that is indicated in the first report but not indicated in the second report, using the hash tree root and the hash tree path between the root and the instructions representing the missing transaction to generate evidence that the second party made a false attestation, and presenting the evidence to the fourth party without disclosing the instructions of the transactions of the additional parties to the fourth party based on the use of the hash tree root and path.

[0019] Given a root and a path in a hash tree, the hash tree can be used to demonstrate that a given candidate leaf (in this case, one of the instructions for the transaction in question between Alice and Bob, e.g., the transaction ID) is indeed a leaf of the hash tree with that hash root, without having to reveal any other leaves (in this case, the instructions for the transaction between Charlie and Alice, e.g., the TxID). Thus, evidence of Bob's misrepresentation can be presented to a fourth party, such as a court, police, etc., without violating Charlie's privacy.

[0020] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which: [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a schematic block diagram of a system for determining whether a first party and a second party agree on membership in a set of blockchain transactions, according to embodiments disclosed herein. [Figure 4] 1 is a signaling chart illustrating a method according to an embodiment disclosed herein. [Diagram 5] 1 is a flowchart illustrating a method according to an embodiment disclosed herein. [Figure 6] FIG. 1 is a diagram illustrating an example of a hash tree (Merkle tree). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, 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.

[0023] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing device 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 devices, 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 using 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 optical disk drives.

[0024] The blockchain 150 comprises a chain of data blocks 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, data can be removed from the blockchain 150 so long as each blockchain node 150 stores the block header (described 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 data structure of some kind. The nature of the data structure varies depending 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 common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset as an asset, an example of which is a user 103 to whom the output is cryptographically locked (requiring the user's signature or other solution to unlock and thereby redeem or spend). Each input points to the output of a previous transaction 152, thereby linking the transactions.

[0025] 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 to the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer back to a previous transaction to define an order to the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 traces 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.

[0026] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 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 respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." 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 accepts as valid and that the node 104 is obligated not to accept any other transactions that attempt to use the same output.

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

[0028] The input of the current transaction 152j also comprises an input authority, 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 the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to give the change). In some cases, the transaction can also have multiple inputs to pool amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0029] According to an output-based transaction protocol like Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or the recipient will eventually send this transaction to one or more blockchain nodes 104 of the network 106 (today typically a server or a data center, but in principle it could be other user terminals). It is also not excluded that the party 103 who enacts a new transaction 152j sends the transaction directly to one or more of the blockchain nodes 104 and possibly not to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of them. The blockchain node protocol usually requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the sequence of ordered transactions 152. In such an output-based transaction protocol, this may comprise checking that a cryptographic signature or other authorization of a party 103 included in the input of the 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 checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i, or may simply be fixed by the blockchain node protocol alone, or by a combination of these.In any event, 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 thus forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0030] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether that output has yet to be validly redeemed by an input of another subsequent 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 it attempts to redeem has not yet been redeemed by another transaction. Similarly, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated for warning). This prevents double-spending, where a transactor attempts to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined transaction order, account balances are always in a single defined state.

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

[0032] The first blockchain node 104 to solve the puzzle publishes this to the network 106, providing the solution as a proof that can be easily checked by other blockchain nodes 104 in the network. (Given the solution to the hash, it is easy to check if the output of the hash satisfies the conditions). The first blockchain node 104 propagates the block up to a threshold consensus of other nodes, who accept the block and 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 a previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of hashing, required to create the proof-of-work solution signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it is assigned the same output as a previously verified transaction, also known as double-spending. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106, and block pointers 155 impose a sequential order on the blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks on each blockchain node 104 in the network 106.

[0033] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be operating on different snapshots of the pool of unpublished transactions 154 depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve the puzzle within a very short time of each other, so that conflicting views of the blockchain are propagated between the nodes 104. That is, the branch of the fork that grows the longest becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0034] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 (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) is given the ability to newly allocate an additional acceptance amount of digital assets in a new special type of transaction that distributes an additional prescribed amount of digital assets. This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction" or "generation transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the node constructing the new block's intention to follow the protocol rules, allowing this special transaction to be redeemed later. The rules of the blockchain protocol may require a maturity 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 will be explained later.

[0035] 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 takes the form of an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0036] 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 process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein 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 a lower layer such as the application layer, the operating system layer, or the protocol layer, or any combination thereof.

[0037] Also connected to the network 101 are computer devices 102 of each of a number of parties 103 who assume the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties 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).

[0038] Some or all of the parties 103 may be connected as part of a different network, for example a network overlaid on top of the blockchain network 106. Although users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network 106, these users are not blockchain nodes 104 because they do not perform the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to herein as Bob, but it will be understood that, without limitation, any reference herein to Alice or Bob may be replaced with the terms "first party" and "second party," respectively.

[0039] The computer equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. This memory may comprise one or more memory units using 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 on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed to a given party 103 herein may be implemented using software running on the processing unit of the respective computer equipment 102. The computer equipment 102 of each party 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 party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0040] The client application 105 may be initially provided to the computing equipment 102 of any party 103 on a suitable computer readable storage medium, for example downloaded from a server or provided in 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.

[0041] 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, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated throughout the network of blockchain nodes 104 and thereby 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 various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0042] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily a limitation, and instead any client functionality described herein may instead be implemented in a suite of two or more separate applications, for example interfacing via an API or one plugging into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. It will be understood that the following is described with respect to client application 105, but is not limited thereto.

[0043] 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 a 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 transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send the transaction 152 according to a transaction protocol. As noted above, each blockchain node 104 is configured to execute software configured to validate the transaction 152 according to the blockchain node protocol and to forward the transaction 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol proceeds with a given node protocol, together implementing 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.

[0044] When a given party 103, say Alice, wants to submit a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice 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 processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of script and node protocol.

[0045] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., 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 at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 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 be propagated throughout the network 106 immediately.

[0046] Once admitted to the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different transaction pools 154, but whoever arrives first may end up defining the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 will solve the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. The order of transactions is also immutably recorded, since each transaction 152 has a pointer back to the previous transaction.

[0047] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views of which instance is "valid" before one 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 one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0048] 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 constantly 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 its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, any data field in a transaction may also be signed. For example, this data field may point to a previous transaction if the previous transaction ID is included in the data field.

[0049] UTXO-based model FIG. 2 shows an exemplary transaction protocol. It is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but can be implemented in other exemplary blockchain networks as well.

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

[0051] Suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 can refer to a preceding (i.e., earlier) transaction that still has an unspent output 203 locked to Alice.

[0052] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits 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 be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan (Tx0)" transactions. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. These may be equivalently replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. It 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 (a later transaction or "child") that points to a preceding transaction (an earlier 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. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a certain amount of time to wait for the parent.

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

[0054] A lock script (commonly called scriptPubKey) is a piece of 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 lock script specifies what information is needed to use the transaction output 203, e.g. the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0055] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice’s public-private key pair. A The input 202 of Tx1 comprises a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. The input 202 of Tx1 comprises an unlock script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0056] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] In the above, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that compose the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. In any case, when executed together, the scripts will generate Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in the input of Tx1 contains Alice's signature, who signed the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

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

[0058] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending 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 the transaction is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses an unspent transaction output 203. If it attempts to use an output that has already been spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0059] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount specified by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0060] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" a portion of the amount defined in the UTXO as spent, and another portion is spent. However, it is possible to split the amount from the UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs 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 remainder to herself in the second output of Tx1, or to pay another party.

[0061] In practice, Alice would also typically need to include a fee for any Bitcoin nodes 104 that successfully included her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain nodes 104 and therefore may not be propagated and included in the blockchain 150, even though it is technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount specified 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 won the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0062] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs locked to each party that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0063] Note that scripting code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the scripting language. As an example, OP_RETURN is an opcode in the scripting language that, when preceded by OP_FALSE at the beginning of a lock script, creates an unusable output of a transaction that can store data within the transaction, thereby immutably recording the data to the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0064] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific portion of the 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 portion of the outputs that are signed depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature (and thus fixed at the time of signing) to select which outputs are signed.

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

[0066] Side Channels As shown in FIG. 1, the client applications on 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 (at the direction of either party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 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 transaction (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing transactions in this manner may also be referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0067] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 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 107 referred to anywhere herein may comprise any link or links over one or more networking technologies or communication media for exchanging data "off-chain," i.e., apart from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange information or particular pieces of data, etc., over the side channel 107, this does not necessarily imply that all of these pieces of data must be transmitted over the exact same link or the same type of network.

[0068] Verifying membership of a set of transactions As mentioned in the Overview of the Invention, it is desirable to allow a third party to verify whether two parties (first and second parties, Alice and Bob) agree on the membership of a set of blockchain transactions made between them (i.e., agree on which transactions are part of the set). It is also desirable to do so in a manner that allows the identity (ID) of the party making the misrepresentation to be verifiable. For example, the third party could be a tax authority checking that both Alice and Bob have reported the same set of transactions for tax purposes. Or, Alice and Bob could be two divisions within a company, and the third party could be a private auditor checking that the two divisions are reporting the same transactions for audit purposes. As another example, the blockchain could be a consortium blockchain used to track the origin of regulated goods such as gemstones or animal products. In this case, the third party could be a regulatory body checking that one party is not trying to hide fraudulent transactions. Note again that "Alice" and "Bob" are just labels, and each could represent an individual or an organization such as a company, government agency, academic institution, charity or club, or a subdivision such as a department within such an organization.

[0069] 3 illustrates an exemplary system according to an embodiment disclosed herein. The system includes a first party 103a (Alice) computer device 102a, a second party 103b (Bob) computer device 102b, and a third party 303 (e.g., tax authority, auditor, etc.) computer device 302. In the following, various actions are described as being performed by the first party, the second party, or the third party, etc., but it will be understood that this is shorthand for meaning that the actions are performed by each party 103a, 103b, 303 using each party's computer device 102a, 102b, 302.

[0070] The computing equipment 302 of the third party 303 may take the form of a server system comprising one or more physical server units located at one or more geographical sites. The various actions described herein performed by the third party 303 may be performed using software (code) stored in the memory of the computing equipment 302 of the third party and executed on a processing unit of the computing equipment 302 of the third party. This memory may comprise one or more memory units, and the processing unit may comprise one or more processing units. Similar comments regarding the various options for the implementation of the memory and processing units (magnetic memory, electronic memory, CPU, GPU, etc.) apply as already outlined in relation to the computing equipment 102a, 102b and / or the node 104 of the first and second parties.

[0071] The third party computer equipment 302 is connected to the blockchain network 106 to enable it to at least inspect transactions 152 stored in blocks 151 on the blockchain 150. The first and second party computer equipment 102a, 102b are also connected to the blockchain network 106 to enable it to conduct blockchain transactions 152 between them as described above. Furthermore, as will be explained in more detail shortly, this allows it to record additional "proof" transactions that contain proof for transactions conducted between Alice and Bob (and potentially between itself and other parties such as Charlie). For example, this can take the form of a hash tree root (Merkle root) of a hash tree whose leaves are the IDs of transactions in the set.

[0072] The system is also configured to enable each of the first and second party devices 102a, 102b to send reports to a third party, with these reports comprising an indication of all purported transactions that have taken place between them, indicated, for example, by transaction ID (TxID).

[0073] The system may also include an off-chain side channel 107 between Alice and Bob, as previously described, which allows them to negotiate a transaction between them before sending it to the blockchain 150 for recording. Protocols for this, such as Simplified Payment Verification (SPV), may also include an exchange of information that allows for later identification of misstatements if detected.

[0074] FIG. 4 illustrates method steps performed by three parties according to an embodiment disclosed herein.

[0075] In step 410, Alice and Bob make a blockchain transaction between them. This involves recording the blockchain transaction on the blockchain 150 that is transacted between Alice and Bob, for example using any of the techniques described above in connection with Figures 1 and 2. In an output-based (e.g., UTXO-based) model, this means that the transaction 152 comprises an input 202 that points to an output of another preceding transaction that is locked to Alice. The input 202 of the current transaction (the one between Alice and Bob) comprises an unlock script that comprises Alice's signature, thus unlocking the pointed output of the preceding transaction. The transaction between Alice and Bob comprises a forward output 203 that comprises a lock script that locks the output to Bob, i.e. requires Bob's signature to unlock it. According to various known transaction formats, this output 203 may include Bob's address based on Bob's public key. In a typical transaction format, the address comprises a hash of Bob's public key. However, in principle it could be some other transformation, or simply the public key itself. In a typical format such as tat used for Bitcoin, it will be in a hashed form. This is because Bob's key appears in the locking script, typically in the form of a pay-to-public-key-hash. In contrast, Alice's public key appears explicitly in the transaction, because the public key itself (not a hash) appears in the unlocking script.

[0076] Once formed, the transaction may be sent to the blockchain network 106 by either Alice or Bob, either directly or through another intermediate party (not shown).

[0077] In an embodiment, step 410 of conducting a transaction between Alice and Bob may comprise agreeing on the transaction between Alice and Bob before it is sent to be recorded on-chain. This may comprise engaging in a protocol between Alice and Bob via an off-chain side channel 107. For example, the protocol could be Simplified Payment Verification (SPV). The protocol may comprise exchanging a template version of the transaction between Alice and Bob via the side channel 107, with each party filling out their part of the transaction via one or more exchanges. And / or the protocol may comprise exchanging identifying information between the parties to enable them to be identified (Bob providing his identity information to Alice, and / or vice versa). For example, this may comprise Bob entering his address based on a public key in the template transaction (e.g., a hash of his public key), or providing his address or public key to Alice to include the address in the transaction. The identifying information exchanged may also comprise information (separate from the template transaction) linking the public key to Bob.

[0078] Currently, parties typically do not use the same public key for each transaction. Instead, they have a master public key and for each individual transaction, they derive a transaction-specific child public key from the master for use in the locking script of that particular transaction. This means, among other things, that Bob cannot be identified by the child public key or address alone. The child public key is related to the master public key by a derivation function, which is parameterized by additional information, referred to herein as derivation information. In other words, the child public key is a function of the master public key and one or more parameters, the parameters being the derivation information, and the function being the derivation function. The derivation information comprises one or more elements that are specific to a particular transaction, such as the transaction's index value, or information about the content or purpose of the transaction, such as an invoice, sales order, or receipt. This links the child public key to a particular transaction. The derivation information may also comprise an element known as a chaincode, which is common to all child keys derived from a given master. Details of suitable child key derivation functions are known per se to those skilled in the art.

[0079] In the protocol of step 410, the identification information provided by Bob to Alice may comprise Bob's master public key and / or derivation information, preferably both, so that Alice can verify that the child public key or address is linked to Bob's master public key. In any case, Alice may also provide such information to the third party 303 at a later time if it is detected that Bob has made a misrepresentation (more on this shortly). Bob may need to inform Alice what type of derivation function he is using (e.g., which standard), and Alice may need to inform this to the third party 303, or the type of derivation function used may simply be an assumed default.

[0080] In an embodiment, each party's master public key is linked to the party's public identifier by a digital certificate authority (CA, not shown). That is, the CA issues a digital certificate that is signed by the CA and links the master public key to a public identity (ID). The public identity (ID) may comprise, for example, a human readable name and / or address of the party. In an embodiment, the identification information exchanged in step 410 may comprise copies of Alice's and / or Bob's digital certificates.

[0081] In step 420, Alice sends a report of the blockchain transaction she made with Bob to the third party 303. This may be sent via an off-chain side channel (not shown) between Alice and the third party 303. Alternatively, the report may be sent via an on-chain channel, i.e., Alice records another blockchain transaction addressed to the third party on the chain so that the third party can find it on the chain (in the case of an output-based model, this means that there is an output containing the third party's address, and the third party can monitor it on the chain). In any case, the report comprises an indication of the transaction. This indication could comprise a copy of the transaction itself, but this would be cumbersome in terms of data volume. Therefore, it is more preferable that the indication of the transaction comprises only an identifier of the transaction, e.g., a transaction ID (TxID).

[0082] In step 430, Bob also sends (or at least is expected to send) a report of the same blockchain transaction he made with Alice to the third party 303. All of the above regarding how Alice's report is generated and transmitted can also be applied mutatis mutandis to Bob's report.

[0083] The method continues with Alice and Bob conducting one or more additional transactions between them over a period of time (i.e., one or more additional instances of step 410 are performed). For example, Bob may be a supplier with whom Alice does business regularly. Steps 420 and 430 are performed for each instance of step 410 (or at least would be if both parties are acting in good faith). As shown in FIG. 4, this may comprise a separate instance of steps 420 and 430 for each transaction 410. That is, each of Alice and Bob sends a separate report message to the third party each time they conduct each transaction. For example, the report may be sent in response to agreeing to the transaction via a protocol on the side channel 107 or in response to confirmation that the transaction was indeed recorded in a block 151 on the blockchain 150.

[0084] However, it is not excluded that Alice could instead store batches of transactions that she indicates to the third party 303 in the same reporting message (e.g., as a list of transaction IDs per message). For example, she could send a report of all transactions of interest that she was involved in, organized by week, month, or year. Similar comments may apply to Bob.

[0085] Note that each of Alice and Bob may also send similar reports to the third party 303 about transactions they have conducted with other parties, such as Charlie. Thus, for example, Alice's report would also include a report of the TxIDs between Alice and Charlie.

[0086] In step 440, Alice generates a proof of the set of transactions she was involved in, including at least the transaction 410 between Alice and Bob. This should be the same set that she reported to the third party 303 in the report 420. For example, this set could be all transactions in a particular time period or all eligible transactions (e.g., transactions above a particular threshold). For example, she may generate weekly, monthly, or yearly proofs. The proof comprises a proof value generated by applying an obfuscating transformation (preferably a non-reversible transformation) to indications (e.g., transaction IDs) of the transactions she reported to the third party 303, for example, all those reported in the last time period (e.g., last week, last month, or last year). In an embodiment, the transformation takes the form of a hash-based function comprising one or more hashes of a combination of the reported transaction indicators (e.g., transaction IDs).

[0087] A simple example is a hash or double hash of the concatenation of transaction indicators (e.g., IDs). However, for reasons that will become clear, it is more preferable that the proof value is the root of a hash tree. A hash tree is sometimes called a Merkle tree, and a hash root is sometimes called a Merkle root. In this case, the leaves of the hash tree are transaction indicators (e.g., IDs). At the bottom of the tree, each node is a hash of one of the corresponding leaves. At the next higher layer of the tree, each node is a hash of a different respective subset (typically two) of the nodes of the layer below, proceeding up the layers of the tree until a single root value is reached. A simple example is shown in Figure 6, where "+" here denotes concatenation (although in principle other types of join operations could be used). Note that the terms Merkle tree, Merkle root, and Merkle path as used herein do not necessarily mean a binary hash tree (i.e., where the subsets joined from each layer to the next layer are only two nodes), although this is typically the most common implementation.

[0088] Merkle trees (hash trees) have the convenient property that to prove that a given leaf is a member of a set, one only needs the leaf's value, the Merkle root, and the Merkle path between the leaf and the root (i.e., the values ​​of all the hashes along the path from the leaf to the root); one does not need the values ​​of all the leaves. This makes it possible to provide, for example, that TxID_1 is a member of a set without giving away or knowing any of TxID_2, TxID_3, TxID_4, etc. This is useful for privacy reasons.

[0089] Whatever form the proof takes, Alice then records this proof in a further transaction on the blockchain 150. This may be referred to herein as a proof transaction. This is separate from transactions between Alice and Bob, Alice and Charlie, etc. The proof transaction may be addressed to a third party 303 to make it easier for the third party to find on the chain. In an output-based model (e.g., a UTXO-based model), this means that the output 203 of the proof transaction comprises the address of the third party 303. For example, the address may be based on the third party's public key, e.g., a hash of their public key, and the output may be locked to that public key and require the third party's 303's corresponding private key to unlock it. If the blockchain protocol being used does not allow zero-value outputs, the amount defined in this output may be an insignificant (negligible) value or it may be an actual substantial payment to the third party 303 (e.g., an actual tax payment, or a payment for auditing services).

[0090] In step 450, Bob generates a proof of the set of transactions he participated in, including at least the transaction 410 between Alice and Bob. The above discussion of Alice's proofs applies mutatis mutandis to Bob. Bob does not necessarily use the same form of proof as Alice, although in an embodiment he does (e.g., Merkle root).

[0091] At step 460, the third party 303 monitors the attestation transactions from Alice and Bob on the blockchain 150. In an embodiment, this may comprise monitoring the blockchain 150 for transactions addressed to the third party 303, for example, based on the presence of the third party's public key in the transaction output. In practice, this monitoring may be implemented by the third party 303 subscribing to a service that monitors the blockchain 150 for defined activities.

[0092] In an alternative embodiment, the third party 303 does not need to monitor the blockchain 150; instead, Alice and Bob modify the third party to check for the presence of the attestation transaction on the chain and direct the third party to the attestation transaction, e.g., by sending a pointer to the transaction.

[0093] FIG. 5 illustrates a method that may be performed by a third party 303 according to embodiments disclosed herein.

[0094] In step 510, the third party 303 obtains Alice's proof value (e.g., Merkle root MR) from Alice's proof transaction on the blockchain 150. In step 520, the third party 303 calculates the proof value (e.g., Merkle root MR') from the set of transaction indicators (e.g., IDs) received from Alice's report message 420. These two steps may be performed in either order. In step 530, the third party 303 checks whether they are equal. If they are not equal, in step 540, the third party may ask Alice to resubmit her proof and loop back to step 530.

[0095] Steps 510 to 540 are also performed mutatis mutandis with respect to Bob.

[0096] Assuming (or once) Alice's authenticated, calculated attestation values ​​match, as do Bob's attestation values, then the method proceeds to step 550. Now, the third party 303 checks that all transactions reported (420) by Alice were also reported (430) by Bob. This is done by comparing transaction indicators (e.g., IDs) reported by both parties. This may comprise checking all transactions indicated within a given time period, such as, for example, a week, month, year, etc. If Alice and Bob reported the same set of transactions (e.g., over a given time period), then they are likely both honest, there is nothing suspicious, and the method ends. In an embodiment, in this scenario, the third party 303 may discard the reported transaction IDs from storage (perhaps after performing some processing, such as processing the indicated transactions for tax purposes, and / or after keeping them for a defined retention period).

[0097] On the other hand, if one of Alice and Bob reports a transaction that the other did not report and was expected to report (e.g., because it was a transaction from a given time period, e.g., last week, month, or year), the transaction that is present in one party's report and not present in the other party's report is treated as a suspicious transaction. In this scenario, the method branches to step 560, where the third party 303 determines an indication (e.g., transaction ID) of the transaction that one party (e.g., Alice) reported and the other party (e.g., Bob) did not report. This can be determined from Alice's report 420. Then, in step 570, the third party 303 identifies that the non-reporting party (e.g., Bob) is non-compliant and takes action against that party. In an embodiment, this may comprise obtaining information to establish Bob's identity (ID) so that it can be used as evidence.

[0098] Assuming it is Bob who is non-compliant, in response to the decision to report a mismatch, the third party 303 may send a request to Alice to supply some or all of the identifying information it initially received from Bob during stage 410 of negotiating the transaction via the side channel 107. This may comprise the derivation information (e.g., the chaincode, the index, and / or the invoice) discussed above. Given Bob's master public key, the derivation information, and the known form (type) of the derivation function used, the third party 303 can calculate what Bob's child public key for the suspicious transaction should be. Bob's master public key may be provided to the third party 303 by Alice upon request, or may have been pre-supplied by Bob during the initial registration stage before starting to use the service. The type of derivation function used may be default, may be notified by Alice, or may have been pre-registered by Bob. The third party 303 may also obtain the address actually used in the suspicious transaction by reading from the suspicious transaction on the chain or receiving it from Alice. The third party 303 can then compare this to the calculated child public key to determine if it is the same as that used for Bob's address. For example, if the address is a hash of a public key, this comparison comprises hashing the calculated public key and comparing the result with the address. Assuming they match, it establishes that the suspicious transaction is linked to Bob's master public key. This can be used to present to a fourth party, such as the police or a court, as evidence that it was Bob who made the misrepresentations.

[0099] For completeness, note that if it is Alice's behavior that is being checked, then in the typical transaction format, Alice's child public key appears explicitly in the transaction, since the public key itself (not the hash) appears in the unlocking script. Thus, in this case, there is no need to include the hash in the comparison with the computed child public key. Also, in principle, in alternative transaction formats, Bob's address could simply comprise a copy of the public key, not necessarily a transformation of the public key such as a hash.

[0100] In addition to the link between the child public key and the master public key, Bob's master public key may be linked to Bob's public identity (ID) by a digital certificate issued by a Certificate Authority (CA). The certificate linking the two may be obtained by Alice from Bob during protocol 410 and then provided by Alice to the third party 303 upon request when a suspicious transaction is detected. Alternatively, the certificate may have been registered with the third party 303 in advance by Bob, or may be obtained by the third party 303 requesting the certificate directly from the CA. In either case, this may form part of the evidence that the party known as Bob has in fact made a misrepresentation.

[0101] Optionally, both Alice and Bob register (303) their master public keys with a third party before using the service. This is not necessarily a requirement, since Bob will need to give Alice the master key in any case (for reasons explained above). The master key is preferably signed by a Certificate Authority (CA), which could be the third party itself, or another CA.

[0102] In an embodiment, Bob gives Alice three things in the setup phase 410: his master key, a certificate from the CA that links his master key to his identity, and the child derivation information. If there is a mismatch in the records, Alice may send all three to the third party 303. In this case, the third party 303 has everything it needs to prove the link between Bob's identity and the transaction. However, in alternative implementations, the third party 303 may already have Bob's master public key and / or certificate from the registration phase, or may obtain the certificate directly from the CA. Thus, in some other embodiments, Alice may send only the derivation information.

[0103] In an embodiment, the third party 303 may store evidence of Bob's non-compliance (i.e., his misrepresentation). To do this, the third party 303 does not need to store all the reported instructions (e.g., all transaction IDs) from Alice and Bob's complete reporting. All the third party 303 actually needs to store is evidence of misconduct. Only one transaction is needed to show this. Thus, when the third party 303 identifies a suspicious transaction, it stores the transaction (or its identifier, e.g., TxID), the proof, and a link to Bob's identity (ID) in the transaction. In the case of a Merkle root, it also stores the Merkle path. The third party 303 is then free to delete the rest of the reported transaction instructions (e.g., IDs). The third party 303 is left with only one transaction. This provides evidence of misconduct, since Bob cannot prove that this transaction was included in his published on-chain proof (e.g., he cannot prove that it was included in his Merkle tree).

[0104] Merkle tree implementations may be particularly advantageous for privacy. The leaves of Alice's Merkle tree may contain indications (e.g., IDs) of transactions made by both Bob and other parties such as Charlie. The fact that Charlie made a particular set of transactions with Alice may be secret or confidential, and assuming Charlie is not suspected of misrepresentation, it is desirable not to have to divulge this information in evidence presented to a fourth party (e.g., police or court). As previously mentioned, Merkle trees allow a candidate leaf to be proven to be a member of a set given only the root and Merkle path. Thus, this is all that needs to be stored and / or presented as evidence, not indications (e.g., TxIDs) of Charlie's transactions with Alice. Since we are assuming that Alice has sent all expected transactions to the third party 303, the third party 303 can determine the associated Merkle path. If the third party 303 has all the transactions (in a particular order), it can build Alice's Merkle tree and recreate the Merkle root. Once the entire tree is known, the path to any leaf can be easily computed.

[0105] NOTE: Although it has been described above that all transactions between Alice and Bob, Alice and Charlie, etc., and the first and second proof transactions, as well as any other transactions used for on-chain signaling, are all recorded on the same blockchain 150, this does not necessarily have to be the case. For example, transactions between Alice and Bob could be transactions on one blockchain, but the proofs are recorded on another blockchain. Or, transactions between Alice and Bob could include transactions that take place over different blockchains. Or, Alice and Bob could transact over one blockchain, and Alice and Charlie could transact over another blockchain.

[0106] It should also be noted that although examples have been described herein with respect to transactions from Alice to Bob, similar methods may be applied to transactions from Bob to Alice, or between Alice and Charlie, etc. Also, although illustrated in terms of Alice assisting Bob in identifying misstatements, the methods may be applied in reverse as well (regardless of whether Bob is the payer or payee).

[0107] Application example - Tax return Below we consider an application of the disclosed system where the transparency and anonymity of the blockchain public ledger can be used to encourage tax compliance. In particular, it can be used to provide a system for recording or "lodging" tax receipts on the blockchain to identify non-compliant users. The system relies on only a small percentage of honest users to identify many non-compliant users.

[0108] The privacy model of at least some blockchains, such as the Bitcoin blockchain, means that identity information is firewalled from on-chain transaction information. However, identity information can still be exchanged between transacting parties off-chain. Indeed, existing regulations often require identity information to be exchanged between transacting parties. For example, the 5th Anti-Money Laundering Directive (AMLD5) requires entities (individuals and / or businesses) to report identity information when conducting transactions over €150 within the UK and Europe.

[0109] An embodiment of the disclosed system may work as follows: Consider a blockchain transaction between two parties, Alice and Bob. To comply with AML regulations, Alice and Bob exchange information off-chain that is proven to link their identities to the transaction. Alice and Bob separately send transaction IDs (TxIDs) to the same tax authority off-chain. Once a month, Alice and Bob record the Merkle root of their on-chain transactions with the tax authority. Because Alice and Bob both submit their TxIDs to the same authority, the authority needs to receive each TxID twice. If they receive only one TxID, for example from Alice, they will investigate and ask who they are transacting with. Alice answers that it is Bob, providing the authority with a provable link from his identity to the transaction. The tax authority now has evidence of Bob's non-compliance.

[0110] As an example implementation, subsection 1 below analyzes a Bitcoin transaction in detail and explains how a provable link to identity can be established off-chain. Subsection 2 describes a system for identifying tax non-compliance (or, more generally, how to identify non-membership with a link to identity). Subsection 3 describes the extent to which the process of identifying non-compliance can be outsourced to a third party. This works because the off-chain firewall to identity is only breached for non-compliant users.

[0111] 1. Characteristics of Bitcoin Transactions Consider a Bitcoin transaction of x satoshis from Alice to Bob. The transaction looks like this:

[0112] [Table 1]

[0113] This is just a normal transaction; its structure does not need to change at all. A similar format can be used for other output-based (e.g. UTXO-based) models.

[0114] For simplicity, no additional inputs or outputs, such as changes to Alice, are considered here. The unlocking script uses a public key controlled by Alice.

[0115]

number

[0116] The lock script is in Pay-to-Public-Key-Hash format and contains a valid signature from a public key controlled by Bob.

[0117]

number

[0118] This means that the signature from should be used. The payload data contains the optional disabled OP_FALSE OP_RETURN output, or may be included in other ways, such as OP_DROP or OP_RETUTN in other transaction protocols.

[0119] Normally, Alice would have a master public key, PK A and possibly chaincode C A Alice owns a wallet with additional information called the master key. This master key can be tied to Alice's identity (ID), for example by a Certificate Authority (CA) that issues digital certificates. However, it does not appear on-chain. Instead, the public key that Alice uses in transactions is

[0120]

number

[0121] , which is not Alice's master key. Public key

[0122]

number

[0123] is usually PK A Without knowing how the keys are derived, someone looking at transaction TxID1 would not realize that it contains a key that Alice controls.

[0124] Transaction TxID1 also includes an option to store payload data in an unavailable output (this is a common place to store data in a transaction, and can also be included in a lock / unlock script followed by an OP_DROP command). The payload data can include metadata about the transaction, for example: General receipt data, such as items purchased, individual costs, merchant name, and timestamp. · Registration and tax codes of the businesses involved. Identity information of the individual concerned; and / or ·receipt All of this data is encrypted, and Alice, Bob, or both may have access to a decryption key. Alternatively, a hash commit of this data may be all that is given in the payload. This allows metadata to be provably linked to the transaction without giving any details (some salt may need to be included to ensure sufficient entropy in the hash pre-image). If a hash commit is used, the hash pre-image needs to be stored in a database. Such a database may be maintained by Alice, Bob, or a third party. It may also be a distributed hash table (DHT) where data is replicated by participants in the network.

[0125] The transaction itself may include inputs and outputs related to the payment of taxes, which will not be discussed in detail herein. Taxes do not necessarily have to be paid in a blockchain transaction, although that is a possibility.

[0126] Child keys may be provably linked to a master key. Transactions such as TxID1 involve the creation of a new public key controlled by Bob.

[0127]

number

[0128] As mentioned before, this public key is Bob's master key, PK B This may be linked to his identity, which may in turn be linked to his identity. There are usually two ways to do this:

[0129] 1) A process similar to BIP32. For example,

[0130]

number

[0131] but,

[0132]

number

[0133] It is possible for a user to follow the unhardened child key derivation path given by 2) A process similar to WP42, which requires the master keys of Alice and Bob and a third piece of data m, such as an invoice or other metadata known to both Alice and Bob, e.g., a public key

[0134]

number

[0135] can be derived as follows:

[0136]

number

[0137] This involves both Alice and Bob

[0138]

number

[0139] PK A , P.K. B , m.

[0140] The index i in process (1) is the invoice m or the public key PK in a way that preserves the functionality of BIP32 wallet restoration. A This allows for the integration of both approaches. It was also explored how multiple outputs and multiple transactions can be linked to the same invoice m. This allows for enhanced privacy of transactions between Alice and Bob in situations where the Satoshi value is well known.

[0141] 2. Tax payment and non-compliance identification system In this subsection, we describe a system that allows tax authorities to identify entities that may be non-compliant with taxes. For simplicity, we consider only two entities in this system: Alice and Bob. Alice and Bob share the master public key PK A and P.K. B must be registered with the tax authorities. This can be established through the issuance of a certificate or a tax code from the tax authorities.

[0142] A well-known public key, PK, that represents the address used by the tax authorities to record or "file" tax receipts T Assume we have an account reserved solely for receiving and merging on-chain tax returns from Alice and Bob. T is simply a warning address and is not a method for tax authorities to accept or send payments.

[0143] The system involves two stages: tax reporting and non-compliance identification. The details of each stage are as follows:

[0144] Tax return: The following shows the protocol from Alice's point of view, but it is the same from Bob's point of view. This is an example of the method shown diagrammatically in Figure 4. 1. Alice and Bob construct a transaction. Alice and Bob jointly create a transaction, TxID1, to transfer funds from Alice to Bob. A schematic of TxID1 is referenced in Section 1.1. Alice and Bob also exchange personally identifiable information that provably links their identities to the public keys used in the transaction. For example, they might provide the data necessary for the derivation of the child keys described in Section 1.1. She also sends a link to her identity (off-chain). To ensure Bob's security, he must first ask Alice to send him her identity. Bob can then send a transaction template to Alice along with her identity, similar to a BIP270-like process. Alice signs the transaction, making it valid. (If Bob sent his identity to Alice first, Alice could sign the message without revealing her identity.) Either Alice or Bob submits a transaction to the Bitcoin network and checks that the transaction was accepted with the claimed certainty. 2. Alice and Bob then report the transaction to an off-chain tax authority. Alice and Bob separately report the transaction ID TxID1 to the tax authority. This could be done via sending an off-chain message to the tax authority, but this document does not specify how the transaction ID is reported. 3. Every transaction TxID1 between Alice and Bob needs to be reported twice to the tax authority, once by Alice and once by Bob. The tax authority may build an internal database to store these transactions. By doing this, it can effectively match up each transaction between the two entities. 4. After a typical period of time, say one month, Alice has read all transactions TxID1…TxID N Collect and Merkle Root MR A This is similar to how a Merkle root is constructed in a Bitcoin block, but here only transactions related to Alice are used. 5. Alice obtains the tax authority’s public key, PK T Transaction TxID for A Bob does the same. Transaction TxID A is the Merkle root MR of the transaction signed with Alice’s identity (ID) public key. A The Merkle root may be the unusable output payload data referred to in Section 1.1. 6. Alice and Bob submit the Merkle root to the on-chain tax authority. Transaction TxID A and TxID B is accepted on the Bitcoin network, tax authorities will be required to use Merkle Root MR A and M.R. B Sending a transaction on-chain in this way creates an immutable record of Alice's proof of that month's tax receipt.

[0145] Identifying Tax Non-Compliance: This is an example of a method that is illustrated diagrammatically in FIG. 1. Tax authorities use transaction TxID A From Merkle Route MR A Receive. 2. The tax authority then checks the Merkle root MR' of all the TxIDs that Alice sent that month to verify that it is as expected. A Calculate. 3.MR A =MR' A (i.e., it is a certified Merkle root as expected). If not, the tax authority sends Alice a new MR A Request that the above be resubmitted. 4. Repeat steps 1-3 for Bob. 5. Check that each transaction is confirmed twice. Recall that all TxIDs between Alice and Bob were sent to the tax authorities at the tax return stage. At this stage, the tax authorities check that all TxIDs sent for that month are reported twice, once by Alice and once by Bob. If yes, the tax authorities stop the checking process and identify that Alice and Bob are compliant for that month. 6. Identify which transactions were confirmed only once and request information for this transaction. The tax authority identifies that transaction TxID2 was reported only by one party, say Alice. The tax authority asks Alice who she was transacting with in TxID2. Alice tells the tax authority that it was Bob. The tax authority may request that Alice provide a provable link to Bob's identity in TxID2. 7. The tax authorities will identify Bob's non-compliance at this point and penalize him appropriately.

[0146] Figure 5 illustrates the process by which a third party 303, such as a tax authority, identifies non-compliance by checking the Merkle root (or other such proof) and the list of all transactions sent by Alice and Bob. For simplicity, the diagram shows only MR (Merkle root) as an example instead of specifying the Merkle root of Alice or Bob.

[0147] Note that the equality of MR and MR' only indicates that the on-chain tax records match the tax authorities' tax records, and does not mean that Alice or Bob are in compliance. For example, the four transactions between Alice and Bob in that month are TxID1, TxID2, TxID3, and TxID4, respectively. Alice can obtain all four transaction IDs and the Merkle root MR formed from these transactions. A_4 Bob reports the three transaction IDs TxID1, TxID2, and TxID3 to the tax authorities. B_3 At this point, the tax authorities will report only the MR A_4 =MR' A_4 and M.R. B_3 =MR' B_3 However, in steps 5 and 6, the tax authorities identify that Bob has not reported TxID4 and is therefore not in compliance. Furthermore, Merkle root MR B_3 is evidence that Bob is attempting to falsify tax records or illegally underpay taxes.

[0148] 3. Outsourcing to third-party providers This subsection introduces third-party service providers (SPs) as a new role in the system to enable tax authorities to more effectively identify non-compliance.

[0149] As explained above in subsection 2, to identify tax non-compliance, the tax authority checks the Merkle root and each TxID. In practice, this can be a significant burden for the tax authority if there are a large number of TxIDs between Alice and Bob and / or if a large number of entities need to be identified by the tax authority.

[0150] Therefore, to reduce the burden on the tax authorities in identifying mismatched transactions, a third-party service provider monitors the activities of the entities on behalf of the tax authorities. The term “monitor” means that the third-party service provider receives information from the blockchain network (such as the tax authorities’ public key PK) and T The method comprises: collecting all transactions sent to the blockchain (e.g., any transaction sent to the blockchain); reporting the collected information; verifying the ownership of the public key associated with the entity of the reported TxID off-chain; and checking identity between the compared hash values ​​(e.g., Merkle roots).

[0151] Verifying the ownership of Bitcoin is very important and essential in the tax non-compliance identification system. Existing methods are suitable for ownership verification in our system by using DHT and the Bitcoin blockchain.

[0152] The DHT in subsection 1 above is considered as a database in which data is stored and maintained by participants. In the present application, Alice, Bob, the tax authority, and the service provider are the participating nodes, and the data are all the key-value pairs and metadata on the DHT.

[0153] Monitoring can be divided into two parts: on-chain and off-chain. The on-chain part is the public key PK T The off-chain monitors any transactions sent to the blockchain, and the off-chain monitor matches each TxID entity sent.

[0154] Off-chain monitoring is when the tax authority allows the service provider to receive all TxIDs sent by Alice and Bob. The service provider gets the full data of each TxID on the blockchain and then determines that there is at least one public key on that TxID that can be associated with the sender, say Alice, and the same for all TxIDs sent by Bob. If the TxIDs do not match, the service provider reports them to the tax authority.

[0155] On-chain monitoring is when a tax authority requests a service provider to transmit the tax authority’s public key, PK, on ​​the blockchain. T The purpose of this is to allow the tax authorities to monitor transactions sent to the public key PK T Register with the service provider and PK T The service provider monitors any transactions sent to the A Identifies the sender of the TxID B The SP extracts the Merkle root MR, calculates MR', checks whether MR and MR' are equal, and finally sends a message to the tax authority to report the result.

[0156] The tax authority will consider reports from the SP's on-chain and off-chain monitoring and take any punitive action. Note that the tax authority may not need to ask Alice who the counterparty of that TxID is, since the service provider has identified it in the off-chain monitoring. Furthermore, since the off-chain monitoring provides a complete record, the tax authority can instantly match all transactions between the two entities and identify any discrepancies.

[0157] conclusion Other variations or uses of the disclosed techniques may become apparent to one of ordinary skill in the art given the disclosure herein, and the scope of the disclosure is not limited by the described embodiments, but only by the claims appended hereto.

[0158] 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 a 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, the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references 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 characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0159] 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 above-mentioned functions of creating, publishing, propagating and storing blocks 151 in 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. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

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

[0162] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, an apparatus, or a program may be provided according to any one or more of the following statements:

[0163] Statement 1: A computer-implemented method for determining whether a first party and a second party agree on membership of a set of blockchain transactions transacted between the first party and the second party, comprising: receiving, from a first party, a first report comprising an indication of each of a plurality of blockchain transactions involving the first party, including at least the blockchain transactions in the set, the first report comprising one or more report messages transmitted one or more times; receiving, from a second party, a second report comprising an indication of each of a plurality of blockchain transactions involving the second party, including at least some or all of the blockchain transactions in the set, the second report comprising one or more report messages transmitted one or more times; observing on the blockchain a first attestation recorded by a first party in at least one first blockchain transaction, the first attestation comprising a first attestation value derived from the first party applying a first transformation to instructions reported in the first report; observing on the blockchain a second attestation recorded by a second party in a second blockchain transaction, the second attestation comprising a second attestation value derived from the second party applying a second transformation to the instructions reported in the second report, the first and second blockchain transactions being distinct from the set; checking that the first report is consistent with the first proof by applying a first transformation to the instructions reported in the first report and comparing with the first proof from the blockchain; checking that the second report is consistent with the second proof by applying a second transformation to the instructions reported in the second report and comparing with the second proof from the blockchain; determining whether the indications in the first report refer to the same set of members as the indications in the second report; A computer-implemented method comprising:

[0164] Statement 2: The method of statement 1, wherein the first and second proof values ​​each comprise a hash value, and the first and second transformations each comprise at least one hash function.

[0165] Statement 3: The first proof value comprises the root of a first hash tree, and each of the instructions reported in the first report is a leaf of the first hash tree; and / or The second attestation value comprises the root of a second hash tree, and each of the instructions reported in the second report is a leaf of the second hash tree. The method according to statement 2, wherein either or both of

[0166] Statement 4: The method according to any one of statements 1 to 3, wherein the first and second transformations are transformations of the same form.

[0167] Statement 5: A method according to any one of statements 1 to 4, wherein the instructions in the first and second reports comprise transaction IDs of transactions reported in the first and second reports, respectively.

[0168] Statement 6: The method of any one of statements 1 to 5, wherein each of the first and second transactions is addressed to a third party's public key.

[0169] Statement 7: The method of statement 6, wherein the first and second transactions each have an output comprising a lock script, the lock script being addressed to a third party by including an address based on the third party's public key and requiring a corresponding signature of the third party to unlock it.

[0170] Statement 8: The method of any one of statements 1 to 7, wherein the transactions between the first party and the second party comprise at least some transactions from the first party to the second party, each transaction comprising an address based on a respective child public key of the second party, each child key being related to the master public key of the second party by a derivation function, the derivation function being parameterized by respective derivation information.

[0171] Statement 9: The method of statement 8, wherein the respective derivation information for each child key comprises a respective invoice, sales order, or receipt for a respective transaction.

[0172] Statement 10: The method of statement 8 or 9, wherein the derivation information comprises a chain code common to the child public keys.

[0173] Statement 11: The method of any one of statements 8, 9, or 10, wherein the derivation information for each child key comprises a respective index value.

[0174] Statement 12: The method of any one of statements 8 to 11, wherein the master public key of the second party is linked to the public identity of the second party by a digital certificate authority.

[0175] Statement 13: Receiving, from a first party, respective derivation information for at least one of the blockchain transactions in the set; responsive to determining that the first and second reports indicate different memberships of the set, using the derivation function, the second party's master public key, and the received derivation information to determine a child public key of the second party, thereby verifying that each address is linked to the second party's master public key; 13. The method of any one of statements 8 to 12, further comprising:

[0176] Statement 14: The method of statement 13, wherein the step of receiving the respective derived information is also performed in response to a determination that the first and second reports indicate different memberships of the sets.

[0177] Statement 15: The method of statements 13 or 14, wherein the second party's public key is linked to the second party's public identity by a digital certificate authority, and the determining step further comprises using the master public key and a digital certificate issued by the certificate authority to verify the second party's public identity (ID).

[0178] Statement 16: The first report comprises a plurality of first report messages received at different times, each first report message reporting a different respective one of the blockchain transactions related to the first party, and the first attestation value is an instance of a periodic attestation combining the blockchain transactions related to the first party within a time window; and / or The second report comprises a plurality of second report messages received at different times, each second report message reporting a different respective one of the blockchain transactions involving the second party, and the second attestation value is an instance of a periodic attestation to the blockchain transactions involving the second party within a time window. 16. The method according to any one of statements 1 to 15, wherein either or both of

[0179] Statement 17: The method of any one of statements 1 to 16, wherein the instructions in the first report and / or the second report further include instructions for each of one or more additional blockchain transactions involving one or more additional parties other than the first party, the second party, and the third party, the set being an intersection of transactions involving the first or second party.

[0180] Statement 18: the first proof value comprises the root of a hash tree, and each of the instructions reported in the first report becomes a leaf of the hash tree; In response to determining that the first and second reports indicate different memberships of the set, identifying the presence of at least one blockchain transaction indicated in the first report but not indicated in the second report; using the hash tree root and the hash tree path between the root and the instructions representing the lost transaction to generate evidence that the second party made a false attestation; presenting the evidence to the fourth party based on the use of the root and path of the hash tree without disclosing to the fourth party the direction of the transaction of the further party; The method according to statement 17, comprising:

[0181] Statement 19: The method of statement 18, wherein the evidence depends on at least statement 15, further including verification of a link to the public identity (ID) of the second party.

[0182] Statement 20: The method described in any one of Statements 1 to 19, where the third party is a tax authority.

[0183] Statement 21: A memory having one or more memory units; a processing device comprising one or more processing units; wherein the memory stores code configured to be executed on a processor, the code being configured, when on the processor, to perform a method according to any one of statements 1 to 30.

[0184] Statement 22: A computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 20.

[0185] Statement 23: A computer-implemented method performed by a first party to attest to a set of blockchain transactions conducted between the first party and a second party, comprising: for each of a set of blockchain transactions, executing a protocol with a second party via an off-chain side channel to form a respective blockchain transaction, each blockchain transaction once formed comprising an address based on a respective child public key of the second party, the child public key being related to the master public key of the second party by a derivation function, the derivation function being parameterized by respective derivation information, the protocol comprising receiving the derivation information and the child public key from the second party; upon request from the third party, reporting the respective derivation information to the third party, thereby enabling the third party to verify the link between the master public key and the child public key of the second party; Equipped with Each set of blockchain transactions, once formed, is recorded on the blockchain; 10. The computer-implemented method, wherein the method further comprises the step of transmitting at least one separate blockchain transaction for recording on the blockchain comprising a proof of the set of blockchain transactions, the proof comprising a transformation of the set of instructions.

[0186] Statement 24: A memory having one or more memory units; A processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to execute the method of statement 23 when on the processing device; A computer device comprising:

[0187] Statement 25: A computer program embodied on a computer readable storage and configured to perform the method of statement 23 when executed on one or more processors.

[0188] According to another aspect disclosed herein, a method may be provided that comprises action of any or all of a first party, a second party, and / or a third party.

[0189] According to another aspect disclosed herein, a system may be provided that includes computing equipment of any or all of a first party, a second party, and / or a third party. [Explanation of symbols]

[0190] 100 Systems 101 Packet Switching Network 102 Computer Equipment 102a Computer equipment 102b Computer equipment 103 Parties 103a User 103a Alice 103a First Party 103b Second Party 103b Bob 104 Bitcoin nodes 104 Blockchain nodes 105 Client Applications 106 Peer-to-Peer (P2P) Networks 106 Blockchain Network 107 Off-Chain Side Channels 150 Blockchain 151 Data Blocks 151 New Blocks 151n-1 Block 152 Blockchain Transactions 152 Transactions 152i Preceding Transaction 152j Current Transaction 153 Genesis Block (Gb) 154 Ordered Sets (or "Pools") 155 Block Pointer 201 Header 202 Input 202 Input Field 203 Front Output 203 Output 203 Output Fields 302 Computer Equipment 303 Third party

Claims

1. 1. A computer-implemented method for determining whether a first party and a second party agree on membership of a set of blockchain transactions transacted between the first party and the second party, the method comprising: receiving, from the first party, a first report comprising an indication of each of a plurality of blockchain transactions involving the first party, including at least the blockchain transaction in the set, the first report comprising one or more report messages transmitted one or more times; receiving, from the second party, a second report comprising an indication of each of a plurality of blockchain transactions involving the second party, including at least some or all of the blockchain transactions in the set, the second report comprising one or more report messages transmitted one or more times; observing on a blockchain a first proof recorded by the first party in at least one first blockchain transaction, the first proof comprising a first proof value derived from the first party applying a first transformation to the instructions reported in the first report; observing on the blockchain a second proof recorded by the second party in a second blockchain transaction, the second proof comprising a second proof value derived from the second party applying a second transformation to the instructions reported in the second report, the first and second blockchain transactions being distinct from the set; checking that the first report is consistent with the first proof by applying the first transformation to the instructions reported in the first report and comparing with the first proof from the blockchain; checking that the second report is consistent with the second proof by applying the second transformation to the instructions reported in the second report and comparing with the second proof from the blockchain; determining whether the indication in the first report indicates the same set of members as the indication in the second report; A computer-implemented method comprising:

2. 2. The method of claim 1, wherein the first and second proof values ​​each comprise a hash value, and the first and second transformations each comprise at least one hash function.

3. the first attestation value comprises the root of a first hash tree and each of the indications reported in the first report is a leaf of the first hash tree; and / or The second attestation value comprises the root of a second hash tree, and each of the indications reported in the second report is a leaf of the second hash tree.

3. The method of claim 2, wherein the method is one or both of:

4. 4. The method of claim 1, wherein the indication in the first and second reports comprises a transaction ID of the transaction reported in the first and second reports, respectively.

5. 5. The method of claim 1, wherein each of the first and second transactions is addressed to a public key of the third party.

6. 6. The method of claim 5, wherein the first and second transactions each comprise an output comprising a lock script, the lock script being addressed to the third party by including an address based on the third party's public key and requiring a corresponding signature of the third party to unlock it.

7. 7. The method of claim 1, wherein the transactions between the first party and the second party comprise at least some transactions from the first party to the second party, each transaction comprising an address based on a respective child public key of the second party, each child key being related to the master public key of the second party by a derivation function, the derivation function being parameterized by respective derivation information.

8. 8. The method of claim 7, wherein the respective derivation information for each child key comprises a respective invoice, sales order, or receipt for the respective transaction.

9. The method of claim 7 or 8, wherein the derivation information comprises a chain code common to the child public keys.

10. 10. The method of claim 7, wherein the derivation information for each child key comprises a respective index value.

11. 11. The method of claim 7, wherein the master public key of the second party is linked to the public identity of the second party by a digital certificate authority.

12. receiving, from the first party, the respective derivation information for at least one of the blockchain transactions in the set; responsive to determining that the first and second reports indicate different memberships of the set, using the derivation function, the master public key of the second party, and the received derivation information to determine the child public key of the second party, thereby verifying that each address is linked to the master public key of the second party; 12. The method of claim 7, further comprising:

13. 13. The method of claim 12, wherein the step of receiving the respective derived information is also performed in response to determining that the first and second reports indicate different memberships of sets.

14. 14. The method of claim 12 or 13, wherein the master public key of the second party is linked to a public identity of the second party by a digital certificate authority, and wherein the determining step further comprises using the master public key and a digital certificate issued by the certificate authority to verify the public identity (ID) of the second party.

15. the first report comprises a plurality of first report messages received at different times, each first report message reporting a different respective one of the blockchain transactions relating to the first party, and the first proof value is an instance of a periodic proof combining blockchain transactions relating to the first party within a time frame; and / or The second report comprises a plurality of second report messages received at different times, each second report message reporting a different respective one of the blockchain transactions related to the second party, and the second proof value is an instance of a periodic proof for the blockchain transactions related to the second party within a time frame.

15. The method of any one of claims 1 to 14, wherein the method is one or both of:

16. 16. The method of claim 1, wherein the instructions in the first report and / or the second report further include instructions for each of one or more additional blockchain transactions involving one or more additional parties other than the first party, the second party, and a third party, and the set is an intersection of transactions involving the first and second parties.

17. the first attestation value comprises the root of a hash tree, and each of the instructions reported in the first report becomes a leaf of the hash tree; In response to determining that the first and second reports indicate different memberships of the set, identifying the existence of at least one blockchain transaction indicated in the first report but not indicated in the second report; using the hash tree root and the hash tree path between the root and the indication representing the lost transaction to generate evidence that the second party made a false attestation; presenting the evidence to the fourth party based on the use of the root and path of the hash tree without disclosing to the fourth party the direction of the transaction of the further party; The method of claim 16, comprising:

18. 18. The method of claim 17, wherein the evidence further includes the verification of the link to the public identity (ID) of the second party.

19. a memory comprising one or more memory units; a processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to execute the method of any one of claims 1 to 18 when present on the processing device; A computer device comprising:

Images