Commitment to unconfirmed data

Abstract

A computer implementation method for committing to and verifying data, wherein the data comprises a definite component and one or more undetermined components. The commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component. A committing party obtains a commitment transaction for at least one undetermined component, the commitment transaction refers to the blockchain transaction and / or blockchain transaction output, includes the undetermined component and / or an obfuscated version of the undetermined component, and submits the commitment transaction to one or more blockchain nodes in the blockchain network. A verifying party obtains a commitment transaction for at least one undetermined component, verifies that the commitment transaction refers to the blockchain transaction and / or blockchain transaction output, obtains a proof of inclusion for the commitment transaction, and uses the proof of inclusion to verify that the commitment transaction is recorded on the blockchain.

Description

[Technical Field]

[0001] This disclosure relates to methods for committing to unconfirmed data, and / or controlling who can provide confirmed unconfirmed data, methods for providing unconfirmed data, methods for determining unconfirmed data, and methods for verifying unconfirmed data. [Background technology]

[0002] Creating an immutable record of certain data at a given point in time is often useful. Such provable data integrity can be achieved by cryptographically committing the data. Two useful methods of committing data are hash functions and digital signatures. These commitments can be stored in a secure location or made public through media such as blockchains or national newspapers. [Overview of the project]

[0003] A problem arises when parties want to make a commitment but not all the data is known. Suppose that at the time of commitment t=0, some (or all) of the data is uncertain, but is given at a later time t=1. As an example, consider the birth of a baby who has not yet been named. The hospital wants to create an official birth certificate. Some data is already known, such as the date and time of birth, hospital name, country, and parents' names. However, there is one crucial piece of information that is not yet certain: the baby's name.

[0004] According to one aspect disclosed herein, a method for committing to data implemented by a computer is provided. The data comprises a determined component and one or more undetermined components, and the commitment is based on i) the determined component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component, the method comprising: being performed by a committing party to obtain each commitment transaction for at least one undetermined component, wherein each commitment transaction refers to each blockchain transaction and / or each blockchain transaction output and includes an obfuscated version of the undetermined component and / or the undetermined component; and submitting each commitment transaction to one or more blockchain nodes of a blockchain network.

[0005] According to one aspect disclosed herein, a data verification method implemented by a computer is provided. The data comprises a committed component and one or more unconfirmed components, and the commitment is based on i) a committed component and ii) each blockchain transaction and / or each blockchain transaction output for each unconfirmed component, the method being performed by a verifying party, comprising the steps of: obtaining each commitment transaction for at least one unconfirmed component, wherein each commitment transaction includes an unconfirmed component and / or an obfuscated version of the unconfirmed component; verifying that each commitment transaction refers to each blockchain transaction and / or each blockchain transaction output; obtaining each proof of inclusion for each commitment transaction; and using each proof of inclusion, verifying that each commitment transaction is recorded on the blockchain.

[0006] Another embodiment disclosed herein provides a data determination method implemented by a computer. The data comprises a definite component and one or more indeterminate components, and the commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each indeterminate component. The method is performed by a determination party and comprises the steps of: obtaining a commitment; obtaining the definite component; obtaining one or more indeterminate components from each blockchain transaction; and determining the data based on one or more indeterminate components.

[0007] Furthermore, a computer implementation method for a commitment to data access control is described, wherein the data comprises a definite component and one or more undetermined components, and the method is performed by an access control party and comprises the steps of: i) generating a commitment based on the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component; and issuing and / or providing the commitment to one or more parties.

[0008] Embodiments of this disclosure enable the creation of meaningful data commitments even when some of the data is uncertain. This is achieved using blockchain by specifying a transaction or unused transaction output (UTXO) at the time of commitment and adding data after the transaction or UTXO has been used. In effect, this technique allows parties to commit a data reference (where the data is or will be) rather than the data itself. The double-spend protection and immutability of the blockchain ensure that this data will later be uniquely determined. The same technique can be used to update data, for example, when an individual's address or name changes on verifiable identification documents such as a passport or driver's license.

[0009] Embodiments of this disclosure offer some or all of the following advantages: The blockchain's double-spend prevention feature ensures that there is only one confirmed state for unconfirmed data. Embodiments are compatible with existing signature and commitment algorithms and are private in the sense that no one intercepting the blockchain can know anything about the data unless it is intentionally made public. Blockchain transaction sizes are minimal and consistent. This results in low and predictable transaction fees. Complex smart contract logic is not required. By using a service provider, users do not need to sign blockchain transactions or hold tokens. The blockchain provides an immutable timestamp indicating the date and time the data was confirmed. To verify confirmed data, the verifying party does not need to be a participant in the blockchain network.

[0010] To aid in understanding the embodiments of this disclosure and to show how such embodiments may be carried out, the accompanying drawings are shown as examples. The drawings show the following: [Brief explanation of the drawing]

[0011] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates an example of a transaction that may be recorded on the blockchain. [Figure 3] This is a schematic block diagram of an example system for implementing the embodiments of this disclosure. [Figure 4] This is a schematic diagram of an unconfirmed data commitment using transaction output point vout0, where confirmed data will be provided later in the expenditure transaction. [Figure 5] This diagram schematically illustrates the use of SPV certificates to show that transactions Tx0 and Tx1 have been made public on the blockchain. [Figure 6]This diagram schematically illustrates how data is updated using a transaction chain, with each transaction having one input and one output. [Figure 7] This diagram schematically illustrates the Pedersen commitment, which is used to link confirmed data to blockchain transactions. [Figure 8] This diagram schematically illustrates a transaction in which an electronic signature is provided as confirmed data. [Figure 9] This diagram schematically illustrates a transaction in which an individual's name is provided as confirmed data. [Modes for carrying out the invention]

[0012] 1. Commitment to uncertain data Figure 3 shows an example of a system 300 for implementing the embodiments described herein. System 300 includes an access control party 301, a commit party 302, a verification party 303, and a determination party 304. Each party is illustrated individually, although in some examples one or more parties may be combined as a single party. Each party is configured to communicate with one, some, or all of the other parties through their respective (direct or indirect) connections. For simplicity, only some of the possible connections are shown in Figure 3. Each party operates its own computer equipment. For example, each party may operate computer equipment as described below, with Alice 103a and Bob 103b operating it. Furthermore, each party may be configured to perform all or some of the actions described below, with Alice 103a and / or Bob 103b performing them. System 300 also includes one or more blockchain nodes 104 or blockchain network 106. At least some of the parties are configured to communicate with the blockchain network 106 through their respective (direct or indirect) connections. While Figure 3 shows all parties connected to the blockchain network 106, this is not required in all examples.

[0013] The access control party 301 is configured to generate a data commitment that includes one or more uncertain (unknown, missing, etc.) components. That is, the data is incomplete at the time the commitment is generated. For example, the data may be missing a signature, or there may be multiple choices for a particular field of the data (e.g., a date) and that choice has not yet been selected or decided. The missing data may not be known until a future date. For example, the missing data could be the application number of a patent application that is assigned after filing.

