Method using blockchain

Abstract

This invention discloses a method comprising: a second party receiving confirmation of an agreement statement from a first party; the second party receiving a message after the confirmation and the first party's cryptographic signature. To prove this, the second party generates its own cryptographic signature by signing a portion of data containing the message or a transformation thereof. Then, one or more transactions containing the first and second signatures are sent to a network of nodes. Upon meeting verification conditions, the transactions are propagated through the network to be recorded in a blockchain. The verification conditions for one of the one or more transactions include: the first signature being included in one of the one or more transactions, and the second signature being included in one of the one or more transactions, the second signature being generated by signing a specific portion of data.

Description

Technical Field

[0001] This disclosure presents a specific new second-layer application of blockchain, namely adding secondary functionality to the blockchain. Background Technology

[0002] A blockchain refers to a series of data blocks in which each of the multiple nodes in a peer-to-peer (P2P) network maintains a corresponding copy of the blockchain. At least some nodes can also act as mining nodes, which will be explained in detail later. Each block in the chain consists of 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 specific transaction protocol throughout. In a common transaction protocol, each transaction's data structure includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to a user whose output is cryptographically locked (requiring the user's signature to unlock, thus allowing for redemption or spending). Each input points to the output of a previous transaction, thus linking these transactions.

[0003] In a given current transaction, the inputs (or each input) include a pointer that references the output of a previous transaction in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction. The inputs of the current transaction also include the signatures of the users whose previous transaction outputs are locked. In turn, the outputs of the current transaction can be cryptographically locked to a new user. Therefore, the current transaction can transfer an amount defined in the inputs of previous transactions to a new user defined in the outputs of the current transaction. In some cases, a transaction may have multiple outputs to split the input amount among multiple users (one of whom can be the original user for the change). In other cases, a transaction may also have multiple inputs, aggregating the amounts from multiple outputs of one or more previous transactions and redistributing them to one or more outputs of the current transaction.

[0004] The above can be referred to as an "output-based" transaction protocol, sometimes also called an Unspent Transaction Output (UTXO) protocol (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application to organize all of that user's UTXO values, which are scattered across many different transactions on the blockchain.

[0005] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction's amount is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the mining nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction history (also known as "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also be used to sign the transaction. This data field can point to the previous transaction, for example, if the data field contains the previous transaction ID.

[0006] Regardless of the type of transaction protocol used, when a user wishes to execute a new transaction, they want to send the new transaction from their computer terminal to a node in the P2P network (currently typically a server or data center, but in principle it could be another user terminal). This node checks the validity of the transaction according to the node protocol applied to each node. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain, together forming the entire transaction model. Node protocols typically require nodes to check whether the cryptographic signature in the new transaction matches the expected signature, depending on the previous transaction in the ordered sequence of transactions. In output-based cases, this may include checking whether the user's cryptographic signature contained in the new transaction input matches a condition defined in the output of a previous transaction that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the new transaction input unlocks the output of the previous transaction to which the new transaction input points. In some transaction protocols, the condition may be defined at least in part by a custom script contained in the input and / or output. Alternatively, this may be fixed solely by the node protocol, or by a combination thereof. In either case, if the transaction is valid, the current node forwards the new transaction to one or more other nodes in the P2P network. At least some of these nodes also act as forwarding nodes, applying the same tests according to the same node protocol to forward new transactions to one or more further nodes, and so on. In this way, new transactions are propagated throughout the node network.

[0007] In an output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has been validly redeemed by the input of another subsequent transaction, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction it is attempting to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, the transaction will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the same output of a transaction more than once. On the other hand, an account-based model prevents double-spending by maintaining an account balance. Because a defined transaction order also exists, the account balance has a single, defined state at any given time.

[0008] Besides verification, at least some nodes compete to create transaction blocks during the mining process. At the mining node, new transactions are added to the pool of valid transactions that have not yet appeared in the block. Then, the mining nodes compete to assemble a new valid transaction block from the transaction pool by attempting to solve cryptographic puzzles. Typically, this involves searching for a "random number" value so that when the random number is juxtaposed with the transaction pool and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs.

[0009] The first node to solve the puzzle announces its solution on the network, providing evidence of the solution. Other nodes in the network can then easily examine this solution (once a hash value is provided, checking if the output of the hash value meets the conditions is relatively simple). Based on each node's examination of the winner's announced solution, the winning pool of transactions is subsequently recorded as a new block in the blockchain by at least some of the nodes acting as storage nodes. A block pointer is also assigned to a new block pointing to the previously created block in the chain. Once created, a block cannot be modified because it is identified and maintained by each storage node in the P2P network according to the same protocol. The block pointer also imposes order on the block. Because transactions are recorded in ordered blocks across the storage nodes of the P2P network, an immutable public ledger of transactions is provided.

[0010] Please note that different mining nodes competing to solve a puzzle at any given time may result in different snapshots of the unmined transaction pool at that particular time, depending on when the search for a solution begins. The person solving the puzzle first defines the transactions to be included in the new block and updates the current unmined transaction pool. Then, mining nodes continue competing to create blocks from the newly defined unmined pool, and so on. Furthermore, there are protocols for resolving any potential "forks," where two mining nodes solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain (in short, the one with the longest fork becomes the final chain).

[0011] Therefore, the winning node is said to have "mined" some digital assets. This special type of transaction is sometimes called a "coin-based" transaction. It automatically forms part of a new block. Typically, the transaction will also specify an additional transaction fee in one of its outputs.

[0012] Transactions in blockchains are typically used to transfer digital assets, i.e., data as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in transaction outputs. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, thus enabling the incorporation of more complex data. Assuming the transaction has been verified and is therefore accepted on the blockchain, the additional user data will continue to be stored as an immutable public record at various nodes in the P2P network. This can be used, for example, to store electronic documents on the blockchain. The fact that transactions are cryptographically signed increases trust in documents to some extent, thus providing a degree of security when using blockchain as a method of storing documents, especially when combined with the fact that blockchain provides an immutable public record. Summary of the Invention

[0013] However, this only provides a certain level of security. To further enhance security, this paper recognizes the need for a mechanism that allows a second party to electronically prove that the first party has agreed to a document or similar document (e.g., an agreement statement or a statement within the document's content). The technical challenge in this regard lies in providing a mechanism for proving trust. In particular, when a second party proves that the first party has agreed to certain statements or claims, this paper argues that it is necessary to computationally or cryptographically prove that the second party generated its cryptographic signature after the first party. This paper further recognizes that this can be achieved by leveraging the role of node verification.

[0014] According to one aspect of the disclosure herein, a computer implementation method for proving a first party's consent statement using a blockchain is provided. The method includes the following steps performed on a second party's computer device: The second party receives confirmation of the first party's consent to the statement; the second party receives a message from the first party, which is only available to the second party after the confirmation and after the first party generates its own cryptographic signature to indicate the consent. To demonstrate that the second party has proven it has received the first party's confirmation, the second party generates its own cryptographic signature by signing a portion of data containing the message or its transformation. The second party or another party using the device then sends one or more transactions to a network of nodes. The one or more transactions include a first party's signature contained in at least one of the one or more transactions and a second party's signature contained in at least one of the one or more transactions. The network is configured to propagate each transaction through the network upon satisfaction of verification conditions to record it in a blockchain copy maintained by each of at least some of the nodes. The verification conditions are configured to verify one of the one or more transactions if the first party's signature is contained in one of the one or more transactions, and the second party's signature is contained in one of the one or more transactions, and the second party's signature is generated by signing the portion of data.

[0015] Because the second party only receives the first party's information after the first party has signed and confirmed its consent, and because generating the second party's signature requires signing the information, this cryptographically proves that the second party signed after the first party. Once a transaction is propagated throughout the network, it is preserved as an immutable record of this evidence in the blockchain (in copies maintained by each storage node). However, if the conditions are not met, the forwarding node will not verify the transaction and therefore will not propagate it. Thus, this utilizes a verification process to prove the order of signatures, because only transactions whose signature order is proven to be correct will be propagated and recorded in the blockchain. Attached Figure Description

[0016] To aid in understanding embodiments of this disclosure and to show how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0017] Figure 1 This is a schematic block diagram illustrating a system for implementing blockchain.

[0018] Figure 2 The illustrations show some examples of transactions that can be recorded in the blockchain.

[0019] Figure 3 This is a schematic block diagram of another system for implementing blockchain.

[0020] Figure 4 schematically shown Figure 3 The system shown uses a pair of terminals.

[0021] Figure 5 The illustration shows a set of transaction examples used to prove consent to documents in a blockchain according to the first method.

[0022] Figure 6 The illustration shows example details of some steps in the first method.

[0023] Figure 7 It shows the use Figure 5 and Figure 6 A schematic flowchart illustrating the steps of the first method for a set of transactions is shown below.

[0024] Figure 8 This schematically illustrates another set of exemplary transactions used to prove consent to documents in a blockchain according to the second method.

[0025] Figure 9 The illustration shows example details of some steps in the second method.

[0026] Figure 10 It shows the use Figure 8 and Figure 9 A schematic flowchart illustrating the second method for a set of transactions is shown below.

[0027] Figure 11 The illustration shows a set of example transactions used to prove consent to documents in a blockchain according to a variant of the first method.

[0028] Figure 12 It shows the use Figure 11 A schematic flowchart of the steps of the first method variant of a set of transactions shown. Detailed Implementation

[0029] Figure 1An exemplary system 100 typically used to implement blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or electrically erasable read-only memory, and / or optical media such as optical disc drives.

[0030] At least some nodes 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some nodes 104 act as mining nodes 104M, mining block 151. At least some nodes 104 act as storage nodes 104S (sometimes called "full copy" nodes), each storing a corresponding copy of the same blockchain 150 in its respective storage. A given node 104 can be any combination of forwarding node 104, mining node 104M, storage node 104S, or two or all of these nodes.

[0031] Because mining involves computational resources, each mining node 104M typically takes the form of a server, which may include one or more physical server units, or even an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 may include user terminals or a group of networked user terminals.

[0032] Each node 104's memory stores software configured to run on the node 104's processing device to perform its corresponding role and process transaction 152 according to the node protocol. It should be understood that any action taken by node 104 in this document can be performed via software running on the processing device of the corresponding computer. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service of any particular entity.

[0033] Also connected to network 101 are computer devices 102 of each of the multiple parties 103 acting as consumer users. They act as payers and payees in transactions, but do not necessarily participate in mining or disseminating transactions on behalf of other parties. They do not necessarily run mining protocols. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: first party 103a and its corresponding computer device 102a, second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 can be an individual or organization. For illustrative purposes, first party 103a is referred to as Alice and second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0034] Each party 103's computer device 102 includes a corresponding processing means comprising one or more processors, such as one or more central processing units, accelerator processors, application-specific processors, and / or field-programmable gate arrays. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media like solid-state drives, flash memory or electrically erasable read-only memory, and / or optical media like optical disc drives. The memory on each party 103's computer device 102 stores corresponding instances of at least one client application 105 set to run on the processing means. It should be understood that any action of the given party 103 can be performed by software running on the processing means of the given computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The given party 103's computer device 102 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0035] The client application or software 105 may initially be made available to any given party 103's computer device 102 via a suitable computer-readable storage medium, such as by downloading from a server, or by providing it on a removable storage device, such as a removable solid-state drive, flash memory key, removable electrically erasable read-only memory, removable disk drive, floppy disk or tape, optical disc (such as CD or DVD ROM), or removable optical drive, etc.

