Computer-implemented methods and systems for authentication and / or proof of decryption

Abstract

Embodiments include but are not limited to: solutions for securing and verifying data, controlling access to controlled resources, proving identity and / or authorisation, implementing agreements between computer-based resources. In an example, a first node (Alice) sends an encrypted challenge to a second node (Bob). The challenge can also be called a puzzle. The challenge has been encrypted using the Bob's public key. Upon receipt, the Bob uses his corresponding private key to decrypt Alice's challenge. This enables him to compute a solution and send it to Alice as proof that he must have decrypted her challenge and must, therefore, have knowledge or possession of the private key. If Bob does not have the private key, he is unable to decrypt the challenge and provide the correct solution. Some embodiments can be implemented using a blockchain for provision and execution of the challenge and / or solution.

Description

[0001] COMPUTER-IMPLEMENTED METHODS AND SYSTEMS FOR AUTHENTICATION AND / OR

[0002] PROOF OF DECRYPTION

[0003] TECHNICAL FIELD

[0004] The present disclosure relates to techniques and technical solutions comprising cryptography and encryption / decryption. Embodiments are particularly suited, but not limited, to use in situations where Zero Knowledge Proofs are required. Embodiments can be used to advantage in respect of a variety of purposes including, but not limited to, verification and authentication of identity or data, performance of agreements between parties, secure sharing and transmission of data etc.

[0005] BACKGROUND

[0006] Cryptographic techniques are well known and are used in a multitude of technologies for many different purposes. One commonly used form of cryptography is that of asymmetric key pairs, comprising corresponding public and private keys. As the name suggests, the public key can be freely shared with other parties while the key owner keeps the private key secret. Anyone who has the public key can use it to encrypt data but only the party with access to the private key is able to decrypt it.

[0007] Another cryptographic technique is that of Zero Knowledge Proof, (ZNP) protocols, in which one party known as the prover wishes to prove, to a verifier, that he has possession or knowledge of a piece of secret data without disclosing the data itself. For example, a ZNP can be used to verify a party's identity while maintaining privacy and secrecy of any other data relating to that party. Other use-case examples include the enforcement or promotion of honest behaviour, facilitating interoperability between systems due to the secure exchange of data and outsourcing of processing resources to other entities via verifiable computation. A ZNP typically comprises three elements:

[0008] • The witness (the secret data that the prover wishes to prove knowledge of)

[0009] • A puzzle (also known as a challenge) that the prover can solve to demonstrate knowledge of the secret data

[0010] • The proof (the solution to the puzzle) General background information relating to such techniques can be found in:

[0011] • A Menezes: "Handbook of applied cryptography, Chapter 10" 01 January 1997, XP055505364, https: / / cacr.uwatrloo.ca / hac / about / chaplO.pdf

[0012] • Schmidbauer Tobias; Tobias Schmidbauer@gmx-topmail.de et al: “Challenging Channels: Encrypted Covert Channels Within Challenge-Response Authentication" , pages 1-10, ACM Conference On Fairness, Accountability and Transparency, ACMPUB27, New York, NY, USA 23 August 2022, ISBN 978-1-4503-9640-0.

[0013] Embodiments of the present disclosure provide new, alternative and improved arrangements involving cryptographic techniques.

[0014] SUMMARY

[0015] Embodiments of the disclosure are provided herein and as defined in the appended claims.

[0016] In accordance with the disclosure, a prover performs a Zero Knowledge Proof by providing a challenge solution to a verifier. The challenge solution comprises evidence that the prover has possession or knowledge of a secret i.e. private cryptographic key. Hereafter, we will simply use the term 'knowledge' as intended to include 'or possession of'. Generation of the challenge solution by the prover requires decryption of at least one data item which could be referred to herein as 'challenge data' or simply 'the challenge'. The challenge data item(s) have been encrypted by the verifier using the prover's public key, and therefore the prover can only decrypt the encrypted data item(s) and generate the solution if he has knowledge of the corresponding private key.

[0017] Preferably, the challenge solution comprises some information, indicator or other demonstrator that the prover could only know if he had gained access to the unencrypted version of the data. For example, the verifier may use the prover's public key to encrypt a random question. If the prover is able to return the correct answer to the random question, he must have been able to decrypt the encrypted challenge data to learn what the question was. In other words, embodiments provide a mechanism for proving knowledge of the private key without actually providing a signature. Here, the 'randomness' means that the prover cannot predict what the verifier will ask them to provide as a solution.

[0018] In other possible embodiments, the challenge solution may comprise a processed (e.g. hashed or otherwise operated on) version of the unencrypted challenge data. The prover can send this processed version of the unencrypted challenge data to the verifier, who can perform the same processing and compare her results with those provided by the prover. If the results match, the prover must have decrypted the challenge data using the private key.

[0019] In preferred embodiments, the (correct) solution to the challenge either:

[0020] - does not require the use of an alphabet that has been agreed between the parties; or

[0021] - does not comprise any part of the challenge data itself; or

[0022] - or does not comprise the entire challenge data itself.

[0023] This distinguishes the embodiment from prior art techniques such as those in which a challenge solution is computed as a concatenation of the challenge data (or a part thereof) and a nonce or some other value such as a symbol from a message that is representative of symbols from an alphabet that the two parties have agreed upon. An advantage of this is that the challenge solution provided by the prover of the present disclosure may provide a solution that is independent of the challenge itself in terms of its content. Thus, interception of the prover's message does not assist the interceptor. Also, the parties do not need to securely store the alphabet.

[0024] In some embodiments, after decrypting the challenge data, the prover may process it using one or more operations or functions. One or more of said operations may be or comprise a hash function. The processed decrypted challenged data may then be sent back to the verifier. This provides the advantage that the prover's response is not sent back in its 'raw', original state which may lead to a compromise inn security. For example, if the challenge data comprises a password or memorable phrase that is used to protect a controlled resource, then sending the solution to the verifier in its unencrypted, original form would pose a security risk if the solution is intercepted by an unauthorised party. The more processing operations that the prover applies to the solution, the more secure the prover's response to the verifier may be. Therefore, in a preferred embodiment the prover may apply two or more operations to the solution before sending it to the verifier e.g. the solution may be hashed and then encrypted with a cryptographic key. In some cases, the cryptographic key used for encrypting the solution may be a key (e.g. public key) associated with or derived from a (private) key associated with the verifier.

[0025] Additionally, or alternatively, the challenge data may be provided by the verifier to the prover in the form of encrypted executable instructions i.e. code that can be executed by a processor after it has been decrypted with the necessary private key. An advantage of this is that the authentication process can be fully automated on respective computing resources of the two parties. Moreover, the challenge data can represent or comprise a much more diverse range of challenges such that the prover cannot know in advance the number, type or nature of the operations that it will be required to perform in order to calculate the desired solution. Thus, such embodiments provide a more versatile and secure arrangement compared to prior art solutions which require the prover / verifier to perform the same, predetermined operations each time an authentication is required (albeit with different operands). The prover does not know, or need to know, in advance what the operations and / or operands of the challenge will be.

