CN-113544722-B - Method of using blockchain

Abstract

The invention discloses a method which comprises the steps that a second party receives confirmation of a statement agreed by a first party, and the second party receives a piece of information after the confirmation and the first party encrypt and sign. To prove this, the second party generates its own cryptographic signature by signing the partial data containing the information or its transformation. One or more transactions comprising the first and second signatures are then sent to the network of nodes. In the event that the validation condition is met, the transaction propagates through the network for recording in the blockchain. The verification condition of one of the one or more transactions includes a first signature included in the one of the one or more transactions and a second signature included in the one of the one or more transactions, the second signature generated by signing the particular portion of data.

Inventors

• CRAIG STEVEN WRIGHT
• OWEN VAUGHN
• Bullock doylon

Assignees

• 区块链控股有限公司

Dates

Publication Date

20260505

Application Date

20200304

Priority Date

20190304

Claims (20)

1. 1. A computer-implemented method of proving that a first party agrees to a statement made in a file using blockchain, the method comprising, on a computer device of a second party: the second party receives the confirmation of the first party agreement statement; The second party receiving a piece of secret information of the first party, the secret information being unavailable to the second party and being hidden from the second party prior to the validation and prior to the first party generating an encrypted signature of the first party to indicate the consent other than the validation, wherein the secret information includes additional information of the first party that is neither the file nor the encrypted signature of the first party; receiving the secret information from the first party only after the validation and after the first party generates the cryptographic signature of the first party to indicate the consent other than the validation; To indicate that the second party verifies that the confirmation of the first party has been received, the second party generates an encrypted signature of the second party by signing partial data containing the secret information or a transformation of the secret information, and Transmitting or causing transmission of one or more transactions to a network of nodes in a form including a cryptographic signature of the first party included in at least one of the one or more transactions and a cryptographic signature of the second party included in at least one of the one or more transactions, the network being configured to propagate each transaction through the network for recording in a blockchain copy maintained by each of at least some of the nodes when authentication conditions are met; Wherein the verification condition is configured to verify one of the one or more transactions under the condition that the cryptographic signature of the first party is contained in one of the one or more transactions and the cryptographic signature of the second party is contained in one of the one or more transactions, the cryptographic signature of the second party being generated by signing the portion of data.
2. 2. The method of claim 1, wherein the record of the file is contained in one of the one or more transactions and is thus stored in a blockchain.
3. 3. The method of claim 2, wherein the record of the file is cryptographically signed by one or both of the first and second parties.
4. 4. A method according to claim 3, wherein the portion of data signed by the second party to generate the encrypted signature of the second party comprises a record of the file and/or the data signed by the first party to generate the encrypted signature of the first party comprises a record of the file.
5. 5. The method according to claim 1, Further comprising establishing a video call between the first party and the second party, Wherein the receiving of the acknowledgement includes the second party receiving an acknowledgement from the first party visually or audibly through a video call.
6. 6. The method of claim 5, wherein the recording of the video is stored for future reference, including at least one segment of video containing the visual or audible confirmation.
7. 7. The method of claim 6, wherein the recording of the video is contained in one of the one or more transactions and is thus stored in a blockchain.
8. 8. The method of claim 7, wherein the recording of the video is cryptographically signed by one or both of the first and second parties.
9. 9. The method of claim 1 or 2, wherein the validation condition is configured for each transaction at least in part by a respective code included in the transaction and/or the blockchain previous transaction.
10. 10. The method according to claim 1, wherein: the one or more transactions consist of one transaction comprising cryptographic signatures of both the first and second parties; The verification condition is configured to verify the one transaction under the condition that the signatures of both the first and second parties are contained in the transaction, the encrypted signature of the second party being generated by signing the partial data.
11. 11. The method according to claim 10, wherein: The input of the one transaction includes a pointer to an output of a previous transaction in or to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires an encrypted signature of the first party and an encrypted signature of the second party to unlock the output of the previous transaction; the one transaction includes an unlock script in input to the one transaction, the unlock script including a cryptographic signature of the first party and a cryptographic signature of the second party, configured to effect verification by unlocking the previous transaction using the cryptographic signature of the first party and the cryptographic signature of the second party.
12. 12. The method of claim 1 or 2, comprising including and forwarding the secret information in the one transaction or forwarding the secret information for inclusion in the one transaction before the second party sends to the network for propagation, wherein the verification condition is configured to verify the one transaction under further conditions that the secret information is included in the one transaction.
13. 13. The method according to claim 12, wherein: the validation condition being configured to be used for each transaction at least in part by a corresponding code included in the transaction and/or a prior transaction of the blockchain, and The one transaction includes a hash value of the secret information, and the condition that the secret information is included in the one transaction includes that the secret information forwarded by the second party is a solution of the hash value of the secret information included in the corresponding code.
14. 14. The method according to claim 11, wherein: The locking script includes a code separator separating first and second portions of the locking script, wherein the second portion includes the secret information, wherein the locking script is configured to require an encrypted signature of the first party to sign at least the first portion, but not the second portion, and an encrypted signature of the second party to sign at least the second portion when enabling verification of the one transaction; The receiving of the secret information includes receiving at least a second portion of the locking script; the generation of the cryptographic signature of the second party includes signing at least the second part.
15. 15. The method of claim 14, comprising: Before the second party receives the secret information, the second party receives a first portion of the locking script, wherein a signature of the first party signs at least the first portion; Based on the received first portion, a signature of the first party is verified.
16. 16. The method according to claim 11, wherein: the locking script also requires the secret information to unlock the output of the previous transaction; The unlocking script in the input of the one transaction comprises the secret information, which is configured for using the secret information in the unlocking script.
17. 17. The method according to claim 11, wherein: A record of the file is contained in one of the one or more transactions and is thus stored in the blockchain; the record of the file is included in the output of the one transaction.
18. 18. The method according to claim 11, wherein: Further comprising establishing a video call between the first party and the second party, The receiving of the acknowledgement includes the second party receiving an acknowledgement from the first party visually or audibly through a video call; A record of said video is stored for future reference, including at least one video containing said visual or audible confirmation; A record of the video is contained in one of the one or more transactions and is thus stored in the blockchain; The recording of the video is included in the output of the one transaction.
19. 19. The method according to claim 1, wherein: the one or more transactions include a first transaction and a second transaction; the verification condition is configured to verify the first transaction if the encrypted signature of the first party is included in the first transaction, and verify the second transaction if the encrypted signature of the second party is included in the second transaction, and the encrypted signature of the second party is generated by signing the portion of data.
20. 20. The method according to claim 19, wherein: The input of the first transaction includes a pointer to an output of a previous transaction in or to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires an encrypted signature of the first party to unlock the output of the previous transaction; The input of the second transaction includes a pointer to an output of the first transaction, wherein the output of the first transaction includes a locking script that requires an encrypted signature of the second party to unlock the output of the first transaction; The first transaction comprising a first unlocking script in an input of the first transaction and a second unlocking script in an input of the second transaction, the first unlocking script comprising an encrypted signature of the first party, the second unlocking script comprising an encrypted signature of the second party, configured to unlock an output of the previous transaction using the encrypted signature of the first party and to unlock the output of the first transaction using the encrypted signature of the second party to effect verification; The secret information hidden by the first party also includes an encrypted signature of the first party.

