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] A blockchain refers to a form of distributed data structure in which a replicated copy of the blockchain is maintained and widely disseminated at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in the sequence, which may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, verified pending transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain can be removed at some nodes, and block publication can be achieved simply through the 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. Blockchains can also be utilized to layer additional functionality on top of the blockchain. For example, blockchain protocols 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, thus allowing for the incorporation of increasingly complex data. For example, this could be used to store electronic documents on a blockchain, or to store audio or video data.

[0004] Nodes (often called "miners") in a blockchain network conduct a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them 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) submits the transaction to one of the nodes in 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 blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including 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 a certain amount of digital assets, i.e., a number of tokens. The detection and rejection of invalid transactions is enforced by the actions of competing nodes, who act as agents in the network, encouraging them to report and block misbehavior. Widely published information allows users to continuously audit node performance. By publishing simple block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] In an "output-based" model (also known as 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 transaction's progression sequence. A usable output is sometimes referred to as a UTXO ("unspent transaction output"). An output may further comprise a locking script that specifies the conditions for redeeming 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 indicated output's locking script. 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 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 the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied by each node is that the unlock script meets all of one or more conditions defined in the lock 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. A node that determines that the target transaction is invalid according to either of these conditions will not propagate the transaction (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 a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] It has been identified herein that there are many scenarios in which it is 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 that take place 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 send off-chain reports of transactions they each involved to a third party (e.g., tax authorities, auditors, etc.) and have that third party store all of the reports. However, this would burden the third party's centralized storage space. Furthermore, future proofing would also rely on third-party 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 and Bob's on-chain transactions, without requiring either 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 and Bob's transactions are scattered throughout the blockchain, and unilaterally searching through them all 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 must report their transactions to a third party, but each must provide an attestation of their reported transactions in additional transactions recorded on-chain (these additional transactions are referred to herein as the "first" and "second" transactions, and are separate from the reported transaction, i.e., the transaction between Alice and Bob). For example, the attestation could be the hash root of a hash tree (sometimes called the Merkle root of a Merkle tree), with transaction IDs, etc., becoming leaves.

[0012] According to one aspect disclosed herein, a computer-implemented method for determining 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 is provided. The method includes the steps of 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, the first report comprising one or more report messages transmitted one or more times, the plurality of blockchain transactions involving the first party including at least one of the blockchain transactions in the set, the plurality of blockchain transactions involving the second party including at least some or all of the blockchain transactions in the set, the plurality of report messages transmitted one or more times. The method further comprises the steps of observing, by a third party, a first proof on the blockchain 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 on the blockchain 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 verifies 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. alignment and verifying that the second report is a second proof by applying a second transformation to the instructions reported in the second report and comparing it with a second proof from the blockchain. alignmentThe 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] Reports inform third parties of the reported transactions, while proofs remain on-chain as immutable public records. Third parties can verify that a report is a valid proof. alignment If the decision reveals that one of the parties misrepresented the set to the other, the proof can be used as irrefutable evidence that one of the parties, say Bob, made a false declaration.

[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 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 IDs) from the first and second reports. Instead, the first and second parties may store their own records of the transaction indications in a set. These records of the first and second parties can later be used in combination with on-chain authentication to attest to the transactions they attested. If Alice or Bob destroy their records, they cannot reproduce the proof, which in itself can be evidence of fraud. In other words, because there are on-chain proofs, if Alice and Bob later cannot generate a set of TxIDs that satisfy the proofs, this means they discarded (or perhaps lost) some records, but they cannot pretend not to have reported or attested these transactions. All that a third party needs to remember is the proof of fraud, 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 memorizes 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 this transaction is included in the proven Merkle tree.

[0016] At the same time, since the publicly recorded proof is a transformation of the set (hopefully an irreversible transformation) rather than an explicit instruction (e.g., the raw TxID), 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, there would be a public record of all transactions involving Alice, all transactions involving Bob, etc.

[0017] In an embodiment, Alice's report may include both transactions involving Bob and transactions involving one or more additional parties (such as Charlie), in which case her proof would prove all of 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 misrepresentation needs to be provided to a fourth party, such as a court or police, it is desirable to be able to do so without violating Charlie's privacy by revealing the identity (ID) of Charlie's transactions with Alice (e.g., without revealing the transaction ID).