[0026] For example:

[0027] • During a first authentication session, the challenge data may comprise executable instructions which, when decrypted and executed on the prover's computing resource cause the resource to perform a particular mathematical calculation using two operands that are specified within or hard coded into the executable challenge data;

[0028] • However, during a second authentication session, the challenge data may comprise executable instructions which, when decrypted and executed on the prover's computing resource cause the resource to perform a particular Boolean operation on two specified strings followed by a hash of the result. Such embodiments may comprise the step of:

[0029] • generating and encrypting (using the prover's public key), by the verifier, a given challenge wherein the challenge comprises machine executable instructions that are arranged for execution by a processor such that the processor will execute the given challenge; preferably wherein execution of the challenge by the process will produce, deterministically, a result; and / or

[0030] • decrypting (using a private key corresponding to the prover's public key) the encrypted challenge received from the verifier and executing the decrypted challenge on the prover's processor to produce, deterministically, the result; the method may comprise the step of sending the result from the prover to the verifier as (at least part of) the solution data to the verifier's challenge.

[0031] Additionally, or alternatively, some embodiments of the disclosure may comprise use of blockchain transactions to implement aspects of the disclosed method. For example, the challenge data can be provided in a first blockchain transaction associated with token(s) that can only be spent if the correct solution is provided by the input of a second transaction. In accordance with certain embodiments, the key and any associated algorithm(s) used for encryption and decryption of the challenge data may be the same as, or at least compatible with, the algorithm(s) used by the blockchain system / protocol that the embodiment is arranged for implementation with.

[0032] Beneficial aspects, variations and effects of such embodiments are discussed in more detail below.

[0033] BRIEF DESCRIPTION OF THE DRAWINGS

[0034] 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:

[0035] Figure 1 is a schematic block diagram of a system for implementing a blockchain,

[0036] Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain, Figure 3A is a schematic block diagram of a client application,

[0037] Figure 3B is a schematic mock-up of an example user interface that may be presented by the client application of Figure 3A,

[0038] Figure 4 is a schematic block diagram of some node software for processing transactions, Figure 5 is a flowchart illustrating an overview of an example embodiment of the disclosure. Figure 6 is a flowchart illustrating the embodiment of Figure 5 from a verifier's perspective. Figure 7 is a flowchart illustrating the embodiment of Figure 5 from a prover's perspective. Figure 8 illustrates an example of a blockchain-implemented embodiment in accordance with the disclosure.

[0039] Figure 9 provides a simple diagram illustrating an overview of the disclosure.

[0040] DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0041] We now provide a detailed description of the disclosure with reference to the accompanying drawings. Embodiments may include, but are not limited to: solutions for securing and verifying data, controlling access to controlled resources, proving identity and / or authorisation, implementing agreements between computer-based resources.

[0042] In an example shown in Figure 9, a first node 910 (which may also be referred to as a first user, verifier, first party, first entity or Alice) sends an encrypted challenge 930 to a second node 920 (which may also be referred to as a second user, second party, prover, second entity or Bob). The challenge 930 can also be called a 'puzzle' or 'challenge data'. The challenge has been encrypted using the Bob's public cryptographic key. The encryption may be performed by, or on behalf of, Alice 910.

[0043] The challenge 930 can take any form of task that Alice 910 chooses, or which the parties agree on in respect of the nature, form etc of the challenge. For example, the parties may agree that the challenge will be a mathematical question such as a multiplication of two operands, or the identification of the 100thword in a given document, or the number of specified items in a given image. However, the actual challenge data chosen or used by Alice during a particular verification session remains unknown to Bob while the challenge remains encrypted. Upon receipt, Bob 920 uses his corresponding private key to decrypt Alice's challenge. The decryption reveals and outputs the unencrypted challenge. In other words, decryption enables Bob to know what Alice's challenge is. While it is in its encrypted form, the content of the challenge is not known to Bob (or any other party). Therefore, the decryption enables Bob 920 to compute a solution 940 and send it to Alice 910 as proof that he must have decrypted her challenge 930 and must, therefore, have knowledge or possession of the private key. The solution 940 may also be referred to as 'proof' or 'proof data', or and 'answer', or 'solution data'. Thus, the solution 940 comprises an indication that Bob:

[0044] • Has possession or knowledge of the private cryptographic key;

[0045] • Has decrypted Alice's challenge.

[0046] The indication may also be referred to as 'evidence', 'confirmation', 'verification' or 'proof'. As the challenge has been encrypted using Bob's public cryptographic key, it can only be decrypted using its corresponding private key. Thus, if Bob does not have the private key, he is unable to decrypt the challenge and provide the correct solution 940.

[0047] Upon receipt of Bob's proof 940, Alice 910 may then act accordingly, depending on the use case in which the disclosure is implemented. For example, in some cases, Alice 910 may be a bank. When registering for his bank account he provided Alice with his memorable phrase. When Bob 920 subsequently requests access to his account, Alice uses Bob's public key to encrypt a message asking Bob for the 3rdand 8thcharacters of his memorable phrase plus the first character of his postcode and the last digit of the year in which he was born. Bob's provision of the correct solution 940 can serve as verification or proof to Alice that he is the authorised owner of a particular bank account, because not only does he know the answers to the question, but he would not even have known the question (as he would not have been able to decrypt the challenge) if he was not who he says he is. Upon provision of the correct solution, Alice may allow access to the account. If he fails to provide the correct solution, Bob's access request is denied. In any event, Alice may take the step of confirming that the solution provided to her by Bob is the correct solution for the encrypted challenge she sent to him. We now provide some example embodiments and use cases.

[0048] Zero-Knowledge Proof Including Processing of Challenge Data

[0049] As explained above, embodiments of the disclosure may comprise an improved ZNP technique in which a prover provides a verifier with a puzzle or challenge solution that serves as evidence that data that has been encrypted using a public key associated with the prover has been decrypted using the corresponding private key.

[0050] Turning to Figure 5, an example method formed in accordance with the disclosure comprises a sequence of steps which are undertaken by a first and second party, who we will call Alice and Bob respectively, to perform a ZNP. In accordance with ZNP terminology we will refer to Alice as the verifier and Bob as the prover. In a practical implementation, Alice and Bob could be computer-based resources such as mobile phones, laptops, servers, nodes on a network etc.

[0051] In some embodiments, the challenge may comprise a question that Bob needs to provide an answer to. The question (and possibly accompanying data such as operands or metadata) is encrypted by Alice using Bob's public key. She then sends the encrypted question to Bob and awaits a solution in response. For example, as suggested above, the question might comprise a mathematical operation operand(s) which the prover has to use to calculate the answer; or the question could be "what is the 10thword on line 7 of page 30 in this document?"; or "how many squares in this image include flowers"? In other embodiments, the challenge may require proof of data that is known to both Alice and Bob in advance. For example, Alice may ask Bob to provide the 2nd, 5thand 8thcharacters of a pre-selected or determine phrase or string. In such cases, the method may comprise the step of storing the predetermined data in a storage facility that is accessible by Alice and Bob, such that Alice and Bob can gain access to the predetermined data when necessary. In all these cases, Bob would only be able to provide the correct answer if he has been able to decrypt the question, and in order to do that he must have knowledge of the private key that corresponds to the public key that Alice used to encrypt her challenge question.

[0052] In another embodiment, the evidence may be provided by processing the unencrypted data itself using one or more specified operations to produce a result or output. The output can then serve as the evidence that Bob provides to Alice. For example, the output could be the hash of a data item chosen by Alice. If the processed version of the data returned to Alice matches what she expects, the required evidence of decryption (and thus knowledge of the private key) can be deemed satisfied. Examples of such an embodiment are now provided for illustration, with reference to Figures 5 to 8.

[0053] In the Figure 5 example, Alice needs to verify that Bob is who he says he is, and Bob needs to prove his identity. He wishes to do so without revealing any other information about himself to prevent disclosure of sensitive data during transit. For example, consider a situation where Alice is a healthcare provider and Bob is a patient. In order to use Alice's services, Bob needs to prove to Alice that it is actually him making the access request. Bob has installed Alice's healthcare app on his mobile phone which comprises a digital wallet for secure generation, storage, sharing and use of cryptographic keys.

[0054] At step S500 of Figure 5: during registration via the app, Bob's wallet generates a cryptographic key pair and stores the private key in a secure portion of memory on the device. It uploads Bob's public key to Alice's server where it is stored in association with his healthcare data record(s). So now Bob has his secret key and Alice has Bob's corresponding public key.

[0055] When Bob wants to access Alice's services, he makes a request to do so via the app. In order to verify the identity of the requester, Alice retrieves Bob's public key from storage and uses it to encrypt a piece of data (referred to in the figures as a data item, but can also be referred to as the challenge, challenge data or puzzle). This is shown at step S510. Before encryption, Alice's data is referred to as the unencrypted version. She keeps a copy of the original, unencrypted data.

[0056] The data item could take any suitable form that Alice chooses, such as a message, an image, a file, a document, multimedia content, machine executable code, audio file etc. In some embodiments multiple data items may be encrypted and used in the ZNP process, but for the sake of simplicity we will refer to only one data item in our example.

[0057] At step S520, Alice sends the encrypted data to Bob. She knows that only Bob has (or at least should have) the secret key that can decrypt her encrypted message.

[0058] At Step S530, Bob's app receives the encrypted data from Alice and retrieves the private (secret) key. It uses the key to decrypt Alice's encrypted data. So now Bob and Alice both now have an unencrypted version of Alice's data item.

[0059] At step S540, Bob's app processes the unencrypted version of the data item. The processing can take any suitable form that Alice and Bob have agreed to use. For example, the processing may comprise the use of one or more mathematical operations, Boolean operations, hash functions, encryption operations, masking functions, bitwise operations etc. In some embodiments, different types of operations may be used in combination e.g. a concatenation of two data items followed by hash of the result. Essentially, they may agree to use any suitable, machine executable operation(s) that takes data as input and outputs a processed version of the inputted data. In other examples, they may not agree on the operation beforehand, and Alice may specify the operation to be performed by Bob. This may, in some cases, be specified as part of the challenge data e.g. as metadata, or in a separate message to Bob. In our example, they agree that they will use a hash operation. Advantageously, hashing algorithms provide a one-way function that is quick and simple to execute.

[0060] Thus, at Step S540 Bob hashes the unencrypted challenge data and in step S550 he sends the hash to Alice. Alice receives the hash from Bob. At Step S560, Alice hashes her copy of the original, unencrypted data. So now she has Bob's hash of the unencrypted data and also a hash that she herself has generated of the unencrypted data. At step S570 she compares the two hashes to see if they match. If they do (Step S580) Alice knows that Bob must have a copy of the private key that corresponds to the public key she has stored in association with Bob's record. This is because Bob must have decrypted the data in order to be able to hash it and produce the correct proof, and he can only decrypt it if he has the correct, corresponding private key. Thus, the hash may be referred to in ZNP parlance as the 'witness'. Bob has been able to prove his identity to Alice. Conversely, Alice is able to verify Bob's identity. Importantly, this process is conducted between the two parties without revealing any other information that could have been intercepted by an unauthorised party during the exchange. If the hash is intercepted, it is meaningless.

[0061] It is noted that the verification fails (Step S590) if Alice's comparison of the two hashes does not result in a match. Either party can then take appropriate steps such as retrying the verification process, or Alice may send an alert to a remove source indicating that a potentially illegitimate party has attempted to gain access.

[0062] It is also noted that the method of transmission between Bob and Alice can take any suitable form or a plurality of forms. For example, they may transmit data between them via a computing network such as the Internet, or a LAN or WAN, or via a wireless communication protocol such as Bluetooth, and / or via Near Field Communication (NFC) etc. The data transmission method(s) used will be selected from known data transmission methods according to the particular implementation being put into use.

[0063] Turning now to Figure 6, this process is illustrated from Alice's perspective. Let us assume that the necessary initial steps have been taken (e.g. Bob has downloaded Alice's app, Bob has generated a public-private key pair, a process has been chosen for subsequent verification purposes etc). At step S600 Alice obtains Bob's public key and stores it in association with Bob's records as above. At step S610, she uses the received public key to encrypt a data item, which she then sends to Bob at step 620.