[0036] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the node network 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function includes organizing the amounts defined in the outputs of the various 152 transactions belonging to the relevant parties scattered across the blockchain 150.

[0037] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query blockchain 150 for any transaction to which the corresponding party 103 is the recipient (or actually inspect other party transactions in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify transaction 152 according to a node protocol, in the case of forwarding node 104F forwarding transaction 152, for propagation throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes to exist within it). All nodes 104 in network 106 use the same node protocol (although they can distinguish and process different transaction subtypes according to the rules of subtypes, and different nodes can also play different roles, thus implementing different corresponding aspects of the protocol).

[0038] Blockchain 150 comprises a series of blocks 151. Each block 151 includes a set of one or more transactions 152. Each block 151 also includes a block pointer 155, which points to previously created blocks 151 in the chain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154, which await inclusion in new blocks. Each transaction 152 includes a pointer to the previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The chain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the chain. One or more original transactions 152 in the earlier chain 150 point to the genesis block 153, not to previous transactions.

[0039] When a given party 103 (say Alice) wishes to send a new transaction 152m to be included in blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152m from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be a forwarding node 104F that is most recently or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152m, it processes it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152m meets specific conditions for being "valid," specific examples of which will be described in detail later. In some transaction protocols, the verification conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0040] If the newly received transaction 152m passes the validity test (i.e., is "verified"), any storage node 104S that receives transaction 152m will add the newly verified transaction 152 to pool 154 of the blockchain 150 replica maintained by node 104S. Further, any forwarding node 104F that receives transaction 152m will then propagate the verified transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152m is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0041] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0042] Figure 2 An exemplary transaction protocol is illustrated. This is an example based on the UTXO protocol. A transaction (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description refers to output-based or UTXO-based protocols. However, this is not limited to all possible embodiments.

[0043] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO is not redeemed). The UTXO contains the transaction ID of its source transaction and other information. The transaction data structure may include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152 submitted to the mining node 104M.

[0044] Alice 103a intends to create a transaction to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's new deal 152m is marked as " Tx 1 It acquires the amount of digital assets locked to Alice in the previous transaction output 203 in the sequence, and transfers at least a portion of such amount to Bob. Figure 2 Previous transactions in the data are marked as " Tx 0 ". Tx 0 and Tx 1 It's just an arbitrary label. It doesn't necessarily mean... Tx 0 The first transaction in Blockchain 151 and Tx 1 The next transaction in pool 154. Tx 1 It can point to any previous transaction that still has an unspent output 203 locked to Alice.

[0045] When Alice creates her new deal Tx 1 At that time, or at least when she sent it to network 106, the previous transaction Tx 0 It may have already been verified and included in blockchain 150. It may now be included in block 151, or it may still be waiting in pool 154, in which case it will soon be included in new block 151. Alternatively, Tx 0 and Tx 1 They can be created and sent together to network 102, or if the node protocol allows buffering "orphaned" transactions. Tx 0 Even in Tx 1Then it is sent. In the context of transaction ordering in this article, the terms "previous" and "subsequent" refer to the order of transactions within the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, a subsequent transaction ("child transaction") that points to a previous transaction ("parent transaction") is not validated until the parent transaction is validated. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. Depending on the node protocol and / or the behavior of the mining node, they may be discarded or buffered for a period of time to await the parent transaction.

[0046] Previous transactions Tx 0 One or more outputs 203 include a specific UTXO, labeled as UTXO 0 Each UTXO includes a value representing the amount of digital assets and a locking script. This locking script defines the conditions that the unlocking script in subsequent transaction inputs 202 must meet for subsequent transactions to verify and successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions: the unlocking script in subsequent transaction inputs includes the cryptographic signature of the party whose account was previously locked.

[0047] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (with an uppercase S). The locking script specifies the information required for the spend transaction output 203, such as Alice's signature requirement. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0048] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for the purpose of enabling those who attempt to redeem) UTXO 0 Subsequent transactions are valid. [Checksig] P A Including the public key in Alice's public-private key pair.P A . Tx 1 Input 202 includes pointers to Tx 0 pointers (e.g., via their transaction IDs) TxID 0 In the embodiment, this refers to the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A This includes Alice's cryptographic signature, which is created by Alice applying the private key from her key pair to a predetermined portion of the data (sometimes referred to as a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a validly signed signature can be defined via a locking script, a node protocol, or a combination thereof.

[0049] When new transactions Tx 1 Upon reaching node 104, the node applies the node protocol. This involves running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating the two scripts:

[0050] <Sig P A > || [Checksig P A ]

[0051] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" represents a function consisting of the unlock script (in this example, a stack-based language). When run together, the script uses Alice's public key. P A (included in) Tx 0 (In the output of the locking script) to verify Tx 1Does the locking script in the input contain the signature Alice used when signing the expected portion of the data? The expected portion of the data itself (the "message") also needs to be included. Tx 0 This is so that this verification can be performed. In an embodiment, the signed data includes the entire... Tx 0 (Therefore, a separate element is needed to specify the signed portion of the data in plain text, since it already exists.)

[0052] Those skilled in the art will be familiar with the details of verification via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), any entity, such as Node 104, capable of verifying the encrypted version of the message must have already signed it by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thus enabling any holder of the public key to verify the signature.

[0053] if Tx 1 The unlock script in the middle satisfies Tx 0 One or more conditions specified in the locking script (therefore, in the example shown, if in Tx 1 If Alice's signature is provided and verified, then node 104 believes... Tx 1 Valid. If it's storage node 104S, this means it will be added to transaction pool 154. If it's forwarding node 104F, it will... Tx 1 Forwarded to one or more other nodes 104 in network 106, thus propagating throughout the network. Once Tx 1 Verified and included in Blockchain150, this will put Tx 0 In UTXO 0 Defined as already spent. Please note, Tx 1 This only applies when spending an unspent output of transaction 203. If you attempt to spend an output that has already been spent in another transaction 152, it will not work even if all other conditions are met. Tx 1 This will also be invalid. Therefore, node 104 also needs to check previous transactions. Tx 0Whether the UTXO referenced in the code has been spent (has become a valid input to another valid transaction) is important. This is one of the reasons why the order in which blockchain 150 imposes the definition on transaction 152 is important. In practice, a given node 104 could maintain a separate database marking the UTXOs 203 that have been spent in transaction 152, but the final definition of whether a UTXO has been spent depends on whether it has become a valid input to another valid transaction in blockchain 150.

[0054] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined as spent in the UTXO while simultaneously spending another portion. However, the amount of a UTXO can be divided among multiple outputs of the next transaction. For example, Tx 0 of UTXO 0 The amount defined in can be Tx 1 This involves splitting the data between multiple UTXOs. Therefore, if Alice doesn't want to... UTXO 0 All the amounts defined in the document are given to Bob, and she can use the remainder in... Tx 1 In the second output, you either make change yourself or pay the other party.

[0055] Alice and Bob's digital assets consist of unspent UTXOs locked in any of their transactions within blockchain 150. Therefore, typically, the assets of the given party 103 are dispersed across the UTXOs of various transactions 152 throughout blockchain 150. The total balance of the given party 103 is not defined within blockchain 150. The wallet function of the client application 105 serves to consolidate the different UTXO values ​​locked to the corresponding party and not yet spent in other subsequent transactions. This is achieved by querying any copy of blockchain 150 stored by any storage node 104S, such as the storage node 104S that is most recently or best connected to the corresponding party's computer device 102.

[0056] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, writing [Checksig] P A ] means [Checksig P A ] = OP_DUP OP_HASH160 <H( P aOP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by 'sig' inputs. Similarly, OP_RETURN is a scripting language opcode used to create an unspendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0057] sign P A This is a digital signature. In this embodiment, it is based on the elliptic curve digital signature algorithm using secp256k1. A digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input, all of the transaction output, or part of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the signed output (and thus fixed at the time of signing).