[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 involving one or more additional parties other than the first party, the second party, and the third party, and the set may include instructions for transactions involving the first or second party. common set The first proof value may comprise the 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 include, 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 that is indicated in the first report but not in the second report, using the hash tree root and a hash tree path between the root and the instructions representing the missing transaction to generate evidence that the second party made a false proof, and presenting the evidence to a fourth party based on use of the hash tree root and path without disclosing to the fourth party the instructions of the further parties' transactions.

[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 transaction instructions in question between Alice and Bob, e.g., a transaction ID) is indeed a leaf in the hash tree with that hash root, without having to reveal other leaves (in this case, the transaction instructions between Charlie and Alice, e.g., TxIDs). Thus, evidence of Bob's misrepresentation can be presented to a fourth party, such as a court or police, 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 explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 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. [Figure 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 INVENTION

[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 plurality 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 nearly 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, e.g., 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 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, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0024] A 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 within 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 as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain type of data structure. 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 specific 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, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and thereby redeem or spend it). 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 the 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 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0026] Each blockchain node 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 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 herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 accepts as valid and that the node 104 is obligated to reject 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. While the preceding transaction 152i must exist and be validated for the current transaction to be valid, 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" herein refers to a predecessor in the logical sequence linked by a pointer, not necessarily to a time of creation or transmission in the chronological order, and therefore does not necessarily preclude 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 whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer 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 may be the original user or entity 103a to provide change). In some cases, the transaction can also have multiple inputs to combine amounts from multiple outputs of one or more preceding transactions and redistribute them into 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 establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party sends the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient will ultimately transmit this transaction to one or more blockchain nodes 104 (which today are typically servers or data centers, but could in principle be other user terminals) in the network 106. It is also possible that the party 103 establishing a new transaction 152j sends the transaction directly to one or more of the blockchain nodes 104, possibly without sending it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically 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 a new transaction 152j matches a condition defined in the output of a preceding transaction 152i to which 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 thereof.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 the 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 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 purposes). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because transaction ordering is defined, 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, which is 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 involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined 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 given 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 it to the network 106, providing its 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 whether the hash output 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 is then 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, pointing to a previously created block 151n-1 in the chain. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of hashing, 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 validated 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. Block pointers 155 also 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 based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first first defines which transactions 152 will be included in the next new block 151n and in what order, updating the current pool of unpublished transactions 154. 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 for resolving any "forks" that may occur, where two blockchain nodes 104 solve the puzzle within a very short time of each other, allowing conflicting views of the blockchain to be propagated between the nodes 104. In other words, 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, as 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 a certain amount of digital assets from one agent or user to another) is granted the ability to allocate an additional, specified amount of digital assets in a new, special type of transaction that distributes an additional, specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof of work signals the node constructing the new block's intention to follow protocol rules and allows this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. A regular (non-generational) transaction 152 often 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 typically called a "transaction fee," and is explained below.

[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 comprising one or more physical server units, or 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 multiple parties 103 that act as 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., have 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. While 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 roles required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (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 "first party" and "second party," respectively.

[0039] The computing 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 computing equipment 102 of each party 103 further comprises 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 memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any action attributed to a given party 103 herein may be implemented using software executing on the processing unit of the respective computing equipment 102. The computing 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 smartwatch. The computing equipment 102 of a given party 103 may also comprise 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 the party 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: While various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting; 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 thereof. 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 operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for transactions in which the respective party 103 is a recipient (or, in embodiments, 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 transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 is configured to execute software configured to validate transactions 152 according to a blockchain node protocol and to forward the transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another; a given transaction protocol operates in conjunction with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0044] When a given party 103, e.g., Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she 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 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 for being "valid," examples of which will be discussed in more detail 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 the script and the node protocol.

[0045] Provided that the newly received transaction 152j passes the tests 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 quickly propagate throughout the network 106.

[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 included in the latest block 151. Ultimately, the blockchain node 104 will have solved 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 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0047] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about 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 an account-based model, each transaction defines the amount to be transferred by referencing the absolute account balance, 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 the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). 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 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the 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 while the exemplary UTXO-based protocol is described with reference to Bitcoin, it can be implemented in other exemplary blockchain networks as well.

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

[0051] Suppose Alice 103a wants to create transaction 152j to transfer an amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for 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 merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could refer to a preceding (i.e., earlier) transaction that still has unspent output 203 locked for 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 Tx0 may even be submitted after Tx1 if the node protocol allows buffering of "orphan (Tx0)" transactions. As used herein in the context of a sequence of transactions, the terms "preceding" and "subsequent" refer to the order of transactions in a sequence defined by transaction pointers specified within the transactions (e.g., which transactions point to which other transactions). These terms 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, transmitted 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 specific amount of time to wait for its parent.

[0053] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, labeled herein as 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 subsequent transaction must satisfy in order for the subsequent transaction to be validated and, therefore, for 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 subsequent 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, for example, 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 contain Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A] is Alice's public key P from her public-private key pair. A , which includes a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 comprises a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 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 expression, "||" denotes concatenation, "<...>" means putting 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 either case, when executed together, the scripts will create a new lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A, authenticates that the unlock script in Tx1's input 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 authentication using public-private cryptography 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 an 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 with 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 portion of a transaction, etc., can, in embodiments, mean signing a hash of that data portion or portion 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 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby causing the transaction to propagate throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO 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, 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 blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in 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 for 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; another portion is spent. However, it is possible to split an amount from a 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 all of the 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 is typically also required to include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and therefore may not be propagated or included in the blockchain 150, even though it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require 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 digital assets 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 transaction 152's UTXOs 203 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 entire blockchain 150. No number defining a given party's 103 total balance is stored anywhere in the blockchain 150. 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 spent in another forward transaction. This can be done by querying the copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

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