[0064] At step S630, she receives a hash from Bob. She generates her own hash of the original, unencrypted data item and compares it with the hash received from Bob (steps S640, S650). As above, if Bob and Alice's hashes match (Step S660) then Bob has proved his identity to Alice and she will grant him access to the controlled resource(s) that he has requested. Alternatively, if the hashes do not match (step S670) then the verification fails and one or both of them may take remedial steps as appropriate.

[0065] Turning now to Figure 7, the process is illustrated from Bob's perspective. Again, let us assume that Bob's wallet has been installed and has generated a key pair, the public key of which has been sent to Alice for storage in association with his data record. Now, at step S710, Bob obtains at least one encrypted data item from Alice. She has performed the encryption using Bob's public key.

[0066] At step S720 Bob uses the private key to decrypt the data he has received, thus providing Bob with an unencrypted version of Alice's data. At step S730 he processes (e.g. hashes) the unencrypted data to generate the witness (hash). At step S740 Bob sends the hash to Alice so she can verify using the comparison with her own generated hash as explained above.

[0067] As shown in Figure 7, Bob now waits to receive a further communication from Alice. The communication will either indicate a successful verification and thus permission to access the controlled resource(s) e.g. his healthcare data, or the communication may be indicative of a failed verification and denial of access to the controlled resource(s).