[0014] The access control party 301 generates a commitment based on the deterministic component (known part) of the data (that is, as a function thereof). The commitment is also based on a blockchain transaction (e.g., the transaction identifier (TxID) of the blockchain transaction) and / or an unspent output (UTXO) of the blockchain transaction (e.g., the transaction identifier and output index of the blockchain transaction). In some examples, the commitment is also based on a salt value. For brevity, UTXO is used hereinafter to mean "transaction output identifier".

[0015] The commitment may be generated by hashing the deterministic component with the TxID and / or UTXO (and optionally the salt). In this case, the commitment is (or at least includes) a hash digest. For example, inputs to the hash function may be combined (e.g., concatenated) prior to hashing. The hash function is an SHA-based hash function such as SHA256. An HMAC function can be used as the hash function. In some examples, the deterministic component and the TxID and / or UTXO (and optionally the salt) may form leaves of a hash tree (e.g., a Merkle tree). Accordingly, the hash digest is the root of the hash tree.

[0016] Alternatively, the commitment can be generated by generating a Pedersen commitment based on the deterministic component and the TxID and / or UTXO (and optionally the salt). The commitment can also be generated using other types of zero-knowledge proofs.

[0017] Commitments can also be generated based on metadata about the indeterminate components of the data. For example, metadata may specify one or more properties of the indeterminate data, such as the data type (value, integer, string, etc.), the data length (in bytes, etc.), a description of the data, or an identifier for the intended supplier of the data.

[0018] Until now, only one indeterminate component has been considered. More generally, data can contain multiple indeterminate components, such as a name and signature. One or more indeterminate components may be associated with a single transaction and / or transaction output. Also, one or more indeterminate components may be associated with different transactions and / or transaction outputs. In cases where there are multiple indeterminate components, the commitment is based on the determined component and each transaction and / or UTXO associated with the indeterminate component. For example, if there are three indeterminate components, each associated with a different UTXO, the commitment is based on the three UTXOs. On the other hand, if two of the three UTXOs are associated with the same UTXO, the commitment is based on the two UTXOs, one for the indeterminate component and the other for the remaining two indeterminate components.

[0019] The access control party 301 can make the commitment public. For example, the commitment is made public on blockchain 150. The access control party 301 can send the commitment to blockchain network 106 to have it recorded on blockchain 150, or the access control party 301 can send the commitment to an intermediary party, who then sends the commitment to blockchain network 106.

[0020] In addition or alternatively, the access control party 301 may send the commitment to one or more parties (for example, the committing party 302, the verifying party 303, and / or the deciding party 304).

[0021] As mentioned above, each indeterminate component is associated with a transaction and / or UTXO. Each transaction and UTXO can be controlled by a party. For example, a transaction or UTXO can be locked to a public key associated with a party. Each transaction or UTXO can be controlled by the same party. Alternatively, each transaction or UTXO can be controlled by different parties. In some examples, a particular party can control multiple transactions and / or UTXOs. In some examples, access control party 301 can control one or more transactions and / or UTXOs. A particular transaction and / or UTXO can be controlled by multiple different parties, for example, if it is locked to multiple public keys. For example, a UTXO can be controlled by access control party 301 and commit party 302.

[0022] Access control party 301 may sign the commitment, for example, using an ECDSA signature. The signature may be signed using a private key corresponding to a public key known to be associated with access control party 301. For example, the public key may be an authenticated public key issued to access control party 301. Access control party 301 may publish the signature on the blockchain, for example. For example, the commitment and signature may be included in the same transaction. Access control party 301 may send the signature to one or more parties, such as commit party 302, verifying party 303, and / or decision party 304. The signature proves that the commitment was made by access control party 301.

[0023] The access control party 301 may obtain a proof of inclusion (e.g., an SPV proof) for each transaction that forms the basis of the commitment, i.e., one proof per transaction. The access control party 301 may request these proofs from the blockchain node 104. This does not preclude the access control party 301 from generating these proofs. The access control party 301 may publish these proofs and / or send them to one or more parties, such as the commit party 302, the verifying party 303, and / or the decision party 304.

[0024] The definitive component of the data may be known to one or more parties, such as commit party 302. Otherwise, access control party 301 may send the definitive component of the data to one or more parties, such as commit party 302, verifier party 303, and / or decision party 304. The definitive component may be made public by access control party 301, for example, on blockchain 150. For example, the definitive component may be included in the same transaction as the commitment (and optionally, the signature signing the commitment).

[0025] The committing party 302 is configured to provide, or at least commit, one or more undetermined components. Here, we describe an example in which the committing party provides / commits one of the undetermined components, but more generally, the committing party 302 may provide / commit all or part of the undetermined components.

[0026] The committing party 302 obtains a commitment transaction that references the transaction or UTXO associated with the indeterminate component of the data. This commitment transaction contains the indeterminate component and / or the commitment of the indeterminate component (for example, as the output of the transaction). To avoid confusion, the “commitment of the indeterminate component” is referred to as the “obfuscated version of the indeterminate component,” or simply the “obfuscated component.” The obfuscated component can be generated by hashing and / or encrypting the indeterminate component. The obfuscated component may be a Pedersen commitment (or other type of zero-knowledge proof) of the indeterminate component. The obfuscated component may be based on the commitment (i.e., the commitment generated by the access control party 301) and / or the salt value. This commitment transaction may contain the commitment generated by the access control party 301.

[0027] A committing party 302 may generate a commitment transaction or receive a commitment transaction from another party. A committing party 302 may generate an undetermined component or receive an undetermined component from another party. A committing party 302 may generate an obfuscated component or receive an obfuscated component from another party.

[0028] The committing party 302 sends the commitment transaction to the blockchain network 106. Alternatively, the committing party 302 can send the commitment transaction to another party (for example, the access control party 301), who can then send the commitment transaction to the blockchain network 106. Once recorded on blockchain 150, the commitment transaction immutably fixes the (previously) indeterminate components.

[0029] A transaction or UTXO referenced by a commitment transaction may be locked in the public key of commit party 302. Commit party 302 can sign the commitment transaction using the private key corresponding to that public key. The referenced transaction or UTXO may be locked in multiple public keys (for example, public keys managed by access control party 301). In that case, commit party 302 can send the commitment transaction to those parties for signing, or receive a commitment transaction that has already been signed by those parties.

[0030] In some examples, before generating a commitment transaction, commit party 302 can verify that the referenced transaction is recorded on blockchain 150. Commit party 302 can obtain and use a proof of inclusion to check whether the referenced transaction exists on blockchain 150. Commit party 302 can receive a proof (e.g., an SPV proof) from access control party 301.

[0031] Similarly, committing party 302 can obtain proof (e.g., SPV proof) that the commitment transaction is recorded on blockchain 150. This proof of inclusion can be received from blockchain node 104 or other parties, or generated by committing party 302. Committing party 302 can send this proof to one or more parties, such as access control party 301, verification party 303, and / or decision party 304.