[0064] Typically, the input for a transaction is a public key P AIn embodiments, 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 therefore fixed at the time of signing) that selects which outputs are signed.

[0065] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction typically includes the public key of the party being locked. 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 include authenticating the signature. More generally, a scripting language can be used to define any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0066] Side Channels As shown in FIG. 1, the client applications on Alice's and Bob's respective computing devices 102a, 120b may each include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the direction of either party or a third party). The side channel 107 allows for the exchange of data outside of the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction 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.” A 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 over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, a side channel 107 referenced anywhere herein may comprise any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separately from the blockchain network 106. 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, when it is said that Alice and Bob exchange information or particular portions of data, etc., over the side channel 107, it should be noted that this does not necessarily imply that all of these portions of data must be transmitted over the exact same link or the same type of network.

[0068] Verifying membership in a set of transactions As mentioned in the Summary 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 between them (i.e., agree on which transactions are part of the set). It is also desirable to do so in a way that can verify the identity of the party making the misrepresentation. For example, the third party could be a tax authority checking that both Alice and Bob reported the same set of transactions for tax purposes. Alternatively, Alice and Bob could be two divisions within a company, and the third party could be a private auditor checking that the two divisions reported 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 jewelry or animal products. In this case, the third party could be a regulatory agency checking that one party is not attempting to conceal fraudulent transactions. Note again that "Alice" and "Bob" are merely 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)'s computer device 102a, a second party 103b (Bob)'s computer device 102b, and a third party 303 (e.g., a tax authority, an auditor, etc.)'s computer device 302. While various actions are described below as being performed by the first party, the second party, the third party, etc., it will be understood that this is shorthand for meaning that the actions are performed by each party 103a, 103b, 303 using their respective computer devices 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 geographic sites. The various actions described herein performed by the third party 303 may be performed using software (code) stored in the memory of the third party computing equipment 302 and executed on a processing unit of the third party computing equipment 302. The memory may comprise one or more memory units, and the processing unit may comprise one or more processing units. Similar comments regarding various options for implementation of 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 node 104 of the first and second parties.

[0071] The third-party computing device 302 is connected to the blockchain network 106 so as to be able to inspect at least the transactions 152 stored in blocks 151 on the blockchain 150. The first and second party computing devices 102a, 102b are also connected to the blockchain network 106 so as to be able to conduct blockchain transactions 152 between them as described above. Furthermore, as will be explained in more detail shortly, this allows for the recording of additional "proof" transactions containing proof for transactions conducted between Alice and Bob (and potentially between themselves and other parties, such as Charlie). For example, this could 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 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 Alice and Bob to negotiate transactions between them before sending them to the blockchain 150 for recording. Protocols for this, such as Simple 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 embodiments disclosed herein.

[0075] In step 410, Alice and Bob conduct a blockchain transaction between themselves. This involves recording the blockchain transaction on the blockchain 150 transacted between Alice and Bob, for example, using any of the techniques described above in connection with FIGS. 1 and 2. In an output-based (e.g., UTXO-based) model, this means that transaction 152 has an input 202 that points to the output of another prior transaction that is locked to Alice. The input 202 of the current transaction (between Alice and Bob) has an unlock script that includes Alice's signature, thus unlocking the pointed-to output of the prior transaction. The transaction between Alice and Bob has a forward output 203 that includes 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 includes 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 the TATT used in Bitcoin, this would be in 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, as the public key itself (not a hash) appears in the unlocking script.

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