[0068] In some embodiments, Bob may process his decrypted version of Alice's challenge data using one or more operations or functions before he sends the decrypted then processed challenge data back to Alice as his solution. In this way, Bob sends an encoded solution to Alice. This provides an additional security layer as Bob's response is not sent to Alice in its 'raw', original state which may lead to a compromise in security if his response is intercepted. For example, if Alice's challenge data comprises a password or memorable phrase that is associated with Bob, then sending Bob's solution to the Alice in its unencrypted, original form would pose a security risk if his message is compromised. The more processing operations that the Bob applies to his solution, the more secure his response to Alice will be, as the interceptor would need to know which operations have been applied and any parameters that have been used. Therefore, in a preferred embodiment Bob may apply two or more (encoding) operations to his solution before sending it to Alice e.g. the solution may be hashed and then encrypted with a cryptographic key.

[0069] In some cases, the cryptographic key used for encrypting the solution may be a key (e.g. public key) associated with or derived from a (private) key associated with Alice. In such cases, Alice will use her private key to decrypt Bob's solution after she receives it from him. This provides the advantage that Bob knows that the original message really did come from Alice. Alice may prove this to Bob by responding to him with her own evidence of decryption. In other words, Alice may repeat the steps above by providing to Bob some data that he can be sure must have been obtained by Alice after decrypting his encoded solution. For this purpose, Alice and Bob may agree between them on a challenge that Alice will solve in order to provide proof to Bob, or Bob may send a request to Alice for her to solve his challenge. This request may form part of his response to Alice's challenge, or be sent separately.

[0070] In some embodiments, Bob and Alice may agree or share knowledge between them of which encoding operations Bob and / or Alice will use to secure the solutions, possibly including any parameters that will be used in their encoding operations.

[0071] Deterministic Sub-Key Generation

[0072] A number of variations can be implemented in respect of the process set out above. For example, in some embodiments Bob's key pair may be obtained using a deterministic key generation technique. For example, international patent application PCT / IB2017 / 050856 (published as W02017 / 145016 and which is incorporated herein by reference) discloses methods and systems for generating a common secret independently at two separate nodes.

[0073] The disclosed embodiments can also be used to generate deterministic subkey pairs from a master key pair. Advantageously, the sub-key generation can be performed by each party such that they are able to calculate the other's public sub-key based on knowledge of the master public key. This means that if Alice already knows Bob's master public key, and a message and common generator G that the parties have agreed on, Alice can generate a deterministic public subkey for Bob for each validation session that is initiated. Bob is able to generate the corresponding private subkey himself.

[0074] This provides the advantage that no new public keys need to be sent from Bob to Alice for subsequent process executions, reducing the risk of unauthorised interception of the public key and also saving time and resources due to avoidance of the data transmission.

[0075] Blockchain-Implemented Embodiment(s)

[0076] In some embodiments, a blockchain may be used to perform or enhance one or more of the operations of the disclosed method(s). The disclosure is not intended to be limited for use with one particular blockchain protocol or type of protocol model, although Bitcoin may be used herein for illustrative purposes given its widespread familiarity.

[0077] In a blockchain-implemented version of the disclosure such as illustrated in Figure 8, Alice may create a blockchain transaction (Txl) with an output 810 (also known as an outpoint) that is locked and arranged such that it can only be unlocked (i.e. spent) upon fulfilment of specific criteria. Alice can specify in the criteria that Bob must provide the ZNP witness i.e. the processed version of the encrypted data via a further transaction Tx2 that is written to the blockchain 800.

[0078] In other words, instead of Alice providing an app that Bob installs on his device as used for the illustrations above, and communications going directly between Bob and Alice, in this version the data transmission between the parties is performed using transactions that are placed on the blockchain ledger. In order to provide the required proof, Bob must satisfy the criteria in her locking script 810, thus unlocking Alice's output 810 and transferring control of some associated tokens to Bob's input 820. Alice may also, as an option, require Bob to provide the public key that can then be compared with the public key that Alice knows Bob has. This can provide an extra check to further enhance security.

[0079] Advantageously, the key and associated algorithm(s) used for encryption / decryption of the challenge may be the same as, or at least compatible with, that which is used or required by the blockchain and its associated protocol. In other words, the same keys can be used for encryption / decryption of the challenge data as for signing in the blockchain transaction. The cryptographic algorithm(s) concerned will depend on the blockchain / protocol that is being used for a given implementation.

[0080] For example, the Bitcoin protocol uses Elliptic Curve Digital Signature Algorithm (ECDSA). Elliptic Curve cryptography (ECC) and ECDSA share the same key method. Therefore, an ECDSA key / address can be used with ECC.

[0081] Suppose that Ao is an identity key associated with Alice. In our example, Ao may be generated for PKI or web of trust purposes. Similarly, Bo is an identity key associated with Bob. Using the deterministic key generation techniques of PCT / IB2017 / 050856 mentioned above, Alice generates a sub key Ai from her key Ao, and Bob generates a subkey Bi from his key Bo. Recall that this allows them to independently derive the other's public subkey. In our non-limiting example, Ai and Bi are ECDSA keys as known to be used with Bitcoin for signing and releasing tokens (cryptocurrency) associated with outputs.

[0082] Alice now generates a funding transaction that that spends one or more tokens to her address Ai . As a result, she now has token(s) associated with Ai in an unspent output on the ledger. Alice encrypts her challenge data file F using Bob's public key Bo :