[0032] In some examples, committing party 302 may update previously undetermined components. To do this, committing party 302 obtains an updated commitment transaction containing the updated version of the previously undetermined components and sends that updated commitment transaction to the blockchain network 106. This commitment transaction may be locked to a public key managed by committing party 302, and the updated commitment transaction may contain a signature corresponding to that public key. For example, the UTXO of the commitment transaction may be locked to the committing party's public key.

[0033] The verifying party 303 is configured to verify the commitment of one or more indeterminate components of the data. An example is described in which the verifying party 303 verifies one indeterminate component, but more generally, the verifying party 303 may verify some or all of the indeterminate components.

[0034] For a given indeterminate component of the data, verifying party 303 obtains a commitment transaction that commits to that indeterminate component, i.e., a commitment transaction that includes the component that was previously indeterminate (and is now determinate) or an obfuscated version thereof. Verifying party 303 can receive the commitment transaction from any party, for example, committing party 302, or from blockchain node 104. Verifying party 303 verifies that the commitment transaction refers to the transaction and / or UTXO associated with the indeterminate component, i.e., the transaction and / or UTXO that underlies the commitment generated by access control party 301.

[0035] The verifying party 303 verifies that the commitment transaction is recorded on blockchain 150. The verifying party 303 may obtain and use a proof of inclusion to check whether the commitment transaction exists on blockchain 150. The verifying party 303 may receive such proof (e.g., an SPV proof) from any of the parties, such as committing party 302.

[0036] The verifying party 303 obtains the public key associated with the party responsible for providing the unconfirmed component (for example, the committing party 302). The verifying party also obtains the signature and verifies that the signature signs the message containing the unconfirmed component or an obfuscated version, and that the signature is valid for the obtained public key. The signature can be included in the commitment transaction.

[0037] The verifying party 303 can obtain the commitment and confirmed components from, for example, the access controller 301 or the committing party 302. The verifying party 303 can verify that the commitment is the confirmed and unconfirmed commitment extracted from the commitment transaction. For example, the verifying party 303 can check that the hashes of the confirmed and unconfirmed components are the same as those of the commitment. In some examples, the verifying party 303 can verify that the unconfirmed components satisfy one or more conditions specified in the metadata that constitutes the commitment.

[0038] Decision-making party 304 is configured to determine the complete data. Decision-making party 304 obtains commitments and confirmed components. Commitments and confirmed components are sent to decision-making party 304 from one of the parties, such as access control party 301, commit party 302, and / or verification party 303. Decision-making party 304 also obtains one or more unconfirmed components of the data from each commitment transaction. Decision-making party 304 obtains commitment transactions from one of the parties, such as blockchain 150 or commit party 302. Decision-making party 304 uses the confirmed and unconfirmed components to determine the complete data; that is, decision-making party 304 uses the unconfirmed components to complete the data.

[0039] Decision-making party 304 can take action in response to or based on completed data. For example, completed data may be a contract, and upon completion, decision-making party 304 can act in accordance with the terms of that contract. Completed data may be a network address, which the decision-making party can use to send messages. Completed data may be an identifier of another party (for example, commit-making party 302), and decision-making party 304 can grant that party access to resources based on that identifier.

[0040] Access control party 301 may perform any action that is described as being performed by any of the commit party 302, the verifying party 303, and the decision party 304. Committing party 302 may perform any action that is described as being performed by any of the access control party 301, the verifying party 303, and the decision party 304. Verifying party 303 may perform any action that is described as being performed by any of the access control party 301, the committing party 302, and the decision party 304. Decision party 304 may perform any action that is described as being performed by any of the access control party 301, the committing party 302, and the verifying party 303.

[0041] 1.1 Commitment to Undetermined Data - Other Examples This section provides further examples of the embodiments described above. Some features are optional.

[0042] Throughout this section, we will consider a scenario with two timeframes: an initial time t=0 and a later time t=1. For example, the second timeframe can be considered as one day after the initial timeframe.

[0043] The message m is divided into a part m1 that is known at all times (t=0 and t=1) and a part m2 that is still unknown at time t=0 but is determined to be value d at the later time t=1.

[0044] We want to perform a commitment (Comm) on a portion of the data m at time t=0, even if data m2⊂m is unknown. This commitment can be, for example, the hash value of the data.

[0045] At time t=0, transaction Tx0, which includes output vout0, exists on the blockchain. When making a data commitment Comm, instead of waiting for unconfirmed data, output vout0 is recorded as a placeholder for the unconfirmed data. This is equivalent to setting m2=vout0 at time t=0, and therefore Comm=Comm(m1,vout0). As a simple example, Comm can be set as hash(m1|| vout0).

[0046] Later, at time t=1, the data is determined to a fixed value d. Transaction Tx1 is created, using vout0, and has an output (unavailable) containing a hash of the determined data. A schematic diagram of transactions Tx0 and Tx1 is shown in Figure 4.

[0047] Transaction Tx1 is broadcast to blockchain network 106 and made public in the block. The data is now fully committed. This can be thought of as equivalent to setting m2=d at time t=1. Blockchain 150's double-spend prevention feature means that at time t=1, there is a unique link from commitment Comm to the data record of Tx1.

[0048] If necessary, the data record of Tx1 may contain a pointer to the commitment Comm. For example, the output of Tx1 may be changed to OP_RETURN hash(d || Comm) or OP_RETURN HMAC(Comm, d). This means that there is a unique link linking the data record of Tx1 at time t=1 to the commitment Comm.

[0049] The use of output vout0 may be controlled by the data owner, service provider, or other party. This party can control what this data record is, but can never provide more than one data record, and the records provided will exist permanently on the blockchain.

[0050] To simplify things, let's assume that vout0 is embedded deep within many blocks of blockchain 150. Such an output point can be created at time t=-1, long before the commitment Comm. The output point may be provided by a dedicated service provider.

[0051] The lock script for vout0 can be configured to completely fix the structure of Tx1. For example, it can be fixed so that Tx1 has exactly one input and one unusable output.

[0052] If necessary, a salt can be included in the hash preimage to enhance privacy protection.

[0053] If a signature for data m is required at time t=0, this signature can be used to sign the commitment.

[0054] 1.1.1 SPV certification for efficient data validation Simple Payment Verification (SPV) is a method of proving that a transaction existed on the blockchain without accessing all block data. For an SPV proof, the verifying party needs access to the latest block header chain and a Merkle proof indicating that the transaction is included in the block. Currently, the size of a Bitcoin block header chain is approximately 64MB, and a Merkle proof for a transaction is less than 1kB. The only cryptographic primitive used in an SPV proof is a hash function, and it does not rely on the reliability or security of public-key cryptography. These characteristics make SPV a very useful and efficient protocol.

[0055] It should be noted that the above method requires a transaction output vout0 that is publicly available at a depth of many blocks in blockchain 150 at time t=0. The SPV proof of transaction Tx0 containing vout0 can be provided to the person committing or signing the unconfirmed data. In doing so, one can be assured that vout0 is indeed a valid blockchain output.

