ATTESTING TO KNOWLEDGE OF BLOCKCHAIN TRANSACTION OUTPUTS TECHNICAL FIELD The present disclosure relates to a computer-implemented method of attesting to knowledge of a blockchain output, and to a method of serving blockchain transactions based on said attestations. BACKGROUND 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. Transactions that are submitted to the blockchain network are included in new blocks. 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. It should be noted that 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 time- order index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data. 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. In summary, during this process 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. In order to have a transaction recorded in the blockchain, a user (e.g. a blockchain client application) sends the transaction to one of the nodes of the network to be propagated. 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. In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. 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. So consider a pair of transactions, call them a first and a second transaction (or “target” transaction). 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. In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, 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. An alternative type of transaction model is an account-based model. In this case 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 separate to the blockchain and is updated constantly. SUMMARY Various “light client protocols” exist that allows light client applications (e.g. those run on personal devices such as mobile phones and laptop computers) to reliably read transactions from the blockchain without incurring the full cost of downloading all the data. The client’s requests are served by blockchain nodes who are responsible for maintaining and verifying the blockchain. Example light client protocols are described in bitcoin improvement proposal (BIP) 37 and BIP157. These light client protocols consider the privacy of the client’s requests and aims to minimise the network bandwidth, CPU, and disk usage on both the node’s side and the client’s side. When a transfer (e.g. payment) is made with BIP270, the transaction is transmitted from a first party (e.g. a customer) to a second party (e.g. a merchant) who then broadcasts it to the blockchain network. Hence, the transaction content is known by both parties involved in the transaction. The implication is that nodes will not need to later notify clients about the transaction content in this case. More generally, if nodes had a way to know if the controller of an output is already aware of it, they could omit notifying light clients about the data contained in these outputs. This would allow light client protocols to scale further. According to one aspect disclosed herein, there is provided a computer-implemented method of attesting to knowledge of a first output being included in a first blockchain transaction, wherein the method is performed by a first party and comprises: generating a first attestation signature based on a first message, wherein the first message comprises a first outpoint of the first blockchain transaction and the first output of the first blockchain transaction, wherein the first output is locked to a first public key associated with the first party, and wherein the first attestation signature is generated using a first private key corresponding to the first public key; and causing the first attestation signature to be included in a second output of the first blockchain transaction. The first party (e.g. Alice) would like to attest to having knowledge of a transaction output that is locked, in some way, to her public key. For example, the output may be a pay-to- public-key (P2PK) or pay-to-public-key-hash (P2PKH) output. Alice may or may not have generated the output herself. For example, a second party (e.g. Bob) may have generated the output. Alice constructs a message comprising at least an outpoint of the transaction and the output which she is acknowledging. Alice generates a signature that signs the message. The signature is generated using a private key corresponding to the public key, meaning that only Alice can attest to the output. Including an outpoint (e.g. a combination of a previous transaction identifier and output index) prevents the signature from being replayed, i.e. copied into different transaction. In some examples, Bob may also attest to one or more outputs in the transaction that are locked to his public key(s). According to one aspect disclosed herein, there is provided a computer-implemented method of sending blockchain transactions to a first party, wherein the method is performed by a third party and comprises: obtaining a set of blockchain transactions, wherein a first subset of the set of blockchain transactions comprises respective transactions having a respective output locked to a respective public key associated with the first party; determining whether the first party has knowledge of a respective blockchain transaction of the first subset of blockchain transactions based on whether the respective blockchain transaction comprises a respective attestation signature generated based on a respective message, wherein the respective message comprises a respective outpoint of the respective blockchain transaction and a respective output of the respective blockchain transaction, wherein the respective output is locked to the respective public key associated with the first party; and sending, to the first party, only the respective blockchain transactions of the first subset of blockchain transactions of which it has been determined that the first party does not have knowledge. A third party (e.g. a blockchain node or a dedicated service provider) has access to a set of transactions, each of which has a transaction output locked to a public key associated with Alice or Bob. By determining whether Alice or Bob have attested to knowledge of their respective outputs, the third party can send, to Alice or Bob, only the transactions which they are not aware of, thus saving bandwidth. Embodiments may be used to acknowledge a payment receipt (or transfer receipt, or assignment receipt) by parties involved in a blockchain transaction. A transaction output can, in some sense, be considered as a payment receipt, but the acknowledgement goes further. It acts as a proof that a party controlling the output is aware of its inclusion in the transaction. Blockchain nodes can therefore distinguish between outputs that were acknowledged and those that were not. In particular, it allows the nodes to selectively return data from outputs not known to the parties controlling them. This greatly reduces the amount of data nodes need to store and return to light clients. The inclusion of an acknowledgement is particularly beneficial when both parties can acknowledge the outputs they control, such as in the merchant-funded transaction protocol described in BIP270. This protocol requires the transaction fees for the payment to be covered by the merchant. The protocol implies that for a payment transaction to be valid, it must be jointly created and signed by the customer and the merchant. The described embodiment allows both the customer and the merchant to acknowledge the outputs they control in the payment transaction. This further reduces the amount of data served by nodes to both the customer and merchant who may be operating light clients. Since acknowledgements are included as part of transactions, they are publicly accessible so that anyone can verify them using only on-chain data. In case of a payment made with BIP270 where the customer may transmit the transaction to the merchant with some change outputs left unsigned, the acknowledgements can serve as a recourse to report fraudulent merchants that swap customer’s change outputs. BRIEF DESCRIPTION OF THE DRAWINGS To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which: 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, Figure 3 shows the payment protocol sequence detailed in BIP270, Figure 4 is a schematic block diagram of an example system for attesting to knowledge of a transaction output, in this case an output of a transaction template sent from Alice to Bob, Figure 5 schematically illustrates an example transaction containing an acknowledgement of a payment receipt (i.e. knowledge of an output), Figures 6A to 6C schematically illustrate the construction of an example transaction containing acknowledgements from two parties (e.g. customer and merchant), Figures 7A to 7C schematically illustrate the construction of another example transaction containing acknowledgements from two parties (e.g. customer and merchant), Figure 8 schematically illustrates an example blockchain block and a corresponding address block subset generated from the block, and Figure 9 schematically illustrates an example blockchain block and a corresponding address block subset generated from the block, where certain outputs contain acknowledgements. DETAILED DESCRIPTION OF EMBODIMENTS 1. EXAMPLE SYSTEM OVERVIEW Figure 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. Whilst not illustrated, 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. As mentioned above, 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. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output 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 transaction 152 (other than a coinbase transaction) comprises a pointer back to a previous transaction so as to define an order to sequences of transactions (N.B. sequences of transactions 152 are allowed to branch). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153 which was the first block in the chain. One or more original transactions 152 early on in the chain 150 pointed to the genesis block 153 rather than a preceding transaction. 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. In a given present transaction 152j, 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. In general, 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. Hence “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. In turn, 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. In some cases 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). In some cases 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. According to an output-based transaction protocol such as bitcoin, when 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), then 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). It is also not excluded that 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. In such an output-based transaction protocol, 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. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same 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. In an output-based model, the definition of whether a given output (e.g. UTXO) 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. Because again there is a defined order of transactions, the account balance has a single defined state at any one time. In addition to validating transactions, 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 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. 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. Typically 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. E.g. 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. A block pointer 155 is also assigned to the new block 151n pointing back to the previously created block 151n-1 in the chain. The significant amount of effort, for example in the form of hash, required to create a proof-of-work solution signals the intent of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it spends or assigns the same output as a previously validated transaction, otherwise known as double-spending. Once created, the block 151 cannot be modified since it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order 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. Note that different blockchain nodes 104 racing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of yet-to-be published transactions 154 at any given time, depending on when they started searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 are included in the next new block 151n and in which order, and the current pool 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to race to create a block from the newly-defined ordered pool of unpublished transactions 154, and so forth. A protocol also exists for resolving any “fork” that may arise, which is where two blockchain nodes104 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. According to the bitcoin blockchain (and most other blockchains) 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. Often 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. Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together. The memory of 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. Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104). 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. It will be understood that 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. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, 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. Note: whilst the various 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. As set out above, 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. When 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. When 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. Alternatively the 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. On condition that the newly received transaction 152j passes the test for being deemed valid (i.e. on condition that it is “validated”), 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. Once admitted to the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 will start competing to solve the proof-of- work puzzle on the latest version of their respective pool of 154 including the new transaction 152 (recall that other blockchain nodes 104 may be trying to solve the puzzle based on a different pool of transactions154, but whoever gets there first will define the set of transactions that are included in the latest block 151. Eventually a blockchain node 104 will solve the puzzle for a part of the ordered pool 154 which includes Alice’s transaction 152j). Once the proof-of-work has been done for the pool 154 including the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 comprises a pointer back to an earlier transaction, so the order of the transactions is also immutably recorded. 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. In the account-based case, 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. In such a system, 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. In addition, 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. 2. UTXO-BASED MODEL Figure 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. In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which 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. Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice’s new transaction 152j is labelled “Tx1”. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “Tx0” in Figure 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice. The preceding transaction Tx ₀ may already have been validated and included in a block 151 of the blockchain 150 at the time when Alice creates her new transaction Tx ₁ , 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 Tx0 and Tx1 could be created and sent to the network 106 together, or Tx ₀ could even be sent after Tx ₁ if the node protocol allows for buffering “orphan” transactions. The terms “preceding” and “subsequent” as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with “predecessor” and “successor”, or “antecedent” and “descendant”, “parent” and “child”, or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or “child”) which points to a preceding transaction (the antecedent transaction or “parent”) will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and/or node behaviour. One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, labelled here UTXO0. 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. Typically the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). I.e. 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. So in the example illustrated, UTXO ₀ in the output 203 of Tx ₀ comprises a locking script [Checksig P _A ] which requires a signature Sig P _A of Alice in order for UTXO ₀ to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXO ₀ to be valid). [Checksig P _A ] contains a representation (i.e. a hash) of the public key P _A from a public- private key pair of Alice. The input 202 of Tx ₁ comprises a pointer pointing back to Tx ₁ (e.g. by means of its transaction ID, TxID ₀ , which in embodiments is the hash of the whole transaction Tx ₀ ). The input 202 of Tx ₁ comprises an index identifying UTXO ₀ within Tx ₀ , to identify it amongst any other possible outputs of Tx ₀ . The input 202 of Tx ₁ further comprises an unlocking script <Sig P _A > 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. When the new transaction Tx1 arrives at a blockchain node 104, 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: <Sig PA> <PA> || [Checksig PA] where “||” represents a concatenation and “<…>” means place the data on the stack, and “[…]” is a function comprised by the locking script (in this example a stack-based language). Equivalently the scripts may be run one after the other, with a common stack, rather than concatenating the scripts. Either way, when run together, the scripts use the public key PA of Alice, as included in the locking script in the output of Tx0, to authenticate that the unlocking script in the input of Tx ₁ contains the signature of Alice signing the expected portion of data. The expected portion of data itself (the “message”) also needs to be included in order to perform this authentication. In embodiments the signed data comprises the whole of Tx ₁ (so a separate element does not need to be included specifying the signed portion of data in the clear, as it is already inherently present). The details of authentication by public-private cryptography will be familiar to a person skilled in the art. Basically, if Alice has signed a message using her private key, then given Alice’s public key and the message in the clear, another entity such as a node 104 is able to authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this onto the message as a signature, thus enabling any holder of the public key to authenticate the signature. Note therefore that any reference herein to signing a particular piece of data or part of a transaction, or such like, can in embodiments mean signing a hash of that piece of data or part of the transaction. If the unlocking script in Tx1 meets the one or more conditions specified in the locking script of Tx0 (so in the example shown, if Alice’s signature is provided in Tx1 and authenticated), then the blockchain node 104 deems Tx1 valid. This means that the blockchain node 104 will add Tx1 to the ordered pool of pending transactions 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that it will be propagated throughout the network 106. Once Tx1 has been validated and included in the blockchain 150, this defines UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all the other conditions are met. Hence the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 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. In practice 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. If the total amount specified in all the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore such transactions will not be propagated nor included in a block 151. Note that in 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 UTXO ₀ in Tx ₀ can be split between multiple UTXOs in Tx ₁ . Hence if Alice does not want to give Bob all of the amount defined in UTXO ₀ , she can use the remainder to give herself change in a second output of Tx1, or pay another party. In practice Alice will also usually need to include a fee for the bitcoin node 104 that successfully includes her transaction 104 in a block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain nodes 104, and hence although technically valid, may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transactions 152 if they don’t want). In some protocols, 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. E.g. say a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, then the difference may be assigned (or spent) by the node 104 that wins the proof-of-work race to create the block containing UTXO1. 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. Hence typically, the assets of a given party 103 are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to collate together the values of all the various UTXOs which are locked to the respective party and have not yet been spent in another onward transaction. It can do this by querying the copy of the blockchain 150 as stored at any of the bitcoin nodes 104. Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. “OP_...” refers to a particular opcode of the Script language. As an example, 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. E.g. the data could comprise a document which it is desired to store in the blockchain. Typically 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 secp256k1. 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. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally 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. 3. SIDE CHANNEL As shown in Figure 1, the client application on each of Alice and Bob’s computer equipment 102a, 120b, respectively, may comprise additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For instance this may be used to exchange a transaction 152 between Alice and Bob without the transaction (yet) being registered onto the blockchain network 106 or making its way onto the chain 150, until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a “transaction template”. A transaction template may lack one or more inputs and/or outputs that are required in order to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc. The side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob’s devices 102a, 102b. Generally, the side channel 107 as referred to anywhere herein may comprise any one or more links via one or more networking technologies or communication media for exchanging data “off-chain”, i.e. separately from the blockchain network 106. Where more than one link is used, then the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Note therefore that if it is said that Alice and Bob exchange certain pieces of information or data, or such like, over the side channel 107, then this does not necessarily imply all these pieces of data have to be send over exactly the same link or even the same type of network. 4. BLOCKCHAIN PROTOCOLS 4.1 Simplified Payment Protocol (BIP270) In some examples, a payment may refer to the process of a customer paying for a good or service to a merchant. BIP270 is a protocol designed for payments where the transaction is sent directly from the customer to the merchant who broadcasts it to the network 106. By enabling true peer-to-peer payments, BIP270 enables much faster, scalable payments compared to the traditional approach where the customer broadcasts the transaction to the network and the merchant has to monitor the blockchain 150 to confirm a transaction’s inclusion. The BIP270 protocol comprises three main messages: a payment request, a payment, and a payment acknowledgement. Figure 3 outlines the messages exchanged and actions performed for the protocol. 4.1.1 Merchant-funded Transactions Merchant-funded transactions refers to a payment protocol that follows the BIP270 payment flow and requires merchants to pay the fees for the payment transaction. The following describes details of the merchant-funded transactions protocol. The customer initiates the payment by somehow indicating that she is ready to pay. The merchant generates a URI that opens the customer’s Bitcoin wallet and downloads a PaymentRequest message from the merchant. The PaymentRequest message contains the amount of coins ^^ that need to be paid to the merchant and a transaction template containing an unsigned merchant input. This input is used to cover the fees for the payment transaction. A human-readable name for the merchant and the number of requested coins is displayed to the customer who checks this information before authorising the payment. Upon authorisation, the wallet performs the following actions: 1. checks if the customer has enough funds to process the payment. If funds are not available, it rejects the request and displays an error message to the customer. 2. fills the template with ^^ inputs covering the amount ^^ requested in the payment and optionally adds ^^′ change outputs. The inputs are signed with the SIGHASH_SINGLE flag if there is a corresponding change output of the same index, SIGHASH_NONE otherwise. 3. sends a Payment message to the merchant server that contains the transaction as well as the Merkle proofs of the UTXOs the customer inputs are spending. After validating the inputs using the provided Merkle proofs, the merchant server adds some outputs to receive the payment and to refund the surplus between the amount ^^ ^{ெ^^^} provided in the input and the actual transaction fee ^^. The entire transaction is then signed with the SIGHASH_ALL flag and the signature is entered as part of the the merchant input. Finally, the merchant broadcasts the transaction to the P2P network and responds to the customer with a PaymentACK message containing a copy of the transaction. This notifies the customer’s wallet about the confirmation of the payment. 4.2 Bitcoin Light Client Protocol BIP157 defines a protocol that allows light clients to read relevant transactions from the blockchain without downloading and validating all the blockchain data. They achieve this by downloading the block header chain and verifying the proofs of work, considering only the longest proof-of-work chain received. Light clients can then download only the transactions relevant to them and validate inclusion in the header chain using Merkle proofs. As light clients need to identify and retrieve specific transactions from nodes 104, they can inadvertently reveal the addresses contained in their wallet. It is therefore important for the protocol designed for client-node interactions to consider the privacy risk of clients. In BIP37, light clients send probabilistic filters to miners to specify transactions they are interested in receiving updates for. Probabilistic filters offer an efficient way to express a search pattern while hiding the sought-after data. The protocol, however, has known flaws that weaken the privacy of clients and allows denial-of-service attacks on miners. To overcome these issues, a new light client (referred to as “Efficient Client-side Block Filtering” is described herein. This alternative can be seen as the reverse of BIP37; instead of nodes 104 receiving filters and filtering blocks on behalf of clients, clients receive filters of block subsets from nodes 104, which they use to filter data they are interested in. In case of a match with the filter, the corresponding block subset is retrieved by the client. A block subset contains a mapping between transaction IDs and data of a particular type contained in the corresponding transactions (such as addresses, hashes of OP_RETURN data, outpoints, etc.). Nodes 104 may choose which type of data they support and should advertise that to clients. The block subsets are used by clients to efficiently identify transactions with relevant data. When a transaction is identified as containing relevant data, it is retrieved from noes 104. In some cases, a number of irrelevant transactions are also retrieved to hide the sought-after one. Figure 8 shows an example of a block containing three transactions and the address block subset generated from it. The address block subset contains a mapping between the transactions IDs and the addresses contained in the corresponding transactions. 4.3. Efficient Client-side Block Filtering Efficient Client-side Block Filtering refers to a protocol for generating filters that can be used to efficiently identify transactions of interest. The protocol is particularly beneficial for users and the like that operate light client applications 105. A light client application does not (e.g. is not configured to) store and/or verify the entire blockchain 150. However the protocol may in general be used by any entity, not just light client applications. A blockchain node 104 is configured to obtain a first set of transactions belonging to (i.e. comprised by) a blockchain block 151. The block 151 may have already been published to (i.e. mined to) the blockchain 150, or the block 151 may yet to have been published, e.g. the blockchain node 104 may be in the process of attempting to record the block 151 on the blockchain 150. In any case, the blockchain node 104 has access to the first set of transactions. As will be discussed below, the first set of transactions may include each and every transaction of the block 151, or the first set of transactions may include only some of the transactions of the block 151. In general, a transaction may have, comprise or otherwise be associated with one or more types of data (data type). For example, a data type may be a blockchain address (e.g. a public key or public key hash), an outpoint (e.g. a combination of a transaction identifier and an output index), an unspent transaction output, return data (e.g. OP_RETURN data, which is data following an OP_RETURN opcode), token metadata, a protocol flag, etc. At least some of the first set of transactions comprise one or more data types. Some transactions may comprise only a single data type (e.g. an address). Some transactions may comprise multiple data types (e.g. an address and return data). The blockchain node 104 is configured to generate respective datasets for respective data types. A dataset comprises, for each transaction comprising a particular data type, a respective transaction identifier (TxID) of the transaction and the data type comprised by that data type. More specifically, the dataset comprises the instance (e.g. the value) of the data type. For example, if the data type is “address”, then the instance would be the value of that address, e.g. a public key hash. The TxIDs and data type instances may be serialised, i.e. TxID, then data type instance, then TxID, then data type instance, and so on. In some examples, the dataset also comprises the TxIDs of all transactions in the first set of transactions, not just those comprising the particular data type. The blockchain node 104 may generate a respective dataset for each data type, or for only data type, or for only some data types. For each dataset generated by the blockchain node 104, the blockchain node 104 generates a respective filter that represents that dataset. The filter may be a probabilistic filter, such as a Bloom filter or a Cuckoo filter. Each combination of TxID and data type instance may be applied to the filter separately. In some examples, each TxID is applied to the filter separately and each data type instance is applied to the filter instances. The blockchain node sends some or all of the filters to Alice 103a, or otherwise makes the filter(s) available to Alice 103a, e.g. by posting them to the blockchain 150 or a different publicly available resource. As mentioned, the first set of transactions may not include each transaction in the block 151. The blockchain node 104 may split (i.e. divide) the block 151 into multiple sets of transactions, each containing only some of the transactions in the block 151. The sets may be non-overlapping, i.e. no two sets include the same transaction. Together the multiple sets may cover the entire block 151. The blockchain node 104 may perform the process described above for each set of transactions. That is, for each set, the blockchain node 104 may generate one or more respective datasets and corresponding filters, and send those filters to Alice 103a. In some examples, each set of transactions may have a size (in terms of bytes) that is no larger than a predetermined threshold. In the case where one of the data types is return data (e.g. image files, video files, text files, etc.), the dataset may comprise a hash of the return data rather than the return data itself. The same may apply, in general, to any data type. In the case where one of the data types is blockchain addresses, the dataset may include only those addresses that are still spendable. A spendable address is an address included in an unspent transaction output. In contrast, an address included in a transaction output that has already been spent (i.e. unlocked) is unspendable. In the case where one of the data types is outpoint data, the dataset may include only the outpoints that do not reference transactions included in the same block 151. From Alice’s perspective, Alice 103a receives some or all of the filters generated by the blockchain node 104. The node 104 may send the filters to Alice 103a on request, or autonomously, i.e. without receiving a request. Alice 103a then determines whether at least one of the filters represents a transaction of interest (a “target transaction”). A transaction of interest may be a transaction that contains a data type of interest (i.e. a particular data type), or a particular instance of a particular data type. For example, Alice 103a may be interested in any transactions having a particular blockchain address, e.g. an address based on one of her public keys. In some examples, the node 104 may advertise to (i.e. inform) Alice 103a of the data types that it supports. That is, the node 104 may advertise which data type(s) its filter(s) are generated based on. This allows Alice 103a to know which node 104 to query for a particular type. Alice 103a determines whether a filter represents a target transaction by inputting a particular data item into the filter, and determining whether the filter represents (i.e. encodes) the particular data item. The data item input to the filter may be a transaction identifier of the target transaction (if known), or an instance of a particular data type (e.g. a public key address, an outpoint, etc.). If Alice 103a determines that a filter received from the node 104 does (or might) represent a transaction of interest, Alice 103a requests the dataset corresponding to the filter. The blockchain node 104 then sends the dataset to Alice 103a. As discussed, the dataset contains one or more transactions identifiers. Alice 103a may request one or more transactions corresponding to one or more of the transaction identifiers in the dataset. In some examples, Alice 103a only requests the target transaction. In other examples, Alice 103a requests the target transaction and additional transactions, e.g. so as to mask her interest in the target transaction. The blockchain node 104 may maintain a chain of headers that represent (i.e. encode) the respective datasets generated from respective blocks 151 of the blockchain 150. The chain of headers will be referred to as a “dataset header chain” or “block subset header chain”. The dataset header chain is analogous to the block header chain that encodes the blockchain 150. Each dataset header that represents a dataset is generated in a similar way. The dataset header representing a given dataset is generated by hashing i) the dataset header of the previous dataset (generated based on the previous block in the blockchain) and ii) a hash of the given dataset. The previous dataset header and the hashed dataset may be concatenated before being hashed to form the dataset header. Any suitable hash function may be used, e.g. SHA256, SHA512. As an exception, the dataset header of the initial dataset (generated based on the genesis block) may be generated by hashing only the initial dataset, or a combination of the initial dataset and another value, e.g.0 ²⁵⁶ . The blockchain node 104 may maintain a respective dataset header chain for each data type. Similarly, the blockchain node 104 may maintain a chain of headers that represent the respective filters generated from respective blocks 151. This “filter header chain” is generated in a similar way, where each filter header representing a given filter is generated by hashing i) the filter header of the previous filter (generated based on the previous block in the blockchain) and ii) a hash of the given filter. The blockchain node 104 may send one, some or all of the dataset headers and/or filter headers to Alice 103a. Alice 103a may verify received datasets and/or filters using the respective headers. In some examples, Alice 103a receives dataset headers and/or filter headers from multiple nodes, e.g. blockchain node 104b, and checks for consistency of the headers received from multiple nodes 104. This process is discussed below in section 11. In examples where the blockchain node 104 splits blocks into multiple sets, the dataset header and filter header may be generated in different ways. Taking the case where multiple datasets are generated from a single block for the same data type, each respective dataset is hashed and the respective resulting hash is used as a leaf hash of a Merkle tree (or hash tree, more generally). The Merkle root of the Merkle tree is then used to generate the dataset header by hashing a combination of i) the previous dataset header (generated based on the previous block in the blockchain) and ii) the Merkle root. This process may be performed for each data type. The filter header chain is generated in a similar way. The blockchain node 104 may maintain header chains (dataset and filter) for the entire blockchain 150. Alternatively, the blockchain node 104 may only maintain a header chain for part(s) of the blockchain 150. This allows nodes to prune (i.e. delete) certain datasets and filters. To facilitate maintaining only a particular header chain, the blockchain nodes 104, 104b agree to use a respective block number of the respective block at the start of an interval of blocks in place of the previous block header. See section 4.3.5 for an example. In the scenario where the blockchain node 104 generates the dataset(s) and filter(s) for a block 151 which the node 104 is publishing to the blockchain 150, the node 104 may include a respective commitment to each dataset and/or a respective commitment to each filter as part of the block 151, e.g. in a coinbase (i.e. generation) transaction. The respective commitments may be respective dataset headers and filter headers. Other types of commitments are possible, such as a hash of the entire dataset and a hash of the entire filter. A service provider may be configured to perform some or all of the actions described above as being performed by the blockchain node 104. For a given block 151, the service provider generates a script-based cryptographic puzzle (e.g. a hash puzzle) based on a commitment to a respective dataset and a script-based cryptographic puzzle based on a commitment to a respective filter. The puzzles are used to lock respective transaction outputs (of the same or different transactions). In order to be unlocked, the spending transaction(s) must include the commitments themselves. The commitments may be the dataset header and filter header. The blockchain node 104 may generate the spending transaction(s), which include the commitment(s) (e.g. the headers) and submit them to the blockchain 150, thus revealing the commitments. Alice 103a may obtain the commitments to verify the dataset and filter corresponding to those commitments. The following describes a specific example protocol of the general protocol described above for efficiently identifying transactions. Probabilistic filters are used by light clients 103 to efficiently identify relevant transactions in a block 151. To prevent DoS attack vectors, nodes 104 are responsible for generating filters once for each block, persisting them in memory, and sending them to clients. In BIP157, if the filter matches the data a client is watching for, the entire corresponding block is downloaded. When considering blocks of hundreds of MBs or more, the protocol’s requirement for bandwidth becomes substantially high. This badly impacts the time needed by light clients 103 to read relevant transactions and puts a significant pressure on nodes as the number of light clients grows. 4.3.1 Blockchain Node Operation Nodes 104 that support the Efficient Client-side Block Filtering protocol may perform the following operations. 4.3.1.1 Block Subset Generation For each published block 151, nodes 104 generate block subsets for various types of data. A block subset may contain all the transaction IDs of a block along with the data of a particular type contained in the corresponding transaction. Block subsets are used by clients 103 to identify transactions with data relevant to them published on the blockchain. Relevant data a light client may be interested in includes the following: • address: a payment has been made to its address without the client’s knowledge; the client should be notified and its balance should be automatically updated. • outpoint: one of the outputs a client has created or is partly the owner of (such as a multi-sig output) is spent; it should be notified. For example, if two parties ^^, ^^ own a 1-of-2 Pay To MultiSignature output and ^^ spends it, ^^ should be notified. Another example is when the user has received a transaction from a party but has not yet broadcast it. The user should be able to detect if the party spends the funds that were committed. • UTXO set: the client would like to get notified about any changes to the UTXO set. • OP_RETURN data: the client is expecting to see a particular piece of data published on the blockchain; it should be able to locate the transaction that contains the data and read it. • token metadata: the client would like to track the history of a particular token or get notified when it is transferred or redeemed. Figure 8 shows an example of a block with its corresponding address block subset addresses, return data block subset, and outpoint block subset. For space-efficiency reasons, the return data block subset may store only the hash of the OP_RETURN data contained in each transaction. Nodes 104 may choose to create light address block subsets by pruning from the address block subset addresses contained in an output spent in the same block where it appears. This would reduce the size of the address block subset by keeping only addresses contained in outputs that are spendable after the block is published. The incentive for nodes 104 to support light address block subset is clear; notifying clients about spendable outputs ensures that the party controlling an output is aware of it and hopefully will later solicit and pay the node to spend it. Similarly, nodes 104 may choose to create light outpoint block subsets by pruning outpoints from the outpoint block subset that reference transaction outputs contained in the same block. Nodes 104 may signal to clients which types of block subsets they choose to support. For each type of block subset, they may specify which type of data is considered (for tokens for example, which types of script are included, which ones are not). This ensures that nodes 104 signalling support for a particular type of block subset hold the same content and the filters generated are the same. Once generated, block subsets and filters may be persisted in memory by nodes 104. In some examples, nodes 104 do not generate the subsets dynamically on request as malicious clients may be able to perform DoS attacks by repeatedly requesting block subsets and filters for large blocks. 4.3.1.2 Block Subset Header Chain Generation To ensure clients can efficiently detect faulty nodes 104 serving invalid block subsets, nodes 104 compute the following values and persist them in memory. To be consistent with the blockchain’s typical usage of hashes, double SHA-256 may be used for hash computation, although other hash functions may be used instead. • Block subset hash: double SHA-256 of the serialised block subset (i.e. the transaction identifiers and relevant data). This serves as a commitment to the complete block subset. • Block subset headers: double SHA-256 of the concatenation of the block subset hash with the previous block subset header. This serves as a commitment to all block subsets for previous blocks. The previous block subset header used to calculate that of the genesis block is defined to be the 32-byte array of 0’s. The structure of the block subset header chain may be as follows: ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ(0 ^{ଶହ^} ‖ ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^ _^ )) ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ି^ ‖ ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^ _^ )) As with the blockchain, the block subset header chain might occasionally fork. This implies that a piece of data contained in a block subset might not end up in the longest branch. The double-spend prevention mechanism enforced by nodes 104 of certain protocols (e.g. Bitcoin SV) allows nodes 104 to detect and signal to the network when there are two or more conflicting transactions propagating across the network. Therefore, a client would be notified if a piece of data in a block subset is contained in a transaction that is being double spent and might not end up in the longest branch. 4.3.1.3 Block Subset Filter Generation For each block subset, nodes 104 construct block subset filters by including all the data contained in the corresponding block subset. Nodes 104 may choose to create multiple types of block subset filters by using different types of probabilistic filters. Nodes 104 should signal to clients which types of filters they choose to support. 4.3.1.4 Filter Header Chain Generation To ensure clients can efficiently detect faulty nodes 104 serving invalid block subset filters, nodes 104 may compute the following values and persist them in memory: • Filter hash: double SHA256 of the serialised filter. This serves as a commitment to the complete filter. • Filter headers: double SHA256 of the concatenation of the block subset hash with the previous block subset header. This serves as a commitment to all filters for previous blocks. The previous filter header used to calculate that of the genesis block is defined to be the 32-byte array of 0’s. ^^ ^^ ^^ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ(0 ^{ଶହ^} ‖ ℎ( ^^ ^^ ^^ ^^ ^^ ^^ _^ )) ^^ ^^ ^^ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ( ^^ ^^ ^^ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ି^ ‖ ℎ( ^^ ^^ ^^ ^^ ^^ ^^ _^ )) In addition, nodes 104 are responsible for listening for and serving any requests coming from light clients. 4.3.2 Client Operation The following describes the protocol from the perspective of a client application. 4.3.2.1 Block Header Syncing The client may start by syncing the block header chain from peers (e.g. nodes 104) using the standard headers syncing mechanism and disconnect any outbound peer whose best chain has less work than the longest proof-of-work chain received. 4.3.2.2 Block Subset Header Syncing Once block headers are in sync, the client may sync block subset headers that will help to quickly verify any block subset that it might later download. Unless securely connected to a trusted peer, the client may connect to multiple outbound peers so that it is more likely that at least one of them is honest. If the client connects to at least one honest peer, then the following protocol guarantees that it can identify dishonest peers and eventually obtain the correct block subset headers. When syncing a sequence of block subset headers ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ to ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ , the header preceding ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ may either have been previously saved in memory or be served by a trusted peer. If the client has not previously saved this header (as it happens the first time it syncs block subset headers) and is not connected to a trusted peer, it may query multiple peers, verifying that all header values received are consistent. If it receives inconsistent values, the client may perform a binary search on the complete block subset header chain to detect the point at which the header values sent by the nodes 104 diverge. The client may then download the block subsets from the contradictory nodes 104 at the point where the headers diverge and identifies which element in the block subset differs. It can then query any node for the corresponding transaction along with its Merkle proof to recompute the correct block subset header. Nodes 104 that are found to have sent an incorrect header value are removed from the client’s list of peers. To sync a sequence of block subset headers ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ to ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ , the client may then proceed as follows: 1. If the client had already saved the block subset header preceding ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ , it may query its peers for it. This allows the client to detect any faulty peer whose header is different from the header it had previously saved in memory. 2a. The client then fetches block subset header checkpoints in sequence at evenly spaced intervals (for instance, 1000 block intervals). The header ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ is treated as a header checkpoint as well. A header checkpoint is considered to be trusted if all values received from peers are consistent. After having ensured that all header checkpoints are trusted, the client should persist in memory ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ to safely sync future sequences of block subset headers after restart. 2b. If the client receives conflicting header checkpoints, it queries the conflicting peers for the sequence of block subset hashes in the interval preceding the header checkpoint (from the previous trusted checkpoint excluded up to the checkpoint included). Using the sequence of block subset hashes and the previous trusted header checkpoint, it derives the sequence of block subset headers and verifies the binding links between them up to the conflicting header checkpoints. The client identifies the first block subset hash that the peers disagree on and query the contradictory nodes 104 for the corresponding block subset. It then identifies which element in the block subset differs and query any node for the corresponding transaction along with the Merkle proof to recompute the correct block subset element. Any peer that is found to have sent a sequence with an incorrect block subset hash or an incorrect link is removed from the client’s list of peers. 3. The client can now efficiently download block subset hashes. Using the trusted block subset header checkpoints, the client is not required to connect to multiple peers to download block subset hashes and verify that all values received are consistent. Instead, it can query a single peer for a particular range of blocks where the boundaries correspond to two trusted header checkpoints. The client verifies that the block hashes received from the peer are correctly linked together up to the trusted block subset header checkpoint. Using this mechanism, it can download multiple ranges of block subset hashes from different peers in parallel. The client may ban any peer that sent a faulty range of block subset hashes and query another one until the range received is valid against the trusted block subset header checkpoint. If at any point in the protocol a node is found to have sent an incorrect value, the client may share a record of that to the network. This may can be linked to the node’s identity, e.g. via their Miner ID, which is an example process implemented on the Bitcoin SV blockchain. This builds trust for the clients around nodes 104 that have a good reputation. On the other hand, nodes 104 are aware that if they send incorrect header values, their reputation can be badly impacted. 4.3.2.3 Filter Header Syncing Once the client has synced the sequence of block subset headers, it may sync the sequence of filter headers using the same mechanism described for syncing block subset header. In this case, if the client receives contradictory filter hashes, it downloads the corresponding block subset, verifies it against the verified block subset hash, and recomputes the filter, thus identifying which peer is faulty. 4.3.2.4 Block Subset Filter Request The client may then download the sequence of block subset filters, verify their correctness using the corresponding verified filter hashes, and ban any peer that sent incorrect block subset filters. The client may download and verify multiple filters in parallel. 4.3.2.5 Block Subset Request Once the client has received the sequence of verified filters, it may test if any of the filters matches data it is interested in. If a match is found, the client downloads the block subset, verifies it against the block subset hash, and identifies if a transaction containing relevant data is indeed present in the block subset. 4.3.2.6 Transaction Request In case a relevant transaction is found in the block subset received, the client may query any peer for the transaction along with its Merkle proof. To increase the privacy of the request, it may randomly include dummy transactions contained in the block subset. 4.3.3 Advantages Compared to the BIP37 protocol, the protocol described above enables the interactions between light clients and nodes 104 to dramatically scale with the number of clients. Compared to the BIP157 protocol, the protocol is much more scalable with the block size. 4.3.3.1 Computation complexity Since block subsets and block subset filters are deterministic, they only need to be constructed once and persisted in memory, whenever a new block is published. This keeps the computation required to serve block subsets and their associated filters minimal and eliminates the I/O asymmetry that makes nodes 104 supporting BIP37 vulnerable. 4.3.3.2 Storage complexity The amount of extra memory needed by nodes 104 to store block subsets and filters grows linearly with the size of the blockchain. Except for return data block subsets which store the hash of the OP_RETURN data, block subsets can be stored in the form of an index that points to the relevant transaction data. This makes the extra storage required by nodes 104 minimal. 4.3.3.3 Data Completeness The protocol guarantees that light clients who have the correct list of block headers and are connected to at least one honest peer are able to obtain the correct block subset filters and block subsets for any sequence of blocks. Assume that the client is in the worst-case scenario, that is connected to only one honest node. The client will notice a discrepancy between the data received from the honest node and other nodes 104. As described in the block subset and filter header syncing mechanism, it can verify which node has sent valid data, thus identifying which node is honest and exclude all other faulty nodes 104. Thus, the protocol ensures that light clients connected to at least one honest peer are able to identify all transactions relevant to them. 4.3.3.4 Privacy The protocol described in BIP37 suffers from privacy issues. The privacy provision of the protocol described herein is greatly improved because transactions can be downloaded from any peer so that it is not possible to get complete information on the requested data. The protocol allows users to finely adjust privacy by including any number of dummy transactions in the transaction request. The more transactions the client includes, the better the privacy of the request is. If the client chooses to include ^^ − 1 extra dummy transactions, then the probability for an adversary to guess the sought transaction is 1/ ^^. Private Information Retrieval (PIR) enables users to retrieve a specific entry from a database, replicated among one or multiple non-communicating servers, while hiding from each server the identity of the sought entry. This technique may be integrated into the light client protocol to enable clients to retrieve a specific transaction they have identified to be relevant in a privacy-preserving way. There exist many PIR protocols that achieve sub-linear communication on the size of the database. However, in all PIR protocols the servers’ computation for each retrieval must be at least linear in the size of the database. 4.3.3.5 Communication complexity In BIP157, clients download the entire block content whenever there is a match with the filter, only to throw away the vast majority of the transactions that are irrelevant to them (and even all of them in case of a false positive with the filter). In the protocol described herein, clients only need to download block subsets to confirm the presence of relevant transactions in a block which effectively reduces the waste of bandwidth. In the protocol described herein, clients then need to request the transaction that is relevant to them plus any number of dummy transactions. Compared to BIP157, the protocol requires an extra round of communication for clients to retrieve the complete transaction they are interested in. Nevertheless, this overhead is compensated by the reduction of the total amount of data exchanged between clients and nodes 104. 4.3.4 Block Slicing The Efficient Client-side Block Filtering protocol greatly reduces the amount of data exchanged in the light client-node interactions, compared to the BIP157 protocol. However, downloading block subsets from large blocks (thousands of GB or even a few TB) can be quite expensive. This can represent a significant waste of bandwidth for clients that are only interested in small parts of a block. This section describes how the protocol can scale to arbitrarily large block size. To solve the issue of long latency delay when downloading block subsets for large blocks, nodes 104 may divide large blocks into multiple slices so that block subsets and their corresponding filters are created for each of these slices. Nodes 104 may reach consensus on how to slice blocks, in particular on the maximum size of a slice. This process has the benefit that the size of the block subsets is capped to some value, thus limiting the time needed by clients to download block subsets they are interested in. In the light client protocol described so far, block subsets and filter headers were defined to be the commitment to the block subset and filter of a block (as well as the previous header). To fit the case where multiple block subsets and filters are generated for all the slices of a block, block subset headers (respectively filter headers) are redefined to commit to the root of a Merkle tree containing all block subsets (respectively filters) of the slices of a block. Since headers now commit to multiple block subsets or filters, the following modifications to the Efficient Client-side Block Filtering protocol are required: • If a client receives inconsistent header checkpoints from its peers, it may request the block subset or filter hashes of all the slices of the block to identify the block subset or filter the peers disagree on. The procedure used to identify the correct one is the same as in the protocol. • In order to verify the correctness of filters received from its peers, the client may recompute all nodes 104 of the Merkle tree, going bottom-up from the leaves to the root. The client then checks that the recomputed root is the same as the one it has received and verified. • In order to verify the correctness of a block subset received from its peers, the client may request a Merkle proof of inclusion of the block subset and checks correctness of the proof using the verified block subset hash. A simple way of committing to a list ^^ of ^^ elements is to compute the hash of the concatenation of all hashed elements. To prove that an element belongs to ^^, a prover has to send the index of the element in ^^ and the hash of the ^^ − 1 remaining elements. The advantage of using a Merkle tree is that the proof required to prove inclusion of an element is greatly reduced. Using Merkle trees, nodes 104 only need to send log _ଶ ( ^^) hash values to prove that an element belongs to the list ^^. In particular, for a block divided into ^^ slices, proving the correctness of a particular block subset requires sending only log _ଶ ( ^^) hashes. We choose to use Merkle trees in filter headers to be consistent with the structure of block subset headers. 4.3.5 Data Pruning In the previous section, it was assumed that nodes 104 generate, store, and serve block subsets and their corresponding filters for all blocks 151 in the blockchain 150. However, there are no clear incentives for nodes 104 to provide such a service. The work that must be performed to serve block subsets and filters becomes increasingly larger as the blockchain grows and new users connect. On the other hand, there is an incentive for nodes 104 to support light address block subsets for recent data. Indeed, nodes 104 are incentivised to notify clients about newly published transactions containing spendable outputs. This ensures the owner of an output is aware of it and will later pay the node to spend it. On the other hand, if an output is not known to its owner, then it may stay in the UTXO set for a long period of time. The previous observations motivated the design of a solution that enables nodes 104 to prune old block subsets and filters to serve only recent data. The solution should ensure the following: • Nodes 104 can serve block subsets and filters for the range of blocks of their choice. • Clients can detect nodes 104 serving invalid data in an efficient and reliable manner. A trivial solution where nodes 104 simply prune old block subsets and filters would prevent clients from reliably syncing the chain of headers. Indeed, clients receiving inconsistent header values for the block at the point where the chain is broken would no longer be able to identify the correct value. The problem here is that the link with the root of trust, which is provided by the genesis block, is broken. Instead, according to examples described herein, the chain of headers may be cut at regular intervals, making sure that there is a root of trust preceding each interval. The root of trust is provided for each interval by the height value of the first block in the interval. Nodes 104 may agree on the length of the interval as it must be constant across the network. In the following, we assume the length of the interval to be 1000 (~1 week of data). The block subset headers are calculated as follows (the same calculation applies to filter headers). If ^^ mod 1000 ≠ 0: ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ି^ ‖ ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^ _^ )) If ^^ mod 1000 = 0: ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^_ℎ ^^ ^^ ^^ ^^ ^^ _^ = ℎ( ^^ ‖ ℎ( ^^ ^^ ^^ ^^ ^^_ ^^ ^^ ^^ _^ )) This allows nodes 104 to decide which intervals of block subsets and filters they want to serve to clients. Since each interval has its own root of trust, nodes 104 may choose to prune any of them without breaking the complete chain of headers. 4.3.6 Header Commitment As described above, clients may use a header synchronisation mechanism to synchronise block subset and filter headers for any sequence of blocks. These headers may be used to verify the correctness of the block subsets and block subset filters a client might later download. To synchronise a sequence of headers, clients first need to synchronise header checkpoints at regular intervals. In order to ensure that the checkpoint values received can be trusted, multiple peers have to queried. The checkpoints are then used as a source of trust to verify the correctness of any sequence of headers that have been downloaded, by verifying that the headers are correctly linked together up to the checkpoints. If nodes 104 decide to prune old block subsets and filters using the method described in section 10.5, then clients would no longer be able to retrieve them from nodes 104. In particular, there would no longer be a way for clients to get trustworthy header checkpoints from nodes 104 assumed to be honest. A block subset filter service provider (another example of the first party described above), such as a regulator, government body, or payment processor, may offer a service that persists all block subsets and filters and serve them to clients, e.g. in exchange for a fee. However, for blocks subsets and filters that were pruned by nodes 104, there is no way for clients to verify that the service provider is serving the correct data. This section describes a series of header commitment schemes whereby nodes 104 that secure the blockchain network 106 commit to block subset and filter headers inside blocks. The on-chain attestations for the header values can be used to improve the efficiency of the header checkpoint synchronisation mechanism by reducing the number of queries to nodes 104. In case nodes 104 decide to prune some intervals of block subsets and filters, the attestations also provide a way to verify data received from a block subset filter service provider. The schemes do not require a network-wide change to the Bitcoin consensus rules but instead proposes a new layer of interpretation. 4.3.6.1 Basic Node Commitment In the simplest case, nodes 104 can attest to a block subset and filter header value by including them in the coinbase (i.e. generation) transaction or another transaction in the block produced. Consider a node ^^ _^ who is attempting to mine block ^^ _^ . The full procedure for ^^ _^ to commit to some subset and filter header value of the previous block ^^ ^ _ି^ follows: 1. ^^ _^ computes the block subset of the previous block ^^ _^ି^ . 2. the block subset filter of the previously computed block 3. ^^ _^ computes the corresponding block subset header and filter header. 4. a coinbase transaction ^^ ^^ ^^ _^ which includes the header values as push. ^^ ^^ ^^ _^ should specify the type of data contained in the corresponding block subset. 5. ^^ _^ builds a candidate block ^^ _^ on top of ^^ _^ି^ based on the transactions it during the interval, which includes ^^ ^^ ^^ _^ . If ^^ _^ successfully finds a valid proof-of-work and publishes ^^ _^ before another node finds an alternative valid block, then ^^ ^^ ^^ _^ becomes the on-chain attestation of the block subset and filter headers of ^^ _^ି^ . Note that ^^ _^ commits to the block subset and filter header value of the previous block ^^ ^ _ି^ , no mined it. A client attempting to obtain the attestations for the block subset and filter headers of a block ^^ _^ି^ can do the following: 1. Obtain the list of block headers ^^ _^ , ^^ _^ , … , ^^ _^ to verify the proof- of-work and integrity of the current chain tip ^^ _^ . 2. Obtain the coinbase transaction ^^ ^^ ^^ _^ for the chaintip ^^ _^ , and the corresponding Merkle proof Γ( ^^ ^^ ^^ _^ ). 3. Verify the Merkle proof Γ( ^^ ^^ ^^ _^ ) to check the integrity of ^^ ^^ ^^ _^ . 4. If it passes, extract the attestations from ^^ ^^ ^^ _^ for the block subset and filter headers of ^^ _^ି^ . In this scheme, the block subset and filter headers of a block ^^ _^ି^ are committed in the following block ^^ _^ . This ensures that nodes 104 have enough time to compute the header values. It would also be feasible to allow a longer delay. For example, if the block subset and filter headers of ^^ _^ି^ were to be included in ^^ _^ାଽ , this gives an interval of 10 blocks in which nodes 104 can compute the required headers. The process can be performed by a single node for each block they successfully mine and can be extended such that the node includes the commitments of all blocks since they last successfully published a block to the blockchain 150. A variation of this method involves adding the attestations for the block subset and filter headers to a transaction other than the generation (coinbase) transaction. It is assumed in this case that the transaction would be signed by a well-known public key, and possibly linked to a node’s identifier (e.g. Miner ID) . Moreover, it may be desirable for many other nodes 104 on the network to add attestations to the same header values in this way, such that trust can be built up in the validity of the attestations. 4.3.6.2 Hash-based Bounty Scheme This section describes an alternative scheme based on hash puzzle bounties for the required commitment information. The scheme utilises a block subset filter service provider that would persist all block subsets and filters and serve them to clients. The service provider may then supply the required bounty aimed to incentivise a set of nodes 104 to generate header commitments. It is assumed that nodes 104 can be publicly identified using a well- known public key. This scheme rewards only the first node 104 to correctly produce the block subset and filter header commitments of the relevant block, which creates a race between all the nodes 104 to successfully find and publish the correct solution. The protocol has two phases, (i) a set-up by the block subset filter service provider, followed by (ii) a fulfilment phase carried out by a node. Consider the scenario where the block subset filter service provider wants to incentivise a group of ^^ nodes 104 ^^ _^ , … , ^^ _^ with public keys ^^ ^^ , … , ^^ ^^ ^ _^ respectively to commit to some block subset and header of a mined block ^^ _^ . We call ^^ the set of public keys containing ^^ ^^ _^ to ^^ ^^ _^ . The set-up phase is as follows: 1. Derive the block subset and corresponding header ℎ _^ ^{^௨^} for the block ^^ _^ . 2. Derive the block subset filter and corresponding header ℎ ^{^^௧^} ^ for the block ^^ _^ . 3. Construct a first bounty transaction ^^ ^^ ^{^௨^_^^௨^௧௬} ^ (described below), locking funds with a hash puzzle requiring ℎ _^ ^{^௨^} and a signature ^^ ^^ ^^ ^^ ^^ _^ verifiable by ^^ ^^ _^ ∈ ^^ in order to be redeemed. 4. Construct a second bounty transaction ^^ ^^ ^{^^௧^_^^௨^௧௬} ^ , locking funds with a hash puzzle requiring ℎ ^{^^௧^} ^ and a signature ^^ ^^ ^^ ^^ ^^ _^ verifiable by ^^ ^^ _^ ∈ ^^ in order to be redeemed. 5. Broadcast the bounty transactions ^^ ^^ ^{^௨^_^^௨^௧௬ ^^௧^_^^௨^௧௬} ^ and ^^ ^^ _^ . The bounty transactions can be mined from ^^ _^ା^ onwards. The locking scripts of the bounty transactions reference block ^^ _^ by including the height value ^^ as a data push. They may also include a string which describes the type of data contained in the corresponding block subset. The locking script of the bounty transaction ^^ ^^ ^{^௨^_^^௨^௧௬} ^ for the address block subset header is as follows. Locking script: OP_HASH256 <ℎ ^^ ^^ℎ256(ℎ _^ ^{^௨^} )> OP_EQUALVERIFY OP_1 <ℎ ^^ ^^ℎ160( ^^ ^^ _^ )> … <ℎ ^^ ^^ℎ160( ^^ ^^ _^ )> < ^^> OP_CHECKMULTISIG OP_RETURN < ^^> <”address block subset”> The locking script of ^^ ^^ ^{^^௧^_^^௨^௧௬} ^ is defined in a similar way by replacing ℎ _^ ^{^௨^} with ℎ ^{^^௧^} ^ . Once the bounty transactions have been broadcast, node ^^ _^ in the scheme can perform the following steps to redeem the bounty: 1. Derive the block subset and corresponding header ℎ _^ ^{^௨^} for block ^^ _^ . 2. Derive the block subset filter and corresponding header ℎ ^{^^௧^} ^ for block ^^ _^ . 3. Claim the first bounty transaction by providing ℎ _^ ^{^௨^} and a signature ^^ ^^ ^^ ^^ ^^ _^ verifiable by its public key ^^ ^^ _^ ∈ ^^ in a transaction that spends the output of ^^ ^^ ^{^௨^_^^௨^௧௬} ^ . 4. Claim the second bounty transaction by providing ℎ ^{^^௧^} ^ and a signature ^^ ^^ ^^ ^^ ^^ _^ verifiable by its public key ^^ ^^ _^ ∈ ^^ in a transaction that spends the output of ^^ ^^ ^{^^௧^_^^௨^௧௬} ^ . The unlocking script used to claim the bounty transaction ^^ ^^ ^{^௨^_^^௨^௧௬} ^ is as follows (the unlocking script used to claim ^^ ^^ ^{^^௧^_^^௨^௧௬} ^ is defined in a way replacing ℎ _^ ^{^௨^} h ℎ ^{^^} wit ^{௧^} ^ ). Unlocking script: OP_0 < ^^ ^^ ^^ ^^ ^^ _^ > <ℎ _^ ^{^௨^} > If is assumes that all nodes 104 are calculating ℎ _^ ^{^௨^} , ℎ ^{^^௧^} ^ correctly and as quickly as possible, then the winner of the bounty is simply determined by which node successfully creates the next block first, effectively piggybacking the native proof of work consensus mechanism to decide the winner. Let’s assume the bounty transaction and corresponding redemption transaction for the block subset header ℎ _^ ^{^௨^} have been published on the blockchain. A client attempting to obtain the attestations for the block subset headers of the block ^^ _^ can do the following: 1. Obtain the list of block headers to verify the proof-of-work and integrity of the current chain tip. 2. Obtain the bounty and redemption transactions ^^ ^^ ^{^௨^_^^} ^^ ^{ௗ^^^௧^^^} ^ and the Merkle from the block subset 3. Verify the Merkle proofs Γ൫ ^^ Γ൫ ^^ ^{^௨^_^^ௗ^^^௧^^^} ^ ^^ _^ ൯ to check integrity of ^^ ^^ ^{^௨^_^^௨^௧௬} ^ . 4. Verify that the public key in ^^ ^^ ^{^௨^_^^ௗ^^^௧^^^ ^௨^_^^௨^௧௬} ^ that spends ^^ ^^ _^ belongs to a trustworthy node. 5. If it passes, extract the commitment ℎ ^{^௨^_^^ௗ^^} ^ ^{^௨^} from ^^ ^^ ^{^௧^^^} ^ . The procedure for obtaining the commitment ℎ ^{^^^௧^^} ^ is similar. 4.3.6.3 Improved Header Checkpoint Synchronisation Mechanism As described above, header checkpoints are used by clients to synchronise any sequence of block subset and filter headers efficiently and reliably. Clients may query multiple peers and verify that the checkpoint values received are consistent. The header checkpoint synchronisation mechanism involves a significant number of messages exchanged between clients and nodes 104. Instead of querying multiple nodes 104 for a set of header checkpoints, light clients may use the on-chain attestations of the block subset and filter headers defined in in the above two sections as reliable checkpoint values. The advantage is that after having synchronised block headers a single peer needs to be queried to obtain trustworthy checkpoint values. The verification of the values received only involves fetching Merkle proofs of the transactions containing the committed header values from the peer and validating inclusion of the transactions in the block header chain. The process for synchronising a sequence of headers is then done in the same way as before. The header commitment schemes enable the permanence of the block subset and filter header values. This may prove to be particularly useful if nodes 104 decide to prune old block subsets and filters and client would like to synchronise these from a service provider. In order to ensure that the service provider cannot lie about the block subset and filter values, the client should perform the following operations: 1. Fetch on-chain attestation of block subset and filter headers for blocks at regular interval (e.g.1000), using the methods described in section 10.6.1 and 10.6.2. These are treated as header checkpoints. 2. Fetch block subsets and filter headers from the service provider for the sequence of blocks to be synchronised. 3. Verify that the headers received are correctly linked together up to the header checkpoints. 4. If it passes, fetch filters from the service provider and validate them against the verified filter headers. Block subsets that the client might later download should also be validated against the verified block subset headers. 5. TRANSACTION OUTPUT ACKNOWLEDGEMENTS Embodiments of the present disclosure enable parties to attest to knowledge of transaction outputs that are locked to their respective public keys, i.e. that they have control over. Attesting to knowledge of an output may be taken to mean acknowledging the output. Figure 4 shows an example system 400 for implementing the embodiments described herein. The system 300 comprises a first party (e.g. Alice 103a), a second party (e.g. Bob 103b) and a third party (e.g. a blockchain node 104 of a blockchain network 106). Alice 103a may obtain a transaction template that comprises an output locked to a public key controlled by Alice 103a. A transaction template refers to a blockchain transaction that is missing one or more pieces of data (an input, an output, a signature, etc.). Note that the term “transaction template” may be replaced with simply “transaction”. Alice 103a may generate the transaction template herself, or she may receive the transaction template from another party, e.g. Bob 103b. Alice 103a generates a signature (referred to herein as an attestation signature, or an acknowledgement signature). The attestation signature may be an ECDSA signature, or an alternative type of signature. The attestation signature signs a message comprising at least the output controlled by Alice 103a (i.e. the output that Alice 103a is acknowledging) and an outpoint of the transaction. An outpoint is a reference to an output of a previous blockchain transaction that is referenced by an input of a current transaction, which in this case is the transaction template. Typically an outpoint comprises a transaction identifier of the referenced transaction and an index of the referenced output. In general the message may comprise any outpoint. Alice 103a includes the attestation signature in an output of the transaction. The output may be a return (e.g. OP_RETURN) output. The output comprising the attestation signature is different compared to the acknowledged output. Alice 103a may add this output herself, or it may be added by a different party, e.g. Bob 103b, by providing Bob 103b with the attestation signature. Alice 103a generates the attestation signature with a private key corresponding to the public key to which the acknowledged output is locked. Thus only Alice 103a may generate the attestation signature because only she has knowledge of the private key. Note that the output may be locked to Alice’s public key in any suitable way. For example, the output may be a P2PK or P2PKH output. In addition to the attestation signature, the output comprising the attestation signature may also comprise a protocol flag. The protocol may signal that the output comprises an attestation signature. In some examples, the output may also comprise the respective index of the outpoint and/or the respective index of the acknowledged output. Alice 103a may submit the transaction template to the blockchain network 106, or she may send it to Bob 103b for sending to the blockchain network 106. Alice 103 and/or Bob 103b may add one or more additional items to the transaction template to complete the template, e.g. signatures signing over one or more parts of the transaction. In some examples, merely adding the attestation signature is enough to complete the template. In some examples, the message signed by Alice 103a to generate the attestation signature comprises an index of the outpoint. That is, the message may comprise an outpoint of the transaction and an index of that outpoint within the transaction. The index (e.g.0, 1, 2, etc.) may refer to an input of the transaction that comprises the outpoint. Additionally or alternatively, the message signed by Alice 103a may comprise an index of the acknowledged output. That is, the message may comprise the output itself and an index of that output within the transaction. If the transaction template comprises multiple outputs controlled by Alice 103a, Alice 103a may generate a respective attestation transaction for each respective output. Each respective attestation signature signs a respective message that comprises at least an outpoint of the transaction and a respective output. The same outpoint may be used for more than one attestation signature. In some examples, each attestation signature is included in the same output of the transaction template. In other examples, one, some or each attestation signature is included in its own, separate output. As mentioned, Alice 103a may add additional data to the transaction template. For example, Alice 103a may generate a signature based on a message comprising at least the acknowledged output. This message is included in an input of the transaction that references an output of a previous transaction controlled by Alice 103a. Alice 103a may include a signature flag (e.g. sighash single) that signals that only the acknowledged output is signed with this signature. This signature may be referred to as blockchain signature, as it is used as part of (i.e. required by) the blockchain protocol to unlock an unspent transaction output of a previous transaction. For privacy and security, the blockchain signature may be generated with a different private key compared to the attestation signature. Blockchain signatures per se will be familiar to the skilled person. As was also mentioned above, Alice 103a may send the transaction template to Bob 103b. Bob 103b may perform similar actions to Alice 103a so as to acknowledge an output controlled by Bob 103b (i.e. locked to Bob’s public key). That is, Bob 103b generates an attestation signature and includes the signature in an output of the transaction template. Bob’s attestation signature may be added to the same output as Alice’s attestation signature, or a different output. Bob 103b may generate a blockchain signature based on a message that comprises all inputs of the transaction template (other than the input that is to include the signature) and all outputs of the transaction template. Bob 103b includes his signature in an input of the transaction template that references an unspent transaction output of a previous transaction controlled by Bob 103b. In some examples, before Bob 103b adds his blockchain signature (or even before Bob 103b generates his attestation signature), Bob 103b may verify that Alice’s attestation signature was generated with a private key corresponding to the same public key to which Alice’s output is locked. This verification may vary depending on how the output is locked. For example, if the output is a P2PK output then the public key can be directly extracted from the output and used to verify the attestation signature. If the output is a P2PKH output, Bob 103b used a technique such as that described in section 7 so as to first recover the public key. Note that whilst the above examples have been described in terms of Alice 103a generating and adding an attestation signature followed by Bob 103b generating and adding an attestation signature, the reverse may also occur. That is, Alice 103a may receive a transaction template that comprises Bob’s attestation signature, and then she may generate and add her own attestation signature. At a later time, when the transaction has been recorded on the blockchain 150, a blockchain node 104 may use the attestation transactions to determine whether or not to send transactions to Alice 103a and/or Bob 103b. That is, a node 104 may ordinarily send to Alice 103a transactions having one or more outputs controlled by Alice 103a. The same goes for Bob 103b. Now, the blockchain node 104 may determine whether Alice 103a has knowledge of the output(s) of a transaction and selectively choose not to forward that transaction, since she is already aware of it. The same goes for a transaction having an output controlled by Bob 103b. The blockchain node 104 determines whether Alice 103a or Bob 103b has knowledge of a transaction output (and thus the transaction) based on whether the transaction includes an attestation signature generated by Alice 103a or an attestation transaction generated by Bob 103b. The blockchain node 104 may perform said determining in response to receiving a request for transactions having outputs controlled by Alice 103a and/or Bob 103b. 6. ACKNOWLEDGEMENT OF PAYMENT RECEIPT This section describes a specific example of the general protocol described in section 5. This example protocol, referred to as “acknowledgements of payment receipt” provides a proof that the controller of an output is aware of its inclusion in a transaction. Any of the features described below may be used in conjunction with any of the features described in section 5. It will be appreciated that some of the specific details described below are optional. 6.1 Acknowledgement Structure An acknowledgement of payment receipt may be included in a False Return locking script as follows: OP_FALSE OP_RETURN < ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^> < ^^ _^^ > < ^^ ^^ ^^ ^{^^^} ‖ ^^ _^௨௧ > • ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^: a (32-bit) flag indicating to nodes 104 that the following data contains acknowledgements of payment receipt. • ^^ _^^ : index ^^ _^^ corresponding to some transaction input. • ^^ ^^ ^^ ^{^^^} ‖ ^^ _^௨௧ : acknowledgement for the output at index ^^ _^௨௧ . The signature ^^ ^^ ^^ ^{^^^} signs the output at index ^^ _^௨௧ and the outpoint referenced in the input at index ^^ _^^ . Signing an outpoint prevents the signature from being replayed in another transaction. Note that it doesn’t matter which outpoint is signed. The signing key used to compute the signature ^^ ^^ ^^ ^{^^^} is the same key that corresponds to the public key used to lock the acknowledged output at index ^^ _^௨௧ . This ensures that only the controller of an output can produce the corresponding acknowledgement. Figure 5 shows an example of a transaction containing an acknowledgement of payment receipt. The acknowledgement signs the concatenation of the index ^^ _^^ , the outpoint ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ _௩^^ , the index ^^ _^௨௧ , and the complete output ^^ ^^ ^^ ^^ ^^ ^^ _௩^ೠ^ . The public key ^^ that locks ^^ ^^ ^^ ^^ ^^ ^^ _௩^ೠ^ is associated with the private key ^^ ^^ that is used to compute the signature ^^ ^^ ^^ ^{^^^} . An adversary may attempt to publish a transaction containing an acknowledgement for some output without the controller of the output being aware of it. The acknowledgement described herein is secure under this scenario since the keys used to lock an output and create the signature in the corresponding acknowledgement are the same. Therefore, the authenticity provided by digital signatures guarantees that any party acknowledging some output is aware of its inclusion in the transaction. Moreover, the double-spend prevention mechanism provided by the blockchain protocol ensures that the signature in an acknowledgement, which is computed on both the corresponding output and some outpoint, cannot be replayed in a different transaction. Indeed, outpoints can appear only once in the blockchain as outputs can only be consumed once. 6.2 Merchant-funded Transactions Implementation This section describes an example implementation of acknowledgements of payment receipt in the context of a merchant-funded transactions protocol. The merchant-funded transactions protocol is described in UK patent application no.2118959.2. When using this payment protocol, both the customer (e.g. Alice 103a) who controls some change outputs and the merchant (e.g. Bob 103b) who controls the outputs receiving the payment may acknowledge inclusion of their respective outputs. Consider a payment transaction where the customer 103a adds ^^ inputs and ^^′ change outputs to pay ^^ bitcoins to the merchant. Additionally, the merchant 103b adds ^^ inputs to cover the fees and ^^′ outputs to receive the payment. Without loss of generality, it can be assumed that ^^ = 1 and ^^ ^ᇱ = 1. Two examples are presented: one where the customer’s acknowledgements are signed by the customer 103a, and a more space-efficient one in which they are not signed by the customer 103a. 6.2.1 Signed Customer’s Acknowledgement In this first example, the customer’s acknowledgements ACK ^Cust for the change outputs are included as the first output of the transaction. The acknowledgements are signed by the first customer’s input using the SIGHASH_SINGLE flag. Figure 6A shows a transaction containing the customer’s list of acknowledgements ACK ^Cust . As an example, the message parts signed by ^^ ^^ ^^ _^ ^{^௨^௧^^^} in ACK ^Cust include the outpoint (outpoint ^Cust ) and the second output (locked to the customer’s public key). The key used to compute the signature ^^ ^^ ^^ _^ ^{^௨^௧^^^} is the same key that corresponds to the public key ^^ _^ ^{^௨^௧} . The transaction is then sent to the merchant 103b who adds an output to receive the payment. Before signing and broadcasting the transaction to the network 106, the merchant 103b acknowledges receipt of the payment by adding his acknowledgement ACK ^Merc as a separate output, as shown in Figure 6B. The message parts signed by the merchant’s acknowledgement include the outpoint (outpoint ^Merc )and the final output (locked to the merchant’s public key). The key used to compute the signature ^^ ^^ ^^ _^ ^{ெ^^^^^^} is the same that corresponds to the public key ^^ ^{ெ^^^} . Figure 6C represents the complete, signed transaction containing the customer’s and merchant’s acknowledgements. The signature ^^ ^^ ^^ ^{ெ^^^} signs all outpoints and all outputs. Before adding ACK ^Merc , the merchant 103b may check that the customer 103a provided legitimate acknowledgements, that is to say the signatures in ACK ^Cust are computed on the correct message with the correct key. Verifying an ECDSA signature traditionally requires knowledge of the public key corresponding to the signing key. However, the public keys may be obfuscated in the P2PKH locking scripts by double-hashing them as ℎ( ^^) = ^^ ^^ ^^ ^^ ^^ ^^160( ^^ ^^ ^^256 ⁽ ^^ ⁾ ). Thankfully, the ECDSA signature scheme allows the public key to be recovered from the signature together with the signed message. This process is described below in section 7. The recovery process may return four possible EC points that are valid public keys corresponding to the signature. If none of the public keys returned matches the address ℎ( ^^) given in the corresponding P2PKH, then the signature is deemed invalid. If one of the public keys matches, then the signature can be considered as valid with high probability. In this example, if the number of customer’s inputs ^^ is larger than the number of change outputs ^^′, then all change outputs may be signed by some customer’s input with the SIGHASH_SINGLE flag. The customer 103a is therefore guaranteed that the merchant 103b cannot swap them with its own output before broadcasting the transaction to the network 106. In the case where ^^ is less than or equal to ^^′, this example implies that some of the customer’s change outputs are not signed by the customer 103a and can potentially be swapped by a malicious merchant 103b. Nevertheless, the acknowledgement signatures in ACK ^Cust are enforced by the customer’s input signature (as there is at least one customer’s input). The merchant 103b thus cannot swap the customer’s acknowledgements. Therefore, the acknowledgements allow anyone to detect malicious merchants, by verifying that the signatures in ACK ^Cust are correctly computed on the appropriate parts of the transaction. In particular, they can serve as a recourse for customers to report malicious merchants swapping change outputs. 6.2.2 Unsigned Customer’s Acknowledgement This section describes a more space-efficient example where the customer’s and merchant’s acknowledgments are grouped into a single output. In this example, the customer’s acknowledgements in ACK ^Cust directly follow the ^^′ change outputs and are not signed by any of the customer’s inputs. After receiving the transaction from the customer 103a, the merchant 103b appends his part of the acknowledgement ACK ^Merc in the same output as ACK ^Cust . The acknowledgements ACK ^Cust and ACK ^Merc are constructed in the same way as described in section 6.2.1. Figures 7A to 7C show the states of a transaction as the acknowledgements ACK ^Cust and ACK ^Merc are added. If the number of customer’s inputs ^^ is larger or equal to the number of change outputs ^^′, then all change outputs may be signed by some customer’s input with the SIGHASH_SINGLE flag. The customer 103a is therefore guaranteed that the merchant 103b cannot swap them with its own outputs before broadcasting the transaction to the network 106. Note that contrary to the previous example, this also applies when ^^ is equal to ^^′. An advantage of this example is that the customer’s and merchant’s acknowledgements are included as a single output, instead of two as in the first construction. This offers a reduction in the size of the transaction, which can represent a non-negligible cost saving for merchants processing a large amount of payments, in addition to storage and bandwidth savings. The DER encoding of an ECDSA signature done over the Secp256k1 curve takes up to 72 bytes. Each acknowledgement then requires up to 73 bytes (72 bytes for the signature plus 1 byte for the index). If the payment transaction contains 10 outputs, then the inclusion of acknowledgements of payment receipt results in an extra storage of 725 bytes (720 bytes for the acknowledgements plus 4 bytes for the ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ flag plus 1 byte for the outpoint index). In some countries, it is obligatory for a business to provide an invoice to a customer detailing the products or services sold. Typical data contained in an invoice includes list of items purchased, date of purchase, amount of sales taxes, etc. Even though not all this information needs to be stored on-chain, a merchant may want to store some pieces of it considering the immutable and transparent properties offered by the blockchain. These pieces of information would be included as part of the acknowledgement of payment receipt output and could be signed by both the customer and the merchant. As described in the following section, the acknowledgements of payment receipt can help reducing the amount of data stored by nodes 104 and returned to light clients. This is beneficial for the scalability of the light client protocol. 6.3 Improving Blockchain Light Client Protocol Efficiency This section describes how nodes 104 may support acknowledgements of payment receipt to improve the scalability of the light client protocol. As the number of transactions increases, blocks are becoming increasingly larger. This directly impacts the bandwidth requirement of the light client protocol. To allow the protocol to scale both with the number of transactions and with the number of clients, nodes 104 should preferably filter out as much data as possible that is irrelevant from the light client-miner interaction. When a payment is made with the BIP270 protocol, the payment transaction is passed to the merchant 103b before being broadcasted to the network 106. Therefore, both the customer 103a and the merchant 103b are aware of the transaction content. The acknowledgment of payment receipt described herein serves as proof that a party controlling an output is aware of its presence in a transaction. In the merchant-funded transaction protocol where both the customer 103a and the merchant 103b may create and sign the transaction, the two parties may include such an acknowledgement to prove to nodes 104 that they are aware of the inclusion of the outputs they control. Nodes 104 can therefore distinguish between acknowledged and non-acknowledged outputs and choose to return only data from non-acknowledged outputs, which are not already known to the parties controlling them. Since payment transactions constitute a major proportion of all transactions, filtering out these from the light client protocol would be highly beneficial for its scalability. In the Efficient Client-side Filtering protocol described in section 4.3, nodes 104 have the ability to finely choose which data they consider in the interactions with light clients. The following describes how nodes 104 may use acknowledgements of payment receipt to filter out acknowledged output data. 6.3.1 Miner Operation In the Efficient Client-side Filtering protocol, nodes 104 construct filters on block subsets that clients use to efficiently identify transactions that might be relevant to them. To improve the efficiency of the protocol, nodes 104 may choose to omit acknowledged data from the filters and block subsets created. If a node 104 identifies a ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ flag in a transaction output, it may proceed by verifying each acknowledgement, following these steps: 1. Extract the index ^^ _^^ following the ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ flag, and the acknowledgement composed of the signature ^^ ^^ ^^ ^{^^^} and the output index ^^ _^௨௧ . 2. Recover all possible public keys from ^^ ^^ ^^ ^{^^^} , e.g. using the method described in section 7. The signed message considered in the recovery process is the concatenation of ^^ _^^ , the outpoint referenced in the input at index ^^ _^^ , ^^ _^௨௧ , and the output at index ^^ _^௨௧ . 3. Extract the address ℎ( ^^) contained in the locking script of the output at index ^^ _^௨௧ . If the locking script does not contain any address, reject the acknowledgement. 4. If one of the recovered public keys corresponds to address ℎ( ^^), accept the acknowledgment. Otherwise, reject the acknowledgement. In the protocol described in section 4.3, nodes 104 construct block subsets containing block data relevant to light clients. If an output is found to have a valid acknowledgement, then the block subset may be generated such that it does not include any data contained in the output. The filter created on the block subset and broadcasted to light clients would therefore not contain any data contained in an output with a valid acknowledgement. Figure 9 shows an example of a block with the corresponding address block subset created by miners. In this case, addresses ℎ( ^^ _^ ) and ℎ( ^^ _^ ) are not included in the address block subset because the outputs they are entered into have been acknowledged by their controller. Acknowledgements of payment receipt permit the reduction of the size of the block subset and their corresponding filter. This reduces the extra storage requirement for nodes 104 supporting this light client protocol as well as the communication bandwidth of the protocol. Even though this technique implies some extra computation required to verify the acknowledgements, this is done only once per block. On the other hand, block subsets and filters are served many times to numerous clients. Therefore, the technique greatly improves the scalability of the light protocol in terms of number of clients. It also helps to cope with the increase of the block size which leads to an increase of the corresponding block subsets and filters generated, stored, and served by nodes 104. Notes that the use of acknowledgements is not limited to the Efficient Client-side Block Filtering protocol but can benefit any other light client protocol by reducing the size of the data generated, stored, and returned to light clients. 7. ECDSA PUBLIC KEY RECOVERY This section briefly describes how to create digital signatures with the secp256k1 Elliptic Curve used in some blockchain protocols. Each curve point in secp256k1 has two coordinates ( ^^, ^^) that are integers modulo a prime ^^. The order of the curve is defined as ^^ and ^^ < ^^. The secp256k1 curve is defined as: ^^ ^ଶ ≡ ^^ ^ଷ + ^^ ^^ + ^^ mod ^^, over the prime field ^^ _^ , where 4 ^^ ^ଷ + 27 ^^ ^ଶ ≠ 0 and ^^, ^^ are defined by the secp256k1 standard. For a private key ^^, we generate a signature on the message ^^ with maximum length 2 ^{^ସ} − 1 bits in the following way: 1. Hash the message ^^ using the SHA-256 hash function: ^ _{^ = SHA˗256} ⁽ _^^ ⁾ _, which returns a 256-bit string ^^ called a message digest and convert this into an integer value. 2. Choose a random integer ^^ ∈ {1, 2, … , ^^ − 1}. This integer ^^ is used as an ephemeral key. 3. Add the base point ^^ to itself ^^ times to get an ephemeral public key ^^ = ^^ ⋅ ^^ = ( ^^, ^^). 4. Calculate ^^ ≡ ^^ mod ^^. If ^^ = 0, the signature will be independent of ^^, so return to step 1 and choose another ^^. 5. Calculate the multiplicative inverse ^^ ^{ି^} of ^^ in the prime field ^^ _^ . 6. Calculate s ≡ ^^ ^{ି^} ( ^^ + ^^ ^^) mod n. If ^^ = 0, return to step 1 and choose another ^^. 7. The signature is then given by ( ^^, ^^). Given a message ^^ and a signature ( ^^, ^^), the following method recovers the corresponding valid public keys: 1. Calculate ^^ _^ from ^^ ≡ ^^ mod ^^. In the rare case where ^^ < ^^ − ^^, there exists two values ^^ _^ , ^^ _^ ′ for ^^ such that ^^ ≡ ^^ mod ^^. 2. Recover the ephemeral public key with the corresponding ^^ coordinate. Since points on the curve follow the equation ^^ ^ଶ ≡ ^^ ^ଷ + ^^ ^^ + ^^ mod ^^, there can be two points ( ^^ _^ , ^^ _^ ) and ( ^^ _^ , − ^^ _^ ) with the same ^^ coordinate. This means that in total, we can have four ephemeral public keys ^^ that match the ^^ value in the signature. 3 _{. Calculate the digest of message ^^ as ^^ = SHA˗256} ⁽ _^^ ⁾ _. 4. Calculate the multiplicative inverse ^^ ^{ି^} of ^^ in the prime field ^^ _^ . 5. Recover all public keys ^^ ^^ = ^^ ^{ି^} ( ^^ ⋅ ^^ − ^^ ⋅ ^^) for all possible ephemeral public keys ^^. Since four possible ephemeral public keys ^^ may be derived, the recovery process can yield four valid public keys ^^ ^^ corresponding to the signature. However, the case of two possible coordinates ^^ _^ , ^^ _^ ′ for a single ^^ is very rare. This will happen with probability ^ି^ ~10 ^ିଷଽ which means that in practice the recovery process should yield two possible keys. 8. FURTHER REMARKS Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that 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. In preferred embodiments of the invention, 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). In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a “node” may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and/or propagate those blocks 151 to other nodes. Even more generally, 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. Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof- of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator. It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements. Statement 1. A computer-implemented method of attesting to knowledge of a first output being included in a first blockchain transaction, wherein the method is performed by a first party and comprises: generating a first attestation signature based on a first message, wherein the first message comprises a first outpoint of the first blockchain transaction and the first output of the first blockchain transaction, wherein the first output is locked to a first public key associated with the first party, and wherein the first attestation signature is generated using a first private key corresponding to the first public key; and causing the first attestation signature to be included in a second output of the first blockchain transaction. Statement 2. The method of claim 1, wherein the first message comprises a respective input index of the first outpoint and/or a respective output index of the first output. Statement 3. The method of claim 1 or claim 2, comprising: causing the first blockchain transaction to be submitted to one or more nodes of a blockchain network for inclusion in the blockchain. Statement 4. The method of any preceding claim, comprising: generating one or more additional respective attestation signatures based on respective messages, wherein the respective message comprises a respective outpoint of the first blockchain transaction and a respective output of the first blockchain transaction, wherein the respective output is locked to a respective public key associated with the first party, and wherein the respective attestation signature is generated using a respective private key corresponding to the respective public key; and causing the one or more respective attestation signatures to be included in the second output of the first blockchain transaction. Statement 5. The method of any preceding claim, comprising: generating a first signature based on a second message comprising the first output; and causing the first signature to be included in an input of the first blockchain transaction. Statement 6. The method of any preceding claim, wherein the first blockchain transaction comprises a third output locked to a second public key associated with a second party, wherein the first blockchain transaction comprises a fourth output comprising a second attestation signature attesting to knowledge of the third output by the second party and generated using a second private key corresponding to the second public key, and wherein the method comprises: generating a second signature based on a third message comprising all inputs of the first blockchain transaction and all outputs of the first blockchain transaction; and causing the second signature to be included in an input of the first blockchain transaction. Statement 7. The method of claim 6, comprising: verifying that the second attestation signature has been generated using the second private key corresponding to the second public key, wherein said generating of the second signature is conditional upon the second attestation signature having been generated using the second private key corresponding to the second public key. Statement 8. The method of claim 6 or claim 7, wherein the second output and the fourth output are a same output. Statement 9. The method of any preceding claim, wherein the second output includes one, some or all of: a protocol flag, the respective input index of the first outpoint, the respective output index of the first output. Statement 10. The method of any preceding claim, wherein the second output is a return output. Statement 11. The method of claim 6 or any claim dependent thereon, wherein the fourth output is a return output. Statement 12. A computer-implemented method of sending blockchain transactions to a first party, wherein the method is performed by a third party and comprises: obtaining a set of blockchain transactions, wherein a first subset of the set of blockchain transactions comprises respective transactions having a respective output locked to a respective public key associated with the first party; determining whether the first party has knowledge of a respective blockchain transaction of the first subset of blockchain transactions based on whether the respective blockchain transaction comprises a respective attestation signature generated based on a respective message, wherein the respective message comprises a respective outpoint of the respective blockchain transaction and a respective output of the respective blockchain transaction, wherein the respective output is locked to the respective public key associated with the first party; and sending, to the first party, only the respective blockchain transactions of the first subset of blockchain transactions of which it has been determined that the first party does not have knowledge. Statement 13. The method of claim 11, comprising: receiving a request, from a first party, for one or more respective blockchain transactions having a respective output locked to a respective public key associated with the first party, and wherein said determining is in response to said receiving of the request. Statement 14. The method of claim 12 or claim 13, wherein the third party comprises a blockchain node. Statement 15. The method of any of claims 12 to 14, wherein the set of blockchain transactions comprises a plurality of respective subsets, each subset comprising respective transactions each having a respective output locked to a respective public key associated with a respective party, and wherein the method comprises: determining whether the respective party has knowledge of a respective blockchain transaction of the respective subset of blockchain transactions based on whether the respective blockchain transaction comprises a respective attestation signature generated based on a respective message, wherein the respective message comprises a respective outpoint of the respective blockchain transaction and a respective output of the respective blockchain transaction, wherein the respective output is locked to the respective public key associated with the respective party; and sending, to the respective party, only the respective blockchain transactions of the respective subset of blockchain transactions of which it has been determined that the respective party does not have knowledge. Statement 16. 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 of claims 1 to 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 any of claims 1 to 15. According to another aspect disclosed herein, there may be provided a method comprising the actions of the first party and the second party. According to another aspect disclosed herein, there may be provided a system comprising the computer equipment of the first party and the second party. According to another aspect disclosed herein, there may be provided a method comprising the actions of the first party and the third party. According to another aspect disclosed herein, there may be provided a system comprising the computer equipment of the first party and the third party.