[0083] P P(Enc(B0y) = E(i) She creates a blockchain transaction that spends to Bob's Bi address and includes her encrypted challenge E^. If Bob can decrypt E^ then he must have the private master key Priv(B 0)). Advantageously, the signature proof is only available to Alice.

[0084] Suppose that the challenge that Alice inserted into her transaction comprises a hash puzzle where Bob needs to solve the hash of F in a transaction that is arranged to spend the output that Alice has set up:

[0085] Hash(F) = SF

[0086] If Bob provides the required challenge solution in the corresponding unlocking script, he has digitally signed with his private key. Alice knows that Bob signed because the token(s) associated with the unspent output have now been spent, and this is recorded in the ledger. Advantageously, Bob's signature can be deemed to be proof of his consent to one or more propositions. Such a proposition could comprise, for example, voting for a particular option in a plurality of options, or agreeing to accept an offer, or indicating a desired to proceed with a pre-determined action or course of action e.g. for a network node to begin transmitting data etc. Where the proposition is an offer for goods or services, the challenge data may comprise all or some of a contract or agreement.

[0087] Benefits and aspects of this approach include, but are not limited to:

[0088] • The provision of an auditable and immutable transaction log that is implemented on the blockchain;

[0089] • The verification processing is handled on-chain, transferring the processing burden away from Alice / Bob's local devices and enabling automation of the process;

[0090] • Bob is able to provide the required proof without revealing his identity or other information;

[0091] • Alice has on-chain proof that Bob has signed with his key because her output from Txl has been spent to his input in TX2;

[0092] • A time lock mechanism can be provided by Alice in her transaction Txl such that if Bob does not complete the session and fails to produce the required solution within a specified time period, the time lock mechanism executes and one or more tokens associated with the output are returned to Alice; Alice does not lose tokens to Bob if he cannot successfully provide the required proof;

[0093] • the same cryptographic method (e.g. Elliptic Curve Cryptography) can be used for encryption / decryption of the challenge as the for the digital signature(s) applied to the transaction. In other words, Alice can arrange her blockchain transaction so that the same keys are used for both. This ensures that the party signing the spending transaction(TX2) is the same as the as the party who decrypts the encrypted challenge, and provides enhanced security and traceability because Alice has multiple forms of proof with regard to Bob's actions - he has decrypted the challenge, signed the blockchain transaction and received token(s) spent to his address;

[0094] • Provision of the correct puzzle solution can be interpreted as an indication that Bob has decrypted the data item and thus has access to it in its unencrypted form. In certain use cases such as licensing or other agreements, Bob's provision of the witness can be taken by Alice as an acceptance of the terms and conditions in her data item, or as an acknowledgement of receipt of the information conveyed by the data item e.g. risks or legal disclaimers associated the product or service being provided.

[0095] EXAMPLE SYSTEM OVERVIEW

[0096] Certain embodiments of the disclosure may use or interact with a blockchain. 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.

[0097] 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.

[0098] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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, 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.

[0109] 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).

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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 outputbased 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.

[0117] UTXO-BASED MODEL

[0118] 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.

[0119] 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.

[0120] 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 " TxT. 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 “ Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is T1 the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0121] 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.

[0122] One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0123] 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, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA] contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0124] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

[0125] 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.

[0126] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0127] 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.

[0128] SIDE CHANNEL

[0129] 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.

[0130] CLIENT SOFTWARE

[0131] Figure 3A illustrates an example implementation of the client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 comprises a transaction engine 401 and a user interface (Ul) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data over the side channel 301, and / or send transactions to one or more nodes 104 to be propagated through the blockchain network 106, in accordance with the schemes discussed above and as discussed in further detail shortly.

[0132] The Ul layer 402 is configured to render a user interface via a user input / output (I / O) means of the respective user's computer equipment 102, including outputting information to the respective user 103 via a user output means of the equipment 102, and receiving inputs back from the respective user 103 via a user input means of the equipment 102. For example the user output means could comprise one or more display screens (touch or nontouch screen) for providing a visual output, one or more speakers for providing an audio output, and / or one or more haptic output devices for providing a tactile output, etc. The user input means could comprise for example the input array of one or more touch screens (the same or different as that / those used for the output means); one or more cursor-based devices such as mouse, trackpad or trackball; one or more microphones and speech or voice recognition algorithms for receiving a speech or vocal input; one or more gesture-based input devices for receiving the input in the form of manual or bodily gestures; or one or more mechanical buttons, switches or joysticks, etc.

[0133] Note: whilst the various functionality herein may be described as being integrated into the same client application 105, this is not necessarily limiting and instead they could be implemented in a suite of two or more distinct applications, e.g. one being a plug-in to the other or interfacing via an API (application programming interface). For instance, the functionality of the transaction engine 401 may be implemented in a separate application than the Ul layer 402, or the functionality of a given module such as the transaction engine 401 could be split between more than one application. Nor is it excluded that some or all of the described functionality could be implemented at, say, the operating system layer.

[0134] Where reference is made anywhere herein to a single or given application 105, or such like, it will be appreciated that this is just by way of example, and more generally the described functionality could be implemented in any form of software.

[0135] Figure 3B gives a mock-up of an example of the user interface (Ul) 500 which may be rendered by the Ul layer 402 of the client application 105a on Alice's equipment 102a. It will be appreciated that a similar Ul may be rendered by the client 105b on Bob's equipment 102b, or that of any other party.

[0136] By way of illustration Figure 3B shows the Ul 500 from Alice's perspective. The Ul 500 may comprise one or more Ul elements 501, 502, 502 rendered as distinct Ul elements via the user output means.

[0137] For example, the Ul elements may comprise one or more user-selectable elements 501 which may be, such as different on-screen buttons, or different options in a menu, or such like. The user input means is arranged to enable the user 103 (in this case Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the Ul element on-screen, or speaking a name of the desired option (N.B. the term "manual" as used herein is meant only to contrast against automatic, and does not necessarily limit to the use of the hand or hands).

[0138] Alternatively or additionally, the Ul elements may comprise one or more data entry fields 502, through which the user can ... These data entry fields are rendered via the user output means, e.g. on-screen, and the data can be entered into the fields through the user input means, e.g. a keyboard or touchscreen. Alternatively the data could be received orally for example based on speech recognition.

[0139] Alternatively or additionally, the Ul elements may comprise one or more information elements 503 output to output information to the user. E.g. this / these could be rendered on screen or audibly.

[0140] It will be appreciated that the particular means of rendering the various Ul elements, selecting the options and entering data is not material. The functionality of these Ul elements will be discussed in more detail shortly. It will also be appreciated that the Ul 500 shown in Figure 3 is only a schematized mock-up and in practice it may comprise one or more further Ul elements, which for conciseness are not illustrated.

[0141] NODE SOFTWARE

[0142] Figure 4 illustrates an example of the node software 450 that is run on each blockchain node 104 of the network 106, in the example of a UTXO- or output-based model. Note that another entity may run node software 450 without being classed as a node 104 on the network 106, i.e. without performing the actions required of a node 104. The node software 450 may contain, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that contains one or more of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The consensus module 455C may contain a validation module (not shown) configured to validate transactions according to the blockchain protocol. The validation module may instead be separate from the consensus module 455C. One or more of the modules may operate in parallel. A node 104 may contain additional modules. The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Txj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 152i (Txm-), then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Txtbased on the pointer in the input of Txj. Txtmay be published on the blockchain 150, in which case the protocol engine may retrieve Txtfrom a copy of a block 151 of the blockchain 150 stored at the node 104. Alternatively, Txtmay yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txtfrom the ordered set 154 of unpublished transactions maintained by the nodel04.

[0143] Either way, the script engine 451 identifies the locking script in the referenced output of Txtand passes this to the script engine 452.

[0144] The script engine 452 thus has the locking script of Txtand the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx0and Tx are illustrated in Figure 2, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

[0145] By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it "unlock" the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result "true". Otherwise it returns the result "false".

[0146] In an output-based model, the result "true" from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of TXj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Txthas not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node's respective ordered set of transactions 154 for incorporating in a block 151, and the propagation module 455P forwarding Txj to another blockchain node 104 in the network 106. Optionally, in embodiments the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

[0147] Note also that the terms "true" and "false" herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, "true" can refer to any state indicative of a successful or affirmative outcome, and "false" can refer to any state indicative of an unsuccessful or non-affirmative outcome. For instance in an account-based model, a result of "true" could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).