[0077] In embodiments, 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 template versions of the transaction between Alice and Bob via the side channel 107, with each party filling out their portion 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 for inclusion in the transaction. The exchanged identifying information 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, derive a transaction-specific child public key from the master for use in that particular transaction's locking script. This means, among other things, that Bob cannot be identified by his 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, where the parameters are the derivation information and the function is the derivation function. The derivation information comprises one or more elements specific to a particular transaction, such as a transaction index value or information about the transaction's content or purpose, 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. The details of suitable child key derivation functions are themselves known to those skilled in the art.

[0079] In the protocol of step 410, the identifying 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 keys or addresses are linked to Bob's master public key. In either case, Alice may also later provide such information to third party 303 if it is detected that Bob has made a misrepresentation (as will be explained in more detail 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 third party 303 of this, 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 conducted 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-chain so that the third party can find it on-chain (in the case of an output-based model, this means there is an output containing the third party's address, which the third party can monitor on-chain). In either 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 supposed to send) a report of the same blockchain transaction he made with Alice to third party 303. Everything mentioned above about how Alice's report is generated and sent can also be applied mutatis mutandis to Bob's report.

[0083] The method continues as Alice and Bob conduct 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 could 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 separate instances of steps 420 and 430 for each transaction 410. That is, Alice and Bob each send a separate reporting message to a third party after each transaction. For example, the reporting could be sent in response to agreeing to the transaction via a protocol on side channel 107 or in response to confirmation that the transaction was actually recorded in block 151 on 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 summarizing all transactions of interest that she was involved in 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 third parties 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 transaction 410 between Alice and Bob. This should be the same set that she reported to the third party 303 in 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 a weekly, monthly, or yearly proof. The proof comprises a proof value generated by applying an obfuscation transformation (preferably, an irreversible 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 combinations of 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 later, it is more preferable for the proof value to be 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 the hash of one of the corresponding leaves. At the next higher layer of the tree, each node is the concatenation of a different respective subset (typically two) of the nodes from 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 "+" 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 combined subsets from each layer to the next 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, all that is needed is 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). All the leaf values ​​are not needed. This makes it possible to provide, for example, that TxID_1 is a member of a set without giving away or knowing 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-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 a negligible (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 regarding Alice's proofs also applies mutatis mutandis to Bob. Bob does not necessarily use the same form of proof as Alice, although in embodiments he does (e.g., Merkle root).

[0091] In step 460, third party 303 monitors attestation transactions from Alice and Bob on blockchain 150. In embodiments, this may comprise monitoring blockchain 150 for transactions addressed to 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 third party 303 subscribing to a service that monitors 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, for example, by sending a pointer to the transaction.

[0093] FIG. 5 illustrates a method that may be performed by a third party 303 according to an embodiment 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., ID) 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 proof values ​​match, as do Bob's authentication values, then the method proceeds to step 550. Here, 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 a week, month, or year. 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 retaining 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, last month, or last year), the transaction that is present in one party's report but not 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 the indication (e.g., transaction ID) of the transaction that one party (e.g., Alice) reported but 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 the non-reporting party (e.g., Bob) as 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 that it is Bob who is non-compliant, in response to the decision to report the discrepancy, the third party 303 may send a request to Alice asking her to provide some or all of the identifying information initially received from Bob during stage 410 of negotiating the transaction via side channel 107. This may comprise the derivation information (e.g., the chaincode, index, and / or invoice) described above. Given Bob's master public key, the derivation information, and the known type of 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 phase before starting to use the service. The type of derivation function used may be default, communicated by Alice, or pre-registered by Bob. The third party 303 may also obtain the address actually used in the suspicious transaction by reading it from the suspicious transaction on-chain or receiving it from Alice. The third party 303 can then compare this with the calculated child public key to determine whether it is the same as the one used for Bob's address. For example, if the address is a hash of a public key, this comparison may involve 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 misrepresentation.

[0099] For completeness, note that if it is Alice's behavior that is being checked, then in typical transaction formats, Alice's child public key appears explicitly in the transaction, as the public key itself (not the hash) appears in the unlock script. Therefore, 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 it 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 certification authority (CA). The certificate binding the two may be obtained by Alice from Bob during protocol 410 and then provided by Alice to third party 303 upon request when a suspicious transaction is detected. Alternatively, the certificate may have been registered with third party 303 in advance by Bob, or may be obtained by third party 303 requesting the certificate directly from a CA. In either case, this may form part of evidence that the party known as Bob has in fact made a misrepresentation.