[0056] At time t=1, the data is finalized and recorded as a transaction on blockchain 150. If a third-party verifier wishes to verify the data, transactions Tx0 and Tx1 and the SPV proof of Tx1 may be provided. The verifier can explicitly confirm that the SPV proof of Tx1 is valid and that Tx1 is using the output of Tx0. (An additional SPV proof of Tx0 is not required.) A schematic diagram of the elements of the SPV proofs of Tx0 and Tx at different times is shown in Figure 5.

[0057] The above method can be verified by third parties who are not participants in the blockchain network by using SPV certificates. Verification only requires providing the latest block header list and the SPV certificate for the transaction.

[0058] The information available at two different points in time is summarized in Table 1 below. [Table 1]

[0059] 1.1.2 Data Update This method can be extended to updating data. In this case, a transaction chain can be used to specify how the data is updated. In a transaction chain, each transaction has an input corresponding to the previous transaction and an output specifying the next transaction. In the simplest example of a transaction chain, as shown in Figure 6, each transaction has only one input and one output.

[0060] Alternatively, each data element can specify the next UTXO to be used to update the data.

[0061] 1.1.3 Merkle Trees for Privacy and Efficiency The data is divided into a confirmed part and an unconfirmed part m=(m1,m2), where m2=vout0 at time t=0. It is convenient to structure these two parts as leaves of a Merkle tree and use the Merkle root as a commitment Comm = hash(hash(m1) || hash(vout0)).

[0062] This is convenient because it allows for easy verification of commitments without requiring confirmation or uncertainty about each other's existence. It is more efficient with larger data sizes and enhances privacy protection. Furthermore, it can be extended to include multiple distinct confirmed parts and multiple individual uncertain parts.

[0063] If a digital signature is required for the data at time t=0, this signature can be used to sign the Merkle root Comm.

[0064] 1.1.4 Pedersen Commitment to Maximum Privacy Protection Instead of using a hash function to link confirmed data to transaction Tx1, a Pedersen commitment can be used to enhance privacy. The problem with using a hash function is that anyone with access to the hash's preimage (and salt, if used) can verify a timestamped record of the confirmed data on the blockchain. If this is shared with an unauthorized party, that unauthorized party may be able to verify the link. This is a privacy issue.

[0065] To overcome this problem, technologies such as Pedersen commitments can be used to ensure that the link between data and blockchain records can only be verified by authorized parties. These authenticated parties are called designated verifiers, and the link is verified using zero-knowledge proofs. Since these proofs are linked to the designated verifier's public key, only the designated verifier can verify them.

[0066] It should be noted that the original data commitment Comm contains a reference to vout0. Instead of using a hash function, this commitment can include a Pedersen commitment. For example, Comm can be set to Comm = Pedersen (m1|| vout0). This allows you to control which users can verify that vout0 is associated with the commitment.

[0067] 1.1.5 Step-by-step workflow example Suppose Alice 103a asks Bob 103b to cryptographically sign a message m consisting of m and m2. Here, m2 is a placeholder for some data that is unknown at the time of signing or is kept secret from Alice or Bob.

[0068] The most intuitive template is to set m2=vout0, making the transaction output point the reference point for the desired data. The value of vout0 can be as small as the dust value, which is 1 satoshi at the time of writing. The lock script for vout0 can be constructed to provide secure access control to who can provide the desired data. For example, a P2PKH lock script for Bob's public key means that only Bob can provide the desired data, while a multi-signature lock script ensures that given data in an expenditure transaction is authorized by all necessary parties. Without losing generality, let's assume Daisy provides the data. The lock script is PK Daisy This will result in P2PKH. There are several implementation options. 1. Daisy can include the desired data in the spending transaction of vout0. 2. Daisy can include data commitments or hashes in spending transactions and can present the data separately to the verifying party off-chain. 3. Daisy can delegate its rights to another entity by paying vout0 to the target entity.

[0069] Additionally, it is possible to use PUSHTX or an equivalent to apply only one or more of Daisy's options, or none of them.

[0070] Another template format is m2 = metadata || vout0, where metaData can be used to specify what data can be expected from the expenditure vout0. An example of metaData is shown below. [Table 2]

[0071] This method is particularly effective if the data is unknown to Bob, the signer. By adding sufficient constraints to metaData, it can be ensured that Bob has not signed anything unintended or unexpected.

[0072] As a party to the verification, Charlie is m, Sig Bob PK Bob Tx1 and the Merkle proof of Tx1 are given. 1. Charlie is PK Bob Regarding m on Sig Bob We will verify this. 2. Charlie analyzes m as m1 and m2, and extracts metaData and vout0 from m2. 3. Charlie verifies the Merkle proof of Tx1 and confirms that Tx1 is using vout0. 4. Charlie extracts the data payload d from Tx1 and verifies that all constraints within metaData are not violated.

[0073] Assuming all steps are completed successfully, the complete message is represented by m1 and d. If only the hash value or commitment value of the data is given in the expenditure transaction, Charlie is expected to take d as input and verify its integrity against the hash value or commitment value.

[0074] If the data can be updated or delegated as specified in metaData, Charlie needs to trace the spending chain of vout0 back to the most recent transaction. Another way for Charlie is to take the entire transaction chain, represented by the transaction ID, and the Merkle proof of the most recent transaction as part of the input, and then query the spending status of the most recent transaction to ensure that its output is not yet unused.

[0075] 1.1.6 Use Cases This section presents four use cases for the protocol regarding commitments to unconfirmed data. 1. Document Signature 2. Digital Certificates 3. Associating IPv6 addresses with IDs 4. Decentralized Identifier (DID)

[0076] The first three use cases all involve digital signatures on unconfirmed data. The fourth use case (DID) does not involve a signature. Instead, it considers a commitment on the blockchain that includes unconfirmed data.

[0077] 1.1.6.1 Signing the document The term "document" can be replaced with "message" or "data item." Documents, messages, or data items may be in a human-readable or human-readable format. Furthermore, documents, messages, or data items may be created by a user or by a computer.

[0078] eSig refers to an unencrypted digital signature, while dSig refers to an encrypted digital signature.

[0079] Here, we consider a scenario where document m1 requires both eSig and dSig. The following example may be helpful to keep in mind. [Table 3]

[0080] It is important that dSig signs both m1 and eSig, thereby ensuring the integrity of both (i.e., that they cannot be changed in the future).

[0081] The scenario begins at time t=0 using document m1 (but without eSig or dSig). We are then asked to provide dSig without eSig. This is problematic because dSig is needed to sign eSig in order to ensure its integrity.

[0082] Instead of waiting for the eSig, you can use the method described above. Treat the eSig as unconfirmed data and sign a placeholder for the eSig. In this method, this placeholder will be the transaction output point vout0.

[0083] Specifically, at t=0, the document m and placeholder vout0 are combined into a Merkle tree, and the root root = hash (hash(m1) || hash(vout0)) is calculated. Then, dSig signs this root dSig(root).