[0058] Note: Locking scripts are sometimes called "scriptPubKey," meaning they include the public key of the party locking the corresponding transaction. Unlocking scripts are sometimes called "scriptSig," meaning they provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferred.

[0059] According to this disclosure, a secure mechanism is provided using a node verification process, whereby a second party 103a (“Bob”) can prove that a first party 103a (“Alice”) has consented to a document. In this scenario, Alice expresses consent, and Bob testifies for the benefit of the other party. The consent document may refer to one, some, or all of one or more statements in the content of the consent document. For example, the document may include a contract, affidavit, or will. It may exist in paper, electronic, or any other form. Alice will provide her cryptographic signature associated with the document, and then Bob will provide his cryptographic signature associated with the document to prove that Alice consented to the document. The signature is contained in one or more transactions 152 of blockchain 150 as evidence of consent and proof. Transaction 152 used to record such content may or may not pay Bob its service fee.

[0060] Furthermore, the disclosed process provides a mechanism to prevent Bob from applying his signature before Alice. This is important because if Bob witnesses Alice's agreement, he cannot sign before Alice signs and expresses her consent (Bob cannot claim to have witnessed something that has not yet happened and for which there is no evidence). Transaction 152, formed and recorded based on this disclosed mechanism, is stored as an immutable record in blockchain 150 to prove the order in which signatures were applied.

[0061] As described above, metadata can be included in the non-spendable output of transaction 152 to store user content such as files. In the embodiments disclosed herein, such mechanisms are used to store an electronic copy of the witness document in blockchain 150.

[0062] Furthermore, according to the embodiments disclosed herein, the blockchain functionality is combined with additional multi-party communication capabilities, such as video calling, which provides a channel for Bob to witness the fact that Alice has consented to the documents.

[0063] Figure 3 and Figure 4 An example of this is shown in the figure. Figure 3 A system 100' for implementing blockchain 150 is shown. In addition to additional communication functions, system 100' is connected to... Figure 1 The content shown is basically the same. (And...) Figure 1 In contrast, the client applications on each of Alice's and Bob's computer devices 102a and 120b include additional functionality, and are therefore labeled 105' (in this example, Alice's is 105a' and Bob's is 105b'). Specifically, as... Figure 4 As shown, the client application 105' runs on each of Alice and Bob's computer devices 102a, 102b, and includes a wallet function 401 and a multi-party communication function 402, such as VoIP functionality, preferably with video calling functionality. Each of these functions 401, 402 can be implemented as a software module, instances of which are stored in the memory of each of Alice and Bob's computer devices 102a, 102b and configured to run on the corresponding processing device.

[0064] Wallet function 401 is configured to interface with P2P network 106 to perform functions such as creating and sending transactions 152 and organizing UTXO values, as detailed above. Figure 1The relevant description and background section. On the other hand, the multi-party communication function 402 enables Alice 103a to establish a separate multi-party communication channel 301 with Bob 103b (at the instigation of either party or a third party). For example, this multi-party communication channel 301 may include a VoIP channel and / or video link for voice and / or video calls between Alice 103a and Bob 103b. The multi-party communication channel 301 can be established via the same packet-switched network 101 as the P2P overlay network 106. Alternatively, the multi-party communication channel 301 can be established via a different network such as a mobile cellular network.

[0065] The multi-party communication function 402 may also provide a side channel 302, separate from the main multi-party communication channel 301, for transmitting data. In an embodiment, this may include a non-user-facing data channel through which client 105a' on Alice's device 102a can send "behind-the-scenes" data to client 105b' on Bob's device 102b. Alternatively, it may include, for example, an instant messaging (IM) channel, an email service, or other channels suitable for sending text and / or numbers. In an embodiment, the side channel 302 may be used to send Alice's signature and / or a secret message to Bob. X (This will be discussed in more detail later). A side channel 302 can be established through the same packet-switching network 101 as the P2P coverage network 106. Alternatively, a side channel 302 can be established through a different network such as a mobile cellular network. A side channel 302 may or may not be established through the same network as the multi-party communication channel 301.

[0066] Wallet function 401 and communication function 402 (such as...) Figure 3 and Figure 4 (As shown) is integrated into the same client application 105'. However, this does not constitute a limitation; on the contrary, it can be implemented in different applications, or the wallet function 401 can be a plug-in to the communication application 402, or vice versa. Furthermore, when using the side channel 302, it may or may not be established through the same application as the multi-party communication channel 301, or the same application providing the wallet function 401. It can be integrated into the same application as a plug-in or separate third-party application of the multi-party communication function 401, the wallet function 401, or one of them.

[0067] Multiple functions can be implemented in any way. Consider the following scenario.

[0068] Alice 103a wants to sign a contract or similar agreement with witness Bob 103b via multi-party communication channel 301. They will sign it with digital signatures and store this information on blockchain 150. Alice is the signer. She possesses the public key. PA Bob is a witness. He possesses the public key. P B Alice may possess electronic documents related to any contracts she wishes to sign.

[0069] In this embodiment, communication channel 301 includes a video link. In this embodiment, Alice and Bob will use video link 301 to record the signing process. Optionally, they may also store the video information of such records on blockchain 150.

[0070] The following describes two methods: M1 and M2. In the first method, M1, Alice and Bob each sign one transaction. In the second method, M2, there are two transactions: Alice signs the first transaction before Bob can sign the second.

[0071] Figure 5 A pair of exemplary transactions that can be used with method M1 are shown. As will be discussed in more detail later, Alice constructs an initial transaction. Tx 0 The transaction is generated using the required locking script. UTXO 1 This is achieved by providing Alice's signature in sequence, H(X) The original image and Bob's signature in the transaction Tx 1 Spending is required during this period.

[0072] Figure 7 It is a flowchart listing the steps in method M1. Figure 6 The transaction status for a specific step during method M1 is shown.

[0073] In step S1, Alice 103a and Bob 103b open a video channel 301 between them. This is the channel through which Bob will witness Alice's consent. More generally, they can communicate with each other using any form of multi-party communication channel 301. For example, the multi-party communication channel 301 could be a voice channel in which the voices of Alice and Bob can be identified. However, for greater security, video may be preferred so that the images of Alice and Bob can be identified in the video. Preferably, the video may also include audio used for exchanging voices. This also provides evidence of the ability and mental state of both parties at the time of signing. Optionally, the video or other such media exchanged through this channel 301 is recorded in a data storage area (not yet in the blockchain 150 at node 104). For example, it may be stored in the memory of Alice and / or Bob's computer devices 102a, 102b, a third-party device, or a server (e.g., in the cloud).

[0074] In step S2, Alice created a secret that only she knew. And perform a hash operation on the secret, that is H(X) In this article, hash refers to cryptographic hash functions, such as SHA256 and BLAKE2. H(X) In X The hash function calculated at that point. Secret. X This can be any data, data that only Alice knows, or at least data that Bob doesn't know and cannot guess. For example, in one embodiment, X It can be a number or a text string. For example, it could be a random number, or a number or other value generated by some deterministic process unknown to Bob. For example, X It could be a 512-bit number with 2^512 possible values, so Bob couldn't guess it.

[0075] In step S3, Alice creates It can be done by providing her signature, The original image and Bob's signature were redeemed. H(X) The original image refers to H(X) The value, which will yield a given value. H(X) of H(X) In other words, it is H(X) The solution. In this embodiment, the locking script can be written in the following illustrative form:

[0076] Locking UTXO 1 = [Checksig P A [Solve] H(X) [Checksig] P B ] .

[0077] Upon redemption, in subsequent transactions Tx 1 The input will require an unlock script signed by Alice and Bob, which can be written in the following illustrative form:

[0078] Unlocking = <Sig P B > < X > <Sig P A >

[0079] When node 104 receives Tx 1 At this time, the node tests its validity. To do this, according to the scripting language's interpretation rules, node 104 will concurrently set up the locking and unlocking scripts, as follows:

[0080] <SigP B > < X > <Sig P A > || [Checksig P A [Solve] H(X) [Checksig] P B ]

[0081] The interpreter at node 104 will then process the locking and unlocking scripts together to determine... Tx 1 Is it valid? According to the rules applied by the node protocol that interprets the scripting language, first check the rightmost input of the unlock script (in this case, Sig). P A ) and the leftmost input of the lock script (in this case, Checksig) P A Then check the rightmost input of the unlock script (in this example, it is...) X ) and the next leftmost input of the lock script (in this case, Solve) H(X) ), and so on. Checksig is used for checking Tx 1 Is the input signature passed? Tx 0 The function in the locking script that verifies the corresponding public key P. H(X) It is used for inspection Tx 1 The input provided X Is the value equal to H(X) The function for solving the problem. It's also important to remember that the Checksig function (including the opcode OP_CHECKSIG) removes its checked signature after performing the check. On the other hand, Solve... H(X) X is not removed. Therefore, when the interpreter begins to examine the leftmost input (Sig) of the unlock script... P B ) and the rightmost input of the lock script (Checksig) P B When Alice's signature (Sig) was displayed P A ) will be deleted, but X It will not be deleted. Therefore, since the node protocol interprets the locking and unlocking scripts according to the rules of the scripting language, Bob does not need to sign anything including Alice's signature. However, according to the embodiments disclosed herein, he needs to sign anything containing... X The content.