[0148] FURTHER REMARKS

[0149] 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.

[0150] 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).

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] TERMINOLOGY

[0156] Herein, we use the term 'obtaining' to include any or all of the terms in the following nonlimiting, non-exhaustive list: receiving (from a source), receiving from or across a computer- implemented network, accessing (e.g. from storage, reading from a computer-based storage resource etc), generating, calculating, deriving or otherwise coming into possession of.

[0157] We use the phrase 'making available' to include any or all of the terms in the following nonlimiting, non-exhaustive list: sharing (e.g. across a computer-implemented network), providing (e.g. placing at a location or in / on a facility that enables access to the item that is being made available), sending, transmitting, communicating or distributing.

[0158] We use the phrase 'processing' to include any or all of the terms in the following nonlimiting, non-exhaustive list: applying a function or operation to, storing, reading or accessing from a computer-based resource, storing or writing to a computer-based resource, calculating, deriving, outputting (from a machine, a machine implemented or executed process, or a mathematical function), providing, transmitting or communicating, changing or adapting.

[0159] The terms 'output' and 'endpoint' as used to refer to blockchain transactions are to be understood as synonymous and may be used interchangeably herein.

[0160] When referring to an action performed by a user, we use the term 'by' to include 'on', 'at', and / or 'on behalf of'. One or more other parties may perform at least some or all of the action on behalf of the user. The other party / parties may be authorised by the user to perform the action(s) on their behalf. For example, Alice may delegate or outsource encryption of the challenge to an authorised third party.

[0161] Blockchain-implemented embodiments disclosed herein may be arranged for interaction with a blockchain ledger, network, nodes and associated protocol substantially as described herein in the section entitled "Example System Overview". The term 'blockchain' may be used herein for ease of reference to refer to any one or more of: a blockchain ledger, network, nodes and associated protocol.

[0162] ENUMERATED CLAUSES

[0163] Embodiments of the present disclosure provide methods and computer-implemented systems. The methods / systems of the disclosure may be described as any one or more items of the following, non-exhaustive and non-limiting list:

[0164] • A Zero Knowledge Proof method / system

[0165] • A verification method / system

[0166] • A method / system for proof of decryption

[0167] • A method / system for proof of knowledge or possession of a (private) cryptographic key; preferably, the cryptographic key corresponds to a public key in a given cryptographic key pair; • A method for controlling access to one or more controlled resources (e.g. data, bank account, network, vehicle etc.)

[0168] • An identity verification method / system

[0169] • A cryptography-based security method / system

[0170] • A data security and / or transmission method / system.

[0171] Some embodiments can be implemented using a blockchain for provision and execution of the challenge and / or solution.

[0172] Any one or more of the enumerated clauses provided herein may comprise the step of: verifying the proof data (i.e. Bob's solution), and may comprise the further step of providing access to, or prohibiting access to, a controlled resource based on successful verification of the proof. One or both of these steps may be performed by or on behalf of Alice.

[0173] Embodiments of the present disclosure are provided in the following enumerated clauses / statements for the purpose of illustration, and without limitation. Any clause or feature recited in respect of one particular statement or set of statements is not to be regarded as thus limited, and may be used in combination with any other feature(s), clause(s) or statement(s).

[0174] Embodiments disclosed herein may provide:

[0175] Enumerated clause set 1:

[0176] 1.1. A computer-implemented method comprising: obtaining, by a second party, challenge data that has been encrypted by a first party using a public key associated with the second party; using, by the second party, the private key associated with the public key to decrypt the challenge data; and providing proof data from the second party to the first party, the proof data comprising (or providing / being / serving as / interpretable as) an indication that the challenge data has been decrypted by the second party. 1.2. A computer-implemented method comprising: making challenge data available, by a first party to a second party, wherein the challenge data has been encrypted using a public key associated with the second party; and obtaining proof data from the second party comprising an indication that the challenge data has been decrypted by the second party.

[0177] 1.3. A computer-implemented method comprising: making challenge data available, by a first party to a second party, wherein the challenge data has been encrypted using a public key associated with the second party; using, by the second party, the private key to decrypt the challenge data; generating, by the second party, proof data comprising an indication that the challenge data has been decrypted by the second party; and obtaining the proof data from the second party by the first party.

[0178] 1.4. The computer-implemented method of any preceding clause, wherein the indication comprises one or more of: a processed version of the decrypted challenge data; an answer to a question, puzzle or challenge that is based on or derived from the decrypted challenge data; a hash of the decrypted challenge data.

[0179] The decrypted challenge data may be processed using one or more operations or functions. One or more of the operations may be a hash function. In some embodiments, the second party may, after decrypting the challenge data, re-encrypt the challenge data using a public key associated with the first party.

[0180] 1.5. The computer-implemented method of any preceding clause, and further comprising the step: agreeing on, between the first and second parties, at least one operation for use in generating the proof data.

[0181] In other words, the first and second parties may agree, in advance of the second party generating / providing the proof data to the first party, upon at least one operation that the second party will use in order to be able to decrypt the challenge data and / or generate the proof data. The computer-implemented method of any preceding clause, wherein the proof data is obtained, based on or derived from the decrypted challenge data using one or more of: a mathematical operation, a Boolean operation, a one-way function such as a hash function, an encryption operation, a masking function, a bitwise operation, or any predetermined, machine-executable operation that takes data as input and outputs a processed version of the inputted data. The computer-implemented method of any preceding clause, and further comprising one or more of the following steps: i) generating the processed version of the decrypted challenge data; ii) obtaining, by the first party, the public key associated with the second party; iii) using the public key associated with the second party to encrypt the challenge data. The computer-implemented method of any preceding clause, wherein: the first party is a verifying party and the second party is a proving party. The computer-implemented method of any preceding clause, and further comprising the step: determining whether or not the second party has decrypted the challenge data based on a comparison of the proof data with a at least one portion of known solution data.

