Deterrent blockchain transaction

Abstract

A computer-implemented method for generating a deterrent blockchain transaction. A first locking script defining an identity concealing public key, derived from an identity defining private key and derivation data using a derivation function, is provided. The first locking script is configured to: verify that a first signature provided in an unlocking script is generated using a first ephemeral key and the identity concealing private key; and verify that a first public key provided in the unlocking script matches the identity concealing public key. The identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature, generated using the first ephemeral key and the identity defining private key, of a second unlocking script. The identity defining private key is derivable from the identity concealing private key and the derivation data.

Description

[0001] BLOCKCHAIN TRANSACTION TECHNICAL FIELD The present disclosure relates to a computer-implemented method for generating a deterrent blockchain transaction, a computer-implemented method for generated a proof blockchain transaction, a computer-implemented method for determining an identity of a malicious user, and computer equipment and computer programs for implemented the methods. BACKGROUND Blockchain transactions are, amongst other things, a means to store and transfer value. For this reason, when the blockchain technology was invented one of the problems that had to be solved was that of double spending. That is, how is a user prevented from transferring the same UTXO to two different persons? The solution proposed was made of two parts. First, given any UTXO, every node in the blockchain network should consider only the first transaction they receive spending that UTXO as a valid transaction. This is known as the first seen rule. Second, by mining new blocks on top of the current blockchain, miners signal their acceptance of the history of the blockchain and thus will not accept transactions that spend inputs that have already been spent. This second part is known as the block confirmation mechanism. The first seen rule and the block confirmation mechanism prevent two transactions that spend the same input from being recorded in the blockchain, but it does not prevent a malicious party from attempting a double spend. Blockchain technology solves the problem of double spending without requiring the existence of a trusted third-party. Even though the blockchain will always record only one transaction spending a given input, malicious attackers can still attempt to double spend a UTXO in the time it takes to the network to validate a transaction and build enough confirmations, i.e., blocks, on top of it. If the attackers are successful in their attempt, by using the same UTXO they will convince two different people to offer them services, but only one of the service providers will cash in the funds. Even though anyone can attempt to double spend by using the same UTXO twice in different transactions, attempts can be made to disincentivise double spending attempts. That is, conditions can be created that discourage a malicious user from attempting to double spend. In previous work, collateral has been used to discourage double spending: the sender is required to post some collateral that, in case of double spending, will be claimed by the receiver. SUMMARY Herein, another disincentive is used to deter users from double spending: loss of reputation and identity disclosure. The idea stems from looking at interactions from a human-based point-of-view instead of a financial one. When people interact, trust is built among the parties, and cheating results in the foregoing of this trust. While in the real world the identity of cheaters is easily discovered once the trick is revealed, in the case of blockchain technology, even if someone cheats, their identity is protected by the layer of pseudonymity provided by the ability of using a different public key for every transaction they execute. Provided herein is a method of forcing users that attempt a double spend to disclose their identities, while at the same allowing honest users to carry on with their business with the same level of privacy offered by UTXOs with P2PKH locking scripts has previously been unknown. A blockchain exchange of using this method may be referred to as a reputation- based exchange, wherein the exposure of the identity of a double spender is revealed and their reputation tarnished. According to one aspect disclosed herein, there is provided a computer-implemented method for generating a deterrent blockchain transaction, the method comprising: providing a first locking script of the deterrent blockchain transaction, wherein the first locking script defines an identity concealing public key of an identity concealing public key- private key pair, wherein an identity concealing private key of the identity concealing public key-private key pair is derived from an identity defining private key and derivation data using a derivation function, wherein the first locking script is configured, when executed together with a first unlocking script of a proof blockchain transaction, to: verify that a first signature provided in the first unlocking script is generated using a first ephemeral key and the identity concealing private key; and verify that a first public key provided in the first unlocking script matches the identity concealing public key; and making the deterrent blockchain transaction available to one or more nodes of a blockchain network; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data. According to a second aspect disclosed herein, there is provided a computer-implemented method for generating a proof blockchain transaction, wherein an identity concealing private key is derived from an identity defining private key and derivation data using a derivation function, wherein the identity concealing private key and an identity concealing public key are an identity concealing public key-private key pair, the method comprising: providing a first unlocking script of the proof blockchain transaction, wherein the first unlocking script comprises: a first signature generated using a first ephemeral key and an identity concealing private key, wherein a first locking script of a deterrent blockchain transaction defines the identity concealing public key; and a first public key, wherein the first public key matches the identity concealing public key; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script of a second proof transaction, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data. According to a third aspect disclosed herein, there is provided a computer-implemented method of determining an identity of a malicious user, the method comprising: receiving an indication that a first output has been double spent; obtaining a first unlocking script configured to unlock a first locking script of a deterrent blockchain transaction, the first unlocking script comprises a first signature generated using a first ephemeral key and an identity concealing private key, and an identity concealing public key, wherein the identity concealing private key and the identity concealing public key are a public key-private key pair, wherein the identity concealing private key is derived from an identity defining private key and derivation data using a derivation function; obtaining a second unlocking script configured to unlock the first locking script of the deterrent blockchain transaction, wherein the second unlocking script comprises a second signature generated using the first ephemeral key and the identity concealing private key, and the identity concealing public key; deriving the identity concealing private key based on the identity concealing public key, the first signature, and the second signature; and deriving the identity defining private key from the identity concealing private key and the derivation data. According to a fourth aspect disclosed herein, there is provided 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 any of the methods disclosed herein. According to a fifth aspect disclosed herein, there is provided a computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform any of the methods disclosed herein. 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 3A shows a circuit representing the function ^^(^^, ^^) = ^^ + ^^;Figure 3B shows the procedure that turns a generic ^^ிinto Figure 4 provides an example method for implementing a reputation-based exchange; Figure 5 provides a first embodiment for identifying a double spender; Figure 6 provides a second embodiment for identifying a double spender; Figure 7 provides a third embodiment for identifying a double spender; Figure 8 provides a fourth embodiment for identifying a double spender; Figure 9 provides a fifth embodiment for identifying a double spender; Figure 10 provides a sixth embodiment for identifying a double spender; and Figure 11 illustrates a circuit for verifying a zero-knowledge proof of valid assignment. DETAILED DESCRIPTION OF EMBODIMENTS 1. PRELIMINARIES 1.1 Double Spending A user attempts a double spend if they create two transactions that share at least one input, they send both transactions to the network, and each transaction has a non-zero probability of being included in a block by an honest node. In practice, a user is attempting a double spend if they construct, sign, and broadcast two transactions that spend the same input to transfer a digital asset to different people. There is not presently a way to prevent a user from attempting a double spend (they can construct, sign, and broadcast any transaction they want). The problem to be solved can be formulated as how to disincentivise users from attempting a double spend. 1.2 Disincentive to Attempt a Double Spend: Reputation A real-world scenario in which Alice buys a newspaper from Bob every day is considered herein. As the days go by, the relationship between Alice and Bob gets stronger and trust is built between the two parties (if Alice pays with non-counterfeit money). If one day Alice tries to trick Bob into accepting counterfeit money, the trust Bob puts in Alice will be foregone, and the time Alice and Bob expended in building their relationship will have been wasted. Even if time is not valuable in nominal terms, i.e. a price cannot be put on time, foregoing a relationship of trust that took weeks, months, or years to build can and should be considered a huge loss for all the parties involved. This realisation can be turned on its head and used as a disincentive to malicious behaviour and double spending attempts. More precisely, to disincentivise users from attempting double spends, a system has been devised such that, if a double spend is attempted, then the other parties in the system are notified of the identity of the malicious user. This will prevent the malicious user from taking part in other exchanges, or at least put all their exchanges under further scrutiny from the other members of the community. In this way, a user that attempts a double spend will face disruption in their operations, be it business or daily life. The problem with this approach when considered in the context of blockchain technology is that the identities of the parties interacting in a transaction are not known. Therefore, there is a need to devise a way to force a user to reveal their identity if they attempt a double spend. 1.3 Disincentive to Attempt a Double Spend: Collateral If Alice attempts a double spend at the cost of Bob and Charlie, the possible outcomes are that either the double spend is not successful, e.g., Bob is notified of the double spend attempt and refuses the payment, or that it is successful and either Bob or Charlie is unpaid for the service they provided. The problem is that Alice never risks losing anything from a double spending attempt. Herein, the concept of a requirement for Alice to put something at stake that she might lose if she were to attempt a double spend is explored. In other words, Alice has to post collateral for the exchange she wishes to perform, and this collateral is claimable from Bob and Charlie. The idea of posting collateral to safeguard parties receiving the UTXO, for example a merchant or other payment receiving party, from double spending attempts has been considered previously. Herein, instead, the focus is on the reputation-based disincentive. 1.4 Commit to r: Force Secret Key Disclosure A Fixed-^^ Pay-to-Public-Key (FR-P2PK) type transaction output has previously been introduced. FR-P2PK forces a user to reveal their private key in the case of a double spend attempt. The mathematical idea behind FR-P2PK is set out below. In blockchain technology, the most common way to prove ownership of UTXOs is via the Elliptic Curve Digital Signature Algorithm (ECDSA). More precisely, in the locking script of the UTXO there is an OP_CHECKSIG opcode that to be executed correctly requires a public key and a valid signature (the message to be signed is a digest of transaction data). The public keys used are points on the elliptic curve secp256k1. When a user Bob wants to receive a payment, they create a private key ^^ and generate theassociated public key ^^ = ^^^^, where ^^ is the generator of the elliptic curve. Then, theyshare the public key, and Alice, the sender of the payment, locks the UTXO with the following script: OP_DUP OP_HASH256 <^^(^^)> OP_EQUALVERIFY OP_CHECKSIG To spend the UTXO, Bob must produce the following answer to the locking script: <^^^^^^> <^^> Here, ^^^^^^ is the signature of a message digest ^^ with the private key ^^. Mathematically, the signature ^^^^^^ is constructed from the message digest ^^ as follows: 1. Generate a random ephemeral key ^^ ∈ {1, … , ^^ − 1}, where ^^ is the order ofthe group associated with the elliptic curve. 2. Compute ^^ = ^^^^; if ^^ = ^^௫ = 0 ^^^^^^ ^^, go back to 1.3. Compute ^^ = ^^ି^(^^ + ^^^^) ^^^^^^ ^^; if ^^ = 0 ^^^^^^ ^^, go back to 1.4. Output ^^^^^^ = (^^, ^^)The signature algorithm has a known vulnerability: if two different messages are signed(^^, ^^ᇱ such that ^^ ≠ ^^′) with the same ephemeral key ^^, then the private key ^^ can berecovered:^^^^ᇱ − ^^ᇱ^^ି^ ^^ + ^^^^ ^^ᇱ ^^ି^ ^^ᇱ ^^^^ ^^ ^^ᇱ ^^^^ = ( ) ^^^^) = ^^ᇱ(^^ + ^^^^) ⇒ ^^ = (^^ᇱ − ^^)^^Exploiting the above vulnerability a user can be forced to disclose their private key if they attempt a double spend. The way to do it is as follows. When Alice wants to pay Bob, she does so by spending a UTXO whose locking script is the following: [lockingScript]:= OP_OVER OP_SWAP OP_DUP OP_HASH256 <^^(^^)> OP_EQUALVERIFY OP_CHECKSIGVERIFY [checkR(^^)] [checkR(^^)]:= OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP <^^> OP_EQUALHere, ^^ = ^^௫ is the x-coordinate of the point ^^ = ^^^^, where ^^ ∈ {1, … , ^^ − 1} is a randomnumber chosen by Alice. When Bob sees that the UTXO Alice is using has the above locking script, he knows that if Alice double spends the UTXO, then [checkR(^^)] will force her sign two different transactions using the same ephemeral key. Indeed, the solution to [lockingScript] is: [unlockingScript] := <^^^^^^> <^^> Where ^^^^^^ is a signature generated with private key equal to the private key associated to ^^ and with ephemeral key equal to ^^. Hence, Bob knows that if Alice double spends, he will be able to calculate her private key based on the unlocking scripts of the two transactions attempting to spend the same UTXO. When constructing commit-to-^^ locking scripts, that is, scripts as the locking script above, it is important that the party who spends the UTXO is the one to choose the ephemeral key that generates the point ^^. Indeed, if the receiver chooses ^^, then as soon as the sender spends the UTXO (before any double spending is attempted) the receiver can compute theprivate key of the sender as ^^ = where ^^^^^^ = (^^, ^^) is the signature used to unlockthe UTXO. In the following,[checkR(^^)] refers to the script above. Depending on where [checkR(^^)] appears in the locking script, OP_EQUAL might be replaced with OP_EQUALVERIFY. 1.5 Commitment Schemes A commitment scheme is a protocol that allows a user to commit to some data without revealing the data itself. In this way, the user retains ownership of their data and at the same time can convince third parties that they will not change the data later. More formally:Definition: A commitment scheme is a triple (^^^^^^^^^^^^^^^^, ^^^^^^^^, ^^^^^^) of algorithms suchthat:1. ^^^^ = ^^^^^^^^^^^^^^^^(^^): given a security parameter ^^ as input, the GENeratePARAMeter algorithm returns the public parameters ^^^^ of the commitment scheme. 2. ^^ = ^^^^^^^^(^^, ^^, ^^^^): given a message, a random value ^^ and the publicparameters, the COMMitment function returns the commitment of ^^ according to ^^. 3. ^^^^^^(^^, ^^, ^^, ^^^^) ∈ {0,1}: given a message ^^, a value ^^ and a commitment ^^,the function VERify returns the logical value corresponding to the equality^^ =?^^^^^^^^(^^, ^^, ^^^^).In the following, when a commitment scheme is considered, is it assumed that the publicparameters have been set and published. Thus, from brevity, ^^^^^^^^(^^, ^^) is writteninstead of ^^^^^^^^(^^, ^^, ^^^^).Definition: A commitment scheme is said to be: •Hiding if it is infeasible to obtain any information about ^^ from ^^^^^^^^(^^, ^^).• Binding if it is infeasible, given ^^^^^^^^(^^, ^^), to find ^^ᇱ ≠ ^^ and ^^ᇱ ≠ ^^ suchthat ^^^^^^^^(^^, ^^) = ^^^^^^^^(^^ᇱ, ^^ᇱ).1.5.1 Pedersen’s Commitments Pedersen’s commitment scheme is instantiated using cyclic groups in which the Discrete Logarithm Problem (DLP) is assumed to be hard. Pedersen’s commitments are both hiding and binding.Let ^^^ be a cyclic group of prime order ^^ with two independent generators ^^, ^^ ∈ ^^^. Hereindependent generators means that they are drawn uniformly at random from elements of^^^ and that the random variables associated to this sampling operation are uncorrelated.Then, given a message ^^ ∈ ℤ^ and a random ^^ ∈ ℤ^, the Pedersen’s commitment of ^^according to ^^ is ^^^^^^^^(^^, ^^) ≔ ^^^^ + ^^^^.1.5.2 Hashing A hash function is a one-way function, that is, it is a deterministic function that is assumed to be infeasible to invert. Because of this property, hash functions can be used to construct commitment schemes. Indeed, if ^^ is a hash function, then ^^(^^) is a commitment to ^^ for every message ^^. 1.6 Zero-Knowledge Proofs In this section, Zero-Knowledge Proofs (ZKP) are introduced. In a nutshell, a ZKP is a protocol that a prover enacts to prove to a verifier the validity of a statement without revealing any information to the verifier except that the statement is true or false. Their appeal is clear, they allow the prover to retain ownership of their data while at the same time proving the validity of their claims to others.A special type of ZKP is focused on, called Sigma protocols. Let ℛ ⊂ {0,1}∗ × {0,1}∗ be abinary relation. A couple (^^^^, ^^) ∈ ℛ is called the couple of a statement and a witness.Validity of a statement means that ^^^^ ∈ {0,1}∗ and that there exists ^^ such that (^^^^, ^^) ∈ℛ. A prover will want to prove to a verifier that they know a witness ^^ such that (^^^^, ^^) ∈ℛ without revealing ^^.A sigma protocol for a relation ℛ is a three-move protocol between a prover P and a verifier V in which: 1. The prover commits to some randomness ^^ via ^^. 2. The verifier samples a random challenge ^^. 3. According to ^^ and ^^ the prover computes a solution ^^. 4. Based on (^^, ^^, ^^) the verifier accepts or rejects the proof.Sigma protocols must be complete: an honest prover can always convince a verifier of the validity of a true statement; sound: for statement ^^^^, a fixed commitment ^^ and twodifferent challenges ^^, ^^′ and valid solutions ^^, ^^ᇱ, there is a way to extract the witness ^^such that (^^^^, ^^) ∈ ℛ; zero-knowledge: the verifier does not learn anything more from theinteraction than the validity (or invalidity) of the statement ^^^^. 1.6.1 ZKP to Prove Multiplicative Link Between Two Private Keys In this section, the following situation is considered: users Alice and Bob are interacting, Bob shows two public keys to Alice and he wants to prove to her, in zero-knowledge, that the private keys of these two public keys are related.More precisely, Bob chooses two private keys ^^^, ^^ଶ and computes ^^^ = ^^^^^, ^^ = 1,2, and^^^^ = ^^ଶ^^ ^^ି ^^^^^^ ^^, where ^^ is the order of the group associated to the elliptic curve. Heshows ^^^, ^^ଶ and ^^^^ to Alice and he wants to prove the following statement: “If you know ^^^^and the private key ^^^ associated to ^^^, you can compute the private associated to ^^ଶ as^^^^ ⋅ ^^^ ^^^^^^ ^^”. He does so with the following protocol:1. Bob chooses a random ^^ and sends ^^ = ^^^^ to Alice.2. Alice chooses a random challenge ^^ and sends it to Bob. 3. Bob sends ^^ = ^^^^^ + ^^ to Alice.4. Alice checks that ^^^^ = ^^^^^ + ^^ and that (^^ ⋅ ^^^^)^^ = ^^^^ଶ + (^^^^)^^. If so, Bobaccepts the proof as valid. Otherwise, he rejects the proof. This has previously been proved to be a ZKP. 1.6.2 ZKP from Arithmetic Circuits Arithmetic circuits are acyclic, directed graphs where each node has at most two edges coming in and at most one edge coming out. Internal nodes, that is, those with edges coming in and edges coming out, are labelled + or × depending on whether they are addition or multiplication nodes (see later for why they are named in this way). Nodes arealso called gates and edges are also called wires. Let us write ^^ = (^^, ^^) to denote the gates(nodes) and wires (edges), respectively, of the circuit.Definition: A valid assignment for a circuit ^^ = (^^, ^^) is a collection of values {^^^}^∈ா, onefor each wire in the circuit, such that the values satisfy the mathematical relations definedby the gates of the circuit. That is, if there are edges ^^^^, ^^^^, ^^^௧ connecting node ^^ to node^^, node ^^ to node ^^ and node ^^ to node ^^, and ^^^^, ^^^^, ^^^௧ are the values corresponding to^^^^, ^^^^, ^^^௧, respectively, then:• If node ^^ is an addition node, then ^^^^ + ^^^^ = ^^^௧.• If node ^^ is a multiplication node, then ^^^^^^^^ = ^^^௧.Any polynomial function can be represented as an arithmetic circuit. The number of inputs of the function equals the number of nodes in the circuit that have no incoming edges, while the number of outputs of the function equal the number of nodes in the circuit that have no outgoing edges. For this reason, we call the values of a valid assignment corresponding to nodes without incoming edges the inputs of the circuit, and the values corresponding to nodes without outgoing edges the outputs of the circuit. The circuit shown in Figure 3Arepresents the function ^^(^^, ^^) = ^^ + ^^.Any function executable on a computer can be represented as an arithmetic circuit. Indeed, any function executable a computer can be represented as a sequence of logical NAND gates (bit operation that is false if and only if all its inputs are true), and a NAND gate can bewritten as an arithmetic circuit as follows: given ^^, ^^ ∈ {0,1}, compute ^^^^^^^^(^^, ^^) = 1 −^^^^^^(^^, ^^) = 1 − ^^^^. By combining multiple NAND circuits as above, any functionexecutable on a computer (or, equivalently, computable by a processor) can be represented. Notice that any such function is bounded, i.e., there is an upper bound on its execution time. This is because even if loops have range depending on some input, the number of iterations can be bounded by looking at the bit length of the input. Notice that it is assumed that inputs in binary format are passed to the function. The knowledge of a valid assignment to an arithmetic circuit can be provide in zero-knowledge. For the rest of this discussion, an arithmetic circuit ^^ = (^^, ^^) and a finite field^^ are fixed. For simplicity, it is assumed that the wires in the circuits are numbered from 1to ^^.Let {^^^}^ୀ^,…,^ be a valid assignment for ^^. The ^^^’s are divided into public inputs ^^^^ =(^^^, … , ^^^), that is, the ones that can be shown to a verifier, and private inputs ^^ =(^^^ା^, … , ^^^), the ones which are kept hidden from the verifier. Then, valid assignmentsdefine a relation:^^^ ^^^^ ^^ valid assignment to ^^} Here the public inputs are the statements, and the private inputs are the witnesses. Hence, arithmetic circuits give rise to relations that can be put into the framework of sigma protocols.The example to keep in mind is the following: take a function with ^^ inputs ^^(^^^, … , ^^^)and assume we wish to prove the statement ‘I know input values such that ^^ =^^(^^^, … , ^^^)’. Then, we construct the circuit associated to ^^ and we show to a verifier… ^^ but we keep ^^^ secret. Then, proving the statement is equivalent to prove that we know a witness for relation ℛ where ^^^^ = (^^^, … , ^^^ି^, … , ^^), and this can be donewith sigma protocols, as we will see shortly. 1.6.2.1 Groth 16 The general idea to produce a ZKP for a valid assignment to an arithmetic circuit is to encode the circuit as a Quadratic Arithmetic Programme (QAP), i.e., a system of polynomial equations, and transform the knowledge of a valid assignment into a divisibility statement. When the circuit is constructed, a series of public parameters is set up; these public parameters are specific to the circuit, which implies that they must be recalculated anew for every circuit. Most importantly, the link between the circuit and the public parameters ensures to the parties involved in the ZKP that the valid assignment they see is for circuit ^^. This means that even if the verifier does not see the computations carried out by the circuit, they know what those computations are. Herein, the method introduced by Groth to produce ZKP for valid assignments to arithmetic circuits is used. One of strengths of this method is that, regardless of the circuit size, the proof has constant size. This is very important to avoid overloading the network and to avoid the assumption of high bandwidth. It is worth remarking that the techniques require the use of bilinear pairings, and thus one is forced to work with pairing-friendly elliptic curves, and secp256k1 is not pairing-friendly. 1.6.2.2 ZK Key-Statement-Proofs (ZKKSP) Another way to produce a ZKP of a valid assignment to an arithmetic circuit will now be explained. While in general this technique requires more data to be exchanged between the prover and the verifier, it is very efficient when among the statements to be proved thereare some of the form ‘Check that ^^ = ^^^^’. Such statements are what we call keystatements. Let ^^^be a cyclic group of prime order ^^ where the DLP is assumed to be hard. ^^^is used to construct Pedersen’s commitments, see § 1.5.1. Assume that a prover P and a verifier V share a circuit ^^ and P wants to prove to V that they have a valid assignment for ^^. They can do so in zero-knowledge as follows: 1. For every wire ^^ in ^^, P constructs a Pedersen’s commitment to ^^^: they choose a random ^^^ and set ^^^ ≔ ^^^^^^^^(^^^, ^^^) = ^^^^^ + ^^^^^.2. P shares {^^^} with V. 3. P and V engage in either ZKP a) or ZKP b) below for every node in ^^ according to whether it is an addition or multiplication node. 4. If all the ZKP proofs are carried out correctly, then V is satisfied that P knows a valid assignment for ^^ Here are the two ZKPs: a) ZKP for addition gates: the statement to be proved is ^^^ + ^^^ = ^^^, commoninputs to P and V are {^^^ = ^^^^^^^^(^^^, ^^^)}. P and V proceed as follows:i. P choses a commitment to 0 by sampling a random ^^ They share ^^ = ^^^^^^^^(0, ^^) with V.ii. V samples a random challenge ^̃^ ∈ ℤ^ and sends it to P.iii. P computes ^^ ^^ sends it to V. iv. V checks that ^^^^ = + ^^, if so, the proof V accepts the proof. b) ZKP for multiplication gates: the statement to be proved is ^^^^^^ = ^^^,common inputs to P and V are {^^^ = ^^^^^^^^(^^^, ^^^)}. P and V proceed asfollows:i. P sample five random values ^^^, ^^ଶ, ^^ଷ, ^^ସ, ^^ହ ∈ ii. P computes ^^^ ^^^^^^ ^^^^^^ ^^^^^^ ^^ସ^^ and sends them to V.iii. V samples a random challenge ^̃^ ∈ ℤ^ and sends it to P.iv. P computes and shares with V the following values:^^^ = ^̃^^^^ ^^^ = ^̃^^^^ ^^^ = ^̃^^^^ = ^̃^^^^ ^^ହ ^^ଷ = − ^^^^^^൯ + ^^ସv. V checks that^^^^^^^^(^^^, ^^^) = ^̃^^^^ + ^^^ ^^^^^^^^(^^ଶ, ^^ଶ)= ^̃^^^^ ^^^^^^ = ^̃^^^^ and if so, they accept At the end of the ZKP, P might open the commitments of some of the outputs and / or some of the inputs to show that the valid assignment satisfies some required property. The inputs whose commitments are opened at the end of the protocol are the public inputs of § 1.6.2. All the other ones are the private inputs. Assume that the circuit ^^ has ^^ wires, ^^ addition gates and ^^ multiplication gates. Then: 1. P shares ^^ commitments with V. 2. For each addition gate, P and V share with each other an element ^^ ∈ ^^^and two elements ^^, ^̃^ ∈ ℤ^.3. For each multiplication gate, P and V share with each other three elements^^^, ^^ଶ, ^^ଷ ∈ ^^^ and eleven elements Hence, the ZKP for circuit ^^, if elements of ^^^are ^^^^bytes long and elements of are byte long, requires the sharing of^^^^^^ + ^^(2^^ℤ + ^^^^) + ^^(11^^ℤ + 3^^^^)bytes of data. To put it into numbers, if ^^^^ = ^^ℤ = 32 and the circuit has one addition andone multiplication gate, then the ZKP requires the sharing of7 ⋅ 32 + 2 ⋅ 32 + 32 + 11 ⋅ 32 + 3 ⋅ 32 = 24 ⋅ 32 = 768 Bytes of data (we are considering 7 wires). The ZKP proves that the relations of the arithmetic circuit hold over ^^^, not over theintegers. This is because the validity of relations of the form ^^^^ = ^^^^ are proven, whichimplies ^^ = ^^ ^^^^^^ ^^ as ^^ is a generator.The ZKP constructed from the arithmetic circuit can be leveraged to prove key statement. This is best done with an example. Assume that P knows the valid assignment to ^^ and that he wants to prove that ^^^is the private key of some ^^^. Then, at the end of the ZKP, P couldsimply share ^^^, the randomness in ^^^^^^^^(^^^, ^^^), and V could check that ^^^^^^^^(^^^, ^^^) −^^^^^ = ^^^. If so, they know that ^^^ is the private key of ^^^. This is because ^^^ = logு(^^^^^^^^(^^^, ^^^) − ^^^), the DLP is assumed to be hard, and ^^, ^^ are assumed to beindependent. This strategy can be used to construct ZK Key-Statement-Proofs. These proofs leverage Pedersen’s commitments to reduce the size of the circuit at the expense of increasing the amount of data that must be shared between prover and verifier. Indeed, the circuit doesnot have to check key statements ^^ = ^^^^, because this is done via the commitment, but Pmust share more points on the elliptic curve. 1.6.3 From ZKP to NIZKP The ZKPs we talked about above require an interaction between the prover and the verifier. This implies that the prover must interact with each verifier to which they want to prove the validity of statement ^^^^. It would be preferable to be able to relax this assumption, so that the prover does not have to be online every time someone wants to verify the validity of ^^^^. There exist two strategies to transform a ZKP into a Non-Interactive ZKP (NIZKP). They are the Fiat – Shamir heuristic and the Fischlin’s transform. Here, the underlying ideas of these strategies are presented. The Fiat – Shamir heuristic relies on random oracles, that is, functions that are assumed to produce truly random outputs. For practical purposes, hash functions with a big enough image space are considered oracles. Then, Fiat and Shamir propose to replace the challenge of the verifier with the image, via a hash function, of the random commitment chosen by the prover (together with possibly some other data). As the hash function is assumed to be a random oracle, this image is equivalent to a challenge sent by a verifier, and the proof does not require interaction anymore. The Fischiln’s transform takes a different approach and leverages the special soundness property: if for a fixed commitment two answers to two different challenges are produced, then the secret can be computed. Then, the idea is to require the prover to show proof of work by computing solutions to various challenges with fixed commitments and requiring that these solutions satisfy specific properties. As carrying out the PoW implies that more than one solution has been computed, by the special soundness property we know that the prover knows the secret, and no interaction is needed to obtain this certainty. 1.6.4 Designated Verifier NIZKP are particularly handy because a prover can construct a single ZKP and share it with multiple parties without having to engage in multiple protocols. However, as the prover can replay the NIZKP, so can the verifiers to which the prover has sent the transcript of the NIZKP. This is not always something the prover might be happy with; thus, a method to ensure that a NIZKP transcript cannot be replayed by the verifier for which it is intended is needed. The solution to this problem is called Designated Verifier (DV). That is, the statement to be proved is changed so that a verifier V with a NIZKP transcript from prover P can produce transcripts that look like they have been constructed by P but that prove validity of arbitrary statements. The strategy to achieve this depends on whether a ZKP is turned into a NIZKP using either the Fiat – Shamir heuristic or the Fischilin’s transform. Below, it is assumed that any NIZKP can be turned into a Designated Verifier ZKP (DVZKP). Notice that in the name it is not stressed the non-interactivity of the proof because it is implied by the DV. 1.6.5 How to Turn Arithmetic Circuits into DVZKP As was seen in § 1.6.2, knowledge of a valid assignment for a circuit ^^ can be proved in zero- knowledge. In this subsection, it is shown how to modify an arithmetic circuit so that the ZKP of a valid assignment is a DVZKP. The idea is to modify the circuit so that a valid assignment proves either that some function has some given output or that the prover knows a certain secret key. The knowledge of a valid assignment for a circuit ^^ிcan always be rephrased into theknowledge of a valid assignment for a logical circuit ^^^^ி with output equal to 1. Indeed, if^^ = ^^ … , ^^^) is the function computed by circuit ^^ி and {^^^}^ୀ^,…,^ is a valid assignmentfor ^^ி, where ^^^, … , ^^^ are the inputs of the circuit and ^^ = ^^^ is the output, then {^^^} ∪{1} can be relabelled to a valid assignment with output 1 for the circuit ^^^^ி = ^^ிᇲassociated to the function ^^ᇱ(^^^, … , ^^^, ^^) = [^^(^^^, … , ^^^) == ^^]. Figure 3B shows theprocedure that turns a generic ^^ிinto ^^ி^^.Let a cyclic group ^^^ of order ^^ where the DLP be assumed to be hard and let ^^ ∈ ^^^ be agenerator.Definition: Let ^^^^^ be the arithmetic circuit for the function ^^(^^, ^^) = [^^^^ == ^^], that is,the circuit that takes as input a variable ^^ ∈ ℤ^ and a point ^^ ∈ ^^^ and outputs 0 or 1depending on whether ^^ is the private key associated to ^^. The input ^^ is private, while the input ^^ is public.Given any circuit ^^ with a logical output, let us write ^^^^ = ^^ | for the circuit whose output is the result of the of the OR operation applied to the of ^^^^and ^^^^^.Example: If ^^ is the circuit for the function ^^ᇱ(^^, ^^) = [^^ == ^^], then ^^^^ is the circuit forthe function ^^ᇱᇱ(^^, ^^, ^^, ^^) = [^^ == ^^ ^^^^ ^^^^ == ^^].Given the above definitions, any ZKP for an arithmetic circuit ^^ can be turned into a DVZKP as follows:1. Turn the circuit into a logical circuit ^^^^ by adding the output variable, i.e., if^^ = ^^ , th ^^ ᇱி e ^^ ^^ 2. Join the circuit from step 1 with the circuit ^^^^^via an OR operation to obtain^^^^.Indeed, a valid assignment to the circuit ^^^^ with output 1 is an assignment where either^^(^^^, … , ^^^) = ^^ OR ^^ = ^^^^. Hence, anyone with the knowledge of ^^ can produce a ZKP ofsuch a valid assignment and third parties will not trust transcripts unless they have provided^^.More precisely, the interaction would work as follows: a. V sends to P a public key ^^ of which they only know the private key. b. P constructs a NIZKP for the circuit ^^^^with public key for ^^^^^equal to ^^ and sends it to V. Any party that is not V will not trust a transcript of the NIZKP because they are not the ones that have chosen the private key for ^^ and thus the transcript might be proving the validityof ^^ = ^^^^ rather than ^^(^^^, … , ^^^) = ^^. If private keys are considered as identities andpublic keys as pseudonyms, then a valid assignment to the circuit ^^^^ above proves ‘Either^^(^^^, … , ^^^) = ^^ OR I am the person with pseudonym ^^’.1.7 Certification Authority One of the strengths of the blockchain technology is that it allows parties to exchange funds without the need to disclose their identities: the only thing they need is a pseudonym, i.e., a public key, where they would like they receive the funds. However, the focus of this white paper is to construct an exchange where users are disincentivised from attempting a double spend via loss of reputation. This is only implementable if users have an identity which is linked to their payments. The problems of getting one’s identity certified and of proving one’s identity is certified are non-trivial ones. One of the reasons is that as soon as certificates are issued, the need of a blacklist of invalid certificates arises, thus requiring the existence of a revocation authority as well. Many systems have been designed to implement this structure and thus we will not deal explicitly with these problems. A Certification Authority (CA) interacts with users to certify their identities. User Alice has a physical identity ^^^^^^௬^,^and a network identity; the network identity ismade up of a couple (^^^, ^^^) of a private key ^^^ and a public key ^^^. Alice can share herpublic key ^^^, which is a pseudonym for Alice, without fearing that her private key ^^^isrevealed. When a CA certifies Alice’s physical identity, they issue (or agree on) a couple(^^^, ^^^) that from that moment onward is Alice’s network identity. As only the person withphysical identity ^^^^^^௬^,^is supposed to know ^^^, knowledge of ^^^is equivalent to being Alice, and it makes sense to call ^^^the identity of A. The equivalence between knowing ^^^and being the person ^^^^^^௬^,^only holds until ^^^is kept secret, which is why we need a revocation authority.Herein, Alice’s identity refers to a couple (^^^, ^^^) that has been certified by a CA, and thephrase Alice’s identity has been revealed means that the private key ^^^has been revealed.The certification of (^^^, ^^^) is issued in the form of a certificate (e.g., X.509 standard) thateither contains ^^^or a commitment to ^^^. The reason why the certificate might contain a commitment to ^^^instead of ^^^itself is that parties might want to exchange funds without revealing their pseudonyms. Alice and a CA may interact in the following way: 1. User Alice generates (^^^, ^^^) and proves to the CA with a DVZKP that sheknows ^^^for ^^^. 2. User Alice commits to ^^^(e.g., via Pedersen’s commitments) and shares the commitment ^^௩with the CA. Alice also shows that the commitment opens to^^^.3. The CA verifies Alice’s identity and that ^^௩opens to ^^^. 4. Alice commits to ^^௩with ^^ (e.g, via hashing). She shares with the CA a DVZKP that ^^ opens to ^^௩. 5. If the CA is satisfied with all the previous steps, they sign ^^ with their private key and issue the certificate (^^௩, ^^, ^^^^^^).Now, when Alice wants to prove to Bob she has a certified identity she proceeds as follows: a) Alice generates a DVZKP for Bob that proves that ^^ is the commitment of ^^௩. b) Alice shows to Bob that ^^௩opens to ^^^. c) Alice proves to Bob with a DVZKP that she knows the secret key of ^^^. d) Bob verifies the signature of the CA. Here, the use of DVZKPs is fundamental to prevent Bob from being able to prove to other people that he interacted with Alice. Also, Step 2 and 3 require Alice to disclose her pseudonym. This is because the statement proven by a), b), c) and d) above is ‘I am the person with pseudonym ^^^and this pseudonym has been certified by the CA’. If steps b) and c) are removed, the proof would prove ‘I am in possession of a certification by the CA of some identity’, but there would be no link between me and the certified identity. In § 2.2, steps b) and c) are removed, so that Alice’s pseudonym remains secret, and embed the linkbetween Alice and the identity certified by (^^, ^^௩, ^^^^^^) in a different ZKP.2. REPUTATION-BASED EXCHANGES In this section, a reputation-based exchange is constructed. The problems to be solved are those of provably linking a UTXO to the identity of a user, while permitting honest users to maintain their pseudonymity and catching out dishonest users. This is achieved using key derivation statements, that is, a ZKP that a key is derived from another one. These ZKPs are turned into DVZKPs so that Alice can disclose her pseudonym to whoever she wishes to, but the counterparty cannot prove they interacted with Alice. In the examples set out below, it is assumed that the sender of the funds constructs a UTXO that forces identity disclosure if double spent, and that the sender proves to the receiver the correctness of the data in this UTXO. However, this not necessarily the case. If the sender of the funds wishes to be sure that the receiver will not attempt a double spend, the protocol can be run from the point of view of the receiver: they will construct the ZKPs and the keys to which the payment will be made. The sender will then be the verifier and check that all the data is correct. The protocols can leverage two different types of zero-knowledge proofs: zkSNARKs and Zero-Knowledge Key-Statement Proofs (ZKKSPs). The use of zkSNARKs allows for more flexibility in what data users must exchange to complete a transaction in a reputation-based exchange, while ZKKSPs allows for devising a simpler framework at the expense of requesting the users to share their pseudonyms. 2.1 Defining a Reputation-Based Exchange The reputation-based exchange provided herein disincentivises users from attempting a double spend with the threat of identity disclosure. The aim is easier explained than achieved. In blockchain technology, one of the levels of privacy is granted using pseudonyms for receiving and sending payments. These pseudonyms are the public keys to which cryptocurrencies are sent, or more generally to which UTXOs are transferred. The ability to choose a random pseudonym for every single payment not only ensures that people do not know who we are, it also ensures that spending habits cannot be traced by searching for the transactions that contain a specific public key. When devising a reputation-based exchange, there is the challenge of having to provably link a UTXO to the identity of a user, while at the same time ensuring that for honest users the link can be checked only if the user wishes that to happen, and for dishonest ones the link is visible to all. For example, a UTXO could be linked to the public key ^^^of Alice, whichis part of the certified identity (^^^, ^^^). However, this is not desirable because it wouldreveal the payment was directed to Alice.As a slight modification of the above idea, the UTXO could be linked to ^^^+ ^^^^, where ^^ ∈^is a number drawn uniformly at random. Then, the UTXO is provably linked to Alice, but no one can tell unless Alice provides them with ^^. However, it must be ensured that if Alice double spends the UTXO, then her identity is revealed. Alice could be forced to commit to a certain ephemeral key as in § 1.4, so that if sheattempts to double spend, then ^^^ + ^^ is revealed, but then we would still need Alice toreveal ^^ to catch her out. A solution could be to place ^^ in the transaction as well, but if either ^^ or ^^^^ appears in the locking script, then anyone can work out ^^^.Notice that the situation is even more complicated than this. Indeed, even if put both ^^^ +^^^^ and ^^^^ in a P2PKH script, ^^^ would not be revealed when the UTXO is created, butAlice would have to reveal ^^^^ when she spends the UTXO for the first time, thus revealing her pseudonym ^^^. The problem is to allow Alice to disclose her pseudonym only to whoever she wishes to, and at the same time force her to disclose her identity when she attempts a double spend. The solution provided herein is to use key derivation statements. Here and in the following, the term exchange is used to mean a network of users who transact with each other. The way users transfer value between each other’s accounts is via transactions. For example, let Alice and Bob be two users interacting in an exchange. The exchange is considered a reputation-based exchange if: 1. When Alice and Bob interact, they either not reveal their pseudonyms, i.e., their public keys, to each other, or if they do neither must retain proof of the pseudonyms that they can replay to third parties. (Flexibility in information disclosure) 2. When Bob receives a payment from Alice, he is free to choose a different address for every payment. Similarly, Alice can send payments from any address she wants. (Spending habits are not traceable) 3. Bob knows a protocol that forces Alice to reveal her identity (private key) if she double spends a UTXO she used as input in a transaction directed to Bob. (Identity disclosure for dishonest users) Point 1 of the above definition is the reason why Alice’s private key is defined to be her identity. In a reputation-based exchange, something is needed that each user keeps secret and whose revelation triggers a loss of trust in the user. This secret value is what we call a user’s identity. If ^^^were used as Alice’s identity, then Alice would always need to hide it from Bob, as otherwise he could tell everyone he interacted with Alice and that Alice is not to be trusted (he knows her identity, so Alice must have cheated somewhere). However, there are situations in which Alice might want to interact with Bob using the same pseudonym, so that trust is built between Alice and Bob, but no third party knows about it. To achieve this level of flexibility, the private key ^^^is taken to be Alice’s identity. 2.2 ZKP for Key DerivationA user Alice has a private key ^^^ and wants to prove that some key ^^ has been derived from^^^, i.e., ^^ = ^^(^^^) for some function ^^.ZKPs are developed to prove key derivation according to the BIP-32 standard, as is known in the art. The idea is to use arithmetic circuits. That is, once the derivation function ^^ is fixed, an arithmetic circuit is constructed that computes it, and then the knowledge of a valid assignment is turned into a ZKP.Considering the following derivation function: ^^(^^, ^^) = ^^ ⊕ ^^. Here, ^^, ^^ ∈ ℤ^, ^^ ≠ 0,where ^^ is the order of the elliptic curve group in the blockchain specification, and ^^ = ^^^^.Then, considering the circuit ^^^ைோassociated to the following function: ^^(^^, ^^, ^^) =• Compute ^^^^^^^ ≔ ^^^^.• Check ^^^^^^^ == ^^.• Compute ^^^^^^ଶ ≔ ^^ ⊕ ^^.• Compute ^^^^^^ଷ ≔ ^^^^^^ଶ^^.• Compute ^^^^^^ସ ≔ ^^^^.Output ^^^^^^ଷ, ^^^^^^ସ. Notice that ‘check’ operations in arithmetic circuits can be implemented either by adding a further output given by the result of the equality check (if inputs are in binary format, take pairwise AND of the bits of the two numbers and then the AND of the results) or by converting the circuit into its logical version and taking an AND of all the results at the end. The circuit ^^^ைோtakes: •two secret inputs ^^, ^^• one public input ^^.Notice that the inputs of a valid assignment to the circuit ^^^ைோ with output ^^^, ^^ଶ are givenby a triple (^^, ^^, ^^) where ^^^ = (^^ ⊕ ^^)^^, ^^ଶ = ^^^^ and ^^ = ^^^^. Thus, using thetechniques explained in § 1.6.2, a user Alice can turn the knowledge of a valid assignment to^^^ைோ with output ^^^, ^^ଶ into a ZKP for the statement ‘The private key of ^^^ is equal to ^^^,the private key of ^^ଶ is ^^ଶ, and it holds that ^^ଶ = ^^ and ^^^ = ^^ ⊕ ^^, where ^^ is the privatekey of ^^’. Instead of passing ^^ as a public input, we could pass it as a private input and pass a commitment to it as a public input. Then, we check inside the function that defines the circuit that the commitment provided is correct. In this way, no public information is leaked during the proof. We implement this idea by constructing the circuit ^^⊕associated to the following function (here ^^^^^^^^ is the data needed to compute the commitment): ^^(^^, ^^, ^^, ^^, ^^^^^^^^) =• Compute ^^^^^^^ ≔ ^^^^.• Check ^^^^^^^ == ^^.• Compute ^^^^^^ଶ ≔ ^^^^^^^^(^^, ^^^^^^^^).• Check ^^^^^^ଶ == ^^.• Compute ^^^^^^ଷ ≔ ^^ ⊕ ^^.• Compute ^^^^^^ସ ≔ ^^^^^^ଷ^^.• Compute ^^^^^^ହ ≔ ^^^^.Output ^^^^^^ସ, ^^^^^^ହ.The circuit ^^^ைோtakes: •four secret inputs ^^, ^^, ^^, ^^^^^^^^• one public input ^^.Notice that the inputs of a valid assignment to the circuit ^^⊕ with output ^^^, ^^ଶ are givenby a quintuple (^^, ^^, ^^, ^^, ^^^^^^^^) such that ^^^ = (^^ ⊕ ^^)^^, ^^ଶ = ^^^^, ^^ = ^^^^, ^^ =^^^^^^^^(^^, ^^^^^^^^). Therefore, a user Alice can turn the knowledge of a valid assignment to^^⊕ with output ^^^, ^^ଶ into a ZKP for the statement ‘The private input ^^ is the valuecommitted in ^^, the private key of ^^^ is ^^^, the private key of ^^ଶ is ^^ଶ, and it holds that^^ଶ = ^^ and ^^^ = ^^ ⊕ ^^, where ^^ is the private key of ^^’’.Notice that, if ^^ is drawn uniformly at random from ℤ^, i.e., ^^ is a uniform randomvariable, then ^^ ⊕ ^^ is a uniform random variable. Therefore, the key derivation algorithm^^ → ^^ ⊕ ^^ does not leak any information about ^^. Indeed, from the point of view of anobserver the public keys associated with ^^ ⊕ ^^ are random elements in ^^^.2.3 Reputation-Based Exchange System Figure 4 provides an example method for executing a reputation-based exchange in a system comprising users Alice 103a and Bob 103b, a CA 502, and the blockchain network 150. The circuits introduced in the previous subsection are utilised in the reputation-based exchange. The situation is as follows: Alice 103a wants to pay Bob 103b, and Bob 103b wants to be sure that Alice 103a will be not attempt a double spend. If Alice 103a does attempt a double spend, then Bob 103b wants the certainty that Alice’s identity will be revealed. We assume that Alice 103a has had her identity verified by a CA 502 and that Alice’s identityis (^^^, ^^^). The certificate issued by the CA is (^^௩, ^^, ^^^^^^), where ^^௩ is a commitment to ^^^,^^ is a commitment to ^^௩ and ^^^^^^ is the signature of the CA. The scheme introduced in § 1.7is used only as an example implementation; any designated verifier scheme with a CA 502 would work.Prior to the interaction, Alice 103a picks a random ^^ ∈ ℤ∗ ∗^ and random numbers ^^^, ^^ଶ ∈ ℤ^(ephemeral keys) and constructs a UTXO with locking script given by: OP_OVER OP_SWAP [P2PKH [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^ଶ] [checkR(^^ଶ)]Where ^^^ = (^^^ ⊕ ^^)^^ and ^^ଶ = ^^^^. The unlocking script for this UTXO is:<^^^^^^ଶ> <^^ଶ> <^^^^^^^> <^^^>Where ^^^^^^^ is a signature with private key ^^^ ⊕ ^^ and ephemeral key ^^^ and ^^^^^^ଶ is asignature with private key ^^ and ephemeral key ^^ଶ. Notice that the[checkR(^^^)] and[checkR(^^ଶ)] script codes ensure that if Alice double spends this UTXO, the private keys^^^ ⊕ ^^ and ^^ will be derivable from the two unlocking scripts attempting to spent theUTXO, and hence, her identity is revealed. Alice 103a broadcasts this transaction such that it is stored to the blockchain 150. Referring to Figure 4: 1. At the beginning of the interaction, Alice 103a proves to Bob 103b that her identity is verified by the CA 502. This interaction can happen in two different ways: a. Alice 103a proves to Bob 103b her identity is verified by the CA 502 with a DVZKP and she opens the commitment ^^௩to ^^^. b. Alice 103a proves to Bob 103b her identity is verified by the CA 502 with a DVZKP, but she does not open the commitment ^^௩. 2. Bob checks that Alice’s identity is still valid by requesting verification that the identity is valid from the CA 502. If the identity is not valid, Alice 103a had previously double spent, and so Bob 103b can choose not to trust Alice 103a and refuse to partake in the transaction. 3. The CA 502 verifies that Alice’s identity is valid, and notifies Bob 130b. 4. With knowledge that Alice’s identity id verifies, and therefore that Alice has not previously double spent, Bob 103b picks a random ^^^ ^ computes ^^^ = ^^^^^, referred to as a designated verifier key. 5. Bob 103b shares his designated verifier key ^^^with Alice 103a. This message sent from Bob 103b to Alice 103a may be referred to as an acceptance message, as it indicates that Bob 103b has accepted Alice’s identity as valid.6. Using the techniques of § 1.6.5., Alice 103a produces a DVZKP ^^ with designated verifier^^^ for either:a. The valid assignment (^^ ^ைோ^, ^^, ^^^) for ^^ with output ^^^ = (^^^ ⊕ ^^)^^,^^ଶ = ^^^^ if 2.a was enacted.b. The valid assignment (^^ , ⊕^ ^^, ^^^, ^^௩, ^^^^^^^^) for ^^ with output ^^^ =(^^^ ⊕ ^^)^^, ^^ଶ = ^^^^ if 2.b was enacted.This is referred to as a key generation proof. 7. Then, Alice 103a shares the DVZKP ^^ with Bob 103b. 8. Bob 103b checks ^^. 9. If Bob 103b satisfied with the key generation proof, he shares a public key ^^^where he wants to receive the funds with Alice 103a. 10. Alice 103a constructs a transaction sending the required funds to Bob 103b and spending the UTXO the funding transaction, that is the UTXO associated with the locking script defining the ephemeral key Alice 103a must use. The funding transaction may be referred to as a deterrent blockchain transaction because it includes the locking script which if double spent, results in the identity of Alice 103a being derivable. The spending transaction may be referred to as a proof transaction. 11. Alice 103a shares the proof transaction with Bob 103b. 12. Bob checks that ^^^and ^^ଶin the proof ^^ hash to the values contained in the locking script of the UTXO being spent and that the locking script is correctly formed. 13. If so, Bob 103b accepts the transaction and broadcasts it so that a node stores it on the blockchain 150. Steps 14 to 16 of Figure 4 assumed that Alice 103a has been malicious and double spent the output of the deterrent transaction. 14. Bob 103b receives a notification that he has not received the intended funds due to double spending by Alice 103a. The notification includes a copy of the transaction which has successfully spent the output. Alternatively, Bob 103b may request this successful transaction from the blockchain 150 in response to the notification. 15. Once Bob 103b has both transactions comprising the unlocking scripts which would unlock the UTXO of the deterrent transaction, Bob 103b derives the identity of Alice 103a. Methods for doing so are set out below. 16. Bob 103b then reports Alice 103a to the CA 502 by providing her identity and indicating double spending. The CA 502 is then able to add Alice’s identity to a blacklist or otherwise invalidate her identity such that when a next user requests confirmation of the validity of Alice’s identity, the CA 502 can notify the user of Alice’s pervious double spending. Notice that the DVZKP of step 6 proves to Bob that Alice knows ^^^, the private key of ^^^. To validate Alice’s identity, instead of interacting with the CA 502 at step 2, Bob 103b may search a database storing either valid or invalid identities for the Alice’s identity, thus also removing step 3 from the method set out above. In the case of a database storing valid identities, if Alice’s identity is stored, Bob 103b is assured that Alice 103a has not previously double spent. I contrast, if the database stores invalid identities (a bloacklist) and Alice’s identity is stored, Bob 103b can infer that Alice 103a has previously double spent and therefore is not trustworthy. The database may be held on-chain. If the blacklist of revoked certificates is kept on chain, then Bob 103b only needs access to the blockchain 150 and not to the wider network to perform this check.In the example locking script shown above, it is important that Alice chooses two different^^^, ^^ଶ ∈ for the commit-to-^^ locking script. Indeed, if Alice signs the same transactionwith two different keys ^^^, ^^ଶbut with the same ephemeral key ^^, then the s-coordinates ofthe two signatures are ^^ ି^^ = ^^ (^^ + ^^^^^) for ^^ = 1, 2, and operations can be carried out onthese numbers that reveal information concerning ^^^and ^^ଶ. For example, ^^^− ^^ଶ=^^ି^^^(^^^ − ^^ଶ). While this not a problem if ^^^ and ^^ଶ are uncorrelated, in our situation thereis a relationship between the two keys ^^^ ⊕ ^^ and ^^, and thus it is preferable to makeAlice sign with two different ephemeral keys. The above protocol successfully implements a reputation-based exchange in which parties are disincentivised from double spending via the threat of identity disclosure. Indeed, referring back to the three properties in the definition at the end of § 2.1, we see that: 1. Alice 103a and Bob 103b can either disclose their pseudonym or not (step 5 of the protocol). In either case, neither of them retains any proof that they can replay. 2. Alice 103a can send a payment from any address she likes, and Bob 103b can receive to whichever address he prefers. 3. If Alice 103a is dishonest, then her identity is revealed. If Bob 103b is dishonest and allows Alice 103a to write down erroneous data in the UTXO she uses to pay him, so that even if she double spends then her identity is safe. Bob 103b has no incentive to do this, because if he does, then he is at risk of not being paid. Indeed, even if Alice 103a managed to convince Charlie to disregard the protocol and to be paid with the same incorrectly formed UTXO Bob has agreed to be paid to, then both Bob 103b and Charlie would have 50 / 50 odds of being paid. Hence, Bob has not incentive to agree to collude with Alice 103a. Below, ^^^^^^^^^is the deterrent transaction with which Alice 103a creates comprising the locking script set out above, while ^^^^^^^^ଶis the transaction with which Alice 103a sends the funds to Bob 103b.

[0002] ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number ^^^^^^^^^^^^^^^^^^ ^^OP_OVER OP_SWAP[P2PKH ^^^][checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^ଶ] [checkR(^^ଶ)] ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number (^^^^^^^^^^, ^^) <^^^^^^ଶ> <^^ଶ>0xFF…FF ^^ [P2PKH ^^^]<^^^^^^^> <^^^>In the above example, Alice 103a constructs the UTXO that disincentives double spend attempts before commencing the interaction with Bob 103b, but this does not have to be the case. Indeed, Alice 103a could construct the UTXO on-demand and share with Bob 103b both the transaction creating the UTXO and the transaction that transfers the funds to Bob 103b. Clearly, this exposes Boba103b to the risk of a 50 / 50 run: if the network does not immediately notify him that the inputs used to construct the UTXO in ^^^^^^^^^already appear in another transaction which has not yet been mined, then Bob 103b will get his funds only if the transaction ^^^^^^^^^is mined first. To create the UTXO in ^^^^^^^^^Alice 103a had to generate a random number ^^. This meansthat she must keep track of ^^ to be able to spend the outpoint (^^^^^^^^^, 0). To avoid havingto store in memory a huge number of random values, various ^^ could be generated in a hierarchical way. Figure 5 illustrates how Bob 103b, on being alerted to double spending by Alice 103b, can derive Alice’s identity. The deterrent transaction 702 comprises the locking script locking the UTXO to the public keys ^^^and ^^ଶ, and identifying the ephemeral keys ^^^and ^^ଶwhich must be used when generating a signature. The proof transactions 704 and 706 both comprise an unlocking script which could unlock the UTXO of the deterrent transaction 702.In the example of Figure 5, the following applies:^^^ = (^^^ ⊕ ^^)^^^^ଶ = ^^^^^^ᇱis referred to as an identity concealing private key, with ^^^ being its corresponding anidentity concealing public key. ^^^, Alice’s identity, may be referred to as an identity defining private key. The identity concealing private key is derived, by Alice 103a, from the identity revealingprivate key and derivation data, wherein:^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ = ^^using a derivation function:^^ᇱ = ^^^ ⊕ ^^^^ଶ is referred to as a derivation public key, and ^^ as a corresponding derivation private key.The derivation data can be derived from these if two signatures associated therewith are obtained. With both of the proof transactions 704 and 706, Bob 103b derives ^^ᇱfrom the signaturescorresponding to ^^ଶ:^^ᇱ Bob 103b derives ^^ from the signatures corresponding to ^^^:⇒ ^^ Using the derived identity concealing private key and derivation data, Bob 103b obtains theidentity defining private key using the invertible derivation function:^^ᇱ = ^^ ⊕ ^^ , ^^, ^ ᇱ^ ^ ⇒ ^^^In this way, Bob 103b can identify Alice 103a. 2.4 Generalisation to Any Derivation Function that Allows Parent Key Recovery A derivation functions provides a way to derive, from any private key, another private key in an injective (different keys and different derivation data give rise to different functions) anddeterministic way. For example, if our key space were ^^ ≔ ℤ∗^ as in the blockchainnetwork, then a derivation function would be a map ℤ∗ ∗ ∗^ × ^^ → ℤ^ that to any key ^^ ∈ ℤ^ anany derivation data ^^^^^^ ∈ ^^ associates another key ^^ᇱ ∈ ℤ∗^ , and such that the keyassociated to (^^, ^^^^^^) is different from the key associated to ൫^^, ^^^^^^൯ for any (^^, ^^^^^^) ≠൫^^, ^^^^^^൯. The algorithm:1. Sample ^^ ∈ ℤ∗^ . If ^^ = ^^, resample.2. Compute ^^ᇱ = ^^ ⊕ ^^.as used in § 2.3 is an example of such a derivation function where ^^ = ℤ∗ ∗^ and ^^ = ℤ^ .Among all derivation functions, those for which, given a key ^^ᇱ ∈ ^^, ^^^^^^ ∈ ^^ and someauxiliary data ^^^^^^, it is possible to decide whether ^^′ was derived from some ^^ using ^^^^^^,and if so, calculate ^^ are of particular interest. For example, given ^^′ ∈ ℤ∗ ∗^ , ^^^^^^ = ^^ ∈ ℤ^ ,and ^^^^^^ the empty string, then if ^^ ≠ ^^′, ^^′ was derived from ^^ = ^^ᇱ ⊕ ^^. The derivation functions used herein are those for which there exists an algorithm that given an identity concealing private key, derivation data and auxiliary data returns the identity defining private key from which the identity concealing private key was derived according to said derivation function. It will be appreciated that the auxiliary data may be an empty string, and is therefore not always necessary for returning the identity defining private key. Derivations functions with this decidability property are of particular interest because they can be used to devise reputation-based exchanges. The following data is known to all parties:• The derivation function ^^ ∶ ^^ × ^^ → ^^.• All algorithm ^^ that, given ^^′ ∈ ^^, ^^^^^^ ∈ ^^, and ^^^^^^ returns the key ^^ ∈ ^^ such that^^′ was derived from ^^ using ^^^^^^ .Then, a reputation-based exchange can be constructed as follows (recall that (^^^, ^^^) isAlice’s identity which has been certified by a CA 502): 1. Prior to the interaction with Bob 103b, Alice 103a derives a private key ^^′ from her private key ^^^using derivation data ^^^^^^, stores the auxiliary data ^^^^^^, and constructs a UTXO with locking script: OP_OVER OP_SWAP [P2PKH ^^′] [checkR(^^)] Where ^^ᇱ = ^^′^^ and ^^ ^ is chosen at random. If Alice 103a double spends this UTXO, then she is forced to reveal the private key ^^′. 2. When Alice 103a meets Bob 103b, she gives him a DVZKP of her identity (in which her public key can either be revealed or not, see also § 2.3). If Bob 103b does not accept the proof, the protocol halts. However, if he does, Bob 103b sends his verifier designated verifier key. 3. Alice 103a shares ^^^^^^ and ^^^^^^ with Bob 103b off-chain and gives him a DVZKP that: i. ^^ᇱ = ^^ᇱ^^.ii. ^^ᇱ = ^^(^^^, ^^^^^^).iii. ^^^ = ^^^^^.iv. ^^(^^ᇱ, ^^^^^^, ^^^^^^) = ^^^. If Bob 103b does not accept the proof, the protocol halts. 4. Bob 103b shares with Alice 103a a public key. 5. Alice 13a constructs a transaction that spends the UTXO of step 1 and that sends the funds to the public key Bob 103b gave her. She then sends the transaction to Bob 103b. 6. Bob 103b checks that the transaction is constructed correctly and that ^^′ in the DVZKP of step 3 is the same as the one in the UTXO being used an input. If so, he broadcasts the transaction. In ^^^^^^^^^below, Alice 103a constructs the UTXO of step 1. In ^^^^^^^^ଶ, she transfers the funds to Bob 103b by spending that UTXO. ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number ^^^^^^^^^^^^^^^^^^ <^^^^^^^> <^^^> ^^OP_OVER OP_SWAP[P2PKH ^^′] [checkR(^^)]

[0003] ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number (^^^^^^^^^^, ^^) <^^^^^^> <^^′> 0xFF…FF ^^ [P2PKH ^^^]The protocol above satisfies all the requirements set out in § 2.1. Indeed, flexibility in information disclosure is ensured by step 2, that spending habits are not traceable is ensured by step 1, 4 and 5, and identity disclosure for dishonest users is ensured by step 1. Figure 6 shows how Alice’s identity is derivable if she double spends the UTXO of the deterrent blockchain transaction 802. If Alice 103a double spends by generating two proof transactions ^^^^ଶఈ804, ^^^^ଶఉ806, then Bob 103b can calculate the identity concealing private key ^^′ using the signatures of each ofthe unlocking scripts of the proof transactions ^^^^ଶఈ 804, ^^^^ଶఉ 806:^^^^^^ ᇱ∝, ^^^^^^ఉ ⇒ ^^Bob 103b receives the derivation data ^^^^^^ and auxiliary data ^^^^^^ from Alice 103a off-chain before he accepted the transaction – see step 3 in the method set out above. Based on this data and the derived identity concealing private key ^^′,Bob 103b can derive the identitydefining private key using the derivation function:^^(^^ᇱ, der, aux) = ^^^ ⇒ ^^^Thus, Bob 103b can reveal Alice’s identity. Therefore, the above method implements a reputation-based exchange for any derivation function for which there exists an algorithm ^^ as above that computes the parent key from a derived key and some auxiliary data. It can be seen that in this version of the protocol, the deterrent transaction 802 locking script comprises only a single P2PKH and defined ephemeral key, and therefore the unlocking scripts only comprises a single signature. This is because the derivation data ^^^^^^ is provided to Bob 103b off-chain, while in the method of § 2.3, the derivation data ^^ is derived from the locking and unlocking scripts. However, since Alice 103a shares both ^^^^^^ and ^^^^^^ with Bob 103b: • Bob 103b must store two values for each transaction to be able to discover the identity of dishonest users. •Bob 103b might be able to obtain ^^ ᇱ^ = ^^^^^ from ^^ , ^^^^^^ and ^^^^^^ even ifAlice 103a decided not to share it in step 2. • Bob 103b might be able to obtain ^^ from ^^^^^^ and ^^^^^^ without needing access to ^^’. Hence, the above protocol should only be used with derivation functions such that the counterparty does not have a feasible way to derive ^^ from ^^^^^^ and ^^^^^^ without ^^′. Also, Alice 103a and Bob 103b must decide which derivation functions to use according to whether they wish to share their pseudonyms (public keys) or not.An alternative protocol that does not have the above drawbacks by devising a way to store^^^^^^ and ^^^^^^ on-chain so to ensure that they remain hidden unless Alice 103a attempts adouble spend is provided below. More formally, if the auxiliary data ^^^^^^ lives in some space^^^^^^, then an invertible map is constructed:Φ ∶ ^^ × ^^^^^^ → ^^ × … × ^^so that ^^^^^^ and ^^^^^^ can be hidden using a commit-to-^^ P2PKH. The updated protocol works as follows. It is assumed that: •The derivation function ^^ ∶ ^^ × ^^ → ^^ is known to all the parties.• All the parties know the algorithm ^^ that, given ^^′ ∈ ^^, ^^^^^^ ∈ ^^, and ^^^^^^decides whether ^^′ was derived from some ^^ using ^^^^^^, and in this case computes ^^. •All parties know the function ∶ ^^ × ^^^^^^ → ^^ × … × ^^ and its inverseΦି^.Then, the interaction between Alice 103a and Bob 103b is: 1. Prior to the interaction with Bob 103b, Aliceb103a derives a private key ^^′ from her private key ^^^ using ^^^^^^. She takes ^^^^^^ and ^^^^^^ and computes:(^^^, … , ^^^) = Φ(^^^^^^, ^^^^^^)Then, she computes ^^ = ^^ ^^, ∗^ ^ she samples ^^^, … , ^^^ ∈ ℤ^ at random, and she constructs a UTXO with locking script: OP_OVER OP_SWAP [P2PKH ^^′] [checkR(^^ᇱ)] OP_OVER OP_SWAP [P2PKH ^^ [checkR(^^^)] … OP_OVER [P2PKH ^^^] [checkR(^^^)] Where ^^ᇱ = ^^′^^. If Alice 103a double spends this UTXO, then she is forcedto reveal the private key ^^′ and the private keys ^^^, … , ^^^.2. When Alice 103a starts the interaction with Bob 103b, she sends him a DVZKP of her identity (in which her public key can either be revealed or not, see also § 2.3). If Bob 103b does not accept the proof, the protocol halts. If he does, he sends his designated verifier key to Alice 103a. 3. Alice 103a gives Bob 103b a DVZKP that: a. ^^ᇱ = ^^ᇱ^^.b. ^^ᇱ = ^^(^^^, ^^^^^^).c. ^^^ = ^^^^^.d. ^^(^^ᇱ, ^^^^^^, ^^^^^^) = ^^^.e. ^^^ = ^^^^^ for ^^ = 1, … , ^^.f. (^^^, … , ^^^) = Φ(^^^^^^, ^^^^^^).If Bob 103b does not accept the proof, the protocol halts. In this protocol, ^^^and ^^^are a derivation private key-public key pair. 4. Bob 103b shares with Alice 103a a public key. 5. Alice 103a constructs a transaction that spends the UTXO of step 1 and that sends the funds to the public key Bob 103b gave her. She then sends the transaction to Bob 103b. 6. Bob 103b checks that the transaction is constructed correctly and that the data he received in the DVZKP of step 3 is the same as the one in the UTXO being used an input. If so, he broadcasts the transaction. Figure 7 shows how Alice’s identity is derivable if she double spends the UTXO of the deterrent blockchain transaction 902. If Alice 103a double spends by generating two proof transactions ^^^^ଶఈ904, ^^^^ଶఉ906, then Bob 103b can calculate the identity concealing private key ^^′ using the signatures of each ofthe unlocking scripts of the proof transactions ^^^^ଶఈ 904, ^^^^ଶఉ 906:^^^^^^ ᇱ∝, ^^^^^^ఉ ⇒ ^^In this protocol, Bob 103b derives the derivation data ^^^^^^ and the auxiliary data ^^^^^^ fromthe locking and unlocking scripts. First, Bob 103b derives the derivation private keys:⇒ ^^^ Using the derivation private keys, Bob 103b is able to derive the derivation and auxiliarydata:^^^^^^ With knowledge of the derivation data, auxiliary data, and the identity concealing privatekey, Bob 103b can reveal Alice’s identity:^^(^^ᇱ, der, aux) = ^^^ ⇒ ^^^It is clear that the above protocol has flexibility in information disclosure and that spending habits are not traceable. To see that it forces identity disclosure of dishonest users, noticethat if Alice 103a double spends the UTXO of step 1, then she reveals ^^′ and ^^^, … , ^^^. Bycomputing … , ^^^) Bob obtains (^^^^^^, ^^^^^^) that he can pass to the algorithm ^^ toobtain ^^^ = ^^ , ^^^^^^, ^^^^^^) and thus reveal Alice’s identity. Hence, the above protocolimplements a reputation-based exchange, and the protocol ensures that Bob 103b will only obtain the data necessary to discover Alice’s identity when she attempts a double spend. Below are two transactions that Alice 103a constructs to execute the above protocol: ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number ^^^^^^^^^^^^^^^^^^ <^^^^^^^> <^^^> ^^OP_OVER OP_SWAP[P2PKH ^^′] [checkR(^^ᇱ)] OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] ^^^^^^^^^^Version 1 Locktime 0In-count 1 Out- 1 count Input list Output list Outpoint Unlocking script Sequence Value Locking script Number (^^^^^^^^^^, ^^) <^^^^^^^> <^^^> 0xFF…FF ^^[P2PKH Bob]… <^^^^^^^> <^^^> <^^^^^^′> <^^′> 2.4.1 Securely Storing Data On-Chain As we explained in the previous subsection, two problems faced when devising a reputation-based exchange are that: • Bob 103b might be able to discover Alice’s public key starting from ^^ᇱ, ^^^^^^ and ^^^^^^. •Bob 103b might be able to discover Alice’s identity ^^^ starting from ^^^^^^ and^^^^^^ without needing access to ^^′, the private key of ^^′.While the first problem is not as serious as the second (Alice 103a might want to disclose her pseudonym to build some level of trust with Bob 103b), a solution is provided herein that solves both the above problems. The idea is to obfuscate ^^^^^^ and ^^^^^^ by mapping them to a tuple of private keys, and then ensure these private keys are revealed if Alice 103a attempts a double spend, so that in such case Bob 103b can reveal Alice’s identity using the algorithm ^^.The key space is ^^ = ℤ∗^ and for the sake of generality we define a function Ψ ∶ {0,1}∗ →^ that turns any data into a sequence of private keys in an invertible way. Then, Φ ∶^^ ^^^^^^ ^^ = , |Ψ(^^^^^^)|), where |Ψ(^^^^^^)| is the number of elements in Ψ(^^^^^^).In the following, given a bit string ^^ ∈ {0,1}∗ we write ^^ ^^ ^^ to denote the part of ^^ from the ^^-th to th ^^-th byte. Here, it is assumed that ^^ is written in big endiannotation. With this definition, Ψ is defined on the input ^^ ∈ {0,1}∗ as follows:a) Compute ^^௧ = |^^|.b) Compute ^^ the smallest positive solution to the equation ^^௧ + ^^ =0 ^^^^^^ 31.c) Draw ^^ ∈ {0,1}଼∗ௌ at random and set ^^ᇱ = ^^ || ^^.d) Divide ^^ = ^^^ || … || ^^^ where each ^^^ is of length 31 ^^^^^^^^^^.e) Draw at random ^^^ ∈ {1, … , 254}, ^^ = 2, … , ^^ and set ^^^ = ^^^ || ^^^.f) Set ^^^ = ^^ || ^^^ (notice that ^^ > 0).g) Define Ψ(^^) = (^^^, … , ^^^).The function Ψ is invertible. Indeed, by construction it is known that for each ^^ = 2, … , ^^,there are ^^[ଶ,ଷଶ]^ = ^^^, and for ^^ = 1 we have ^^[ଶା^,ଷଶ]^ = ^^^, where ^^ = ^^[^,^]^ (notice thatsince 1 < ^^ < 31, it fits in one byte). Thus, we can reconstruct ^^ = ^^^ || … || ^^^.Then, if Alice 103a wants to obfuscate the data (^^^^^^, ^^^^^^) and place it on-chain so that it isrevealed if she attempts a double spend, she first computes:Φ(^^^^^^, ^^^^^^) = (Ψ(^^^^^^), Ψ(^^^^^^), |Ψ(^^^^^^)|) = ൫(^^^, … , ^^^), (^^^ା^, … , ^^^), ^^൯Then she computes ^^ = ^^ ^^,^^ = ^^^^ ∗^ ^^^^௧^ , samples ^^^, … ^^^ ^^ ^ and she locks UTXO with locking script OP_OVER OP_SWAP ^^ [checkR(^^^)] … OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^^ା^] [checkR(^^^ା^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^^^^^௧^] [checkR(^^^ା^)] As in the previous example, ^^^and ^^^are a derivation public key-private key pair. ^^^^^^௧^and ^^ may also be considered a derivation public key private key pair. With knowledge of the private keys ^^^and ^^, the derivation data is derivable. For the above method to be secure, i.e., to be sure that the data is really obfuscated and that it is revealed only when Alice 103a attempts to double spend, it is assumed that ^^^^^^ and ^^^^^^ are random from the point-of-view of an attacker. Indeed, if this is not the case, then we cannot appeal to the DLP to ensure the security of the obfuscation. In any case, the burden of choosing ^^^^^^ and ^^^^^^ in a secure way resides with Alice 103a, if she chooses them in an insecure way she is always at risk of a social-engineering-type attack.If it is assumed that ^^^^^^ and ^^^^^^ are random strings, then the strings ^^^, … , ^^^ are random,and therefore the keys ^^^, … , ^^^ are random. The only difference between choosing theprivate keys at random in ^ and the method used here is that ^^^ is random element in ^^ random element in {0x01, … ,0x^^^^} × However, this only reduces the number of possible values for ^^ ଼∗ଷଶ^ from 2 to2଼∗ଷ^ ⋅ ^^^ ^^ > 1, from 2଼∗ଷଶ to 2଼∗ଷ^ ⋅ 255. Hence, it is still not feasible to compute the private key from the public keys. While ^^^^^^ should be chosen at random by Alice 103a, she cannot choose ^^^^^^ as it iscomputed as the result ^^^^^^(^^, ^^^^^^), i.e., it is determined once ^^^^^^ is fixed. Thus, ^^^^^^ mightnot be random, e.g., it could be the empty string. However, it is assumed that ^^ needs both^^^^^^ and ^^^^^^, thus, even if a malicious attacker manages to get ^^^^^^, they would still not beable to recover ^^.The reason why the prefix of the ^^^’s, ^^ = 2, … , ^^ is at most 0x^^^^ is so that ^^^ is recoverable from ^^^. However, encoding ^^^as a private key, it is only possible to recover it modulo ^^.Hence, it should be ensured that ^^ [ଶ,ଷଶ]^ < ^^, so that ^^^ = ^^^ over the integers rather thanover ℤ^.Φ(^^^^^^, ^^^^^^) = (Ψ(^^^^^^), Ψ(^^^^^^), |Ψ(^^^^^^)|) is defined to be consistent with the treatmentgiven in § 2.4. However, one could have also defined Φ(^^^^^^, ^^^^^^) = ൫Ψ(^^^^^^), Ψ(^^^^^^)൯and locked the UTXO with locking script: OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_0 OP_DROP OP_OVER OP_SWAP [P2PKH ^^^ା^] [checkR(^^^ା^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)]Here the segment OP_0 OP_DROP signals which part is about ^^^^^^ and which part is about^^^^^^. Indeed, from the above locking script the only information an attacker gains from thekeys ^^^, … , ^^^ is that 31(^^ − 1) ≤ |^^^^^^| ≤ 31^^, and similarly for ^^^^^^. However, the lengthof a message is the only information that an attacker is allowed to gain when we depart from the concept of perfect security (and in any case they would probably be able to get this information anyway by brute forcing the private key of ^^^^^^௧^). 2.4.2 General Let ^^ ∶ ^ ^^ → ^ be an injective derivation function and ^^^^^^ ∶ ℤ∗^ × ^^ → ^^^^^^ be the function that given (^^, ^^^^^^) ∈ ℤ∗^ × ^^ returns the auxiliary data ^^^^^^(^^, ^^^^^^) needed to runthe algorithm ^^ such that ^^^^^^), ^^^^^^, ^^^^^^(^^, ^^^^^^)൯ = ^^. To ease the notation, ^^^^^^ = ^^^^^^(^^, ^^^^^^) is used following, i.e., the function is conflated with its output ona given point (this will not create any issue because the input point will be fixed).Let ^^ ^^^^^^ ∗^ be the function of § 3.3.1. Then, the following circuit ^^ constructed: ^^ Private inputs: • private key ^^ • public key ^^ • derivation data ^^^^^^ • auxiliary data ^^^^^^ •Check ^^ == ^^^^.• Check ^^(^^(^^, ^^^^^^), ^^^^^^) == ^^.• Compute ൫(^^^, … , ^^^), (^^^ା^, … , ^^^), ^^൯ = Φ(^^^^^^, ^^^^^^)• Compute ^^′ = ^^(^^, ^^^^^^)^^.• Compute ^^^ = ^^^^^,^^ = 1, … , ^^.• Compute ^^^^^^௧^ = ^^^^.• Output ^^′ and ^^^, … , ^^^, ^^^^^^௧^.^^ is turned into a designated verifier circuit ^^ᇱas explained in § 1.6.5. Then, a reputation-based exchange is constructed as follows: 1. Prior to interaction with Bob 103b, Alice 103a constructs a UTXO with locking script: OP_OVER OP_SWAP [P2PKH ^^ᇱ] [checkR(^^ᇱ)] OP_OVER OP_SWAP [checkR(^^^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^^ା^] [checkR(^^^ା^)] … OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^^^^^௧^] [checkR(^^^ା^)] Where the private key of ^^ᇱ is ^^(^^^, ^^^^^^), where ^^^ is the identity of Alice^^ ^^ ∈ ∗^ ^ ℤ^ are numbers drawn uniformly at random, and the private keys of ^^ , … , ^^^, ^^^^^^௧^ are ^^ ^^ Φ(^^^^^^, ^^^^^^).2. When Alice 103a meets Bob 103b, she gives him a DVZKP of her identity (in which her public key can either be revealed or not, see also § 2.3). If Bob 103b does not accept the proof, the protocol halts.3. Bob 103b samples a random ^^^ ∈ ^ and sends to Alice ^^^ = ^^^^^ (thedesignated verifier key). 4. Alice 103a produces for Bob 103b the proof of a valid assignment to ^^ᇱwith inputs ^^, ^^, ^^ᇱ, ^^^, … , ^^^, ^^^^^^௧^, ^^^^^^, ^^^^^^ (the same as the ones in theUTXO she constructed in point 1). Alice 103a shares this DVZKP with Bob. 5. If Bob 103b does not accept the proof of the previous point, the protocol halts. Otherwise, Bob 103b shares with Alice 103a a public key to which he wants to be paid. 6. Alice 103a constructs a transaction that spends the UTXO of step 1 and that sends the funds to the public key Bob 103b gave her. She then sends the transaction to Bob 103b. 7. Bob 103b checks that the transaction is constructed correctly and that the data he received in the DVZKP of step 3 is the same as the one in the UTXO being used an input. If so, he broadcasts the transaction. The above protocol satisfies the conditions of the definition we gave at the end of § 3.1: it has flexibility of information disclosure (step 2), spending habits are not traceable (step 1 and step 5 and 6), and the identity of dishonest users is revealed: if Alice 103a attempts todouble spend the UTXO, she is forced to reveal the keys ^^^, … , ^^^, ^^ from which Bob 103b,computing can obtain (^^^^^^, ^^^^^^) and thus compute ^^^ as ^^^ = ^^(^^ᇱ, ^^^^^^, ^^^^^^).Figure 8 shows how Alice’s identity is derivable if she double spends the UTXO of the deterrent blockchain transaction 1002. If Alice 103a double spends by generating two proof transactions ^^^^ଶఈ1004, ^^^^ଶఉ1006, then Bob 103b can calculate the identity concealing private key ^^′ using the signatures ofeach of the unlocking scripts of the proof transactions ^^^^ଶఈ 1004, ^^^^ଶఉ 1006:^^^^^^ , ^^ ᇱ∝ ^^^^ఉ ⇒ ^^Bob 103b derives the derivation data ^^^^^^ and the auxiliary data ^^^^^^ from the locking and unlocking scripts. First, Bob 103b derives the derivation private keys:⇒ ^^^ Using the derivation private keys, Bob 103b is able to derive the derivation and auxiliarydata:Φି^൫(^^^, … , ^^^), (^^^ା^, … , ^^^), ^^൯ = (^^^^^^, ^^^^^^) ⇒ ^^^^^^, ^^^^^^With knowledge of the derivation data, auxiliary data, and the identity concealing privatekey, Bob 103b can reveal Alice’s identity:^^(^^ᇱ, der, aux) = ^^^ ⇒ ^^^2.4.3 Example ImplementationConsider the derivation function ^^(^^, ^^) = ^^ + ^^, where ^^, ^^ ∈ ℤ^, ^^ ≠ 0. Then, areputation-based exchange can be implemented as explained in the previous section. Indeed, in this case: •^^^^^^ = ^^• ^^^^^^ = "" (empty string)• ^^(^^(^^, ^^), ^^^^^^, ^^^^^^) = ^^(^^, ^^) − ^^^^^^ = (^^ + ^^) − ^^ = ^^In the following example, it is assumed that Alice’s identity is:^^^=0x^^5^^^^44^^1^^8^^0^^6318725^^^^^^^^^^4^^1^^1741^^^^982^^0^^^^3^^929^^^^^^07409^^4^^^^186^^3^^^= 0x03806^^^^^^9753^^^^^^^^^^874467^^^^^^^^67^^^^7^^53^^359^^^^^^4^^228^^56^^^^60^^5419035^^433Then, to pay Bob103b, Alice 103a samples a random ^^ ^ ^^= 0x^^3^^^^^^90^^574^^40^^^^31^^^^30354367^^247864^^28015894^^2^^797^^91269^^^^855844As |^^| = 32, Alice 103a samples ^^ ∈ {0,1}଼∗ଷ^:^^ = 0x04^^21528^^^^911^^1^^7^^27^^6^^52^^^^95^^^^^^^^^^011867937^^^^^^07^^^^^^163^^8689^^And sets ^^ᇱ = ^^ || ^^. Then, she divides into ^^ᇱ = ^^^||^^ଶ as below:^^^=^^ଶ= 0x^^^^^^90^^574^^40^^^^31^^^^30354367^^247864^^28015894^^2^^797^^91269^^^^855844She draws a random ^^ଶ = 0x^^^^, she sets:^^^= 0x1^^04^^21528^^^^911^^1^^7^^27^^6^^52^^^^95^^^^^^^^^^011867937^^^^^^07^^^^^^163^^8689^^^^3^^ଶ= 0x^^^^^^^^^^90^^574^^40^^^^31^^^^30354367^^247864^^28015894^^2^^797^^91269^^^^855844And she computes:^^^= 0x038^^12849086^^2^^^^8564^^7388464231414325^^34^^3^^2^^63^^016^^^^0594^^79267886^^ଶ= 0x03287^^91^^2^^2^^19^^04^^4367^^6686^^3^^4^^^^^^^^^^^^889681^^0^^^^4530^^2^^254^^8^^^^^^5^^0Then, she locks the UTXO she wants to use to pay Bob 103b with locking script: OP_OVER OP_SWAP [P2PKH ^^′] OP_OVER OP_SWAP [P2PKH ^^^] [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^ଶ] [checkR(^^ଶ)] OP_OVER OP_SWAP [P2PKH ^^^^^^௧^] [checkR(^^ଷ)]Where:^^ᇱ= 0x03021955^^842^^90519960^^6957403437^^31249348^^^^^^^^37^^^^004524^^3^^^^^^^^0^^781^^ᇱ^ three random numbers: ^^^= 0x1^^^^73^^342^^16^^5^^67699^^^^^^489^^^^^^8^^4^^537^^58751^^164^^6^^482^^1818^^0^^^^6^^7^^ଶ= 0x^^3651^^^^2^^^^520^^97^^^^^^^^084081^^76^^^^4^^^^^^861659^^0537^^92^^896^^8818^^4^^944^^ଷ= 0x1^^2^^58^^^^^^^^7^^^^61^^259^^^^71211^^900769481^^^^585^^^^^^80^^1080^^^^972^^8^^4^^^^7^^To prove to Bob that all the data was constructed correctly, she provides a ZKP proving the valid assignment to the circuit shown in Figure 11. 2.5 Avoiding zkSNARKs The methods set out in the previous sections employ the idea of devising a circuit that would prove a key derivation statement, turn the circuit into a ZKP and then build a protocol around this ZKP. The drawback of this approach is that zkSNARKs must be used, which are powerful but sometimes not the most efficient solution. In this subsection ZKKSP are used, see § 1.6.2.2, to avoid the use of zkSNARKs. The idea is to prove a key derivation statement using ZKKSP, so to that the information needed to derive the new key can remain hidden. This solution requires the parties to know each other’s pseudonyms.In § 1.6.1 sets out how to construct a ZKP of the following statement ‘Given the public keys^^ , ^^ and the number ^^^^, the ^^ ଶ private key ^^ଶ of ^^ଶ is equal to ^^^ି (^^^^), where ^^^ is theprivate key of ^^^’. Considering the circuit ^^×composed of a single multiplication gate.Then, assume that Alice 103a shows to Bob 103b three public keys ^^^, ^^ଶ, ^^ଷ and that sheclaims that the private key ^^ଶ of ^^ଶ is equal to ^^^^^ଷ, where ^^^ and ^^ଷ are the private keys of^^^ and ^^ଷ, respectively. Then, if Alice 103a proves to Bob 103b that she has a validassignment {^^^, ^^ଶ, ^^ଷ} to ^^× and she then produces key openings {^^^, ^^ଶ, ^^ଷ} such that^^^^^^^^ ^^^ − ^^^^^ ^^^ ^^^^^^^^ ^^ − ^^ ^^ ^^ ^^^^^^^^ ^^ − ^^ ^^ ^^ then 103b is convinced of Alice’s statement. This ZKKSP can be used to devise a reputation-based exchange: 1. Prior to the interaction, Alice creates a UTXO with locking script: OP_OVER OP_SWAP [checkR(^^^)] OP_OVER OP_SWAP [P2PKH ^^_2] [checkR(^^ଶ)] Where ^^ = ^^ ^^ for ^^ ∈ dr ^^ ^ ^ ^ awn uniformly at random, ^^ଶ = ^^^ି ^^^^^, where ^^^ is Alice’s identity, and ^^^, ^^ଶ ^ are drawn uniformly at random. 2. At the beginning of the interaction, Alice proves to Bob her identity with a DVZKP and opens the commitment ^^௩to ^^^. Bob also checks that Alice’s identity is still valid. 3. Alice shows to Bob a DVZKP of the ZKKSP ‘The private key of ^^^is equal to the private key of ^^^multiplied by the private key of ^^ଶ’. 4. If Bob is satisfied with the proof in the previous step, he sends to Alice a public key to which he wants to be paid. 5. Alice constructs a transaction spending the UTXO of step a) and sending the funds to the public key of point d). She shares this transaction with Bob. 6. Bob checks that the locking script of the transaction is correctly formed and that the public keys in the locking script are the correct ones. If so, he broadcasts the transaction.In this example, the identity concealing private key is:^^ᇱ = ^^ ^^ି ^^^where ^^^is the derivation data. Figure 9 illustrates how Bob 103b, on being alerted to double spending by Alice 103b, can derive Alice’s identity. The deterrent transaction 1102 comprises the locking script locking the UTXCO to the public keys ^^^and ^^ଶ, and identifying the ephemeral keys ^^^and ^^ଶwhich must be used when generating a signature. The proof transactions 1104 and 1106 both comprise an unlocking script which could unlock the UTXO of the deterrent transaction 1102. With both of the proof transactions 704 and 706, Bob 103b derives ^^ᇱfrom the signaturescorresponding to ^^ଶ:^^^^^^ , ^^^ ᇱଶ∝ ^^^ଶఉ, ⇒ ^^Bob 103b derives ^^^ from the signatures corresponding to ⇒^^^ Using the derived identity concealing private key and derivation data, Bob 103b obtains theidentity defining private key using the derivation function:^^ᇱ ^^ ^ ^^ᇱ ^ In this way, Bob 103b can identify Alice 103a. Instead of a ZKKSP, a ZKP can be used as described out in § 1.6.1. In this case, Alice 103a locks the UTXO of the deterrent transaction with the following locking script: OP_OVER OP_SWAP [checkR(^^)] OP_RETURN <^^^^> where ^^^^ = ^^ ^^ି ^^^ ^^^^^^ ^^, ^^^ = ^^^^^ ^^ ∈ ^ , then Alice 103a could have simply sent to Bob103b the transcript of the ZKP for the statement: ‘The private key of ^^^multiplied by ^^^^ is equal my identity, i.e., to the private key of ^^^’, and Bob 103b would have known that if Alice 103a attempted a double spend, then he could have computed her identity. Figure 10 shows the transactions which may be generated by Alice 103a and how Bob 103b can derive the identity defining private key. Specifically, Bob 103b derives the identity concealing private key ^^^from the twosignatures:^^^^^^∝, ^^^^^^ఉ ⇒ ^^^Bob 103b, using the derived identity concealing private key and the derivation data ^^^^ extracted from the locking script of the deterrent blockchain transaction, can derive Alice’sidentity:^^^^ ^^ ^^^ ^^^^^^ ^^ ^^ ^ ^^^^ Alice 103a may choose to use this method as it reduces the computational requirements on Alice when generating her proof of identity and the space requirement for each of the deterrent transaction 1202 and the proof transaction 1204, 1206. However, even if no information is leaked about ^^^from ^^^^ and ^^^, this is not true for multiple iterations of the protocol. To see this, notice that if ^^^is drawn uniformly atrandom from ℤ∗^, then ^^^^ = ^^^ି^^^^ ^^^^^^ ^^ leaks information about ^^^. Indeed, ^^(^^^^) =^^^^^(^^^), where ^^ ^^ି is uniform, and therefore a malicious attacker can restrict the range ofviable candidates for ^^^by using, e.g., the law of large numbers. In the methods set out above, it is assumed that each party 103a, 103b knows the derivation functions. However, it will be appreciated that prior knowledge of the derivation function may not be needed, and the derivation function used, and / or the algorithm for reversing the derivation function, may be exchanged together with the transactions. For example, the derivation function and / or its reverse may be defined in the locking script of the deterrent blockchain transaction. 3. USE CASES The protocols introduced in § 2 ensures that if a malicious user attempts a double spend, then it is possible to reveal their identity. The most obvious use case is that of reputation- based exchanges. That is, UTXOs that reveal identity upon double spending attempts are most useful when designing exchanges where trust among the parties is important. The word exchange should not be misinterpreted: it does not necessarily mean stock exchange or financial market. Exchange as used herein refers to a network of parties that wish to trade on a frequent basis. For example, a CBDC system could be enhanced by requiring that UTXOs spent in the transactions have any of the format specified in § 2. To ensure even further privacy, at the point of registration with the CA it might be the latterto provide the identity to the user, i.e., the couple (^^, ^^). Then, instead of giving to the userAlice the couple (^^^, ^^^) (which is the way in which the CA records Alice in their database)the CA could give her (^^^ ⊕ ^^, (^^^ ⊕ ^^)^^) for some secret value ^^, so that even if Alicedouble spends, her identity is not revealed until ^^^ ⊕ ^^ is brought to the CA. This methodwould provide enhanced privacy in case Alice had their private key ^^^ ⊕ ^^ stolen and it wasnot her that attempted a double spend. 4. EXAMPLE SYSTEM OVERVIEW 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. 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. 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 (often referred to as “miners”) 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. A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain 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. 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. Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations. 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. 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” or “nonce”). 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. Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a “recipient” field (in which a receiving address of an account is specified) and a “value” field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an output- based transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a “signature” field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (e.g. send or “release” a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact’s script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction. 5. 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 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 Tx0comprises 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. 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. Locking 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, UTXO0 in the output 203 of Tx0 comprises a locking script [Checksig PA] which requires a signature Sig PA of Alice in order for UTXO0to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXO0to be valid). [Checksig PA] contains a representation (i.e. a hash) of the public key PA from a public- private key pair of Alice. The input 202 of Tx1 comprises a pointer pointing back to Tx1 (e.g. by means of its transaction ID, TxID0, which in embodiments is the hash of the whole transaction Tx0). The input 202 of Tx1 comprises an index identifying UTXO0 within Tx0, to identify it amongst any other possible outputs of Tx0. The input 202 of Tx1 further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the “message” in cryptography). The data (or “message”) that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these. When the new transaction Tx1arrives 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). 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 keyPA. In embodiments this is based on the ECDSA using the elliptic curve secp256k1. A digitalsignature 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. 6. 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. 7. 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 for generating a deterrent blockchain transaction, the method comprising: providing a first locking script of the deterrent blockchain transaction, wherein the first locking script defines an identity concealing public key of an identity concealing public key-private key pair, wherein an identity concealing private key of the identity concealing public key-private key pair is derived from an identity defining private key and derivation data using a derivation function, wherein the first locking script is configured, when executed together with a first unlocking script of a proof blockchain transaction, to: verify that a first signature provided in the first unlocking script is generated using a first ephemeral key and the identity concealing private key; and verify that a first public key provided in the first unlocking script matches the identity concealing public key; and making the deterrent blockchain transaction available to one or more nodes of a blockchain network; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data. Statement 2. The method of statement 1, wherein the identity concealing private key is not derivable from the identity concealing public key and the first signature only. Statement 3. The method of statement 1 or statement 2, wherein the identity concealing private key is derivable further from auxiliary data. Statement 4. The method of any preceding statement, wherein the derivation data is derivable from the first unlocking script and the second unlocking script. Statement 5. The method of statement 4, wherein the locking script further defines a derivation public key of a derivation public key-private key pair, wherein derivation private key of the derivation public key-private key pair is derived from the derivation data, wherein the first locking script is further configured, when executed together with the first unlocking script of the proof blockchain transaction, to: verify that a third signature provided in the first unlocking script is generated using a second ephemeral key and the derivation private key; and verify that a second public key provided in the first unlocking script matches the derivation public key; wherein the derivation private key is derivable from the derivation public key, the third signature, and a fourth signature of the second unlocking script, wherein the second unlocking script comprises: the fourth signature generated using the second ephemeral key and the derivation private key; and the derivation public key. Statement 6. The method of statement 5, wherein the derivation data is the derivation private key. Statement 7. The method of statement 5 when dependent on statement 3, wherein the derivation private key is further derived from the auxiliary data using an invertible function, wherein the derivation data and the auxiliary data are derivable from the derivation private key based on the invertible function. Statement 8. The method of any of statements 1 to 3, wherein the method further comprises trasnmitting the derivation data to a candidate recipient off-chain. Statement 9. The method of statement 8 when dependent on statement 3, wherein the method further comprises transmitting the auxiliary data to the candidate recipient off- chain. Statement 10. The method of any preceding statement, wherein the method further comprises: providing, to a candidate recipient, a zero-knowledge proof proving that the identity defining private key is derived from using the derivation data using the derivation function; and receiving an acceptance message from the candidate recipient, the acceptance message indicating that the candidate recipient has verified the zero-knowledge proof; wherein the deterrent blockchain transaction is generated in response to the acceptance message. Statement 11. A computer-implemented method for generating a proof blockchain transaction, wherein an identity concealing private key is derived from an identity defining private key and derivation data using a derivation function, wherein the identity concealing private key and an identity concealing public key are an identity concealing public key- private key pair, the method comprising: providing a first unlocking script of the proof blockchain transaction, wherein the first unlocking script comprises: a first signature generated using a first ephemeral key and an identity concealing private key, wherein a first locking script of a deterrent blockchain transaction defines the identity concealing public key; and a first public key, wherein the first public key matches the identity concealing public key; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script of a second proof transaction, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data. Statement 12. The method of statement 11, wherein the method further comprises: receiving, from a provider, a zero-knowledge proof proving that the identity defining private key is derived from the derivation data using the derivation function; verifying the zero- knowledge proof; and in response to verifying the zero-knowledge proof, sending a public key for including in the deterrent blockchain transaction. Statement 13. A computer-implemented method of determining an identity of a malicious user, the method comprising: receiving an indication that a first output has been double spent; obtaining a first unlocking script configured to unlock a first locking script of a deterrent blockchain transaction, the first unlocking script comprises a first signature generated using a first ephemeral key and an identity concealing private key, and an identity concealing public key, wherein the identity concealing private key and the identity concealing public key are a public key-private key pair, wherein the identity concealing private key is derived from an identity defining private key and derivation data using a derivation function; obtaining a second unlocking script configured to unlock the first locking script of the deterrent blockchain transaction, wherein the second unlocking script comprises a second signature generated using the first ephemeral key and the identity concealing private key, and the identity concealing public key; deriving the identity concealing private key based on the identity concealing public key, the first signature, and the second signature; and deriving the identity defining private key from the identity concealing private key and the derivation data. Statement 14. The method of statement 13, wherein the first unlocking script further comprises a third signature generated using a second ephemeral key and a derivation private key, and a derivation public key, wherein the derivation private key and the derivation public key are a public key-private key pair, wherein the derivation private key is derived from auxiliary data and the derivation data using an invertible derivation function, wherein the second unlocking script further comprises a fourth signature generated using the second ephemeral key and the derivation private key, and the derivation public key, wherein the method further comprises: deriving the derivation private key based on the derivation public key, the third signature, and the fourth signature; and deriving the derivation data based on the derivation private key and the derivation function. Statement 15. The method of statement 13, wherein the method further comprises obtaining the derivation data and auxiliary data off-chain, wherein the identity deriving private key is further derived using the auxiliary data. 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 statements 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 statements 1 to 15.