Description

Method of using blockchain Technical Field The present disclosure discloses a specific new second tier application of a blockchain, namely adding secondary functionality to the blockchain. Background Blockchain refers to a series of blocks of data in which each of a plurality of nodes of a peer-to-peer (P2P) network maintains a respective blockchain copy. At least some of the nodes may also act as mining nodes, as will be explained in detail later. Each tile in the chain includes one or more transactions, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a particular transaction protocol throughout. In one common transaction protocol, the data structure of each transaction includes at least one input and at least one output. Each output specifies an amount representing a digital asset value pertaining to the user whose output is cryptographically locked (requiring that the user's signature be unlocked for redemption or spending). Each input points to the output of a previous transaction, linking the transactions. In a given current transaction, the input (or each input) includes a pointer that references the output of a previous transaction in the sequence of transactions, specifying that the output is to be redeemed or "spent" in the current transaction. The input for the current transaction also includes a signature of the user whose previous transaction output was locked. In turn, the output of the current transaction may be cryptographically locked to the new user. Thus, the current transaction may transfer the amount defined in the previous transaction input to the new user defined in the current transaction output. In some cases, the transaction may have multiple outputs to split the input amount among multiple users (one of which may be the original user for alteration). In some cases, the transaction may also have multiple inputs, summarizing the amounts of multiple outputs of one or more previous transactions together, and reassigning to one or more outputs of the current transaction. The above may be referred to as an "output-based" transaction protocol, sometimes also referred to as an unexpired transaction output (UTXO) type protocol (where the output is referred to as UTXO). The user's total balance is not defined by any number stored in the blockchain, rather, the user needs a special "wallet" application to sort through all UTXO values for that user, which are scattered across many different transactions in the blockchain. Another type of transaction protocol may be referred to as an "account-based" protocol as part of an account-based transaction model. In the account-based case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored separately by the mining node into the blockchain and is updated continuously. In such systems, transactions are ordered using running transaction records (also referred to as "position") for the accounts. The value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields may also be signed in the transaction. This data field may point to the last transaction, for example, if the data field contains the last transaction ID. Whatever the type of transaction protocol employed, when a user wishes to perform a new transaction, he wishes to send the new transaction from his computer terminal to one node of the P2P network (now typically a server or data center, but in principle other user terminals are possible). This node checks whether the transaction is valid according to the node protocol applied to each node. The details of the node protocols will correspond to the type of transaction protocol used in the associated blockchain, together forming the overall transaction model. Node protocols typically require the node to check whether the encrypted signature in the new transaction matches the expected signature, depending on the last transaction in the ordered sequence of transactions. In the output-based case, this may include checking whether the user's cryptographic signature contained in the new transaction input matches a condition defined in the previous transaction output of the new transaction spending, where the condition typically includes at least checking whether the cryptographic signature in the new transaction input unlocks the output of the last transaction to which the new transaction input is directed. In some transaction protocols, conditions may be defined, at least in part, by custom scripts included in the inputs and/or outputs. Or this may be fixed solely by the node protocol or may be fixed by a combination thereo