[0084] At this point, the digital signature can be verified against document m1. Later, at time t=1, the digital signature is provided by the user. This hash is embedded in the transaction using vout0.

[0085] Although eSig was created later, dSig remains uniquely linked to eSig due to vout0 expenditure and the blockchain's double-spend prevention feature. An example transaction is shown in Figure 7.

[0086] 1.1.6.2 Digital Certificates Digital certificates such as X.509 are sets of attributes that are certified using a digital signature. At the current level of technology, all attributes must be known at the time of signing. The method described herein allows us to consider the case where one of the attributes is unknown. Let's look again at the example of a birth certificate mentioned in the introduction. The certificate would look like this: [Table 4]

[0087] The digital certificate is complete in the sense that it has a signature that proves the authenticity of the attribute. However, the baby's name at attribute position 4 is still undecided. Later, the parents decide to name the baby Charlie. A blockchain transaction Tx1 is created containing the hash of this name. This is broadcast to the blockchain network and is fully confirmed.

[0088] Because the name Charlie is easily guessable, salt is added to the transaction to keep the baby's name secret from those viewing the blockchain. An example transaction is shown in Figure 8.

[0089] 1.1.6.3 Association of IPv6 Addresses and IDs Internet Protocol version 6 (IPv6) is the latest version of the communication protocol used to locate and communicate with a global system of interconnected devices called the Internet. IPv6 addresses are 128 bits long and have the format 2001:db8:abcd:0012:0000:0000:0000:0000.

[0090] Each IPv6 address is divided into eight 2-byte groups separated by colons. These groups have the following functions: • Network address - The first three numeric groups (first 48 bits) of the subnet mask • Subnet address - The fourth numerical group of the subnet mask (bits 49 through 64) • Device address - The last four numeric groups (last 64 bits) of the subnet mask

[0091] The IPv6 address space is extremely vast. This means that IPv6 addresses can be used globally for a single purpose and do not change over time, unlike IPv4 addresses which need to be reused. Therefore, IPv6 addresses can be easily linked to a user's identity and managed by the user themselves.

[0092] In fact, users can generate their own IPv6 addresses and register themselves with the network.

[0093] Users are expected to have numerous IPv6 addresses corresponding to multiple devices. The problem then becomes, "How do we determine which IPv6 address corresponds to a specific person?" This is challenging because IPv6 addresses need to be associated with human names, and IPv6 addresses are long, cumbersome numbers (unlike, for example, email addresses).

[0094] One solution is to expose IPv6 addresses and their owners as a globally accessible repository. This repository uses a public key primary key (PK). IPv6Auth It can be assumed that it is managed by a trustworthy institution.

[0095] Such organizations may play an equivalent role for specific local subnetworks. These local networks are identified by the first four groups of IPv6 addresses.

[0096] Assume that an IPv6 address management authority limits the number of IPv6 addresses each user can register. For example, each user is assigned five IPv6 addresses. These addresses do not need to be predetermined. The technology disclosed herein can be used to create a certificate for registering five addresses that a user may decide in the future. An example of such a certificate is shown below. [Table 5]

[0097] The output point is controlled by the user, Alice herself. Let's say Alice wants to specify her first IPv6 address. To do this, Alice creates a transaction in the following format: [Table 6]

[0098] Once a transaction is sent to the blockchain network, Alice's IPv6 address is permanently associated with the certificate. Alice can create these IPv6 addresses at any time in the future. However, this method limits the number of addresses that can be linked to the aforementioned certificate to five. This limit is guaranteed by the blockchain's double-spend prevention feature, and no further intervention from an IPv6 certificate authority is required after the certificate is issued.

[0099] 1.1.6.4 Decentralized Identifier (DID) Decentralized identifiers (DIDs) are used to enable verifiable, decentralized digital identities. They are generally self-issued and self-managed. Verifiable credentials (VCs) are a set of claims that are cryptographically verifiable by the intended verifying party. While DIDs are entirely decentralized, VCs can be issued by trusted entities. Users can leverage the trustworthiness of VCs to enhance the trustworthiness of their DIDs by cryptographically linking them to their VCs. For example, if a driver's license is issued in the form of a public-key certificate, a user can request that their DID be included. On the other hand, as the virtual world becomes more important to users in the future, privacy will be necessary to prevent information leaks from the virtual world to the real world. Therefore, it is natural that users would not want to disclose their DID in the virtual world to real-world certificate authorities. Furthermore, having a driver's license might be an attribute that users want to link to future virtual identities that they have not yet registered or established in the virtual world. In practice, two scenarios are possible. 1. A DID is private and must be kept confidential from the credential issuer. 2. The DID is unknown to the issuer at the time the credential is issued.

[0100] One option to handle both scenarios is that the user commits an unused transaction output vout user , for example SHA256(vout user ), and includes it in the driver's license. As the verifying party, given the user's driver's license and the spending transaction of vout user , the following steps are performed: 1. Check that the driver's license is authentic. 2. Extract the commitment to vout user and confirm that it matches SHA256(vout user ). 3. Read the DID from the spending transaction and verify that the user is the owner of the DID.

[0101] Note that if a user commits to a vout that they do not control, no data can be added to the spending transaction. In addition, if another person's DID is added, the user cannot prove to the verifying party that they are the owner of that DID. Therefore, no benefit can be obtained through fraudulent activity. For this reason, it should be kept in mind that the certificate issuer does not need to know the user's DID to sign the commitment to vout user .

[0102] If verification is successful, the verifying party is confident that the user with the DID actually possesses a driver's license. Note that the verifying party does not even need to read any driver's license information other than the commitment. As a user, they have successfully linked the DID to a certificate issued by a trusted entity, thereby increasing the reliability of the DID. At the same time, privacy remains protected because the trusted entity has no efficient means of independently identifying the user's DID. Conversely, when creating a DID, a user may want to link it to credentials they will acquire in the future or existing credentials they will update in the future. Following a similar approach to the above, one or more placeholders can be added to the DID document specifying unused transaction output points managed by the user. Including unused transaction output points under the control of the credential issuer can also directly provide reliability for the corresponding credentials.

[0103] In summary, the described method can be used in four scenarios within the context of DID and VC. 1. DID was unknown at the time of VC issuance. 2. The DID should be kept private and only accessible to VC issuers. 3. VC is an attribute within the DID document that was not known at the time of DID creation. 4. VC is an attribute of a DID document that is expected to be updated regularly.

[0104] 2. Example of a System Overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0105] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0106] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any available output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Available outputs are sometimes called UTXOs ("unused transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit 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 to unlock the locking script of the pointed-to output. Thus, we consider a pair of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0107] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0108] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0109] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0110] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0111] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as 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, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0112] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that node 104 has accepted as legitimate and for which node 104 is not obligated to accept other transactions attempting to use the same output.

[0113] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. While spending or redeeming is certainly one common use, it does not necessarily mean the transfer of a financial asset. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0114] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0115] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0116] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0117] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0118] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0119] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, 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 include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0120] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and 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 removable optical drive.

