WO2023156104A1 - Attestation d'appartenance d'un ensemble - Google Patents

Attestation d'appartenance d'un ensemble Download PDF

Info

Publication number
WO2023156104A1
WO2023156104A1 PCT/EP2023/050874 EP2023050874W WO2023156104A1 WO 2023156104 A1 WO2023156104 A1 WO 2023156104A1 EP 2023050874 W EP2023050874 W EP 2023050874W WO 2023156104 A1 WO2023156104 A1 WO 2023156104A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
candidate
hash
blockchain
node
Prior art date
Application number
PCT/EP2023/050874
Other languages
English (en)
Inventor
Steven Patrick COUGHLAN
Jack Owen DAVIES
Wei Zhang
Original Assignee
Nchain Licensing Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Licensing Ag filed Critical Nchain Licensing Ag
Publication of WO2023156104A1 publication Critical patent/WO2023156104A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/002—Countermeasures against attacks on cryptographic mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present disclosure relates to attesting to a set of unconsumed outputs (e.g. UTXOs) of blockchain transactions.
  • a set of unconsumed outputs e.g. UTXOs
  • a blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network”) and widely publicised.
  • the blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions.
  • Each transaction other than so-called “coinbase transactions”, points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions.
  • Coinbase transactions are discussed further below.
  • New blocks are created by a process often referred to as “mining”, which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain.
  • mining a process often referred to as "mining”
  • proof-of-work i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain.
  • the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.
  • the transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and/or to timeorder index pointers.
  • a blockchain can also be exploited in order to layer additional functionality on top of the blockchain.
  • blockchain protocols may allow for storage of additional user data or indexes to data in a transaction.
  • Nodes of the blockchain network (which are often referred to as “miners") perform a distributed transaction registration and verification process, which will be described in more detail later.
  • a node validates transactions and inserts them into a block template for which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus enabling each node to record the new block on the blockchain.
  • a user e.g. a blockchain client application
  • Nodes which receive the transaction may race to find a proof-of-work solution incorporating the validated transaction into a new block.
  • Each node is configured to enforce the same node protocol, which will include one or more conditions for a transaction to be valid. Invalid transactions will not be propagated nor incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, then the transaction (including any user data) will thus remain registered and indexed at each of the nodes in the blockchain network as an immutable public record.
  • the node who successfully solved the proof-of-work puzzle to create the latest block is typically rewarded with a new transaction called the "coinbase transaction" which distributes an amount of the digital asset, 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 of the network and are incentivised to report and block malfeasance.
  • the widespread publication of information allows users to continuously audit the performance of nodes.
  • the publication of the mere block headers allows participants to ensure the ongoing integrity of the blockchain.
  • the data structure of a given transaction comprises one or more inputs and one or more outputs.
  • Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions.
  • the spendable output is sometimes referred to as a UTXO ("unspent transaction output").
  • the output may further comprise a locking script specifying a condition for the future redemption of the output.
  • a locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets.
  • Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e.
  • a reference to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output.
  • the first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output.
  • the second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.
  • one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.
  • a hash tree in general is a data structure comprising a root node, one or more internal layers, and a leaf layer, arranged in a hierarchy from root (highest layer) to leaf layer (lowest in the hierarchy).
  • Each of the internal layers and the leaf layer comprises a plurality of nodes at that layer.
  • the root node is a hash of the nodes in the next layer down in the hierarchy, and in each internal layer, each node is a hash of a different subset of the nodes at the next layer down in the hierarchy.
  • each leaf nodes themselves are typically also hashes, each a hash of respective preimage data.
  • each leaf can be used to designate a different corresponding subset of the transaction outputs (e.g. the UTXOs of a given transaction), e.g. by each leaf comprising a hash of its corresponding subset of UTXOs (or the like).
  • a different corresponding subset of the transaction outputs e.g. the UTXOs of a given transaction
  • each leaf comprising a hash of its corresponding subset of UTXOs (or the like).
  • a party may wish to make a public commitment to the membership of a set of data items (i.e. commit to which data items are members of the set.
  • the data items could by UTXOs, or in other applications other types of data item.
  • a challenge transaction is recorded on chain that contains a hash of the root of the Merkle tree, along with code (e.g. a locking script) that will implement the puzzle.
  • code e.g. a locking script
  • the challengee would then submit for recordal on the blockchain a candidate transaction which points to the challenge transaction and comprises the Merkle root in question (e.g. in an unlocking script).
  • This would cause a node of the blockchain network to validate the transaction by running the code from the challenge transaction (e.g.
  • the method comprises causing a challenge transaction to be recorded on a blockchain, the challenge transaction comprises code implementing a challenge.
  • the code is configured to perform operations of: receiving and verifying a signature of a challengee from the candidate transaction; and also receiving from the candidate transaction candidate preimage data comprising a candidate instance of a root of the hash tree and a candidate instance of an additional piece of additional information identifiable to only a restricted subset of parties comprising at least the challenger and the challengee.
  • the code is configured to evaluate whether the candidate transaction provides a solution to a hash puzzle, by performing a hash operation on the candidate preimage data, thereby producing candidate hash result data, and verifying whether the candidate hash result data matches reference hash result data included in the challenge transaction, the reference hash result data being a result of applying the same hash operation to reference preimage data comprising a reference instance of the root and a reference instance of the additional information.
  • the candidate transaction is thus allowed to be validated for recordal on said blockchain, thereby redeeming a reward specified in the challenge transaction, on condition that the signature and the candidate hash result data are verified by said verifying steps.
  • Figure 1 is a schematic block diagram of a system for implementing a blockchain
  • Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain
  • FIGS 3 and 4 schematically illustrate the concept of a Merkle tree by way of example
  • Figure 5 schematically illustrates a scheme for indexing nodes of a Merkle tree
  • Figure 6 schematically illustrates by way of example the concept of a holey Merkle tree
  • Figure 7 is a flow chart of an example method according to embodiments disclosed herein.
  • Figure 8 is a flow chart of a method of providing and executing a hash puzzle
  • Figure 9 is a schematic transaction diagram of a an example of a challenge transaction and a corresponding candidate transaction
  • Figure 10 is a schematic illustration of a an example of a process of updating a holey Merkle tree
  • Figure 11 schematically illustrates a relationship between the changelog A, the new set of leaves.
  • the state of the blockchain at a particular block height can be considered as the set of unspent transaction outputs recorded on chain, sometimes known as the UTXO set.
  • a given node (or "miner") of the blockchain network may also maintain a local UTXO set that additionally includes those in the pool of pending transactions maintained at the node.
  • the UTXO set is used for validating incoming transactions, and each blockchain node therefore maintains a local copy of the UTXO set, according to the worldview of that node.
  • the UTXO set must be derived from the historical transactions that have occurred on the blockchain.
  • a deterministic mechanism for processing, structuring, and committing to the UTXO set, e.g. at any given block height, such that the mechanism can be utilised by any observer to check the membership of a particular UTXO at a given block height.
  • the disclosure provides a new data structure for a UTXO set, structuring the UTXO set as a Holey Merkle Tree (HMT).
  • HMT Holey Merkle Tree
  • the disclosure also provides an efficient algorithm to update the UTXO set by incremental deterministic UTXO set updates.
  • Embodiments also provide a commitment scheme that ensures the integrity of the UTXO set, by incentivising miners to publicly commit to a particular UTXO set snapshot.
  • the disclosed embodiments for committing to the state of the UTXO set at a particular block height enable an efficient verification on a given UTXO set for the given block height. Once the UTXO set is verified, it can be used in a wide variety of applications to enable users to check membership of UTXOs in the set at a particular historical point in time.
  • FIG. 1 shows an example 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.
  • P2P peer-to-peer
  • the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.
  • Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers.
  • Each blockchain node 104 comprises processing apparatus 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 equipment 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 or media.
  • the memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and/or an optical medium such as an optical disk drive.
  • the blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106.
  • maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151.
  • Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.
  • 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 property, an example of which is a user 103 to whom the output is cryptographically locked (requiring a signature or other solution of that user in order to be unlocked and thereby redeemed or spent).
  • Each input points back to the output of a preceding transaction 152, thereby linking the transactions.
  • Each block 151 also comprises a block pointer 155 pointing back to the previously created block 151 in the chain so as to define a sequential order to the blocks 151.
  • Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106.
  • Each blockchain node 104 is configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory.
  • Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151.
  • the ordered pool 154 is often referred to as a "mempool”. This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.
  • the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j.
  • Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction.
  • the preceding transaction could be any transaction in the ordered set 154 or any block 151.
  • the preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid.
  • "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions).
  • the preceding transaction 152i could equally be called the antecedent or predecessor transaction.
  • the input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction 152i is locked.
  • the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b.
  • the present transaction 152j can thus 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 present transaction 152j .
  • a transaction 152 may have multiple outputs to split the input amount between multiple users or entities (one of whom could be the original user or entity 103a in order to give change).
  • a transaction can also have multiple inputs to gather together the amounts from multiple outputs of one or more preceding transactions, and redistribute to one or more outputs of the current transaction.
  • an output-based transaction protocol such as bitcoin
  • a party 103 such as an individual user or an organization
  • wishes to enact a new transaction 152j (either manually or by an automated process employed by the party)
  • the enacting party sends the new transaction from its computer terminal 102 to a recipient.
  • the enacting party or the recipient will eventually send this transaction to one or more of the blockchain nodes 104 of the network 106 (which nowadays are typically servers or data centres, but could in principle be other user terminals).
  • the party 103 enacting the new transaction 152j could send the transaction directly to one or more of the blockchain nodes 104 and, in some examples, not to the recipient.
  • a blockchain node 104 that receives a transaction checks whether the transaction is valid according to a blockchain node protocol which is applied at each of the blockchain nodes 104.
  • the blockchain node protocol typically requires the blockchain node 104 to check that a cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in an ordered sequence of transactions 152.
  • this may comprise checking that the cryptographic signature or other authorisation of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i which the new transaction spends (or "assigns"), wherein this condition typically comprises at least checking that the cryptographic signature or other authorisation in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked to.
  • the condition may be at least partially defined by a script included in the output of the preceding transaction 152i . Alternatively it could simply be fixed by the blockchain node protocol alone, or it could be due to a combination of these.
  • 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 test according to the same blockchain node protocol, and so forward the new transaction 152j on to one or more further nodes 104, and so forth. In this way the new transaction is propagated throughout the network of blockchain nodes 104.
  • the definition of whether a given output is assigned (or "spent") is whether it has yet been validly redeemed by the input of another, onward 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 which it attempts to redeem has not already been redeemed by another transaction. Again if not valid, the transaction 152j will not be propagated (unless flagged as invalid and propagated for alerting) or recorded in the blockchain 150. This guards against double-spending whereby the transactor tries to assign the output of the same transaction more than once.
  • An account-based model on the other hand guards against double-spending by maintaining an account balance.
  • blockchain nodes 104 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by "proof-of-work". At a blockchain node 104, new transactions are added to an ordered pool
  • the blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle.
  • this comprises 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, then the output of the hash meets a predetermined condition.
  • the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of- work puzzle, and other types are not excluded.
  • a property of a hash function is that it has an unpredictable output with respect to its input. Therefore this search can only be performed by brute force, thus consuming a substantive amount of processing resource at each blockchain node 104 that is trying to solve the puzzle.
  • the first blockchain node 104 to solve the puzzle announces this to the network 106, providing the solution as proof which can then be easily checked by the other blockchain nodes 104 in the network (once given the solution to a hash it is straightforward to check that it causes the output of the hash to meet the condition).
  • the first blockchain node 104 propagates a block to a threshold consensus of other nodes that accept the block and thus enforce the protocol rules.
  • the ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104.
  • the block pointer 155 also assigns a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each blockchain node 104 in a network 106, this therefore provides an immutable public ledger of the transactions.
  • a protocol also exists for resolving any "fork” that may arise, which is where two blockchain nodesl04 solve their puzzle within a very short time of one another such that a conflicting view of the blockchain gets propagated between nodes 104. In short, whichever prong of the fork grows the longest becomes the definitive blockchain 150. Note this should not affect the users or agents of the network as the same transactions will appear in both forks.
  • a node that successfully constructs a new block 104 is granted the ability to newly assign an additional, accepted amount of the digital asset in a new special kind of transaction which distributes an additional defined quantity of the digital asset (as opposed to an inter-agent, or inter-user transaction which transfers an amount of the digital asset from one agent or user to another).
  • This special type of transaction is usually referred to as a "coinbase transaction", but may also be termed an "initiation transaction” or "generation transaction”. It typically forms the first transaction of the new block 151n.
  • the proof-of-work signals the intent of the node that constructs the new block to follow the protocol rules allowing this special transaction to be redeemed later.
  • the blockchain protocol rules may require a maturity period, for example 100 blocks, before this special transaction may be redeemed.
  • a regular (non-generation) transaction 152 will also specify an additional transaction fee in one of its outputs, to further reward the blockchain node 104 that created the block 151n in which that transaction was published. This fee is normally referred to as the "transaction fee", and is discussed blow.
  • each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment.
  • the node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.
  • Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106.
  • Users of the blockchain network (often referred to as “clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106.
  • Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his/her respective computer equipment 102a, and a second party 103b and his/her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated.
  • Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party” respectively.
  • the computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and/or FPGAs.
  • the computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media.
  • This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and/or an optical medium such as an optical disc drive.
  • the memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus.
  • any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102.
  • the computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch.
  • the computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.
  • the client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc.
  • the client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150.
  • this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.
  • client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.
  • the instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106.
  • the client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility).
  • the wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol.
  • each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106.
  • the transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model.
  • the same transaction protocol is used for all transactions 152 in the blockchain 150.
  • the same node protocol is used by all the nodes 104 in the network 106.
  • a given party 103 say Alice, wishes to send a new transaction 152j to be included in the blockchain 150, then she formulates the new transaction in accordance with the relevant transaction protocol (using the wallet function in her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. E.g. this could be the blockchain node 104 that is best connected to Alice's computer 102.
  • any given blockchain node 104 receives a new transaction 152j, it handles it in accordance with the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets a certain condition for being "valid", examples of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable on a per-transaction basis by scripts included in the transactions 152.
  • condition could simply be a built-in feature of the node protocol, or be defined by a combination of the script and the node protocol.
  • any blockchain node 104 that receives the transaction 152j will add the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will propagate the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then assuming the transaction 152j is valid, this means it will soon be propagated throughout the whole network 106.
  • Different blockchain nodes 104 may receive different instances of a given transaction first and therefore have conflicting views of which instance is 'valid' before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid, and then discovers that a second instance has been recorded in the blockchain 150 then that blockchain node 104 must accept this and will discard (i.e. treat as invalid) the instance which it had initially accepted (i.e. the one that has not been published in a block 151).
  • An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model.
  • each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance.
  • the current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly.
  • transactions are ordered using a running transaction tally of the account (also called the "position"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation.
  • an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.
  • FIG. 2 illustrates an example transaction protocol.
  • This is an example of a UTXO-based protocol.
  • a transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.
  • 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 can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed).
  • the UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger.
  • the UTXO may also contain the transaction ID of the transaction from which it came, amongst other information.
  • the transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203.
  • the header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.
  • TxT new transaction 152j
  • Txo the preceding transaction 152i
  • TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.
  • the preceding transaction Txo may already have been validated and included in a block 151 of the blockchain 150 at the time when Alice creates her new transaction Txi, or at least by the time she sends it to the network 106. It may already have been included in one of the blocks 151 at that time, or it may be still waiting in the ordered set 154 in which case it will soon be included in a new block 151. Alternatively Txo and Txi could be created and sent to the network 106 together, or Txo could even be sent after Txi if the node protocol allows for buffering "orphan" transactions.
  • One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo.
  • Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.
  • the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included).
  • the locking script defines an unlocking condition, typically comprising a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.
  • the locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network.
  • the locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Unlocking scripts appear in the outputs of transactions.
  • the unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.
  • UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA] which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid).
  • [Checksig PA] contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice.
  • the input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo).
  • the input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo.
  • the input 202 of Txi further comprises an unlocking script ⁇ Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography).
  • the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.
  • the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). In embodiments this involves concatenating the two scripts:
  • the blockchain node 104 deems Txi valid. This means that the blockchain node 104 will add Txi to the ordered pool of pending transactions 154. The blockchain node 104 will also forward the transaction 7k; to one or more other blockchain nodes 104 in the network 106, so that it will be propagated throughout the network 106. Once Txi has been validated and included in the blockchain 150, this defines ⁇ 77T(%from 7k?as spent. Note that Txi can only be valid if it spends an unspent transaction output 203.
  • Txi will be invalid even if all the other conditions are met.
  • the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Txo is already spent (i.e. whether it has already formed a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on the transactions 152.
  • a given blockchain 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 has been spent is whether it has already formed a valid input to another valid transaction in the blockchain 150.
  • UTXO-based transaction models a given UTXO needs to be spent as a whole. It cannot "leave behind" a fraction of the amount defined in the UTXO as spent while another fraction is spent. However the amount from the UTXO can be split between multiple outputs of the next transaction. E.g. the amount defined in UTXOo in TAT? can be split between multiple UTXOs in Txi. Hence if Alice does not want to give Bob all of the amount defined in UTXOo, she can use the remainder to give herself change in a second output of Txi, or pay another party.
  • the transaction fee does not require its own separate output 203 (i.e. does not need a separate UTXO). Instead any difference between the total amount pointed to by the input(s) 202 and the total amount of specified in the output(s) 203 of a given transaction 152 is automatically given to the blockchain node 104 publishing the transaction.
  • a pointer to UTXOo is the only input to Txi, and Txi has only one output UTXOi. If the amount of the digital asset specified in UTXOo is greater than the amount specified in UTXOi, then the difference may be assigned (or spent) by the node 104 that wins the proof-of-work race to create the block containing UTXOi. Alternatively or additionally however, it is not necessarily excluded that a transaction fee could be specified explicitly in its own one of the UTXOs 203 of the transaction 152.
  • Alice and Bob's digital assets consist of the UTXOs locked to them in any transactions 152 anywhere in the blockchain 150.
  • the assets of a given party 103 are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150.
  • script code is often represented schematically (i.e. not using the exact language).
  • operation codes opcodes
  • "OP_" refers to a particular opcode of the Script language.
  • OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150.
  • the data could comprise a document which it is desired to store in the blockchain.
  • an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl.
  • a digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag.
  • the SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).
  • the locking script is sometimes called "scriptPubKey” referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked.
  • the unlocking script is sometimes called “scriptSig” referring to the fact that it typically supplies the corresponding signature.
  • the scripting language could be used to define any one or more conditions. Hence the more general terms “locking script” and “unlocking script” may be preferred.
  • HASH TREES A hash tree, also known as a Merkle tree, is a data structure which can be used to attest to (e.g. publicly commit to) the membership of a set of data items D.
  • An example hash tree 400 is illustrated by way of example in Figure 3.
  • the hash tree 300 comprises a plurality of layers arranged in a hierarchy from a leaf layer (lowest layer) up to a root layer (highest layer) with one or more internal layers in between.
  • the root layer comprises a single root node 304.
  • Each internal layer comprises a respective plurality of internal nodes 303 within that layer.
  • the leaf layer comprises a respective plurality of leaf nodes 302. Within each of the internal layers and the leaf layer, each node 303/302 has an indexed position within its respective layer.
  • the root node 304 is a hash of a combination (typically a concatenation) of all the internal nodes 303 in the next layer down in the hierarchy (which will be two nodes 303 in the case of a binary tree).
  • each internal node 303 within the layer comprises a hash of a combination (typically a concatenation) of a different corresponding subset of at least two of the nodes 302/303 at the next layer down in the hierarchy.
  • each internal node 303 will be the hash of the combination (e.g. concatenation) of a different respective pair of the nodes in the next layer down 302/303.
  • Each leaf node designates a respective data item 301, also labelled herein D.
  • Each leaf node 302 could designate its respective data item Di by comprising an explicit copy of Di, in the clear. However, typically each leaf node 302 instead comprises a hash of a respective preimage wherein the respective preimage comprises Di. In this case the data Di is not derivable from the leaf node 302, but nonetheless the leaf node 302 may be said to designate or signify its respective data item Di in that this particular leaf node 302 is the element of the tree 303 which nominates the respective data item as being part of the set of data items Do, Di, ...
  • each subset of nodes at each layer may be exactly two nodes, i.e. the tree is a binary tree. In other words each node (except the leaves) branches to two other nodes at the next layer down.
  • each subset of nodes at each layer is an exclusive subset.
  • the term "Merkle tree” is sometimes assumed in the literature to imply a binary tree. However that limitation was not imposed by Mr Merkle in his original patent and that convention is not adopted here. More generally a Merkle tree as referred to herein may refer to hash tree of any degree of branching, or even uneven branching.
  • Merkle tree may be used throughout the following description, but this may equally be replaced with the term hash tree anywhere herein.
  • the set of unspent UTXOs 203 being attested to by the Merkle tree 300 may be the current set of unspent transaction outputs that have already been successfully recorded in blocks 152 on the blockchain 150, i.e. already "mined”.
  • the set UTXOs in question may be the union of set of UTXOs recorded in blocks 152 on-chain 150 and the set of UTXOs of pending transactions 152 currently in the pool of a given miner, or a given blockchain node 104 (i.e. a given node 104 of the blockchain network 106).
  • node may be used differently in different contexts to refer either to a node 104 of the blockchain network 106 or a node 302/303/304 of the Merkle tree 300, which are not the same thing.
  • miner or “mining” as used most generally herein does not necessarily imply a financial reward for the task of incorporating blocks on chain. More generally “mining” may refer to the race to win the proof-of-work puzzle required to generate blocks 152 that are accepted by the blockchain network 106, and a “miner” is any T1 party that participates in the proof-of-work race.
  • miner as used anywhere herein could equally be replaced with operator of a node 104 of the blockchain network 106.
  • a Merkle tree could also be used to attest to other sets of UTXOs.
  • the set of UTXOs in question could be a more specific set of unspent UTXOs, such as the set of unspent UTXOs of which a particular party is the payer 102a or payee 102b.
  • each leaf node 302 designates (i.e. signifies, nominates or attests to) a different respective subset of the UTXOs in the set.
  • each data item Di comprises an indication (identifier) of the respective subset being designated by the respective leaf node 302.
  • the respective leaf node 302 designates its respective subset of UTXOs not by comprising the indication of that subset explicitly, but instead by comprising a hash of a preimage wherein the preimage comprises the indication of the respective subset (optionally the preimage could comprise the indication combined, e.g. concatenated, with another piece of data such as a salt).
  • Di is the preimage of the leaf node 302.
  • each leaf node 302 may correspond to a different respective transaction (Tx) 152, and the subset of UTXOs 203 designated by the respective leaf node 302 may comprise all the unspent UTXOs in the transaction (which could be one or more outputs of the transaction).
  • the indication comprised by Di may comprise the transaction identifier (TxID) of the respective transaction along with an indication of which UTXOs within that transaction are unspent (or equivalently which outputs are spent).
  • each leaf node 302 could correspond to a different individual UTXO, i.e.
  • a given leaf node 302 designates a single UTXO.
  • the indication comprised by Di could comprise a combination of TxID and the number of the particular UTXO 203 within the identified transaction 152 (e.g. output 0 or output 1).
  • each leaf node 302 could correspond to all the UTXOs in a certain specified group of transactions 152 (e.g. range of TxIDs).
  • the Merkle tree 301 (of which the instance illustrated in Figure 3 is just one example), allows a party to attest to or commit to the membership of the set of unspent UTXOs. This is because the tree 300 allows another party to verify that a candidate data item Di is a member of the attested-to set. The principle is illustrated by way of example in Figure 4, where Do happens to be the candidate data item.
  • an attesting party wishes to commit to the membership of a UTXO set, e.g. current UTXOs on chain and/or current UTXOs in their mempool, and that the attestation or commitment is being made for the benefit of at least one other party (the “attestee").
  • the attesting party could be a third-party service provider who provides a service of attesting to the UTXO set for the benefit of one or more miners (who in this example would be the attestees).
  • the attesting party could be a miner who attests to their view of the UTXO set.
  • the attestee party (or parties) could be one or more other miners so as to promote consensus among miners, or could one or more end-users 102 of the blockchain 150.
  • the attesting party makes the Merkle root 304 available to the attestee party, such as by publishing it (e.g. on the blockchain 150), or sending it to them via an off-chain side channel (not shown).
  • the attestee wishes to check that some candidate data item Di - in this an indication of a candidate UTXO - is indeed a member of the set attested to by the Merkle root 304.
  • the attestee can do this given only the candidate data item Di, the Merkle root 304, and a further portion of information called the "Merkle Proof" or "hash tree proof".
  • the "Merkle path" is the subset of nodes 401 (which will include a leaf node 302 and one or more interior nodes 303) that are immediate siblings of each node lying along the path 402 between the candidate leaf node 450 and the Merkle root 302 (including the sibling of the candidate leaf node 450). In other words, consider a path 402 from the candidate leaf node 450 to the Merkle root 304.
  • each layer there will be a node 302/303 that lies on that path 402, and that node will have one or more siblings 401 (exactly one in the case of a binary tree) which is/are the other node(s) 302/303 that are is/are part of the same subset at that layer - that is, the subset of nodes that are combined and hashed to form the node 303/304 at the next layer up along the path 402.
  • the total subset of siblings 401 that lie along the path 402 are referred to as the "Merkle path" (even though they are not the path 402 through the tree per se).
  • the Merkle path may be obtained by the attestee from, for example, either a miner/node who provides this as a service, or some non-node service provider. In embodiments it may be provided along with the Merkle root 304 by the party the attesting who supplies the Merkle root.
  • Table 0 a list of notations used in the description of certain embodiments disclosed herein.
  • a Merkle tree is typically interpreted as a binary hash tree (though this is not essential).
  • each node in the tree may be given an index pair (i a , and is represented as N(i a ,
  • the indices i a , ip are simply numerical labels that are related to a specific position in the tree.
  • the node /V(0,3) is constructed from the four data blocks D o , ...,D 3 as:
  • a Merkle tree in most applications is to facilitate a proof that some data block D t is a member of a list or set of N data blocks D G ⁇ D o , ... , Given a Merkle root and a candidate data block Di, this can be treated as a 'proof-of-existence' of the block within the set.
  • the mechanism for such a proof is known as a Merkle proof and consists of obtaining a set of hashes known as the Merkle path for a given data block D t and Merkle root R.
  • the Merkle path for a data block is simply the minimum list of hashes required to reconstruct the root ⁇ by way of repeated hashing and concatenation, often referred to as the ‘authentication path’ for a data block. If, given a Merkle root ⁇ , we wish to prove that the data block ⁇ ⁇ belongs to the set ⁇ ⁇ represented by ⁇ we can perform a Merkle proof as follows 1) Obtain the Merkle root ⁇ from a trusted source. 2) Obtain the Merkle path ⁇ from a source.
  • Figure 5 shows an example of a Merkle tree, with indices i K within each layer K. Each row is indexed from 0 to the right, and the rows themselves are indexed from 0 up from the leaf layer. A node with a higher value of index i K within a given layer may be describes as to the "right". When speaking of a given layer, index i K may be abbreviated as just I on the understanding of which layer K is in question.
  • Table 1 the layers, node numbers, and arrays containing layer indices of the Merkle tree shown in Figure 5.
  • a partial Merkle tree is a collection of indexed nodes of a Merkle tree which can be used to prove that a proper subset of leaf nodes L' are members of the complete set of leaves L, which can be expressed mathematically as L' c L. It should be noted that the partial Merkle tree for a single leaf is simply its Merkle path.
  • n L 2 k , for some integer k.
  • the value k can also be used to determine the number of layers in a binary Merkle tree, which is simply given by k + 1.
  • the index i of a node situated in the layer K is denoted by i K .
  • i K The index i of a node situated in the layer K.
  • the first equation (1) allows us to calculate the index of the parent of the node of interest.
  • the second equation (2) which is also used in (1), allows us to calculate the parity of the index of the node (i.e. whether it is an odd or even index).
  • the third equation (3) allows us to determine the index of a node's partner (i.e. the node which the node of interest is concatenated and hashed with in the tree), which we call a complementary index c K .
  • the output P of the generatePMT( ) algorithm is a partial Merkle tree of the form: where A K ' is the set of node indices in the K th layer of the PMT, which is a proper subset of the indices of the nodes A K in the K th layer of the full Merkle tree and satisfies the relation A' K c A K .
  • An example algorithm generatePMT( for determining a partial Merkle tree may be described as follows.
  • Step 1 initialises an array A' o corresponding to the nodes of the PMT in the leaf layer, which only contains the leaves provided to the algorithm by L' at this point.
  • a o ' is denoted with a " ' " to indicate it is a subset of the full array /1g of layer 0 nodes.
  • Step 2 populates the rest of A' o by calculating the complementary indices c 0 for all of the leaves already in the array and adds them to the array.
  • the complementary indices are added, they are added in numerical order, meaning each complementary index is placed next to (either immediately left or right of) the corresponding original leaf provided in L' .
  • Step 3 initialises a branch array B o , which allows step 4 to be written as a loop.
  • This step introduces an array which is the ordered union of the PMT nodes 21 ⁇ -1 °f the layer below and the branch nodes B K- ⁇ of the layer below.
  • the branch nodes of a given layer are all the nodes in that layer that can be calculated from other information (i.e. child nodes) that are already somewhere lower down in the PMT.
  • the array includes all the nodes of the lower layer that we have access to for calculation (whether they are stored as part of the PMT or can be calculated 'on-the- fly' from other parts), and therefore can be used as the starting point for determining the relevant arrays A' K , B K , C K in the layer above.
  • step 3 comprises two further subroutines.
  • the first calculates the parent index i K for ever other entry in and adds them to the branch array B K .
  • the second calculates the complement partner indices cTM for all the entries in B K and adds these complement indices to C K if they are not already in B K , which avoids double-counting anything we need to store in A' K that we know we can already calculate based on other information in the PMT.
  • step 3 involves setting each respective A K ' to the array C K we have just populated and deduplicated. There is also a break condition to halt the loop of step 3 if A' K is empty, meaning no further processing is required to generate the PMT.
  • Step 5 of the algorithm simply combines all the arrays A ⁇ A ⁇ , ...,A' k-1 in order to create the final partial Merkle tree P. 4.
  • the present disclosure provides a novel scheme for maintaining a Merkle tree (or hash tree), whereby at least some of the leaf nodes can each either: A) designate a corresponding subset of one or more of the unconsumed outputs (e.g. by comprising a hash of a preimage that compromised an indication of the corresponding subset); or B) comprise a placeholder value, in other words a dummy value, which may also be referred to herein as a "hole".
  • every leaf node has the ability to become either type of node, and may be changed back and forth between the two from one update of the tree to the next.
  • leaf nodes 302 each designate a respective corresponding subset of the UTXOs 203, as discussed previously.
  • each comprises a hash Hi of an indication of its corresponding subset.
  • the subset designated by each leaf could be one or more UTXOs, e.g. the subset of each leaf being an individual UTXO, or all the UTXOs within an individual transaction 152, or the UTXOs of more than one transaction (e.g. the transactions in a given range of TxIDs).
  • each leaf comprises a hash Hi of a respective preimage where the respective preimage comprises a TxID of a respective transaction 152 and an identifier of each UTXO 203 within the transaction (e.g. output 0, output 1, etc.).
  • One or more others of the leaf nodes may comprise "holes", represented herein by the empty sign "0". These are dummy or placeholder values that represent no UTXOs. E.g. they could be zero or a string of zeros, or any other predetermined value that is understood to represent a hole in the leaf layer of the tree where no UTXOs are designated.
  • a "hole” as referred to herein could be any representation of a null value.
  • the following describes a method of attesting to a current state of a set of UTXOs (or more generally unconsumed outputs of blockchain transactions in any output-based model). That is, computing a Merkle tree cumulating in a Merkle root which can later be used to verify the membership of the set.
  • An example flow chart is shown in Figure 7.
  • the method may be used to publicly commit to the membership of the set by publishing the Merkle root, e.g. on the blockchain 150.
  • the method could instead be used to keep a private record, e.g. internally within an organization.
  • the method may be performed by a third-party service provider who makes available the attestation to one or more nodes 104 (or "miners") of the blockchain network 106 in order to confirm the miner's view of the blockchain.
  • the method may be performed by one or more miners who make the attestation available to other miners and/or users 102 of the blockchain network in order to promote confidence in the state of the chain.
  • the attested-to set could be, for example, only the set of UTXOs actually recorded in blocks 151 on the blockchain. Or alternatively it could be the set that additionally includes the UTXOs of pending transactions in the mempool of a given miner.
  • the method begins by determining an initial Merkle tree based on the current UTXO set at the set-up stage. This may include one or more holes 0, or it could begin fully occupied only with leaves 302 that designate UTXOs.
  • the tree may be formed so as to be "balanced". That is to say, each layer contains a full set of nodes 303/303 (i.e. the maximum number of nodes at each layer given the branching ratio of the tree), with the leaf nodes all at the same layer. E.g. in a binary tree this means there are 2 k leaf nodes all at the same, lowest layer where k is the number of layers.
  • one or more holes 0 will be needed to fill the gaps in the leaf layer so as to "fill up" the leaf layer, i.e. include a full set of leaf nodes 302 across the whole bottom layer of the tree.
  • Figure 6 shows and example of this.
  • the method comprises determining an update to the set of UTXOs. For example this could be done the next time that a new block 151 is included on the blockchain 150 (in other words the block height has increased by one). Alternatively it could be in response to some other event, or after some periodic or random time interval has elapsed. E.g. if the tree is being maintained by a node 104 of the blockchain network and includes pending transactions, then the update could be performed after the node 104 has received a predetermined number of new pending transactions into its pool of pending transactions ("mempool").
  • the method at step S20 comprises determining a "delta set" representing the update.
  • the delta set is the total set of new UTXOs being added and UTXOs which have now been spent and so are to be removed.
  • the delta set will comprise an addition of at least one new UTXO and/or removal of one or more UTXOs which have now been consumed.
  • the update will very likely comprise both the removal of at least one now-spent UTXO and the addition of at least one new UTXO.
  • the party performing the method may determine the delta set by monitoring the blockchain 150 and/or mempool themself. Alternatively, they may determine the delta set by receiving it from another party who monitors the blockchain 150 on their behalf.
  • the party performing the method may be a node 104 of the blockchain network 106, or a party operating one or more nodes 104 of the blockchain network 106 - a "miner" for short - and the delta set may be determined by receiving a subscription to the delta set from a third party service provider who monitors the blockchain 150 for new blocks and regularly provides the delta set to one or more miners as a subscription service (e.g. each time the block height increases).
  • the miner could determine the delta set as the union of the delta of on-chain UTXOs received in the subscription combined with the delta to the miner's mempool. Alternatively the miner may monitor the blockchain 150 and determine the delta set directly themself.
  • the party performing the method may be the third-party service provider, and the determination of the delta set may be performed by the service provider monitoring the blockchain 150.
  • the service provider may both use the delta set both to determine the update to the tree for the purpose of their own attestation, and to provide to one or more miners as a subscription service to inform them of updates to the blockchain 150.
  • the method comprises recomputing the hash tree to reflect the update.
  • the idea of the holey Merkle tree is that when there is an update to the UTXO set, sometimes entries will be removed and sometimes entries will be added. Using a holey Merkle tree, it is possible to add new entries in the tree in places where others have been removed, either in the current update round or from one round of update to the next. This will make recomputing the tree simpler.
  • only one of a subset of multiple UTXOs designated by a given leaf may have been spent, still leaving one or more other unspent UTXOs covered by the same leaf 302.
  • the corresponding leaf will be updated but not replaced with a hole 0. It may be replaced with an updated leaf that designates at least the remaining UTXO(s), and which could potentially also designate one or more new UTXOs.
  • an old leaf designating a first subset of UTXOs is replaced with an updated leaf designating a second, different subset of UTXOs, instead of a hole 0, wherein the second subset could overlap with the first subset but is not identical.
  • the tree may need to be expanded to the right. If the tree is to remain balanced, this will mean added a whole new side to the tree (a whole extra half in the case of a binary tree) plus new root node 304.
  • the tree is kept balanced at each update, whether the update involves replacing holes or other previous leaves, or expanding the tree, or any combination of these. It is not essential that the tree is kept balanced by the updates. However, it may be preferable as it minimises the number of layers in the tree, such that the extra computation is also minimised (e.g. in a binary tree, it is only padded up to 2 A k not 2 A (k+1))
  • the process of recomputing the tree may be summarised as follows.
  • the leaf node designating the removed output is removed and replaced, at the same position in the leaf layer, with a new leaf node which either: A) designates an updated subset of one or more unconsumed outputs not including the removed output, or B) comprises a placeholder value (a "hole" 0).
  • a new leaf node is formed designating a subset of one or more unconsumed outputs including at least the new output, wherein the new leaf node is inserted in the tree in place of a replaceable leaf node when available, at the same position in the leaf layer.
  • a replaceable leaf node is one that either: A) designates an output being removed, or B) comprises a placeholder value. But otherwise, if no replaceable leaf node is available, the tree is expanded to accommodate the new leaf node.
  • the recomputing of the tree comprises recomputing the hashes of only those nodes affected by the update, i.e. only the part of the tree affected.
  • this algorithm was known but only for determining the minimum subset of the tree needed to verify that a candidate subset of leaves are members of the set.
  • such an algorithm may be re-purposed for determining the minimum subset of nodes that need to be recomputed to perform the most efficient update of a holey Merkle tree.
  • the recomputing of the hash tree may be performed by a “remove then add” procedure; i.e. first removing any and all leaf nodes designating consumed outputs from the set, then inserting any and all leaf nodes designating new unconsumed outputs. This approach helps reduce the overall size (i.e. number of leaves) of the tree at any given time.
  • the method at the re-computation stage S30 may also provide for shrinking the tree by a layer if, after the update, the tree would otherwise now have a redundant number of layers given its degree of branching and the number of leaves that designate actual UTXOs compared to those that have been removed and would thus otherwise comprise holes ⁇ .
  • the Merkle root 304 is published as a public commitment to the membership of the attested-to UTXO set. This could be done by including it in a transaction 152 on the blockchain 150, or by other means, such as on a website.
  • the commitment may be included in an output 203 (e.g. unspendable output) of a transaction recorded on the blockchain 152, e.g. by means of an OP_DROP opcode, OP_RETURN opcode, or combination of OP_RETURN and OP_FALSE, depending on the locking script protocol being used.
  • step S40 may loop back to step S20 to determine another update and recompute the tree again. For example this may be done each time the block height of the blockchain 150 increases (i.e. a new block has been "mined"), or periodically or randomly, or each time the number of pending transactions in the party's mempool increases by a threshold amount.
  • the update comprises the removal of at least one output
  • the update comprises the addition of at least one new output.
  • the addition could happen on the same occasion (i.e. same update) as the removal, or a different occasion (i.e. different update).
  • an update may comprise both the removal of at least one output and the addition of at least one new output.
  • the update may comprise only addition or only removal.
  • holes can be added in place of an actual content-carrying leaf node that has been removed from a dynamically updated tree. Preferably they can be created in any place in the list of leaves, while padding is only appended at the end. Furthermore, holes act as placeholders which can subsequently be replaced by new content-carrying leaves in further updates to the dynamic tree.
  • a generation transaction is a transaction generated when a node 104 of the blockchain network 106 successfully wins the proof-of-work race to have a new block 151 generated and incorporated onto the blockchain 150 - sometimes described as a new block being "mined”.
  • the generation transaction contains an output that rewards the successful miner with a new portion of a digital asset (e.g. some new Satoshi).
  • this is not essential. Either way, in some blockchain protocols, each generation transaction may have an associated maturity condition associated with it, which must be met before its one or more outputs can be consumed.
  • the maturity condition may be that a certain block height threshold (e.g. 100 blocks) has been reached since the generation transaction was generated - i.e. a certain number of new blocks have been added to the blockchain.
  • the protocol obeyed by all the nodes 104 of the network 106 will not allow such outputs to be spent until the maturity condition has been reached.
  • the miner or service provider may avoid this by including the outputs of unmatured generation transactions in the UTXO set being attested to by the Merkle tree.
  • the method comprises maintaining a list indicating whether the associated maturity condition has been met for each generation transaction (e.g. the respective block height at the time they were generated). This gives a small efficiency increase is it involves querying a smaller data structure.
  • the list of unmatured transactions and their maturity status may be included in the preimage D of one or more of the leaves 302, so that the maturity status of the unmatured transactions is also attested to.
  • the list may simply be kept for internal reference by the party in question (e.g. miner or service provider).
  • HMT Holey Merkle Tree'
  • the goal with elements (1) and (2) is to prescribe a deterministic process for determining and updating the state of the UTXO set on a block-by-block basis, such that these updates are efficient to perform.
  • the aim of introducing element (3) is to provide a way for UTXO set snapshots to be produced, shared, and updated by blockchain nodes 104 in a way that requires minimal trust on the behalf of the user.
  • a UTXO snapshot S n is defined as the complete set of spendable outpoints on the blockchain that are unspent at a block of height n, denoted as B n .
  • n the leftmost outpoints in the snapshot are reserved for coinbase outpoints and ordered in descending block height. If n > 100, then only the outpoints corresponding to the most recent 100 coinbase transactions are reserved and ordered in descending block height. For example,
  • the first 100 transaction IDs does not necessarily imply the first 100 outpoints as one coinbase transaction can have multiple outputs. They are ordered in descending block height for convenience. When a new coinbase transaction is added, it is added to the beginning of the list, it naturally pushes the matured coinbase transaction txid ⁇ out of the coinbase list.
  • the coinbase list can be part of the UTXO set when creating a commitment.
  • they can be represented by a single leaf or multiple leaves.
  • leaves or some of the leaves will be updated by every block.
  • a delta set is a collection of outpoints that are either
  • the second type of outpoint is included in so that we can add them to S n .
  • An intermediate set is a collection of outpoints that are created between B n+1 and B n+t and spent between B n+1 and B n+t . These outpoints are neither included in nor covered in S n . It is optional to keep them for the purpose of defining a UTXO snapshot. It may become important to keep them for the purpose of auditing.
  • the second component for generating a deterministic commitment to a UTXO at a point in time is to introduce a holey Merkle tree (HMT).
  • HMT holey Merkle tree
  • the idea here is to represent the UTXO set S n at a given block B n of height n as a Merkle tree T n , whose root R n can be attested to on the blockchain. See again Figure 6.
  • TxID i
  • the Merkle tree is a balanced, binary Merkle tree.
  • ii The leaves of the Merkle tree may consist of either: a. UTXOs; or b. Holes iii. UTXOs may be represented as either: a. TxID
  • Holes may be represented as a zero element (e.g. a 0 bit, or Boolean 'False').
  • Option b) may in some cases generate a larger tree than a) because each leaf can represent multiple UTXOs, i.e., less likely to generate a hole, but has the drawback that leaves may remain in the tree while only a single UTXO of a transaction is unspent, meaning that the spend-state of all of the transaction outputs must be kept until all have been spent, whereas a) allows each UTXO to be tracked independently. For example, if a transaction generates two outputs including a 'change' output, the change output may not be spent until a long time after the primary output, meaning we have to store the spend-state for both until the later time when the change output is also consumed.
  • STXO spent UTXO
  • Option c) is identical to option b), except the objects stored for each UTXO include the full output information, rather than just the Boolean spend-state of each output.
  • This format for storing the HMT state will become useful when updating the state of the HMT by changing some of the leaves, which is detailed in the following section.
  • some of the leaves change between HMT states, these changes are propagated throughout the rest of the tree. Any hash in the tree that is a propagator of these changes up the tree will need to be updated.
  • a deterministic algorithm updateTree( ) may be specified to allow a particular HMT state, representing a UTXO set S n at block height n, to be updated when a subsequent block B n+1 is obtained.
  • Figure 10 shows an example of a process of updating the HMT state T n — > T n+i , where changes to leaf nodes are highlighted in bold.
  • the overall algorithm updateTree( ) can be used to update the tree from one state T n to another state T n+1 based on a set of changed leaves that are determined by a blockchain block.
  • This algorithm may be defined as follows. updateTree(
  • the algorithm operates by generating the updated set of leaves L n+1 , using the previous set S n and new block data B n+1 and applying a sub-algorithm updateLeaves( ).
  • the algorithm uses the updated set of leaves, in conjunction with the previous tree T n , to generate the new tree T n+1 by invoking another sub-algorithm updateHashes( ).
  • the output T n+1 also includes both L n+1 and R n+1 , by definition.
  • a sub-algorithm which may be specified is is the updateLeaves( ) algorithm, which is responsible for taking the leaf set of a current Merkle tree state L n and updating its state according to the effect of a new block B n+1 .
  • This sub-algorithm updates the set of leaves from a previous state L n , representing the UTXO set prior to receiving the block B n+1 , to a new set of leaves L n+1 representing the state of the UTXO set accounting for this new block.
  • Step 1 initialises a leaf set L that we will manipulate in the algorithm by removing and adding entries corresponding to UTXOs consumed and created respectively in B n+1 .
  • Step 2 initialises an array A which will store the indices at which changes (i.e. removals and additions) to L n are made. We call this the 'changelog array'. This array is necessary to update node hashes later in the updateHashes( ) algorithm.
  • Step 3 is a transaction-wise loop that implements a 'remove-then-add' process for each transaction individually, before moving on to the next transaction in the block. The transactions are processed in the order they appear in the block.
  • Step 3.1 takes the current transaction and removes from L all outpoints consumed by it.
  • the index in L at which each outpoint was previously recorded is inserted into the changelog A.
  • Step 3.2 takes the current transaction and adds each of its outpoints to L at the left-most empty (0) entry position. If there is no empty entry in L, the outpoint is appended to the end of the list. The index in L at which a new outpoint is inserted/appended is recorded in A.
  • Step 4 handles redundant or missing indices in L following step 3, to ensure the tree is balanced and of the correct depth. If L is a power of two, and its HMT will be a perfectly balanced binary tree, then any remaining indices larger than the length of L are removed, which handles the case where the HMT shrinks by one level following step 3. Otherwise, the minimum number of empty elements are appended to L that are required for the number of leaves to reach a power of 2. Once again any indices larger than the new size of the balanced tree are removed. The changelog array A is updated accordingly.
  • Step 5 the temporary leaf set L becomes the new leaf set L n+1 and both L n+1 and the changelog A are output by the algorithm.
  • updateLeaves( ) algorithm could be written; namely using a remove-then-add paradigm as shown above, or alternatively using an add- then-remove paradigm.
  • the remove-then-add option parses a block transaction-wise. This means that the UTXOs consumed by the outputs of one transaction are removed from the leaf set, and then the UTXOs created by the inputs of that transaction are added to the leaf set, both of which occur before moving on to the next transaction in the block.
  • TTOR topological transaction ordering rule
  • the remove-then-add option minimises the overall size (i.e. number of leaves) of the HMT at any given frame in time. This is because updating the leaf set transaction-wise ensures that UTXOs are removed from the Merkle tree at the earliest possible opportunity in the algorithm, which in-turn ensures that the holes in the leaf set are positioned as far left in the ordered set at possible. This means that holes are always filled from as far left as possible, thus minimising the possible number of entries in the leaf set.
  • a second sub-algorithm that may be specified is the updateHashes( ) algorithm. This is responsible for updating the hashes of the previous HMT state T n to form the new HMT state T n+1 based on the changes to the UTXO set caused by the new block B n+1 .
  • the main steps are as follows:
  • Step 1 of the updateHashes( ) algorithm initialises a new tree T n+1 using the previous state T n as the basis. Note that in the case where the new state has a different size (i.e. different k) then step 1 should accommodate this, either by adding additional empty arrays for new layers or removing arrays from higher layers.
  • Step 3 updates the hashes in the leaf layer H ⁇ , by replacing elements in with the new elements in at the corresponding index and saves the resulting H ⁇ .
  • Step 4 generates a partial Merkle tree using algorithm described in section 2.3, taking the changelog indices ⁇ as input.
  • Step 5 is a loop, containing two further loops, which ascends through the remaining layers of the new HMT state ⁇ ⁇ up to and including the new root node at layer ⁇ . For each layer, this step is to identify hash values that are required to update the next layer above. It combines the hashes H ⁇ (P[ ⁇ ⁇ 1]) of the PMT in the ⁇ ⁇ 1 ⁇ layer with the updated hashes just calculated in the ⁇ ⁇ 1 ⁇ layer to create a set of hashes ⁇ which is the subset of H ⁇ required to calculate the new hashes in H ⁇ in the ⁇ ⁇ layer.
  • the first of the smaller loops in step 5 iterates through pairs of elements of H ⁇ ⁇ ⁇ to calculate the changed elements H ⁇ ⁇ in layer ⁇ .
  • the second smaller loop then updates the values in H ⁇ with the changed elements we have just calculated and saves them.
  • Step 6 finally returns the new tree state ⁇ ⁇ as an array of the arrays H ⁇ , H ⁇ , ... , H ⁇ just updated in the previous step.
  • the changelog array ⁇ contains all of the indices of elements in which represent changes (either insertions or deletions) which are to be reflected in generating the new tree from the old tree ⁇ ⁇ as the starting point.
  • the goal is to update the HMT state T n+1 « — T n by recomputing the HMT root R n+1 .
  • the first option is simply to recompute the entire Merkle tree using the complete set of new leaves L n+1 .
  • the second, and far more desirable option is to recompute only the internal nodes required to propagate the changes from L n+1 « — L n to the new root hash R n+1 .
  • This second option is more computationally efficient than the first, and so we have chosen to implement it in the updateHashes( ) algorithm.
  • the hashes required to propagate the changes caused by the new values of leaves L' to the new root R n+1 are identical to the partial Merkle tree of L' .
  • a method of incentivizing a party to publicly commit to the membership of a set of data items D may be to commit to a set of UTXOs, as discussed previously, such as to commit to the current state of a blockchain 150 or the UTXOs on chain plus those pending in a mempool.
  • the method could be performed for example by a third party service provider to incentivize miners (operators of nodes 104) to publicly commit to their view of the UTXO set, or the method could be performed by a miner themselves in order to incentivize other miners.
  • the method could be used to incentivize parties to commit to the membership of a set of any other kind of data items.
  • the scheme could be used to represent anything where the set has elements that may be created and destroyed/consumed.
  • inventory logs may be used to track a set of inventory items that can be either in either a 'sold' or 'unsold' state.
  • the data items D could represent the inventory items.
  • Another example would be a transparent ticketing system where the ticket-provider wishes to attest to the set of remaining tickets (e.g. seats in a football stadium) as and when they are individually sold. This may help reduce fraud and re-selling in secondary markets by providing a record of which seats were sold at which time, the state of the entire 'stadium' of seats now being mapped to the HMT.
  • the challenging party e.g. service provider
  • the set of data items D to be attested to comprises a UTXO set
  • the blockchain used to publish the hash puzzle could be the same blockchain 150 as the UTXO set relates to, or a different blockchain.
  • a hash puzzle is a challenge, also called a hash challenge, in the form of a short program placed in a transaction recorded on a blockchain - call this the challenge transaction.
  • the program may take the form of a locking script in an output 203 of a transaction in a UTXO-based (or output-based) model.
  • the program could take the form of a smart contract in a transaction of an account-based model.
  • the program comprises a reference hash value, being the hash of a preimage wherein the preimage comprises a reference piece of information which the challenger wishes to challenge a challengee party (e.g. a miner) to prove that they know.
  • the program of the hash puzzle also comprises some code (e.g.
  • a script which will receive a candidate piece of information from the challengee, hash a preimage comprising the candidate piece of information to produce a candidate hash, compare the candidate hash with the reference hash stored in the challenge transaction, and on condition that they match release a reward to the challengee (e.g. a quantity of a digital asset such as some Satoshi).
  • the method comprises the challengee sending a candidate transaction to be recorded on the same blockchain as the challenge transaction.
  • This may comprise the challengee sending or propagating the candidate transaction to one or more nodes 104 of the blockchain network 106.
  • the candidate transaction comprises a pointer to the challenge transaction, along with the candidate piece of information, or the preimage that comprises the candidate piece of information (optionally the candidate piece of information could be combined, e.g. concatenated, with another element such as a salt in order to form the preimage).
  • the candidate piece of information may be included in the unlocking script of an input 202 that points to the output of the challenge transaction that contains the hash puzzle.
  • the candidate transaction may comprise a smart contract that comprises the candidate piece of information and references the smart contract of the challenge transaction.
  • the blockchain network 106 attempts to validate the candidate transaction at one or more of the nodes 104 of the blockchain network 106.
  • This comprises executing the hash puzzle, e.g. by running the locking script together with the unlocking script in the case of a UTXO-based (or output-based) model, or by executing the smart contracts in the case of an account-based model.
  • the node 104 executing the puzzle will thus take the candidate piece of information from the candidate transaction, and hash the candidate preimage that comprises the candidate piece of information. If the candidate preimage comprises more data than just the candidate piece of information (e.g. another piece of data concatenated with it), then the additional data may either be received in the candidate transaction or added from the challenge transaction before the candidate preimage is hashed to generate the candidate hash.
  • the node 104 in question checks whether the resulting candidate hash equals the reference hash from the challenge transaction. If so, then at step T50 the candidate transaction is validated and recorded on chain, thus rewarding the challengee for proving knowledge (and publicly attesting to that knowledge) of the candidate piece of information. If on the other hand the candidate hash does not equal the reference hash, then at step T60 the candidate transaction is not validated and instead is rejected by the node 104, and so the challengee does not receive their reward.
  • a hash puzzle such as described above can be used to incentivize one or more challengee parties to publicly commit to a view of a set of data items D, such as a UTXO set.
  • the reference piece of information tested-for by the challenge transaction comprises the Merkle tree root 304 of the set as determined by the challenging party (e.g. service provider).
  • the challenging party e.g. service provider
  • challengees e.g. miners
  • Such a scheme can be used to promote confidence in the state of the chain.
  • the challenger and challengee(s) all use the same algorithm for computing the Merkle tree 300, so this is completely deterministic.
  • the challenge transaction may additionally require a signature of a specific challengee or challenegees to unlock, such as by means of a pay-to-public-key (P2PK) puzzle or pay-to-public-key-hash (P2PKH) puzzle included in the locking script along with the main hash puzzle as an additional condition for redeeming the output of the challenge transaction.
  • P2PK pay-to-public-key
  • P2PKH pay-to-public-key-hash
  • the challenegee may publish multiple instances of the challenge transaction on chain, one for each of the potential challengees, each requiring a signature of the respective challengee to unlock.
  • the challenger could publish a single challenge transaction on chain that will accept the signature of any of multiple different challengees as alternative conditions for unlocking.
  • the hash puzzle should in fact test for two pieces of information: the Merkle root 304 of the attested-to set, and additional piece of information that is specific to a particular challengee.
  • the additional piece of information may be allocated randomly to the challengee.
  • the additional piece of information may be another one of the nodes 302/303 (e.g. internal note 303) other than the root node 304.
  • this may be a randomly allocated one of the nodes (e.g. a random internal node 303).
  • each of a plurality of potential challenges e.g. miners
  • each of a plurality of potential challenges may be allocated different such pieces of additional information, each specific to the respective challengee - for example each may be allocated a different and/or random one of the nodes (e.g. internal node302) in the tree 300 as their respective piece of additional information.
  • the piece of additional information could be a secret password or piece of personal information known only to the challenger and the particular challengee.
  • the challenger arranges to have recorded on a blockchain, e.g. 150, a challenge transaction.
  • a blockchain e.g. 150
  • this comprises sending the challenge transaction (directly or via an intermediate party) to one or more of the blockchain nodes 104 to be propagated through the network 106 and thereby validated and incorporated into a block 151 on chain.
  • the challenger is themselves a miner, they could validate the challenge transaction for recordal themselves, and/or propagate to one or more nodes 104 of one or more other miners to validate.
  • the blockchain on which the challenge transaction is recorded could be the same or a different blockchain as that on which the transactions of the previously discussed UTXO set are recorded. For ease of reference it may be assumed in the following that they are the same blockchain, but this is not limiting.
  • the challengee submits to be recorded on chain a candidate transaction which points to the challenge transaction. If the challengee is a party other than a miner, this comprises sending the candidate transaction (directly or via an intermediate party) to one or more of the blockchain nodes 104 to be propagated through the network 106 and thereby validated and incorporated into a block 151 on chain. If the challengee is themselves a miner, they could validate the candidate transaction for recordal themselves, and/or propagate to one or more nodes 104 of one or more other miners to validate.
  • the challenge transaction comprises code, e.g. a locking script in a UTXO based model or a smart contract in an account-based model, which (steps T30-T40) is run at a node 104 of the blockchain network 106 when a candidate transaction pointing to the challenge transaction is received at the node 104.
  • the code tests for three things in the candidate transaction (e.g. in an unlocking script or smart contract of the candidate transaction): a valid signature of the challengee, the Merkle root 304 attesting to the set of data items D, and the additional piece of information.
  • Figure 9 schematically illustrates the challenge transaction 152Ch (which is recorded on the blockchain 150 already) and the candidate transaction 152Can (which is to be validated for recordal on the blockchain 150).
  • the candidate transaction 152Can comprises: (e.g. in an input 202) a pointer 951 to the challenge transaction 152Ch (e.g. its transaction ID TXID_Ch); and (e.g. in an unlocking script in the input 202) a signature 952 of the challengee party, a candidate instance 953 of the Merkle root 304 being attested to, and a candidate instance 951 of the additional piece if information (e.g. another of the nodes 303 of the tree which has been assigned to that particular challengee as an additional challenge element).
  • the candidate transaction 152Can may be said to comprise candidate preimage data that comprises at least the candidate instance 953 of the root 304 and the candidate instance 954 of the additional information, wherein the preimage data could optionally comprise one or both of these elements combined with (e.g. concatenated with) some further data.
  • the challenge transaction 152Ch comprises (e.g. in a locking script in an output 203 of the challenge transaction 152Ch) a short program (e.g. script) 900 is run as part of the process of validating the candidate transaction 152Can.
  • This program or code 900 comprises a first element (e.g.
  • a Checksig 901 that verifies the signature 952 of the challengee from the candidate transaction 152Can, and a second element (hash puzzle) which verifies the candidate instance 953 of the Merkle root and the candidate instance 954 of the additional piece of information from the candidate transaction 152.
  • the hash puzzle 902 comprises reference hash result data.
  • the hash puzzle 902 comprises two separate constituent hash puzzles.
  • the reference hash result data comprises two separate hash values: a first hash value hl, which was determined by taking a hash of a reference instance of the Merkle root 304 (or more generally preimage data that comprises at least the reference instance of the root); and a second hash value h2 which was determined by taking a hash of a reference instance of the piece of additional information (or more generally preimage data that comprises at least the reference instance of the additional information).
  • a first one of the constituent hash puzzles comprises the first hash value hl, along with code which will hash the candidate instance 953 of the Merkle root 304 from the candidate transaction 152 (or more generally the candidate preimage data that comprises the candidate instance 953 of the Merkle root 304), and check whether this equals hl.
  • a second one of the constituent hash puzzles comprises the second hash value h2, along with code which will hash the candidate instance 954 of the piece of additional information from the candidate transaction 152Can (or more generally the candidate preimage data that comprises the candidate instance 954 of the additional information), and check whether this equals h2.
  • the candidate transaction 152Can is validated for recordal in a block 151 on the blockchain 150 (step T50), and the challengee is assigned the reward defined in the challenge transaction 152Ch.
  • the hash puzzle 902 comprises a single combined hash puzzle.
  • the reference hash result data in the hash puzzle in the challenge transaction 152Ch comprises a combined hash value h, having been determined by taking a hash of reference preimage data that comprises a combination (e.g. concatenation) of the reference instance of the Merkle root 304 and the reference instance of the piece of additional information (and optionally further data).
  • the hash puzzle 902 will hash candidate preimage data that comprises the reference instance 953 of the Merkle root 304 and the refence instance 954 of the additional information combined in the same way (e.g. concatenated) as the reference instances were to produce h.
  • the candidate transaction 152Can is validated for recordal in a block 151 on the blockchain 150, and the challengee is assigned the reward defined in the challenge transaction 152Ch.
  • the challenger may publish multiple challenges on the blockchain 150, each along the lines discussed above, but each requiring the signature of a different potential challengee and a different respective piece of additional information 954 specific to the respective challengee. For example, this could be done by including multiple different challenge transactionsl52Ch on chain, each with a different puzzle 902 requiring a different piece of additional information 954 specific to the respective challengee; or by including the different hash puzzles 902 in different outputs 203 of the same challenge transaction 152Ch; or a combination of these two approaches (some puzzles 902 in different transactions 152, some in different output 203 of the same transaction).
  • This model has significant utility when applied to a commitment scheme for the state of the UTXO set.
  • a commitment scheme for the state of the UTXO set.
  • Such a scheme whereby the UTXO set state is reliably attested at regular intervals, would enable lightweight and timely bootstrapping of Bitcoin nodes (and other third parties) to the network.
  • the bootstrapping node will have to perform a full blockchain synchronisation, often referred to as an initial block download (IBD), whereby the node must obtain the entire history of the chain and replay it in sequence to re-derive the current UTXO state independently.
  • IBD initial block download
  • UTXO commitment schemes that solve (or at least improve) the bootstrapping problem.
  • the scheme in section 7.1 provides a simple method for miners to attest to the UTXO state at a given block height as an additional service and can be implemented by either an individual or collective of nodes.
  • section 7.2 we separately introduce a bounty-based scheme.
  • a third party UTXO set service provider can offer a bounty for anybody to redeem by successfully attesting to the UTXO set snapshot of a previous block.
  • section 7.3 we combine these two mechanisms into a hybrid scheme that collectively enables incentives for all miners to continuously calculate, verify and attest UTXO snapshots as the blockchain grows over time.
  • UTXO snapshots may be modelled using the HMT defined earlier, due to its efficient-update property.
  • the miners that secure the blockchain network can attest to the UTXO set state of any block that they produce.
  • the attestation can simply be in the form of the Merkle root for the HMT of the previous block, which can be included in the coinbase (or another) transaction in the block being produced by the miner.
  • CTx n becomes the on- chain attestation of B n-x , containing the commitment . Note that this process only allows for the snapshot of a given block to be committed in a subsequent block i.e. the UTXO snapshot for the (n — l) t/l block can only be committed in the n th block at the earliest.
  • R n is effectively an accumulator of all of the other transaction IDs in B n , and if any of these transactions (including the coinbase) were to contain R n then we would have introduced a circular hash reference, which is not possible.
  • This process can be performed by a single miner for each block they successfully mine and can be extended such that the miner includes the commitments of all blocks since they last successfully mined a block. It would also be feasible to allow a delay in publishing block hashes such that all network nodes are likely to have been able to calculate the commitment; for example, if the UTXO state of B n were to be included in B n+10 , this gives an interval of 10 blocks in which miners can compute the required commitment H(R n ). It would be possible to include the attestation R n in block B n if we were to change the definition of the UTXO snapshot to exclude the coinbase outpoints of CTx n .
  • Another variation of this method might involve adding the UTXO snapshot commitment to a transaction in the relevant block other than the coinbase.
  • the transaction would be signed by a well-known public key, and possibly linked to a MinerlD.
  • a node attempting to bootstrap from B n can simply do the following: 1) Obtain the list of block headers B o , B lt ..., B n to verify the proof-of-work and integrity of the current chain tip B n .
  • Each bounty transaction should be bound to a particular miner.
  • One way to achieve this is to make sure that the spendable bounty output also requires a signature from a key-pair belonging to the Miner ID associated with that miner, e.g. a signature that can be verified by PK A uce for a miner Alice, where PK AUce is a public key that is linked to Alice's Miner ID in some way.
  • each of the miners in the scheme can perform the following steps to redeem the bounty:
  • This scheme essentially allows all the participating miners to be able to earn a bounty as reward for successfully committing to the correct UTXO snapshot.
  • a node attempting to bootstrap from B n can do the following:
  • the bootstrapping node has the UTXO set snapshot of the chaintip, and trusts it is correct because it is consistent with the hash puzzle provided by the trusted UTXO set provider Charlie, which contains H(R n ). 7.3. Competitive scheme
  • the bounty scheme of section 7.2 is useful in providing some financial incentive for miners to commit to UTXO snapshots, making it an improvement over the scheme in section 7.1.
  • the previous scheme still only offers a relatively weak incentive for most miners to calculate the commitment correctly, because once a single miner reveals the result it can be easily replayed. Adding a bespoke hash puzzle for a random node ensures that even these miners will do some work, but they are still unmotivated to perform the full computation of R n independently.
  • an alpha token i.e. unique info known only to a given miner
  • P (s minerA + s alpha ) • G
  • the script could require both the miner signature for P m t nerA and a second R-puzzle signature, where the 'r' in the puzzle is derived from the miner's alpha.
  • the bootstrapping process for a node joining the network may also be identical to section
  • the UTXO set provider operates multiple bounty 'rounds' per UTXO snapshot that requires commitments.
  • the winner of the first round receives the highest reward, for attesting to the HMT root R n .
  • bitcoin network 106 For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104.
  • the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively.
  • the blockchain, blockchain network and/or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.
  • the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and/or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred Bitcoin network 106).
  • the blockchain network 106 may not be the bitcoin network.
  • a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150.
  • a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and/or propagate those blocks 151 to other nodes.
  • any reference to the term “bitcoin node” 104 above may be replaced with the term “network entity” or “network element”, wherein such an entity/element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks.
  • the functions of such a network entity/element may be implemented in hardware in the same way described above with reference to a blockchain node 104.
  • the candidate preimage data comprises a first candidate preimage comprising the candidate instance of the root, and a second candidate preimage comprising the candidate instance of the additional information
  • the reference hash result data comprises a first reference hash value and a second reference hash value, the first hash value being a result of having hashed a first reference preimage comprising the reference instance of the root, and the second hash value being a result of having hashed a second reference preimage comprising the reference instance of the additional information
  • the hash operation comprises hashing the first candidate preimage to produce a first candidate hash value and hashing the second candidate preimage to produce a second candidate hash value, the candidate hash result data comprising the first and second candidate hash values
  • the verifying of the candidate hash result data comprises verifying that the first candidate hash value matches the first reference hash value, and verifying that the second candidate hash value matches the second reference hash value.
  • the reference hash result data comprises a joint reference hash value that is a result of having hashed a reference preimage that is a combination of at least the reference instance of the root and the reference instance of the additional information
  • the hash operation comprises hashing a corresponding combination of at least the reference instance of the root and the reference instance of the additional information, combined in a same way as was used to produce the candidate hash value, thereby producing a corresponding joint candidate hash value
  • the verifying of the candidate hash result data comprises verifying that the joint reference hash value matches the joint candidate hash value.
  • Statement 4 The method of Statement 1, 2 or 3 wherein the additional information is identifiable only by the challenger and challengee, and/or the code will only verify the signature of the challengee.
  • Statement 5. The method of Statement 1, 2 or 3 wherein the limited subset comprises more than two parties, including the challenger, challengee and at least one other party; and the code will validate a version of the candidate transaction from any of the parties as long as it contains a verified signature of the party and provides the solution to the hash puzzle.
  • Statement 6 The method of Statement 5, wherein the code is configured so as only to reward the party that first submits a candidate transaction for recordal on the blockchain which points to the reference transaction, is validly signed by the party and provides the solution to the hash puzzle.
  • Statement 7 The method of any of Statement 1 to 4, comprising causing multiple different specimens of said challenge to be recorded on the blockchain, each for a different respective challengee, the multiple different specimens being placed either in different challenge transactions or different outputs of the same transaction, or a combination.
  • Statement 8 The method of any preceding Statement, wherein the piece of additional information is another node in the hash tree other than the root, the identity of the other node being known only to the limited subset of parties.
  • Statement 10 The method of any preceding Statement, wherein the set of data items is a set of unspent outputs of blockchain transactions.
  • Statement 11 The method of Statement 10, wherein the challengee is a miner and the challenger is a non-mining service provider.
  • Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any preceding Statement.
  • Statement 14 A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of Statement 1 to 12.
  • a method performed by node of blockchain network comprising: receiving a challenge transaction from a challenger challenging a challengee to publicly commit to a set of data items based on a hash tree wherein leaves of the hash tree designate the data items; and incorporating the challenge transaction into a block recorded on a blockchain of the blockchain network; wherein the challenge transaction comprises code implementing a challenge by being configured so as, when run on a node of a blockchain network in response to an attempt to validate a candidate transaction which has been submitted for recordal on said blockchain and which points to the challenge transaction, to perform operations of: receiving and verify a signature of a challengee from the candidate transaction; also receiving from the candidate transaction candidate preimage data comprising a candidate instance of a root of the hash tree and a candidate instance of an additional piece of additional information identifiable only to a restricted subset of parties comprising at least the challenger and the challengee; evaluating whether the candidate transaction provides a solution to a hash puzzle, by performing a hash operation on the candidate preimage data,
  • Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of Statement 15.
  • Statement 17 A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of Statement 15.
  • a method by a challengee challenged by a challenger to publicly commit to a set of data items based on a hash tree wherein leaves of the hash tree designate the data items comprising: forming a candidate transaction that points to a challenge transaction recorded on a blockchain; and submitting the candidate transaction for validation to be recorded on the blockchain; wherein the candidate transaction is configured so as, when being validated for recordal on the blockchain by a node of a blockchain network, to provide for verification by code included in the challenge transaction and run on the node: a signature of a challengee from the candidate transaction, thereby causing the code when run on the node to verify the signature; and candidate preimage data comprising a candidate instance of a root of the hash tree and a candidate instance of an additional piece of additional information identifiable to only a restricted subset of parties comprising at least the challenger and the challengee, thereby causing code when run on the node to verify the candidate preimage data by: performing a hash operation on the candidate preimage data, thereby producing
  • Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of Statement 18.
  • Statement 20 A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of Statement 18.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de provocation d'une personne défiée pour qu'elle se consacre publiquement à un ensemble d'éléments de données basé sur un arbre de hachage, les feuilles de l'arbre de hachage désignant les éléments de données. Le procédé consiste à amener une transaction de provocation à être enregistrée sur une chaîne de blocs. Cette transaction comprend un code qui, lorsqu'il est exécuté sur un nœud d'un réseau de chaîne de blocs en réponse à une tentative de validation d'une transaction candidate, reçoit et vérifie une signature d'une personne défiée issue de la transaction candidate; et détermine également si la transaction candidate fournit une solution à un puzzle de hachage, la solution requise comprenant la racine de l'arbre de hachage. En cas de réussite de ces tests, l'enregistrement de la transaction candidate sur la chaîne de blocs est validé, ce qui permet d'attribuer une récompense à la personne défiée.
PCT/EP2023/050874 2022-02-15 2023-01-16 Attestation d'appartenance d'un ensemble WO2023156104A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2201981.4A GB2615752B (en) 2022-02-15 2022-02-15 Attesting to membership of a set
GB2201981.4 2022-02-15

Publications (1)

Publication Number Publication Date
WO2023156104A1 true WO2023156104A1 (fr) 2023-08-24

Family

ID=80820932

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/050874 WO2023156104A1 (fr) 2022-02-15 2023-01-16 Attestation d'appartenance d'un ensemble

Country Status (2)

Country Link
GB (1) GB2615752B (fr)
WO (1) WO2023156104A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200382309A1 (en) * 2019-05-29 2020-12-03 International Business Machines Corporation Approximate hash verification for blockchain

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109345388B (zh) * 2018-09-20 2020-09-08 百度在线网络技术（北京）有限公司 区块链智能合约验证方法、装置及存储介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200382309A1 (en) * 2019-05-29 2020-12-03 International Business Machines Corporation Approximate hash verification for blockchain

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALEXANDER CHEPURNOY ET AL: "Edrax: A Cryptocurrency with Stateless Transaction Validation", vol. 20181014:152508, 14 October 2018 (2018-10-14), pages 1 - 25, XP061026538, Retrieved from the Internet <URL:http://eprint.iacr.org/2018/968.pdf> [retrieved on 20181014] *
SAMBHAV SATIJA ET AL: "Blockene: A High-throughput Blockchain Over Mobile Devices", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 14 October 2020 (2020-10-14), XP081785676 *

Also Published As

Publication number Publication date
GB2615752B (en) 2024-04-24
GB202201981D0 (en) 2022-03-30
GB2615752A (en) 2023-08-23

Similar Documents

Publication Publication Date Title
US20220278859A1 (en) Digital contracts using blockchain transactions
CN113924747A (zh) 区块链交易数据字段验证
US20230308287A1 (en) Threshold signatures
WO2023156102A1 (fr) Attestation à un ensemble de sorties de transaction non consommées
US20230388136A1 (en) Merkle proof entity
US20230394063A1 (en) Merkle proof entity
US20230275770A1 (en) Pseudo-random selection on the blockchain
JP2023515368A (ja) ブロックチェーンネットワークと共に使用される証明サービス
US20230308292A1 (en) Digital signatures
WO2024002758A1 (fr) Preuve de possession
WO2023156104A1 (fr) Attestation d&#39;appartenance d&#39;un ensemble
WO2023160921A1 (fr) Procédé d&#39;attestation d&#39;échange de données
WO2024099693A1 (fr) Transaction de chaîne de blocs
WO2023072778A1 (fr) Arbre de merkle fragmenté
JP2024536272A (ja) レイヤ２トークンプロトコル
EP4413686A1 (fr) Rédaction de contenu à partir de transactions de chaîne de blocs
WO2024061546A1 (fr) Application de contraintes sur des transactions de chaîne de blocs
WO2024061617A1 (fr) Transactions de jetons de permutation atomique
WO2024041862A1 (fr) Transaction de chaîne de blocs
WO2023208832A1 (fr) Transaction de chaîne de blocs
JP2024539898A (ja) シャーディングされたマークル木
WO2024041866A1 (fr) Transaction de chaîne de blocs
WO2023227529A1 (fr) Masques de hachage
WO2024052065A1 (fr) Détermination de secrets partagés à l&#39;aide d&#39;une chaîne de blocs
WO2024002756A1 (fr) Preuve de propriété

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23700873

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023700873

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2023700873

Country of ref document: EP

Effective date: 20240916