[0182] 1.10. The computer-implemented method of clause 1.9, and further comprising the step: if it is determined, based on the outcome of the comparison, that the second party has decrypted the challenge data: interpreting the outcome of the comparison as one or more of the following in respect of the second party: verification of the second party's identity; authorisation or permission for the second party to access a controlled resource; verification that the second party is in possession of, or has access to, the private key; acceptance, agreement or confirmation of an intention to proceed with, by the second party, to a proposition, offer, contract or pre-determined potential course of action; acknowledgement of the decrypted challenge data.

[0183] 1.11. The computer-implemented method of any preceding clause, and further comprising one or more of: i) using a deterministic key generation technique to obtain (e.g. generate or compute) the public key and / or the private key; ii) verifying the proof data and, preferably, providing access to, or prohibiting access to, a controlled resource based on successful verification of the proof; iii) storing, or generating, at or on behalf of the first party, known solution data that comprises a solution to a challenge based on or provided within the challenge data.

[0184] A 'deterministic key generation technique' will be readily understood by a person skilled in the art as comprising a process of generating cryptographic keys in a deterministic manner. Such techniques may comprise the use of a key derivation function (KDF) and / or a seed. The computer-implemented method of any preceding clause, and further comprising the step: providing the proof data in a second blockchain transaction to satisfy one or more conditions specified in a first blockchain transaction. The computer-implemented method of clause 1.12, wherein the method further comprises one or more of: i) providing the public key associated with the second party in the second blockchain transaction; ii) providing a blockchain address based on, derived from or associated with, the public key associated with the second party, in the first and / or second blockchain transaction; iii) using the private key, or a derivative of the private key, to sign at least a portion of the second blockchain transaction. computer-implemented method comprising: obtaining, by a second party via a first blockchain transaction, challenge data that has been encrypted by a first party using a public key associated with the second party; using, by the second party, the private key associated with the public key to decrypt the challenge data; and providing proof data from the second party to the first party via a second blockchain transaction, the proof data comprising an indication that the challenge data has been decrypted by the second party. A computer-implemented method comprising: making challenge data available, by a first party to a second party via a first blockchain transaction, wherein the challenge data has been encrypted using a public key associated with the second party; and obtaining proof data from the second party via a second blockchain transaction, the proof data comprising an indication that the challenge data has been decrypted by the second party.

[0185] 1.16. A computer-implemented method comprising: making challenge data available, by a first party to a second party via a first blockchain transaction, wherein the challenge data has been encrypted using a public key associated with the second party; using, by the second party, the private key to decrypt the challenge data; generating, by the second party, proof data comprising an indication that the challenge data has been decrypted by the second party; and obtaining the proof data from the second party by the first party via a second blockchain transaction.

[0186] 1.17. 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 clauses 1.1 to 1.16.

[0187] 1.18. 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 clauses 1.1 to 1.16.

[0188] Additionally, or alternatively, in accordance with another form of wording, embodiments disclosed herein may provide:

[0189] Enumerated clause set 2:

[0190] 2.1. A computer-implemented method comprising: obtaining encrypted data by a second party, wherein the encrypted data is generated by a first party using a public key associated with the second party to encrypt an unencrypted version of the data; using the private key to obtain the unencrypted version of the data at the second party providing a processed version of the unencrypted data to the first party.

[0191] The data may be referred to as 'challenge data'.

[0192] 2.2. A computer-implemented method comprising: making encrypted (challenge) data available to a second party, wherein the encrypted (challenge) data is generated using a public key associated with the second party to encrypt an unencrypted version of the (challenge) data; comparing a processed version of the unencrypted (challenge) data with a processed version of the unencrypted (challenge) data obtained from the second party.

[0193] 2.3. A computer-implemented method comprising: making encrypted (challenge) data available to a second party from a first party, wherein the encrypted (challenge) data is generated using a public key associated with the second party to encrypt an unencrypted version of the (challenge) data; obtaining, at the first party from the second party, a processed version of the unencrypted (challenge) data; comparing the processed version of the unencrypted (challenge) data obtained from the second party with a processed version of the unencrypted (challenge) data generated by the first party.

[0194] 2.4. The computer-implemented method of any preceding clause, and further comprising the step: agreeing on, between the first and second parties, at least one operation for use in generating the processed version of the unencrypted data. The computer-implemented method of clause 2.4, wherein the at least one operation comprises one or more of: a mathematical operation, a Boolean operation, a hash function; an encryption operation, a masking function, a bitwise operation, or any predetermined machine executable operation that takes data as input and outputs a processed version of the inputted data. The computer-implemented method of any preceding clause, and further comprising one or more of the following steps: i) generating a processed version of the unencrypted data; ii) obtaining, by the first party, the public key associated with the second party; iii) using the public key associated with the second party to encrypt the unencrypted version of the data. The computer-implemented method of any preceding clause, wherein: the first party is a verifying party and the second party is a proving party. The computer-implemented method of any preceding clause, and further comprising the step: determining whether or not the second party has decrypted the encrypted data based on the outcome of the comparison. The computer-implemented method of clause 2.8, and further comprising the step: if it is determined, based on the outcome of the comparison, that the second party has decrypted the encrypted data: interpreting the outcome of the comparison as one or more of the following in respect of the second party: verification of the second party's identity; verification that the second party is in possession of, or has access to, the private key; acceptance or agreement to the terms of a contract; acknowledgement of the unencrypted version of the data.

[0195] 2.10. The computer-implemented method of any preceding clause, and further comprising the step: using a deterministic key generation technique to obtain the public key and / or the private key.

[0196] 2.11. The computer-implemented method of any preceding clause, and further comprising the step: providing the processed version of the unencrypted data in a second blockchain transaction to satisfy one or more conditions specified in a first blockchain transaction.

[0197] 2.12. The computer-implemented method of clause 2. 11, wherein the method further comprises: providing the public key associated with the second party in the second blockchain transaction.

[0198] In some embodiments, the keys used for encryption / decryption of the data, and the keys used for signing in respect of the blockchain transaction or at least a part thereof may be formed or derived from the same or a compatible cryptographic algorithm.

[0199] 2.13. 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 clauses 2.1 to 2.12. 14. A computer program embodied on computer-readable storage and configured so as, when executed on one or more processors, to perform the method of any of clauses

[0200] 2.1 to 2.12

[0201] Additionally, or alternatively, in accordance with another form of wording, embodiments disclosed herein may provide:

[0202] Enumerated clause set 3:

[0203] 3.1 A computer-implemented method comprising: obtaining, by a second party, challenge data that has been encrypted by a first party using a public key associated with the second party; wherein the challenge data comprises machine executable instructions which, when executed on a computing resource, will cause the computing resource to perform at least one operation and generate (deterministically) an output; using, by the second party, the private key associated with the public key to decrypt the challenge data; and providing proof data from the second party to the first party, the proof data comprising (or providing / being / serving as / interpretable as) an indication that the challenge data has been decrypted by the second party; wherein the proof data comprises the (deterministic) output.