[0121] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0122] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0123] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on the blockchain 150, since the blockchain 150 is a public body that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate it throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0124] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0125] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0126] 3. UTXO-based model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0127] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unused transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0128] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unused output 203 locked in Alice.

[0129] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0130] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0131] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to use transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in input 202 of the transaction.

[0132] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment v0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 also includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0133] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0134] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an unusable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0135] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0136] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0137] 4.Addendum Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0138] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0139] In a preferred embodiment of the present invention, the blockchain network 106 may be a Bitcoin network, and a Bitcoin node 104 performs at least some or all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0140] In other embodiments of the present invention, the blockchain network 106 does not have to be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0141] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0142] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0143] It will be understood that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, or programs are provided that conform to one or more of the following statements.

[0144] Statement 1. A computer implementation method for data commitment, wherein the data comprises a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component, and the method is performed by the committing party. For at least one undetermined component, A step of obtaining each commitment transaction, wherein each commitment transaction refers to the respective blockchain transaction and / or the respective blockchain transaction output, and includes an indeterminate component and / or an obfuscated version of the indeterminate component, The steps include submitting each commitment transaction to one or more blockchain nodes on the blockchain network and A method that includes [a certain feature].

[0145] Statement 2. The method described in Statement 1, wherein each commitment transaction contains a commitment and / or an obfuscated version of the undetermined component is based on the commitment.

[0146] Statement 3. The method according to Statement 1 or 2, wherein each blockchain transaction and / or each blockchain transaction output referenced by each commitment transaction is locked to the public key of a second party, and each commitment transaction includes a signature corresponding to the public key of a second party.

[0147] Statement 4. An obfuscated version of an undetermined component is based on the salt value, as described in any of Statements 1 through 3.

[0148] Statement 5. Steps to obtain proof of inclusion for each blockchain transaction, including each blockchain transaction and / or each blockchain transaction output, The step of using proof of inclusion to verify that each blockchain transaction is recorded on the blockchain and A method according to any one of statements 1 to 4, comprising:

[0149] Statement 6. The method of any one of Statements 1 to 5, comprising the step of generating an undetermined component and / or an obfuscated version of an undetermined component.

[0150] Statement 7. The method of any one of statements 1 to 6, comprising the step of receiving an undetermined component and / or an obfuscated version of an undetermined component.

[0151] Statement 8. The method described in any of Statements 1 through 7, wherein the obfuscated version of the undetermined component includes at least the hash of the undetermined component.

[0152] Statement 9. The method described in any of Statements 1 through 7, wherein an obfuscated version of the undetermined component includes at least the Pedersen commitment of the undetermined component.

[0153] Statement 10. The method described in any of Statements 1 through 7, wherein the obfuscated version of the undetermined component includes at least an encrypted version of the undetermined component.

[0154] Statement 11. The method of any of statements 1 to 10, wherein each commitment transaction and / or the output of each commitment transaction is controlled by a second party and / or one or more parties.

[0155] Statement 12. The steps include: referring to each commitment transaction and / or the output of each commitment transaction, and obtaining each updated commitment transaction, including the updated version of the unconfirmed component and / or the obfuscated version of the updated version of the unconfirmed component; The steps include ensuring that each updated commitment transaction is submitted to one or more blockchain nodes on the blockchain network, and The method described in statement 11, comprising:

[0156] Statement 13. Any method of any of Statements 1 through 12, comprising the step of disclosing and / or providing an unconfirmed commitment to one or more parties.

[0157] Statement 14. Steps to obtain proof of inclusion for each commitment transaction on the blockchain, The steps include disclosing and / or providing proof of inclusion to one or more parties and A method according to any one of statements 1 to 13, comprising:

[0158] Statement 15. A definite component is part of a message to be signed, and at least one undetermined component contains a signature to sign the message, or A confirmed component includes one or more complete parts of a digital certificate, and at least one unconfirmed component includes an incomplete part of a digital certificate, or The confirmed component includes one or more portions associated with the network address issuer, and at least one unconfirmed component includes the network address, or The definite component contains verifiable credentials, and at least one undetermined component contains a distributed identifier, or The method according to any one of statements 1 to 14, wherein the deterministic component includes at least a portion of a distributed identifier and at least one undeterministic component includes verifiable credentials.

[0159] Statement 16. Steps to generate a commitment, Steps to disclose and / or provide commitments to one or more parties and A method according to any one of statements 1 to 15, comprising:

[0160] Statement 17. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 16.

[0161] Statement 18. A computer program, embodied on computer-readable storage, configured to perform a method described in any of statements 1 to 16 when executed on one or more processors.

[0162] Statement 19. A computer implementation method for verifying data, wherein the data comprises a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) the respective blockchain transaction and / or the respective blockchain transaction output for each undetermined component, and the method is performed by the verifying party. For at least one undetermined component, A step of obtaining each commitment transaction, wherein each commitment transaction includes an undetermined component and / or an obfuscated version of the undetermined component, The steps include verifying that each commitment transaction refers to its respective blockchain transaction and / or its respective blockchain transaction output, The steps include obtaining proof of inclusion for each commitment transaction, The steps include verifying that each commitment transaction is recorded on the blockchain using each proof of inclusion, and A method that includes [a certain feature].

[0163] Statement 20. The steps of obtaining the public key associated with a given party, The steps include obtaining a signature that signs at least the undetermined components and / or an obfuscated version of the undetermined components, Steps to verify that the signature is valid for the public key and The method described in statement 19, comprising:

[0164] Statement 21. The method according to Statement 19 or 20, comprising the step of receiving a reference to each blockchain transaction and / or the output of each blockchain transaction.

[0165] Statement 22. Steps to obtain confirmed components, Steps to obtain commitment, A step to verify that the commitment is based on the definite component and the respective blockchain transactions and / or the respective blockchain transaction outputs. A method according to any one of statements 19 to 21, comprising:

[0166] Statement 23. A method according to any one of Statements 19 to 22, wherein the commitment is based on metadata indicating one or more expected characteristics of an undetermined component, and the method comprises a step of verifying that the undetermined component satisfies one or more expected characteristics.

[0167] Statement 24. A computer implementation method for determining data, wherein the data comprises a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component, and the method is performed by the decision-making party. Steps to obtain commitment, Steps to obtain confirmed components, The steps include obtaining one or more undetermined components from each blockchain transaction, A step of determining data based on one or more undetermined components and A method that includes [a certain feature].

[0168] Statement 25. The method according to Statement 24, comprising the step of performing one or more actions based on the determined data.

[0169] Statement 26. The method according to Statement 24 or 25, wherein the step of obtaining a commitment and / or confirmed component includes the step of receiving a commitment and / or confirmed component.

[0170] Statement 27. The method according to any of Statements 24 to 26, wherein the step of obtaining commitments and / or confirmed components includes the step of extracting commitments and / or confirmed components from public resources.