[0101] Optionally, both Alice and Bob register their master public keys with a third party before using the service (303). This is not necessarily a requirement, as Bob will need to give Alice the master key in any case (for reasons discussed 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 (ID), and child derivation information. If there is a discrepancy in the records, Alice may send all three to the third party 303. In this case, the third party 303 has everything necessary to prove the link between Bob's identity (ID) 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 embodiments, third party 303 may store evidence of Bob's non-compliance (i.e., his misrepresentation). To do this, third party 303 does not need to store every reported instruction (e.g., every transaction ID) from Alice and Bob's complete reporting. Third party 303 actually only needs to store evidence of misconduct. Only one transaction is needed to represent this. Thus, once 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. Third party 303 is then free to delete the rest of the reported transaction instructions (e.g., IDs). Third party 303 is left with only one transaction. This provides evidence of misconduct, because 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 can 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 a court). As previously mentioned, Merkle trees allow a candidate leaf to be proven 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; indications (e.g., TxIDs) of Charlie's transactions with Alice are not required. Since we assume that Alice has sent all expected transactions to the third party 303, the third party 303 can determine the associated Merkle path. Once the third party 303 has all the transactions (in a particular order), it can construct Alice's Merkle tree and recreate the Merkle root. Knowing the entire tree, the path to any leaf can be easily calculated.

[0105] Note: While the above describes all transactions between Alice and Bob, Alice and Charlie, etc., as well as the first and second proof transactions, and any other transactions used for on-chain signaling, as being 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 could be recorded on another blockchain. Or, transactions between Alice and Bob could include transactions that occur 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 equally be applied in reverse (regardless of whether Bob is the payer or payee).

[0107] Application example - tax return Below we consider an example application of the disclosed system, where the transparency and anonymity of the blockchain public ledger can be used to encourage tax compliance. In particular, this 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 operate as follows: Consider a blockchain transaction between two parties, Alice and Bob. To comply with AML regulations, Alice and Bob exchange information off-chain, which proves that their identities (IDs) are linked 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 TxIDs to the same authority, the authority must receive each TxID twice. For example, if they receive only one TxID from Alice, they can investigate and ask who they are transacting with. Alice answers that it is Bob and provides the authority with a provable link from his identity (ID) 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 (ID) 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 (ID)). Subsection 3 explains to what extent 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 regular transaction; its structure does not need to change at all. A similar format can be used in other output-based (e.g., UTXO-based) models.

[0114] For simplicity, additional inputs or outputs, such as changes to Alice, are not 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, and may also be included in other ways, such as OP_DROP or OP_RETUTN in other transaction protocols.

[0119] Typically, Alice has a master public key, PK A and possibly chaincode C A This master key can be tied to Alice's identity (ID), for example, by a Certificate Authority (CA) issuing 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.