[0204] 3.2 A computer-implemented method comprising: sending, by a first party to a second party, challenge data that has been encrypted by the first party using a public key associated with the second party; wherein the challenge data comprises machine executable instructions which, when executed on a computing resource (of the second party), will cause the computing resource to perform at least one operation and generate (deterministically) an output; and receiving, by the first party and from the second party, proof data comprising (or providing / being / serving as / interpretable as) an indication that the challenge data has been decrypted by the second party; wherein the proof data comprises the (deterministic) output.

[0205] Thus, the challenge data comprises at least one machine executable instruction arranged, when executed, to produce at least one output / result. The output(s) may be deterministic in that the same output(s) will be produced each time the same instruction(s) is / are executed with the same operand(s) as input(s). The proof data may comprise the output(s).

[0206] The method may further comprise:

[0207] • using, by the second party, the private key associated with the public key to decrypt the challenge data;

[0208] • executing the decrypted challenge data on the computing resource.

[0209] Clauses 31.1 and / or 3.2 may comprise one or more of:

[0210] • receiving the encrypted challenge data at the second party and from the first party;

[0211] • repeating the steps (i.e sending a further encrypted challenge data from the first party to the second party, receiving the further encrypted challenge data from the first party at / by the second party, using the private key to decrypt the further challenge data by the second party; executing the decrypted further challenge data on a processor of the second party's computing resource; and sending the deterministic output of the execution from the second party to the first party as proof data that the second party has decrypted the further challenge data); wherein the further challenge data comprises different operations and / or operands to the operations relative to the (first) challenge data.

[0212] One, some or all of the steps of any embodiment(s) provided herein may be performed by at least one computing resource comprising at least one processor and associated memory. Communications between the first and second parties may be conducted over at least one electronic network arranged to transmit digital data. Disclaimer

[0213] All references cited herein are incorporated by reference to the maximum extent allowable by law Any incorporation by reference of documents herein is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents herein is further limited such that no claims included in the documents are incorporated by reference herein. Any incorporation by reference of documents herein is yet further limited such that any definitions provided in the documents are not incorporated by reference herein unless expressly included herein.

Claims

CLAIMS1. A computer-implemented method comprising: obtaining, by a second party, challenge data that has been encrypted by a first party using a public key associated with the second party; using, by the second party, the private key associated with the public key to decrypt the challenge data; and providing proof data from the second party to the first party, the proof data comprising an indication that the challenge data has been decrypted by the second party.

2. A computer-implemented method comprising: making challenge data available, by a first party to a second party, wherein the challenge data has been encrypted using a public key associated with the second party; and obtaining proof data from the second party comprising an indication that the challenge data has been decrypted by the second party.

3. A computer-implemented method comprising: making challenge data available, by a first party to a second party, wherein the challenge data has been encrypted using a public key associated with the second party; using, by the second party, the private key to decrypt the challenge data; generating, by the second party, proof data comprising an indication that the challenge data has been decrypted by the second party; and obtaining the proof data from the second party by the first party.

4. The computer-implemented method of any preceding claim, wherein the indication comprises one or more of: a processed version of the decrypted challenge data;an answer to a question or puzzle that is based on or derived from the decrypted challenge data; a hash of the decrypted challenge data.

5. The computer-implemented method of any preceding claim, and further comprising the step: agreeing on, between the first and second parties, at least one operation for use in generating the proof data.

6. The computer-implemented method of any preceding claim, wherein the proof data is based on or derived from the decrypted challenge data using one or more of: a mathematical operation, a Boolean operation, a one-way function such as a hash function, an encryption operation, a masking function, a bitwise operation, or any predetermined, machine-executable operation that takes data as input and outputs a processed version of the inputted data.

7. The computer-implemented method of any preceding claim, and further comprising one or more of the following steps: i) generating the processed version of the decrypted challenge data; ii) obtaining, by the first party, the public key associated with the second party; iii) using a public key associated with the first party to encrypt the proof data, preferably wherein this encryption is performed before the proof data is provided from the second party to the first party.

8. The computer-implemented method of any preceding claim, wherein:the challenge data comprises at least one machine executable instruction arranged, when executed, to produce at least one output; preferably wherein the proof data comprises the at least one output.

9. The computer-implemented method of any preceding claim, and further comprising the step: determining whether or not the second party has decrypted the challenge data based on a comparison of the proof data with known solution data.

10. The computer-implemented method of claim 9, and further comprising the step: if it is determined, based on the outcome of the comparison, that the second party has decrypted the challenge data: interpreting the outcome of the comparison as one or more of the following in respect of the second party: verification of the second party's identity; authorisation or permission for the second party to access a controlled resource; verification that the second party is in possession of, or has access to, the private key; acceptance, agreement or confirmation of an intention to proceed with, by the second party, to a proposition, offer, contract or pre-determined potential course of action; acknowledgement of the decrypted challenge data.

11. The computer-implemented method of any preceding claim, and further comprising one or more of: i) using a deterministic key generation technique to generate the public key and / or the private key; ii) verifying the proof data and, preferably, providing access to, or prohibiting access to, a controlled resource based on successful verification of the proof;iii) storing, or generating, at or on behalf of the first party, known solution data that comprises a solution to a challenge based on or provided within the challenge data.

12. The computer-implemented method of any preceding claim, and further comprising the step: providing the proof data in a second blockchain transaction to satisfy one or more conditions specified in a first blockchain transaction.

13. The computer-implemented method of claim 12, wherein the method further comprises one or more of: i) providing the public key associated with the second party in the second blockchain transaction; ii) providing a blockchain address based on, derived from or associated with, the public key associated with the second party, in the first and / or second blockchain transaction; iii) using the private key, or a derivative of the private key, to sign at least a portion of the second blockchain transaction.

14. A computer-implemented method comprising: obtaining, by a second party via a first blockchain transaction, challenge data that has been encrypted by a first party using a public key associated with the second party; using, by the second party, the private key associated with the public key to decrypt the challenge data; and providing proof data from the second party to the first party via a second blockchain transaction, the proof data comprising an indication that the challenge data has been decrypted by the second party.

15. A computer-implemented method comprising:making challenge data available, by a first party to a second party via a first blockchain transaction, wherein the challenge data has been encrypted using a public key associated with the second party; and obtaining proof data from the second party via a second blockchain transaction, the proof data comprising an indication that the challenge data has been decrypted by the second party.

16. A computer-implemented method comprising: making challenge data available, by a first party to a second party via a first blockchain transaction, wherein the challenge data has been encrypted using a public key associated with the second party; using, by the second party, the private key to decrypt the challenge data; generating, by the second party, proof data comprising an indication that the challenge data has been decrypted by the second party; and obtaining the proof data from the second party by the first party via a second blockchain transaction.

17. 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 16.

18. 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 16.

Images