Claims

CLAIMS 1. A computer-implemented method for generating a deterrent blockchain transaction, the method comprising: providing a first locking script of the deterrent blockchain transaction, wherein the first locking script defines an identity concealing public key of an identity concealing public key-private key pair, wherein an identity concealing private key of the identity concealing public key-private key pair is derived from an identity defining private key and derivation data using a derivation function, wherein the first locking script is configured, when executed together with a first unlocking script of a proof blockchain transaction, to: verify that a first signature provided in the first unlocking script is generated using a first ephemeral key and the identity concealing private key; and verify that a first public key provided in the first unlocking script matches the identity concealing public key; and making the deterrent blockchain transaction available to one or more nodes of a blockchain network; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data.

2. The method of claim 1, wherein the identity concealing private key is not derivable from the identity concealing public key and the first signature only.

3. The method of claim 1 or claim 2, wherein the identity concealing private key is derivable further from auxiliary data.

4. The method of any preceding claim, wherein the derivation data is derivable from the first unlocking script and the second unlocking script.

5. The method of claim 4, wherein the locking script further defines a derivation public key of a derivation public key-private key pair, wherein derivation private key of the derivation public key-private key pair is derived from the derivation data, wherein the first locking script is further configured, when executed together with the first unlocking script of the proof blockchain transaction, to: verify that a third signature provided in the first unlocking script is generated using a second ephemeral key and the derivation private key; and verify that a second public key provided in the first unlocking script matches the derivation public key; wherein the derivation private key is derivable from the derivation public key, the third signature, and a fourth signature of the second unlocking script, wherein the second unlocking script comprises: the fourth signature generated using the second ephemeral key and the derivation private key; and the derivation public key.