[0082] In this embodiment, Alice may need to at least sign... UTXO 1 The locking script, i.e., [Checksig P A [Solve] H(X) [Checksig] P B Optionally, the data Alice may need to sign may also include... UTXO 1 The unlock script minus Alice and Bob's signatures, i.e., < X Bob may need to sign off on some data, including... UTXO 1 The locking script plus the unlocking script of UTXO1 minus Bob and Alice's signatures. That is, Bob's signature < X > || [Checksig P A [Solve] H(X) [Checksig] P B ].

[0083] As input, Alice and Bob signed Tx 1 Sign at the same time TxID 0 [Checksig] P A [Solve] H(X) ][Checksig P B As part of the transaction, it is included TxID 0 In the calculation. Therefore, Alice and Bob indirectly signed the conditions.

[0084] The content requiring signing can be set using the SIGHASH flag. It should also be noted that when a party is claimed to have signed a given portion of data (“message”), in this embodiment, this can refer to that party actually signing a transformation of the data or message, such as a hash of the data or message (a hash is typically considered read when referring to a signature). That is, they first hash or otherwise transform the data, and then sign the hashed or transformed version with their private key. The advantage of this is that hashing can often reduce the amount of data being signed before it is signed with the private key. For example, Alice could sign a transaction. TxID 0 It is the whole Tx 0 The hash value. Bob can sign the following hash value: <x>|| [Checksig P A [Solve] H(X) [Checksig] P B ].

[0085] If Alice and Bob do not provide information regarding the deal Tx 0 If the required part is signed with a valid signature, then... ​ 1 It will not be verified and therefore will not be propagated throughout the network 106 to be recorded in the blockchain 150 replica on each storage node 104S.

[0086] It should be understood that the above is merely an example of a scripting language and its corresponding node protocol. More simply, other languages ​​can be used in... ​ 0 The output contains similar validation conditions. To implement method M1 in a broader sense, at least the conditions must be created, which Bob must therefore sign off on at least the following: X For a given set of data, Alice must sign off on a portion of that data, which may contain any content (depending on the protocol used). The portions of data that Bob and Alice need to sign can be set as part of the scripting language and node protocol, or they can be fixed by the node protocol for a given transaction structure.

[0087] In step S4, Alice creates a cost. ​ 1 transactions ​ 1 A partial version. In an embodiment, the electronic document (or its hash value) may be included in the transaction, for example, in an unspendable output (OP_RETURN). This means that if ​ 1 Once verified, the file will be immutably stored in the blockchain 150 transactions. ​ 1 In the middle. However, this is optional.

[0088] Alice has not yet signed it or ​ Add the original image to ​ 1 .

[0089] ​ 0 The locking script contains ​ Instead X The reason is that if we don't do this, it will reveal... X The original value (it's important to remember that Bob can inspect blockchain 150).

[0090] In step S5, Alice transmits a portion of the transaction via side channel 302. ​ 1 Send to Bob. Alternatively, communication can be made via main channel 301, for example by Alice displaying visual codes such as QR codes in the video, or by embedding invisible or inaudible signals in the video or audio respectively.

[0091] Note: Bob cannot provide this at this time. ​ 1 Provide a valid signature, because he does not know... ​ The preimage of the hash problem. This is because, although Bob ignored Alice's signature when constructing his signature (explained above), the preimage of the hash problem cannot be ignored. That is, Bob needs to sign to make the hash problem... ​ 1 Valid partial data includes X .

[0092] In step S6, Bob asks Alice if she agrees to the terms of the contract (or more commonly, the document), and Alice confirms. This is done via multi-party communication channel 301, preferably via video with voice. However, a purely audio channel can be used, especially when voice is recognizable in the audio. Bob may verbally ask Alice if she agrees to the document, and Alice may verbally answer. Alternatively, one or both parties may use a visual communication method, such as sign language. Communication can even be conducted via another form of medium channel 301, such as a shared virtual whiteboard that allows both parties to write their recognizable handwriting on a shared workspace, for example via tablets and electronic pens at each party's terminals 102a, 102b. Regardless of the method used, Alice's declaration of consent should at least be identifiable as originating from Alice with a reasonable degree of certainty. Preferably, Bob's question can also be identified as originating from Bob. However, in other scenarios, Bob's question may be optional (i.e., Alice may make a declaration without prompting) as long as Bob witnesses Alice's consent via channel 301.

[0093] Regardless of the form of medium used, consent is captured on medium link 301. Optionally, this medium is recorded at least temporarily in a data storage area of ​​Alice, Bob, or a third party (e.g., on Alice's or Bob's local storage drive or a traditional cloud storage account). At least a portion of the medium, including Alice's consent, is recorded, and preferably Bob's questions are also recorded. Whether or not it is recorded, it will be stored in blockchain 150, which provides a record of proof of consent.

[0094] In step S7, Alice provides ​ 1 The Signature and Hash Problem ​ The solution. She sends these to Bob via side channel 302. Alternatively, communication can be made via main channel 301, for example, by Alice displaying video codes such as QR codes in the video, or by embedding invisible or inaudible signals separately in the video or audio. If X Taking on forms meaningful to humans, Alice could even communicate verbally or manually via video or audio channels. For example, X It could be a code or a passage from a book, which Alice can read aloud or have Bob look up.

[0095] In an embodiment, Alice's client application 105a' (or more generally, software including one or more applications) can be configured to automatically conceal the solution. X And send it to Bob, either automatically or by allowing him to do so upon automatic detection that Alice has provided her signature and / or that she has indicated her consent via channel 301 (e.g., using machine intelligence technology to detect the latter). Alternatively, Alice can send it manually or trigger it. X Sending. Generally speaking, this can be done by temporarily making Bob unusable. X Any method.

[0096] In step S8, Bob now knows X And can be for ​ 1 Provide a valid signature. Bob signs. ​ 1 Thus complete ​ 1 .

[0097] In optional step S9, the video data or its hash can be stored in transaction Tx1, such as OP_RETURN. This means that, if verified, the video or other such medium proving consent will be immutably stored in the transaction on blockchain 150. ​ 1 However, this is optional. Note: This part of the output must not have been previously signed by Alice and Bob; this can be achieved using the SIGHASH flag instead of SIGHASH_ALL. The reason is that signing is for signing messages (i.e., transaction data). Alice signs the document, and the signing is recorded. If a video is subsequently added, a record is added, which causes the message to change. Therefore, Alice should sign the document separately, and Bob can use the SIGHASH flag to sign both the video and the document.

[0098] The video data can be signed by Alice, Bob, or both using a signature different from that in steps S7 and S8.

[0099] In step S10, the transaction ​ 1 This is now complete and can be sent to network 106 via Alice or Bob, thus being immutably recorded on blockchain 150.