[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 controlled by Alice.

[0124] Transaction TxID1 also includes the option to store payload data in an unavailable output (this is a common location 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 may contain metadata about the transaction, for example: General receipt data such as items purchased, individual costs, seller name, and timestamp. ·Registration and tax codes of the businesses involved. Identity (ID) 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 a transaction without giving further details (some salt may need to be included to ensure sufficient entropy in the hash preimage). If a hash commit is used, the hash preimage 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, details of which will not be discussed here. Taxes do not necessarily have to be paid in blockchain transactions, 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 earlier, this public key is Bob's master key PK B This can be linked to his identity, which in turn can be linked to his identity. There are usually two ways to do this:

[0129] 1) A process similar to BIP32, e.g.

[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 Alice and Bob's master keys 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, has the characteristic that it can be provably linked to m.

[0140] The index i in process (1) is used to determine whether the invoice m or the public key PK is used in a way that preserves the functionality of BIP32 wallet restoration. A This allows for both approaches to be integrated. We 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, this system considers only two entities, Alice and Bob. Alice and Bob share the master public key PK described in subsection 1 above. A and P.K. B must be registered with the tax authorities, which can be established through the issuance of a certificate or tax code from the tax authorities.

[0142] A well-known public key PK representing the address used by tax authorities to record or "file" tax receipts T Assume we have a public key PK that is reserved solely for receiving and merging on-chain tax returns from Alice and Bob. T is merely a warning address and is not a way 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 Filing: The following shows the protocol from Alice's perspective, but it is the same as Bob's. This is an example of the method shown schematically in Figure 4. 1. Alice and Bob construct a transaction. Alice and Bob jointly create 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 may provide data necessary for the derivation of the child keys described in Section 1.1. They also send a link to their 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 his 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 desired 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 each transaction between the two entities. 4. After a typical period of time, say one month, Alice receives all transactions TxID1…TxID N Collect 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 issue Merkle-root MR A and MR 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 the method shown schematically 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 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 following 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 during the tax filing stage. At this stage, the tax authorities check that all TxIDs sent during that month are reported twice: once by Alice and once by Bob. If yes, the tax authorities stop the checking process and identify Alice and Bob as compliant for that month. 6. Identify which transactions were confirmed only once and request information about 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, this 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 for 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 MR 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 within the system to help tax authorities identify non-compliance more effectively.

[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 become 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 tax authorities in identifying mismatched transactions, a third-party service provider monitors the activities of entities on behalf of the tax authorities. The term "monitor" means that information from the blockchain network (such as the tax authority's public key PK) is T The TxID includes 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 Bitcoin ownership is very important and essential in a tax non-compliance identification system. Existing methods for verifying ownership in our system are suitable by using DHT and the Bitcoin blockchain.

[0152] The DHT in subsection 1 above is considered a database in which data is stored and maintained by participants. As applied herein, Alice, Bob, the tax authority, and the service provider are participating nodes, and the data are all 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 Any transaction sent to the off-chain monitor will be checked against each TxID entity sent.

[0154] Off-chain monitoring involves the tax authority allowing a service provider to receive all TxIDs sent by Alice and Bob. The service provider retrieves the complete data for 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 the tax authority sends the tax authority's public key (PK) to the service provider 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 T Service providers monitor any transactions sent to the Merkle transaction TxID. A Identifies the sender of the TxID B Similarly, 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 review 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 the TxID is, as the service provider has identified it in off-chain monitoring. Furthermore, because 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 those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[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 a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, references above 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) that perform only one or some, but not all, of these functions. That is, network entities may perform the function 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 present invention, blockchain network 106 may not be the Bitcoin network. These embodiments do not exclude 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 blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity configured to create and publish blocks 151 but not 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 entities / elements 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 blockchain nodes 104.

[0162] It will be understood 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 transaction 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 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 instructions reported in the first report; observing on the blockchain 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; Applying a first transformation to the instructions reported in the first report and comparing it with a first proof from the blockchain verifies that the first report is the first proof. alignment checking that The second report is verified as a second proof by applying a second transformation to the instructions reported in the second report and comparing it with a second proof from the blockchain. alignment checking that determining whether the indications in the first report indicate 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 proof 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. 2. The method according to claim 1, 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 public key of a third party.

[0169] Statement 7: The method of statement 6, wherein the first and second transactions each comprise 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 the third party's corresponding signature to be unlocked.

[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 derived 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 determining that the first and second reports indicate different memberships of the sets.

[0177] Statement 15: The method of statement 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 wherein 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 proof value is an instance of a periodic proof combining the blockchain transactions related 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 involving the second party, and the second proof value is an instance of a periodic proof for the blockchain transactions involving the second party within a time frame. 16. The method according to any one of statements 1 to 15, wherein one or both of

[0179] Statement 17: 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, and the set includes instructions for transactions involving the first or second party. common set 17. The method according to any one of statements 1 to 16,

[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 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 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 of statement 17, comprising:

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

[0182] Statement 20: 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; 31. A computing device comprising: a memory storing code configured to be executed on a processing unit, the code configured, when on the processing unit, to perform a method according to any one of statements 1 to 30.

[0184] Statement 22: A computer program embodied on 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 executed 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 the 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 keys being related to the second party's master public key 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; reporting the respective derivation information to the third party upon request from the third party, thereby enabling the third party to verify the link between the master public key and the second party's child public key; Equipped with Each set of blockchain transactions, once formed, is recorded on the blockchain, 1. A computer-implemented method, wherein the method further comprises transmitting at least one separate blockchain transaction for recording on the blockchain, the transaction 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, wherein a memory stores code configured to be executed on the processing device, the code being configured to perform the method of statement 23 when on the processing device; A computer device comprising:

[0187] Statement 25: A computer program embodied on 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 the 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 Switched 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 forward 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