6. The method of claim 5, wherein the derivation data is the derivation private key.

7. The method of claim 5 when dependent on claim 3, wherein the derivation private key is further derived from the auxiliary data using an invertible function, wherein the derivation data and the auxiliary data are derivable from the derivation private key based on the invertible function.

8. The method of any of claims 1 to 3, wherein the method further comprises trasnmitting the derivation data to a candidate recipient off-chain.

9. The method of any preceding claim, wherein the method further comprises:providing, to a candidate recipient, a zero-knowledge proof proving that the identity defining private key is derived from using the derivation data using the derivation function; and receiving an acceptance message from the candidate recipient, the acceptance message indicating that the candidate recipient has verified the zero-knowledge proof; wherein the deterrent blockchain transaction is generated in response to the acceptance message.

10. A computer-implemented method for generating a proof blockchain transaction, wherein an identity concealing private key is derived from an identity defining private key and derivation data using a derivation function, wherein the identity concealing private key and an identity concealing public key are an identity concealing public key-private key pair, the method comprising: providing a first unlocking script of the proof blockchain transaction, wherein the first unlocking script comprises: a first signature generated using a first ephemeral key and an identity concealing private key, wherein a first locking script of a deterrent blockchain transaction defines the identity concealing public key; and a first public key, wherein the first public key matches the identity concealing public key; wherein the identity concealing private key is derivable from the identity concealing public key, the first signature, and a second signature of a second unlocking script of a second proof transaction, wherein the second unlocking script comprises: the second signature generated using the first ephemeral key and the identity defining private key; and the identity concealing public key; and wherein the identity defining private key is derivable from the identity concealing private key and the derivation data.