[0100] Alice declared her consent to Bob and provided her signature. P A All of this was concealed previously. X The fact means that Bob's signature could not be effectively provided at least until then. This was because Bob's signature was based on a locked script. X (In the embodiments, X It is contained separately ​ 1 (in Chinese) is ​ 1 The valid conditions mean that Bob or anyone else could not make ​ 1 It spreads through network 106 and is added to blockchain 150 until Bob is provided. X Prior to this, Bob would not have been able to provide a valid signature in an encrypted manner. ​ 1 It remains immutably recorded in Blockchain 150 as a cryptographic demonstration of the signature order. For added security, a copy of the file / or video or other such medium (or hash value or other such transformation thereof) may optionally be included with Tx1.

[0101] Method M1 provides a solution that uses only a single transaction. ​ 1 The method of recording evidence. The advantage of this is that all evidence is recorded at a single point on Blockchain 150, allowing for efficient searching and retrieval of evidence by any party, such as Alice, Bob, or other members of the public, when they wish to query it later. It's important to remember that Blockchain 150 does not include a transaction index, and therefore does not maintain its own cumbersome separate index; searching the blockchain requires traversing the blockchain transactions to find the desired transaction. A single transaction at a single point on Blockchain 150 is much easier to find computational resources for than two transactions scattered at arbitrary points in the chain. Fewer transactions require less propagation and therefore place less burden on networks 101 and 106.

[0102] Method M2 provides a way to achieve results similar to those of Method M1 using two transactions. The advantage of this is that, although described below with examples in a scripting language, Method 2 can also be implemented using account-based transaction models and other protocols that do not allow script-defined validity conditions.

[0103] ​ A set of exemplary transactions that can be used by method M2 is shown. As will be discussed in more detail later, Alice constructs an initial transaction. ​ 0 Alice provided her signature in the transaction. ​ 1 Spend money during the transaction. ​ 2 Bob provided his signature fee. ​ 1 The output of .

[0104] ​ It is a flowchart listing the steps in method M2. ​ The transaction status for a specific step during method M2 is shown.

[0105] In step S1, Alice and Bob open a video channel or other media channel 301 between them. The video or other media can then be recorded.

[0106] In step T2, Alice creates a system that can be redeemed by providing her signature. ​ 1 .

[0107] In step T3, Alice created the cost. ​ 1 Partial transactions ​ 1 The transaction contains a spendable output. ​ 2 It can be redeemed by providing Bob's signature. Optionally, the electronic document (or its hash value) may also be included. ​ 1 In, for example, in OP_RETURN.

[0108] In the scenario of method M2, Alice needs to... ​ 0 Transaction ID ( ​ 0 Sign the signature (Sig) and then use that signature (Sig) P A ) included ​ 1 In the input, so that ​ 1 efficient. ​ 0 It is the whole ​ 0 The hash value. Bob will need to sign. ​ 1 Transaction ID ( ​ 1), and the signature (Sig) P B Included in further transactions ​ 2 In the input, to effectively redeem ​ 1 Output . ​ 1 It is the whole ​ 1 The hash value, which includes Alice's signature Sig P A Therefore, Bob in ​ 2 Providing a valid signature depends on Alice in ​ 1 The signature in the document. If Bob does not provide a signature or the signature is incorrect, ​ 2 It will not be considered valid by node 104, and therefore will not be propagated or recorded in blockchain 150.

[0109] Alice has not yet added her signature to ​ 1 .

[0110] In step T4, Alice trades part of her transaction. ​ 1 Send to Bob. Note: Bob is unable to provide redemption at this time. ​ 2 The valid signature, because he did not know the transaction. ​ 1 Transaction ID ( ​ 1 (Please remember that the transaction ID is the hash of the transaction data.) This is because Alice has not yet provided a signature for Tx1.

[0111] In step T5, Bob verbally asks Alice if she agrees to the terms of the contract (or more commonly, the document). Alice verbally confirms. This is captured on video link 301. Alternatively, another form of communication and / or medium, such as sign language, may be used via link 301 (see the preceding discussion of method M1).

[0112] In step T6, Alice is ​ 1 She provides a signature, which now completes the transaction. She sends it to Bob via side channel 302. Alternatively, communication can take place via the main medium channel 301 (see also the corresponding discussion on method M1).

[0113] In step T7, Bob creates the cost. ​ 2 transactions ​ 2 Bob signed ​ 2 .

[0114] In optional step T8, the recorded video or other media data can be stored in a manner similar to step S9 in method M1. ​ 2 Similarly, this data can be signed by Alice, Bob, or both.

[0115] In step T9, the transaction ​ 1 and ​ 2 This is now complete and can be sent to network 106 via Alice or Bob. It is immutably recorded on blockchain 150. In the M2 method, this is not required. X However, the order of signatures is still mandatory because they must exist. ​ 1 Only then can it be effectively generated ​ 2 .

[0116] Method M2 can even use account-based models and trading protocols, which do not allow scripts to define customizable validation conditions. Note that all transactions involved in Method M2 use only standard scripts, which correspond to common or standard validation criteria for many non-script-based and account-based trading protocols.

[0117] Methods M1 and M2 share several common characteristics. First, the signing order is fixed: Alice must provide her signature before Bob can. Furthermore, in embodiments of both methods, a video of the signing transaction serves as proof of the abilities of both the signatory Alice and the witness Bob. Including video data or a hash of video data in the transaction is optional. Including any electronic copy of documents related to the contract or a hash of those documents is also optional.

[0118] In both methods, the signed record and optional supplementary data (file and / or video data) are stored on the blockchain and are immutable. When a transaction is submitted to the blockchain, the digital signature is checked by node 104. Only transactions with valid signatures are stored on blockchain 150. Therefore, third parties cannot verify the validity of the signature themselves, making it trustworthy. The record is replicated through full-copy nodes 104S on the distributed network, making it easily accessible to third parties.

[0119] In this embodiment, although a hash-based message verification code (HMAC) is used, both parties can transmit partially filled transactions and verify that the transactions have not been unexpectedly altered or transmitted incorrectly.

[0120] Note: The amount of digital assets transferred into the spendable UTXO output of a transaction is unrelated to the current purpose. Therefore, in Method 1, it is... ​ 0 ( ​ 1 The output of 0 and ​ 1 The output is 0. See method M2 for details. ​ 0 ( ​ 1 The output of ) is 0, ​ 1 ( ​ 2 The output of 0 and ​ 2 The output is 0. In any given transaction, there may be more spendable outputs to split the input value or other inputs not shown. Alice may transfer some or all of the digital assets defined in the UTXO to herself, service provider Bob, or another party.

[0121] ​ and ​ An alternative implementation of method M1 is shown, using a single transaction with a code separator instead of... X The hash value.

[0122] ​ This is a schematic diagram of the transaction used in a variant example of this method. Alice constructs an initial transaction. It generates the required locking script. By providing Alice's signature and Bob's signature in turn, it can be used in the transaction. Spending is done within this. In this example, the secret... It's not actually a transaction. Part of it. However, in order for Bob to be in To create a valid signature, it needs to know... .

[0123] ​ The corresponding flowchart is shown.

[0124] This embodiment is in The locking script uses code delimiters to control the content of the locking script that Bob needs to sign. Alice then conceals the portion of the locking script that Bob needs to sign in a manner similar to concealing X in the previously described embodiment.

[0125] The signature will be signed ​ 1 The output. In the embodiment, the sighash flag in the unlock script can be set to... ​ 1 Which parts are signed? However, the signature also signs a portion of the locking script, and the locking script is contained within... ​ 0 In the absence of code delimiters, the entire lock script is always signed by default in at least one protocol. Conversely, when code delimiters are used, the following is specified: ​ 0 The party that signed the document can control the part of the document.

[0126] In step U1, Alice and Bob open a video channel between them. The video can then be recorded.

[0127] In step U2, Alice creates a secret known only to herself. .

[0128] In step U3, Alice creates It can provide Alice's signature for a portion of the locked script by starting with a code delimiter, and by providing the secret... The entire locking script provides Bob's signature for redemption.

[0129] The locking script can be written in the following illustrative form:

[0130] Locking = [Checksig ] < > OP_DROP OP_CODESEPARATOR[Checksig ].

[0131] To create a valid transaction, Alice must sign the lock script except for [Checksig] P B ] < X Everything except OP_DROP. Bob must sign off on everything in the locking script, including [Checksig]. ] < > OP_DROP.

[0132] Alice did not reveal the whole story to Bob. (It may not have been sent to network 106 and mined in block 151 yet).

[0133] In step U4, Alice creates the cost. Partial transactions Electronic documents can be included in transactions, such as in unspendable outputs (OP_RETURN).

[0134] Alice has not yet added her signature.

[0135] In step U5, Alice sends to Bob A partial version, which included a locking script after the code delimiters. She also revealed to Bob... The transaction ​ 0 The rest, including the transaction ID.

[0136] Alice sends part of the transaction to Bob .

[0137] Note: At this point, Bob is unable to... Provide a valid signature, because he does not know... The entire locking script ( ​ 0 of ​ In particular, he was unaware of the secret that appeared before the code separator. .

[0138] Alice doesn't need to send a partial version to Bob beforehand (i.e., step U5 is optional). However, one advantage of doing so is that Bob can check the validity of the signature when she provides it, since Bob knows all the parts of the transaction Alice has signed.

[0139] In step U6, Bob verbally asks Alice if she agrees to the terms of the contract. Alice verbally confirms. This can be recorded on the video link.

[0140] In step U7, Alice is Provide signature and its secret She sent this to Bob.

[0141] In step U8, Bob now knows Therefore, the entire locking script can be constructed. And verify that the transaction ID to which it belongs is correct. Now, he can provide a valid signature. Bob signs. .

[0142] In step U9, optionally, the video data or the hash value of the data may be stored in the transaction. In, for example, in OP_RETURN. This part of the output must not be signed by Alice and Bob beforehand; this can be achieved using the SIGHASH flag instead of SIGHASH_ALL.

[0143] The video data may be signed by Alice, Bob, or both using a signature different from that used in steps U7 and U8.

[0144] In step U10, the transaction ​ 1 It can be sent to the network via Alice or Bob, thus being immutably recorded on Blockchain 150. ​ 0 It can be sent simultaneously, or in ​ 1 Before or ​ 1 Send after 。

[0145] It should be understood that the above embodiments are described by way of example only.

[0146] For example, as described above, the parties 103a and 103b who sign a given transaction do not necessarily have to be the same parties who first created the transaction, assembled the complete transaction, and sent the complete transaction to network 106. Similarly, a third party can draft a written contract on behalf of Alice and Bob, requiring only Alice and Bob's signatures. The same applies to electronic transactions 152. Likewise, others can send signed contracts to their storage locations.

[0147] The first party must provide at least the signature of the second party, and the second party must provide at least the signature of the second party. Other elements of the transaction can be created by the first party, the second party, or other third parties, or any combination of these parties. In use X In the embodiments, X The preferred option is also provided by the first party to the second party, but or X It can be a shared secret between a first party and a trusted third party, and the secret X It can be provided to the second party by a trusted third party.

[0148] The elements of a transaction can be assembled by a first party, a second party, any third party, or a combination thereof. A complete transaction can be sent directly to the network by a first party or a second party, or it can be forwarded to the network via a third party.

[0149] Furthermore, the scope of this disclosure is not limited to the specific transaction protocols or node protocols discussed above. For example, similar functionality related to methods M1 and M2 can be implemented using other scripting languages, depending on the language recognized by the node protocol of the node 104 application on the relevant specific system.

[0150] In some blockchains, transactions use account-based protocols that do not employ the concept of "spending" the output of one transaction in a sequence or redeeming the output of another transaction in the sequence. In account-based blockchains, accounts are typically identified by account addresses. The current state of all accounts is stored individually in the blockchain by mining nodes and is continuously updated. Transactions have sender and receiver fields, and are reportedly transferred from an account in the sender field to an account in the receiver field (although in reality, transactions are sent from the endpoint to blockchain nodes for verification and propagation to other blockchain nodes; the account itself is a logical structure defined by the blockchain state, which in turn is defined by the sequence of transactions it contains). A transaction, for example, can transfer a certain amount of digital assets between sender and receiver accounts, such that the amount is deducted from the sender's account balance and added to the receiver's account balance. An account can be created by sending a transaction to an account address that did not previously exist (i.e., an account address never included in any earlier transactions in the blockchain), and subsequent transactions involving that account will specify its address in their sender or receiver field. Therefore, all transactions on the blockchain associated with a given account (including the transaction that creates the account) are linked by a public account address.

[0151] Therefore, in the account-based model, transactions do not operate on a UTXO-based system or similar system, so each transaction either spends or redeems the output of the previous transaction. Instead, transactions use the account's running transaction log (also known as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Therefore, even with the allowance of custom scripts, method M2 can still be implemented in an account-based protocol.

[0152] In the account-based case, the transaction ID of transaction 1 can optionally be included in the data field of transaction 2. This then simplifies to the same case as method M2. In some account-based protocols, smart contracts can act as locking scripts. Within a smart contract, a signature of specific data bits can be required. Therefore, a smart contract can be signed, requiring Alice to sign, and then Bob, who is specifically responsible for signing Alice's signature, can also sign it. In this case, as described in the UTXO-based version of method M2 above, the information that Bob is unaware of is itself Alice's signature.

[0153] In further variations, if the transaction and node protocols allow for more flexible scripting languages, all variations of conditional validation can be programmable into one or more transactions. For example, a custom script could be written requiring Bob to sign a portion of data containing Alice's signature (or a transformation thereof) within the same transaction. This would provide a single-transaction test as in method M1, but would not be necessary in method M2. X Alice concealed her signature from Bob only after signing and declaring her consent through communication channel 301.

[0154] Furthermore, while the above description refers to public blockchains, this does not constitute any limitation. Instead, blockchain 150 could be, for example, a consortium blockchain used between selected organizations, or even a private blockchain within a given organization.

[0155] It should also be noted that the order described above is not necessary for all steps in methods M1 and M2. For example, referring to step S5 in method M1, Alice does not need to send the partial transaction to Bob at this point. She can wait until step S7 to send the partial transaction. ​ 1 Send together X And its signature. Similarly, for example, in method M2, Alice does not need to send part of it to Bob in step T4. ​ 1 However, it can wait until step T6 to send it along with its signature. Furthermore, as mentioned above, the other party can provide part of the transaction, or a party trusted by Alice can even be responsible for sending it to Bob. X In simpler terms, the key is to conceal from Bob the information required for a signature to provide a valid signature that will be verified by node 104. Furthermore, it involves concealing or withholding information from Bob (such as secret information, for example...) X This does not mean that the information already exists beforehand. In some embodiments, it may be generated after Alice provides her signature and / or gives her consent to Bob.

[0156] Another example variant of method M1 is shown below. As mentioned above, ​ 0 The locking script contains ​ Instead X The reason is that if this is not done, it will be revealed in Blockchain 150. X The original value. However, in principle, Alice could also conceal it. ​ 0 until ​ 0 and ​ 1 All can be sent up to network 106 (it's important to remember that some systems have rules regarding orphaned transactions). In this case... ​ 0 The [Solve] script in the locking script ​ [This can be replaced with checking only if it matches] X Equal functions (e.g., using the opcode OP_EQUALVERIFY).

[0157] Once the basic principles explained in this article are given, other variations of method M1 and / or M2 may become apparent to those skilled in the art.

[0158] Furthermore, while the foregoing describes the content of Alice's consent document, this is not mandatory. For example, Alice's consent could simply be an agreement to an oral contract or another set of one or more conditions. More generally, this method can be used for any statement in any form (written or otherwise) specified on any medium (electronic or otherwise). The term "statement" as used herein does not limit the nature of the consent. For example, it could be any statement by Alice, Bob, or the other party regarding facts or opinions; or any claim made by Bob or the other party to Alice.

[0159] More generally, according to one aspect of the disclosure herein, a computer-implemented method for proving a first-party consent statement using a blockchain is provided; the method is executed on a second-party computer device, comprising: the second party receiving confirmation of the first-party consent statement; the second party receiving a message from the first party, the message being available to the second party only after the confirmation and after the first party generates its own cryptographic signature to indicate consent in addition to the confirmation; to indicate that the second party has proven that it has received the first party's confirmation, the second party generating its own cryptographic signature by signing partial data containing the message or partial data of a transformation of the message; sending one or more transactions to a node network or causing one or more transactions to be sent to a network, the form of which includes a first-party signature contained in at least one of the one or more transactions and a second-party signature contained in at least one of the one or more transactions, the network being configured to propagate each transaction through the network when verification conditions are met, and to record each transaction in a blockchain copy maintained by each of at least some nodes; wherein the verification conditions are configured to verify one of the one or more transactions under the following conditions: a first-party signature is contained in one of the one or more transactions, a second-party signature is contained in one of the one or more transactions, and the second-party signature is generated by signing the partial data.

[0160] Please note that in method M2, the second transaction to be verified requires the first transaction to also be valid. When a node verifies a transaction, it checks whether the previously verified transaction is being spent and has an unspent output. Therefore, in method M2, the second transaction is verified on the condition that the first party's signature is included in a transaction (the first transaction), and requires that the second party's signature be included in the second transaction and that the second party's signature is generated by signing the aforementioned portion of the data. In method M1, individual transactions are verified on the condition that both signatures are included in the same transaction.

[0161] The concealed information may include the first party's signature, or separate information received together with or separately from the first party's signature, such as a random number. If it is separate information, it may also be included in one of the one or more transactions intended to be sent to and recorded on the blockchain.

[0162] In an embodiment, the method may include a second party receiving at least one of one or more transactions in partial form. The partial form may be received from a first party or a third party facilitating the recording. In an embodiment, the method may include the second party receiving a signature from the first party. The first party's signature may be received as part of a partial form of one or more transactions, or received separately. In an embodiment, the second party completes one or more transactions by including its own signature in the partial form. If received separately, the second party may also add the first party's signature to complete the transaction. The transmission to the network may then include the second party forwarding the completed transaction for propagation within the node network and thus recording it in the blockchain. The forwarding may include sending it directly to one of the nodes, or sending it to a third party's computer device for subsequent direct or indirect forwarding to one of the nodes.

[0163] In an alternative embodiment, once the second party receives the first party's signature and information (if separate), the second party can create one or more transactions involving the node on its computer device. The second party can then forward the complete form of the one or more transactions to propagate through the node network and thus record them in the blockchain (again, said forwarding may include sending directly to one of the nodes or sending to a third party's computer device for subsequent direct or indirect forwarding to one of the nodes).

[0164] In another alternative embodiment, a first party may send a partial form of one or more transactions, its signature, and confidential information (if separate from the signature) to a third party, and a second party may send its own signature to the third party, enabling the third party to assemble the complete form of one or more transactions based on these elements received from both parties. The third party can then forward one or more transactions directly or indirectly to one of the nodes for propagation throughout the network and thus recording in the blockchain. Alternatively, the first party may forward its signature and (if separate) confidential information to the third party, and the second party may forward its own signature to the third party, allowing the third party to assemble one or more transactions. Again, the third party can then forward one or more transactions directly or indirectly to one of the nodes for propagation throughout the network and thus recording in the blockchain.

[0165] The first party's signature can be generated by the first party signing at least a portion of at least one of one or more transactions or a transformation thereof (e.g., partial or complete hashes of one or two transactions). The second party's signed portion may also include part or all of at least one transaction or a transformation thereof, such as a hash value. In embodiments, the second party's signed portion may be specified by a protocol applied to each node, code included in one or more transactions, or a combination of these.

[0166] In this embodiment, the statement may be a statement in a file.

[0167] In one embodiment, the record of the file is contained in one of one or more transactions and is therefore stored in the blockchain.

[0168] The file record may include the file itself in its clear format, file transformations such as file hash values, or encrypted versions of the file.

[0169] In this embodiment, the records of the file may be cryptographically signed by one or both of the first and second parties.

[0170] To achieve this, in this embodiment, the data signed to generate the first and / or second signatures may include records of the document. Alternatively, the first and / or second parties may apply separate cryptographic signatures to the document records.

[0171] In an embodiment, the portion of data signed by a second party to generate the second party's signature may include records of the file, and / or the data signed by a first party to generate the first party's signature may include records of the file.

[0172] In an embodiment, the method may further include establishing a video call between a first party and a second party, wherein receiving the confirmation may include the second party receiving confirmation from the first party in a visual or audible manner via video call.

[0173] In an embodiment, the video recording may be stored for future reference, including at least one video segment containing the aforementioned visual or audible confirmation.

[0174] In one embodiment, the recording of the video may be included in one of one or more transactions and thus stored in a blockchain.

[0175] Video recordings may include the video itself in its original, formatted form, video conversions such as hash values ​​of relevant parts of the video, or encrypted video.

[0176] In this embodiment, the video recording may be encrypted and signed by one or both of the first and second parties.

[0177] To achieve this, in one embodiment, the data signed to generate the first and / or second signatures may include a recording of video. Alternatively, the first and / or second parties may apply separate cryptographic signatures to the video recording.

[0178] In this embodiment, the verification conditions are configured to be used for each transaction at least in part through corresponding code included in the transaction and / or previous transactions on the blockchain. For example, a previous transaction could be a transaction pointed to by the relevant exchange.

[0179] Alternatively, the verification conditions can be defined, at least in part, through a public node protocol implemented at each node.

[0180] When one or more transactions are created and / or sent, or when previous transactions may be ready to be included in the blockchain, previous transactions may already be included in the blockchain.

[0181] In a first type of embodiment, one or more transactions may consist of a single transaction containing the signatures of both a first party and a second party; the verification conditions may be configured to verify the single transaction under the following conditions: the signatures of both the first party and the second party are included in the transaction, and the second party's signature is generated by signing the portion of data.

[0182] The advantage of using only one transaction is that all evidence is stored in the same transaction, making it possible to re-interrogate with fewer search operations later.

[0183] In one embodiment, the input of a transaction may include a pointer to the output of a previous transaction in or intended to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires the signatures of a first party and a second party to unlock the output of the previous transaction. The transaction may also include an unlocking script in its input, the unlocking script including the signatures of a first party and a second party, configured to perform verification by unlocking the previous transaction using the first and second signatures.

[0184] In an embodiment, in addition to the first party's signature, the information may include a secret message from the first party.

[0185] In an embodiment, the method may include: a second party including and forwarding the secret information in a transaction before transmission over a network, or forwarding the secret information to include it in the transaction. Verification conditions may be configured to verify, under the further condition that the secret information is included in the transaction.

[0186] In an embodiment, the transaction may include the hash value of the secret information, and the condition for the secret information to be included in the transaction may include: the secret information forwarded by the second party is the solution to the hash value of the secret information contained in the code.

[0187] The advantage of this is that the first party does not need to disclose the original value of the secret information in the transaction.

[0188] In an embodiment, the locking script may also require secret information to unlock the output of a previous transaction, and the unlocking script in the input of the transaction may include the secret information, which is configured to use the secret information in the unlocking script.

[0189] In an alternative embodiment, the locking script may include a code separator separating first and second portions of the locking script, wherein the second portion includes the information that, when the locking script is configured to enable verification of the transaction, a first party's signature is required to at least sign the first portion, but not the second portion, and a second party's signature is required to at least sign the second portion. In this case, receiving the information includes receiving the second portion of the locking script, and generating the second party's signature includes at least signing the second portion.

[0190] In some of these embodiments, the method may include: before the second party receives the information, the second party receives a first portion of a locking script, wherein the first party's signature at least signs the first portion; based on the received first portion, the second party verifies the first party's signature.

[0191] In this embodiment, the previous transaction may be created by a first party. In this embodiment, the previous transaction may be transmitted to the network directly or indirectly by the first party and thus recorded in the blockchain instance of each node. Alternatively, the previous transaction may be partially created by a third party or even a second party and sent to the first party for signing and transmission; or the first party may send its signature to a third or second party to assemble and transmit the previous transaction.

[0192] In one embodiment, the second party may receive, from the first party, a transaction comprising at least a portion of an unlocking script, and may complete the transaction by the second party, including the second party's signature and secret information (as used). The first party's signature may be received in the transaction, or may be received and included separately by the second party in the transaction. Once completed, the transaction may be sent directly to the network by the second party, or the transaction may be sent by the second party to a third party for forwarding to the network. In another alternative, the first party may send its signature and secret information to a third party, and the second party may send its signature to the third party. In this case, the unlocking script may be generated by the third party or received by the third party from the first party. These elements may be assembled into the transaction by the third party, which may then directly or indirectly transmit the transaction to the network for propagation.

[0193] In an embodiment, the records of the file may be included in the output of the transaction.

[0194] In one embodiment, the recording of the video may be included in the output of the transaction.

[0195] The second party's signature can be formed by signing a portion of the transaction containing secret information in plaintext, or by signing a portion of data containing a hash value of the secret information. In embodiments, the portion of data signed by the second party may also include one or more other elements of the transaction, such as a locking script and / or an unlocking script or a portion thereof; or a transformation such as a hash value of such a script or its technology. In a particular embodiment, the second party signs at least the secret information and the locking script, or only the secret information and the locking script. In embodiments, the portion of data signed by the second party does not include the first party's signature.

[0196] The first party's signature can be generated by signing at least a portion of data from said transaction or a transformation thereof (e.g., a hash value). In an embodiment, the data signed by the first party may include a locking script, and / or one or more other outputs from a previous transaction, and / or one or more other inputs to said transaction, rather than including inputs to an unlocking script; or transformations such as hash values ​​of any or all of these. In an embodiment, the data signed by the first party does not include secret information.

[0197] In a second type of embodiment, one or more transactions may include a first transaction and a second transaction; the verification conditions are configured to verify the first transaction if the first party's signature is included in the first transaction; and to verify the second transaction if the second party's signature is included in the second transaction, the second signature being generated by signing the portion of data.

[0198] In an embodiment, the input to the first transaction may include a pointer to the output of a previous transaction in or intended to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires the signature of a first party to unlock the output of the previous transaction. The input to the second transaction may include a pointer to the output of the first transaction, wherein the output of the first transaction includes a locking script that requires the signature of a second party to unlock the output of the first transaction. The first transaction may include a first unlocking script in the input of the first transaction and a second unlocking script in the input of the second transaction, the first unlocking script including the signature of the first party and the second unlocking script including the signature of the second party, configured to use the first party's signature to unlock the output of the previous transaction and the second party's signature to unlock the output of the first transaction to achieve verification. Information concealed by the first party may include the first party's signature.

[0199] In an embodiment, the records of the file may be included in the output of the second transaction.

[0200] In one embodiment, the video recording may be included in the output of the second transaction.

[0201] The first party's signature can be generated by signing data from a first transaction and / or previous transactions. The second transaction's signature can be generated by signing data from a second transaction and / or previous transactions. In an embodiment, the portion of the data signed by the second party may include the transaction ID of the first transaction, which may be the hash value of the entire first transaction during the signing of the first transaction. The data signed by the first party may include the transaction ID of previous transactions, which may be the hash value of the entire previous transaction.

[0202] According to another aspect disclosed herein, a computer program product contained on a computer-readable storage medium is provided, including code configured to perform operations upon execution on a computer device of a second party in accordance with any request of the second party.

[0203] According to another aspect disclosed herein, a second-party computer device is provided, including a processing device and a memory, the processing device including one or more processors, and the memory including one or more storage devices storing software configured to run on the processor, the software being configured to perform operations upon any request from the second party during runtime.

[0204] According to another aspect disclosed herein, a computer-implemented method executed on a first-party computer device is provided, the method comprising: the first party generating its own cryptographic signature indicating a statement of consent; separately from the first party's signature, confirming the first party's statement of consent to a second party; after the first party generates its own signature and sends the confirmation to the second party, making information of the first party available to the second party, and then sending the information to the second party, thereby causing the second party to generate its own cryptographic signature by signing a portion of data containing the information or a transformation thereof; by sending the information, causing one or more transactions to be sent to a node network in the form of a first party's signature contained in at least one of the one or more transactions and a second party's signature contained in at least one of the one or more transactions, the network being configured to propagate each transaction through the network upon satisfaction of verification conditions and to record each transaction in a blockchain copy maintained by each of at least some of the nodes; wherein the verification conditions are configured to verify one of the one or more transactions under the following conditions: the first party's signature is contained in one of the one or more transactions, the second party's signature is contained in one of the one or more transactions, and the second party's signature is generated by signing the portion of data.

[0205] In embodiments, the method may include supplementary steps corresponding to any embodiment of the method performed by a second party and / or a third party or node.

[0206] According to another aspect, a computer program product contained on a computer-readable storage medium is provided, including code configured to perform operations according to a corresponding method of the first party when run on a computer device of the first party.

[0207] According to another aspect, a first-party computer device is provided, including a processing device and a memory, the processing device including one or more processors, and the memory including one or more storage devices storing software configured to run on the processor, the software being configured to perform operations according to the first-party method at runtime.

[0208] According to another aspect, a computer program contained on a computer-readable storage medium is provided, which is configured to perform operations according to the method of the first party when run on a computer device of the first party.

[0209] According to another aspect disclosed herein, a method is provided performed by a first node in a node network, comprising: receiving one or more transactions, each including a cryptographic signature of a first party contained in one of the one or more transactions and a cryptographic signature of a second party contained in at least one of the one or more transactions; verifying that both the first party's signature and the second party's signature are contained in one of the one or more transactions, the first party's signature signing partial data including or derived from a message from the first party that is available to the second party only after the first party generates the first signature; recording the one or more transactions in a blockchain copy maintained by the first node; and subsequently propagating the one or more transactions to one or more other nodes to record them in a blockchain copy recorded at each of the one or more other nodes; wherein the first node is configured, under the conditions of said verification, to perform the recording and subsequent propagation of at least one of the one or more transactions.

[0210] In an embodiment, the method performed by the first node may include supplementary steps corresponding to any embodiment of the method performed by the first party, the second party, and / or the third party.

[0211] According to another aspect, a network node is provided that is configured to perform the method of said node.

[0212] According to another aspect, a computer program contained in a computer-readable storage medium is provided, which is configured to execute a method of a node when run on a node.

[0213] According to another aspect, a node network is provided, each node being configured to operate according to a method associated with a first node, thereby being configured to propagate one or more transactions throughout the network and record them in the blockchain copy of each node under the conditions of verification.

[0214] According to another aspect disclosed herein, a method may be provided that includes actions by a first party, a second party, any third parties that may be involved, and a network of nodes.

[0215] According to another aspect disclosed herein, a system comprising a first-party computer device, a second-party computer device, any third-party computer device, and a network of nodes may be provided.

[0216] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.< / x>

Claims

1. A computer-implemented method for using blockchain to prove statements made in a first-party consent document, the method comprising, on a second-party computer device: The second party receives confirmation of the first party's agreement statement; The second party receives a secret message from the first party. Before the confirmation and before the first party generates its own cryptographic signature to indicate consent in addition to the confirmation, the secret message is not available to the second party and is concealed from the second party. The secret message includes additional information from the first party that is neither the file nor the first party's cryptographic signature. The secret information can only be received from the first party after the confirmation and after the first party generates the first party's cryptographic signature to indicate the consent in addition to the confirmation; To demonstrate that the second party has confirmed receipt of the first party's confirmation, the second party generates a cryptographic signature by signing a portion of data containing the secret information or a transformation of the secret information; and, Sending or prompting the sending of one or more transactions to the node network, the form of which includes a cryptographic signature of the first party contained in at least one of the one or more transactions and a cryptographic signature of the second party contained in at least one of the one or more transactions, the network being configured to propagate each transaction through the network when verification conditions are met, to be recorded in a blockchain copy maintained by each of at least some of the nodes; The verification condition is configured to verify one of the one or more transactions under the following conditions: the first party's cryptographic signature is contained in one of the one or more transactions, the second party's cryptographic signature is contained in one of the one or more transactions, and the second party's cryptographic signature is generated by signing the portion of data.

2. The method of claim 1, wherein the record of the file is contained in one of the one or more transactions and is therefore stored in a blockchain.

3. The method according to claim 2, wherein the records of the file are encrypted and signed by one or both of the first party and the second party.

4. The method of claim 3, wherein the portion of data signed by the second party to generate the second party's cryptographic signature includes records of the file, and / or the data signed by the first party to generate the first party's cryptographic signature includes records of the file.

5. The method according to claim 1, This further includes establishing a video call between the first party and the second party. The receipt of the confirmation includes the second party receiving confirmation from the first party in a visual or audible manner via video call.

6. The method of claim 5, wherein the recording of the video is stored for future reference, including at least one segment containing the visual or audible confirmation video.

7. The method of claim 6, wherein the recording of the video is contained in one of the one or more transactions and is therefore stored in a blockchain.

8. The method according to claim 7, wherein the recording of the video is encrypted and signed by one or both of the first party and the second party.

9. The method of claim 1 or 2, wherein the verification condition is configured to be used for each transaction at least in part by a corresponding code included in the transaction and / or previous transactions of the blockchain.

10. The method according to claim 1, wherein: The one or more transactions consist of a single transaction containing the cryptographic signatures of both the first party and the second party; The verification conditions are configured to verify a transaction under the following conditions: both the first party's and the second party's signatures are included in the transaction, and the second party's cryptographic signature is generated by signing the portion of the data.

11. The method of claim 10, wherein: The input of a transaction includes a pointer to the output of a previous transaction in or intended to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires a cryptographic signature from the first party and a cryptographic signature from the second party to unlock the output of the previous transaction. The transaction includes an unlocking script in the input of the transaction, the unlocking script including the cryptographic signature of the first party and the cryptographic signature of the second party, configured to perform verification by unlocking the previous transaction using the cryptographic signature of the first party and the cryptographic signature of the second party.

12. The method of claim 1 or 2, comprising, prior to the second party sending the secret information to the network for propagation, including and forwarding the secret information in the transaction, or forwarding the secret information to include it in the transaction; wherein the verification condition is configured to verify, under further conditions, that the secret information is included in the transaction.

13. The method according to claim 12, wherein: The verification conditions are configured to be used for each transaction at least in part by corresponding codes included in the transaction and / or previous transactions in the blockchain; as well as The transaction includes the hash value of the secret information, and the condition for the secret information to be included in the transaction includes: the secret information forwarded by the second party is the solution to the hash value of the secret information contained in the corresponding code.

14. The method of claim 11, wherein: The locking script includes a code separator that separates the locking script into first and second parts, wherein the second part includes the secret information, wherein when the locking script is configured to enable verification of the transaction, it requires the cryptographic signature of the first party to sign at least the first part, but not the second part, and the cryptographic signature of the second party to sign at least the second part; Receiving the secret information includes at least receiving a second part of the locking script; The generation of the second party's cryptographic signature includes signing at least the second part.

15. The method of claim 14, comprising: Before the second party receives the secret information, the second party receives a first part of the locking script, wherein the first party's signature at least signs the first part; Based on the first portion received, the signature of the first party is verified.

16. The method of claim 11, wherein: The locking script also requires the secret information to unlock the output of the previous transaction; The unlock script in the input of a transaction includes the secret information, which is configured to use the secret information in the unlock script.

17. The method of claim 11, wherein: The record of the document is contained in one of the one or more transactions and is therefore stored in the blockchain; The records in the file are included in the output of the transaction.

18. The method according to claim 11, wherein: This further includes establishing a video call between the first party and the second party. The receipt of the confirmation includes the second party receiving confirmation from the first party in a visual or audible manner via video call; The video recordings are stored for future reference, including at least one video containing the aforementioned visual or audible confirmation. The video recording is contained in one of the one or more transactions and is therefore stored in the blockchain; The video recording is included in the output of the transaction.

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 first party's cryptographic signature is included in the first transaction. And, verifying the second transaction on the condition that the second party's cryptographic signature is included in the second transaction, and, the second party's cryptographic signature is generated by signing the portion of data.

20. The method of claim 19, wherein: The input to the first transaction includes a pointer to the output of a previous transaction in or intended to be included in the blockchain, wherein the output of the previous transaction includes a locking script that requires the first party's cryptographic signature to unlock the output of the previous transaction; The input to the second transaction includes a pointer to the output of the first transaction, wherein the output of the first transaction includes a locking script that requires the cryptographic signature of the second party to unlock the output of the first transaction; The first transaction includes a first unlock script in the input of the first transaction and a second unlock script in the input of the second transaction. The first unlock script includes the cryptographic signature of the first party, and the second unlock script includes the cryptographic signature of the second party. They are configured to use the cryptographic signature of the first party to unlock the output of the previous transaction and the cryptographic signature of the second party to unlock the output of the first transaction to achieve verification. The secret information concealed by the first party also includes the first party's encrypted signature.

21. The method according to claim 3, 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 first party's cryptographic signature is included in the first transaction. And, verifying the second transaction on the condition that the second party's cryptographic signature is included in the second transaction, and, the second party's cryptographic signature is generated by signing the portion of data; The records in the file are included in the output of the second transaction.

22. The method of claim 20, wherein: This further includes establishing a video call between the first party and the second party. The receipt of the confirmation includes the second party receiving confirmation from the first party in a visual or audible manner via video call; The video recordings are stored for future reference, including at least one video containing the aforementioned visual or audible confirmation. The video recording is contained in one of the one or more transactions and is therefore stored in the blockchain; The video recording is encrypted and signed by one or both of the first and second parties. The video recording is included in the output of the second transaction.

23. A computer program product contained on a computer-readable storage medium, comprising code configured to perform operations according to any one of claims 1 to 22 when executed on a computer device of the second party.

24. The computer device of the second party, comprising a processing means and a memory, the processing means comprising one or more processors, the memory comprising one or more storage means, the memory storing software configured to run on the processor, the software being configured to perform operations upon runtime according to any one of claims 1 to 22.

25. A computer-implemented method executed on a first-party computer device, the method comprising: The first party generates its own encrypted signature, indicating that the first party agrees to the statements made in the document; Separately from the first party's signature, the second party confirms the first party's agreement to the stated statement; The secret information of the first party is concealed from the second party until the first party generates the first party's encrypted signature and sends the confirmation to the second party. Then, the secret information is sent to the second party, thereby enabling the second party to generate the second party's encrypted signature by signing a portion of the data containing the information or its transformation. The secret information is additional information of the first party, which is neither the file nor the first party's encrypted signature. as well as, By sending the secret information, one or more transactions are sent to the node network, the form of which includes a cryptographic signature of the first party contained in at least one of the one or more transactions and a cryptographic signature of the second party contained in at least one of the one or more transactions, the network being configured to propagate each transaction through the network when verification conditions are met, and to record each transaction in a blockchain copy maintained by each of at least some of the nodes; The verification condition is configured to verify one of the one or more transactions under the following conditions: the first party's cryptographic signature is contained in one of the one or more transactions, the second party's cryptographic signature is contained in one of the one or more transactions, and the second party's cryptographic signature is generated by signing the portion of data.

Images