[0171] Statement 28. A method according to any of Statements 24 to 27, comprising the step of verifying that the commitment is based on a definitive component and the respective blockchain transaction and / or the respective blockchain transaction output.

[0172] Statement 29. For each undetermined component, The steps include: obtaining each commitment transaction, which includes the undetermined components and / or obfuscated versions of the undetermined components; The steps include verifying that each commitment transaction refers to its respective blockchain transaction and / or its respective blockchain transaction output, and A method according to any one of statements 24 to 28, comprising:

[0173] Statement 30. For each undetermined component, The steps include obtaining proof of inclusion for each commitment transaction, The steps include verifying that each commitment transaction is recorded on the blockchain using each proof of inclusion, and The method described in statement 29, comprising:

[0174] Statement 31. A method according to any one of Statements 24 to 30, wherein the commitment is based on metadata indicating one or more expected properties of one or more undetermined components, and the method comprises a step of verifying that one or more undetermined components satisfy one or more expected properties.

[0175] Statement 32. A definite component is part of a message to be signed, and at least one undefinite component contains a signature to sign the message, or A confirmed component includes one or more complete parts of a digital certificate, and at least one unconfirmed component includes an incomplete part of a digital certificate, or The confirmed component includes one or more portions associated with the network address issuer, and at least one unconfirmed component includes the network address, or The definite component contains verifiable credentials, and at least one undetermined component contains a distributed identifier, or The method according to any one of statements 24 to 30, wherein the deterministic component includes at least a portion of a distributed identifier and at least one undeterministic component includes verifiable credentials.

[0176] Statement 33. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 24 to 32.

[0177] Statement 34. A computer program, embodied on computer-readable storage, configured to perform a method described in any of statements 24 to 32 when executed on one or more processors.

[0178] Statement 35. A computer implementation method for a commitment to data access control, wherein the data comprises a deterministic component and one or more indeterministic components, and the method is performed by an access control party. i) a step of generating a commitment based on the confirmed component and ii) the respective blockchain transaction and / or the respective blockchain transaction output for each unconfirmed component, The steps of issuing and / or providing a commitment to one or more parties and A method that includes [a certain feature].

[0179] Statement 36. The method according to Statement 35, wherein the commitment comprises i) the confirmed component and ii) the hash of each blockchain transaction and / or each blockchain transaction output for each unconfirmed component.

[0180] Statement 37. The method of Statement 35, wherein the commitment includes i) the confirmed component and ii) the root of a hash tree generated based on the respective blockchain transaction and / or the respective blockchain transaction output for each unconfirmed component.

[0181] Statement 38. The method described in any of Statements 35 to 38, wherein one or more of each blockchain transaction and / or one or more of each blockchain transaction outputs are controlled by the respective parties.

[0182] Statement 39. The method described in Statement 38, wherein one or more of each blockchain transaction and / or each blockchain transaction output are controlled by different parties.

[0183] Statement 40. The method described in Statement 38, wherein one or more of each blockchain transaction and / or each blockchain transaction output are controlled by the same respective parties.

[0184] Statement 41. The method described in any of statements 38 to 40, wherein one or more of each blockchain transaction and / or one or more of each blockchain transaction outputs are controlled by their respective public keys.

[0185] Statement 42. Any method in any of Statements 38 to 41, wherein each party controls one or more of its respective blockchain transactions and / or their respective blockchain transaction outputs.

[0186] Statement 43. The method described in any of Statements 38 to 42, wherein one or more of each blockchain transaction and / or one or more of each blockchain transaction outputs are controlled by multiple respective parties.

[0187] Statement 44. Each blockchain transaction is a different blockchain transaction, and / or each blockchain transaction output is a different blockchain transaction output. The method described in any of statements 35 through 43.

[0188] Statement 45. The method in any of statements 35 to 43, wherein one or more of each blockchain transaction is the same blockchain transaction, and / or one or more of each blockchain transaction outputs is the same blockchain transaction output.

[0189] Statement 46. Any method described in any of statements 35 through 45, where the commitment is based on the salt value.

[0190] Statement 47. Steps to generate a signature based on the commitment, The steps of making the signature public and / or providing it to one or more parties and A method according to any one of statements 35 to 46, comprising:

[0191] Statement 48. For each undetermined component, The steps include obtaining proof of inclusion on the blockchain for each blockchain transaction and / or the output of each blockchain transaction, The steps include disclosing and / or providing proof of inclusion to one or more parties and A method according to any one of statements 35 to 47, comprising:

[0192] Statement 49. Any method described in any of Statements 35 through 48, in which the commitment includes the Pedersen commitment.

[0193] Statement 50. The method described in any of Statements 35 to 49, wherein the commitment is generated based on metadata indicating one or more expected characteristics of the undetermined components.

[0194] Statement 51. A method of any of Statements 35 to 50, comprising the step of disclosing and / or providing a definitive component to one or more parties.

[0195] Statement 52. A definite component is part of a message to be signed, and at least one undefinite component contains a signature to sign the message, or A confirmed component includes one or more complete parts of a digital certificate, and at least one unconfirmed component includes an incomplete part of a digital certificate, or The confirmed component includes one or more portions associated with the network address issuer, and at least one unconfirmed component includes the network address, or The definite component contains verifiable credentials, and at least one undetermined component contains a distributed identifier, or The method described in any of statements 35 to 51, wherein the deterministic component includes at least a portion of a distributed identifier and at least one undeterministic component includes verifiable credentials.

[0196] Statement 53. For at least one undetermined component, A step of obtaining each commitment transaction, wherein each commitment transaction refers to the respective blockchain transaction and / or the respective blockchain transaction output, The steps include submitting each commitment transaction to one or more blockchain nodes on the blockchain network and A method according to any one of statements 35 to 52, comprising:

[0197] Statement 54. Memory comprising one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 30.

[0198] Statement 55. A computer program, embodied on computer-readable storage, configured to perform, when executed on one or more processors, the method described in any of statements 35 to 53.

[0199] Another aspect disclosed herein may provide a method comprising actions of any combination of access control parties, commit parties, and verifying parties. Another aspect disclosed herein may provide a system comprising any combination of computer equipment of access control parties, commit parties, and verifying parties. [Explanation of symbols]

[0200] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output 301 Access Control Party 302 Committed Parties 303 Verification Party 304 Decision-making parties

Claims

1. A computer implementation method for data commitment, wherein the data comprises a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component, and the method is performed by the committing party. For at least one undetermined component, A step of obtaining each commitment transaction, wherein each commitment transaction refers to the respective blockchain transaction and / or the respective blockchain transaction output, and includes the undetermined component and / or an obfuscated version of the undetermined component, The steps include: submitting each of the aforementioned commitment transactions to one or more blockchain nodes in the blockchain network; A method that includes [a certain feature].

2. The method according to claim 1, wherein each of the aforementioned commitment transactions includes the commitment, and / or the obfuscated version of the undetermined component is based on the commitment.