11. A computer-implemented method of determining an identity of a malicious user, the method comprising: receiving an indication that a first output has been double spent;obtaining a first unlocking script configured to unlock a first locking script of a deterrent blockchain transaction, the first unlocking script comprises a first signature generated using a first ephemeral key and an identity concealing private key, and an identity concealing public key, wherein the identity concealing private key and the identity concealing public key are a public key-private key pair, wherein the identity concealing private key is derived from an identity defining private key and derivation data using a derivation function; obtaining a second unlocking script configured to unlock the first locking script of the deterrent blockchain transaction, wherein the second unlocking script comprises a second signature generated using the first ephemeral key and the identity concealing private key, and the identity concealing public key; deriving the identity concealing private key based on the identity concealing public key, the first signature, and the second signature; and deriving the identity defining private key from the identity concealing private key and the derivation data.

12. The method of claim 11, wherein the first unlocking script further comprises a third signature generated using a second ephemeral key and a derivation private key, and a derivation public key, wherein the derivation private key and the derivation public key are a public key-private key pair, wherein the derivation private key is derived from auxiliary data and the derivation data using an invertible derivation function, wherein the second unlocking script further comprises a fourth signature generated using the second ephemeral key and the derivation private key, and the derivation public key, wherein the method further comprises: deriving the derivation private key based on the derivation public key, the third signature, and the fourth signature; and deriving the derivation data based on the derivation private key and the derivation function.

13. The method of claim 11, wherein the method further comprises obtaining the derivation data and auxiliary data off-chain, wherein the identity deriving private key is further derived using the auxiliary data.

14. 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 13.

15. 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 13.

Images