3. The method according to claim 1 or 2, wherein each of the blockchain transactions and / or each of the blockchain transaction outputs referenced by each of the commitment transactions is locked to the public key of a second party, and each of the commitment transactions includes a signature corresponding to the public key of the second party.

4. The obfuscated version of the undetermined component is based on a salt value, according to any one of claims 1 to 3.

5. A step of obtaining proof of inclusion for each blockchain transaction, including each of the aforementioned blockchain transactions and / or the output of each of the aforementioned blockchain transactions, The steps include verifying that each of the aforementioned blockchain transactions is recorded on the blockchain using the proof of inclusion, and The method according to any one of claims 1 to 4, comprising:

6. The method according to any one of claims 1 to 5, comprising the step of generating the undetermined component and / or the obfuscated version of the undetermined component.

7. The method according to any one of claims 1 to 6, comprising the step of receiving the undetermined component and / or the obfuscated version of the undetermined component.

8. The method according to any one of claims 1 to 7, wherein the obfuscated version of the undetermined component includes at least a hash of the undetermined component.

9. The method according to any one of claims 1 to 7, wherein the obfuscated version of the undetermined component includes at least the Pedersen commitment of the undetermined component.

10. The method according to any one of claims 1 to 7, wherein the obfuscated version of the undetermined component includes at least an encrypted version of the undetermined component.

11. The method according to any one of claims 1 to 10, wherein each of the aforementioned commitment transactions and / or the output of each of the aforementioned commitment transactions is controlled by a second party and / or one or more parties.

12. The steps include: referring to each of the aforementioned commitment transactions and / or the output of each of the aforementioned commitment transactions, and obtaining each updated commitment transaction, which includes an updated version of the undetermined component and / or an obfuscated version of the updated version of the undetermined component; The steps include: ensuring that each of the aforementioned updated commitment transactions is submitted to one or more blockchain nodes in the blockchain network; The method according to claim 11, comprising:

13. The method according to any one of claims 1 to 12, comprising the step of disclosing and / or providing an undetermined commitment to one or more parties.

14. The steps include obtaining proof of inclusion for each of the aforementioned commitment transactions on the blockchain, The steps include disclosing and / or providing proof of each of the aforementioned inclusions to one or more parties, and The method according to any one of claims 1 to 13, comprising:

15. The definite component is part of the message to be signed, and at least one undetermined component includes a signature to sign the message, or The confirmed component includes one or more complete parts of the digital certificate, and at least one unconfirmed component includes an incomplete part of the digital certificate, or The determined component includes one or more portions associated with a network address issuer, and at least one undetermined component includes a network address, or The confirmed component includes verifiable credentials, and at least one unconfirmed component includes a distributed identifier, or The method according to any one of claims 1 to 14, wherein the determined component includes at least a portion of a distributed identifier and at least one undetermined component includes verifiable credentials.

16. The steps of generating the aforementioned commitment, The steps include disclosing and / or providing the aforementioned commitment to one or more parties. The method according to any one of claims 1 to 15, comprising:

17. A computer implementation method for verifying data, wherein the data includes a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) the respective blockchain transaction and / or the respective blockchain transaction output for each undetermined component, and the method is performed by the verifying party. For at least one undetermined component, A step of obtaining each commitment transaction, wherein each commitment transaction includes the undetermined component and / or an obfuscated version of the undetermined component, A step of verifying that each of the aforementioned commitment transactions refers to the respective blockchain transaction and / or the respective blockchain transaction output, The steps include obtaining proof of inclusion for each of the aforementioned commitment transactions, The steps include verifying that each of the aforementioned commitment transactions is recorded on the blockchain using the respective proof of inclusion, and A method that includes [a certain feature].

18. The steps include obtaining the public key associated with a given party, A step of obtaining a signature that signs at least the undetermined component and / or the obfuscated version of the undetermined component, A step of verifying that the signature is valid for the public key. The method according to claim 17, comprising:

19. The method according to claim 17 or 18, further comprising the step of receiving a reference to each of the aforementioned blockchain transactions and / or the output of each of the aforementioned blockchain transactions.

20. The steps include obtaining the confirmed component, The steps include obtaining the aforementioned commitment, A step of verifying that the commitment is based on the definitive component and the respective blockchain transactions and / or the respective blockchain transaction outputs. The method according to any one of claims 17 to 19, comprising:

21. The method according to any one of claims 17 to 20, wherein the commitment comprises the step of verifying that the undetermined component satisfies the one or more expected characteristics, based on metadata indicating one or more expected characteristics of the undetermined component.

22. A computer implementation method for determining data, wherein the data includes a definite component and one or more undetermined components, and the commitment is based on i) the definite component and ii) each blockchain transaction and / or each blockchain transaction output for each undetermined component, and the method is performed by the decision-making party. The steps include obtaining the aforementioned commitment, The steps include obtaining the confirmed component, The steps include obtaining one or more undetermined components from each of the aforementioned blockchain transactions, The step of determining the data based on the one or more undetermined components: A method that includes [a certain feature].

23. The method according to claim 22, further comprising the step of performing one or more actions based on the data determined above.

24. The method according to claim 22 or 23, wherein the step of obtaining the commitment and / or definitive component includes the step of receiving the commitment and / or definitive component.

25. The method according to any one of claims 22 to 24, wherein the step of obtaining the commitment and / or definitive component includes the step of extracting the commitment and / or definitive component from a public resource.

26. The method according to any one of claims 22 to 25, comprising the step of verifying that the commitment is based on the definitive component and the respective blockchain transactions and / or the respective blockchain transaction outputs.

27. For each undetermined component, The steps include obtaining each commitment transaction that includes the aforementioned undetermined component and / or an obfuscated version of the aforementioned undetermined component, A step of verifying that each of the aforementioned commitment transactions refers to the respective blockchain transaction and / or the respective blockchain transaction output. The method according to any one of claims 22 to 26, comprising:

28. For each undetermined component, The steps include obtaining proof of inclusion for each of the aforementioned commitment transactions, The steps include verifying that each of the aforementioned commitment transactions is recorded on the blockchain using the respective proof of inclusion, and The method according to claim 27, comprising:

29. The method according to any one of claims 22 to 28, wherein the commitment comprises the step of verifying that the one or more undetermined components satisfy the one or more expected characteristics, based on metadata indicating one or more expected characteristics of the one or more undetermined components.

30. The definite component is part of the message to be signed, and at least one undetermined component includes a signature to sign the message, or The confirmed component includes one or more complete parts of the digital certificate, and at least one unconfirmed component includes an incomplete part of the digital certificate, or The determined component includes one or more portions associated with a network address issuer, and at least one undetermined component includes a network address, or The confirmed component includes verifiable credentials, and at least one unconfirmed component includes a distributed identifier, or The method according to any one of claims 22 to 29, wherein the determined component includes at least a portion of a distributed identifier and at least one undetermined component includes verifiable credentials.

31. A memory having one or more memory units, Computer equipment comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 30.

32. A computer program, which is implemented on computer-readable storage and is configured to perform the method described in any one of claims 1 to 30 when executed on one or more processors.

Images