Blockchain-implemented method and system

Abstract

To provide a method and a system for performing, controlling, and / or automating a task or a process.SOLUTION: A method provides a block chain transaction with a Redeem script for output. The Redeem script includes: a plurality of input parameters, one of which is a target output parameter, uniquely associated with a possible state of at least one data source to be supplied to an unlock script of a further transaction using the output; and Logic, in order to provide an intermediate result, for providing a result based on calculation performed on an input parameter provided by the unlock script and comparison of a target output parameter by the unlock script to the intermediate result. The method also attempts to use the transaction output more than once and supply different target output parameters.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to distributed ledger technology (including blockchain-related technologies), and more particularly to the use of blockchain in performing, controlling, and / or automating tasks or processes. The present invention may relate to the use of blockchain or related technologies to record or represent the execution of a portion of logic. This portion of logic may be configured to implement the function of a logic gate or multiple logic gates, such as AND, XOR, NOT, OR, etc. [Background technology]

[0002] It is important to note that we use the term "blockchain" herein for convenience and ease of reference, as it is the most widely known term currently in this context. However, the term is used herein (including in the claims) to encompass all forms of electronic, computer-based distributed ledgers, including but not limited to blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof.

[0003] A blockchain is an electronic ledger implemented as a decentralized, distributed system based on consensus-based computers, composed of blocks. Blocks in turn are composed of transactions. Each transaction contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks chain together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs. Scripts specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure each transaction is valid, and invalid transactions are rejected by the network. Software clients installed on nodes perform this validation work on unspent transactions (UTXOs) by running their own locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, the transaction is valid and the transaction is written to the blockchain.

[0005] The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein for convenience and purposes of explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations are within the scope of the present invention.

[0006] Blockchain technology is most widely known for its use in implementing cryptocurrencies. However, more recently, digital entrepreneurs have begun to explore both the use of the cryptocurrency security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used for tasks and processes that are not limited to the cryptocurrency realm, such as automated control processes. Such solutions would be more diverse in their applications, yet still be able to take advantage of the benefits of blockchain (e.g., permanent, tamper-resistant record of events, distributed processes, etc.).

[0007] Such an improved solution has been devised.According to the present invention, there is therefore provided a system and method as defined in the accompanying claims. Summary of the Invention

[0008] Thus, according to the present invention, a computer-implemented method may be provided. The present invention may be described as a control method. The present invention may control the operation of a technical process or the operation of one or more devices. Additionally or alternatively, the present invention may control the execution of a blockchain script. The present invention may control the output generated by an attempt to unlock a lock script associated with a transaction output (UTXO). The present invention may control whether an output (UTXO) in a blockchain transaction is unlocked. The present invention may control whether a portion of cryptocurrency is transferred from one party to another via the blockchain. can be controlled.

[0009] The present invention provides a computer-implemented control method, comprising: providing a blockchain transaction including a Redeem script for the output, the Redeem script comprising: i) a plurality of input parameters, each input parameter uniquely associated with a possible state of at least one data source to be supplied to an unlock script of a further transaction configured to use said output, one of said input parameters being a target output parameter; ii) logic, - calculations performed on the input parameters provided by the unlock script to provide intermediate results; and - comparing the target output parameters of the unlocked script to the intermediate results; and logic configured to provide a result based on the attempting to use the transaction output more than once, each attempt providing different target output parameters; The present invention provides a method comprising:

[0010] Thus, embodiments of the present invention allow a blockchain transaction (Tx) to return a non-true value from a script, which may be accomplished by using a parameter to verify or determine that the output of the script matches a target value supplied by, represented by, or associated with the parameter.

[0011] Additionally or alternatively, the method may include providing a blockchain transaction (Tx) including a Redeem script for the output, where the Redeem script specifies multiple public keys. These may be cryptographic keys. They may form part of a public / private key pair. Each of the keys in the multiple (or "list") may be associated with a corresponding private key. Each public key may be uniquely associated with at least one possible state of the data source. Thus, the Redeem script may include a list of public keys, only whose corresponding private keys can be used to spend the transaction output (TxO).

[0012] The target output parameters may represent the computational agent's desire to use (or not use) the transaction output. Logic may be configured to provide results that are based on or influenced by the target output parameters and / or a determination of which target output parameters are provided via the unlock script. The target output parameters may be provided via metadata in the unlock script.

[0013] Thus, embodiments of the present invention may allow a blockchain transaction (Tx) to return a non-true value from a script.

[0014] The method may include attempting to spend the transaction output more than once. Each attempt may include submitting a (different) transaction to the blockchain network. Each spend attempt may be performed using a transaction that provides or supplies a different agent subkey to the Redeem script. Each attempt may generate a blockchain transaction that attempts to spend the output to a different (blockchain) address. In effect, this attempt is a double (or more) spend. Double spend is traditionally considered bad behavior, as it attempts to transfer the same amount of cryptocurrency to different recipients. However, in this application, it is used to benefit.

[0015] The target output parameter may represent true or false.

[0016] A computing agent may be configured to monitor the status of a data source. The agent may be associated with a subkey that may be derived or generated from another cryptographic key. The other key may be associated with the computing agent. The subkey may be generated substantially as described in the section below entitled "Generating a Key from a Shared Secret," or in any other manner known in the art.

[0017] The logic may be configured to perform an equality check or comparison. The check or comparison may compare intermediate results to target output parameters. The intermediate results may be provided by executing logic in the Redeem script, which may be a portion of the logic configured to emulate or provide the functionality of a logic gate. The intermediate results may be placed on / read from a stack in memory.

[0018] The method may include generating a transaction, which may include submitting the transaction to a blockchain.

[0019] The transaction and / or further (use) transactions may be generated by a computational agent. The transactions may be generated automatically (without human intervention) based on input received from sensors or other signal / data sources.

[0020] Additionally or alternatively, the Redeem Script may include portions of logic configured to provide results based on or affected by which of multiple public keys is used to sign the Unlock Script, and thus, the execution of logic provided within the Redeem Script may be determined by which key was used to sign the Unlock Script.

[0021] Additionally or alternatively, a minimum number of said private keys may be required to sign the unlock script of further blockchain transactions to spend the outputs.

[0022] The result or output provided by the logic may depend on or be affected by determining which (particular) private key was used to sign the unlock script. The method may include verifying the private key used to sign the unlock script against the associated public key provided in the Redeem script.

[0023] Advantageously, this allows the present invention to provide a greater degree of control than prior art techniques that require that a specific number of keys be used, rather than a specific key being used. By determining which specific key from among multiple keys is used, the present invention provides an alternative, enhanced security technique that allows for a greater degree of granularity or sophistication when controlling the locking / unlocking of transaction outputs (UTXOs). Thus, the present invention can be said to provide an improved cryptographic technique for controlling the transfer of portions of cryptocurrency.

[0024] The logic in the Redeem Script may be configured to implement the functionality of logic gates, which may be NOT, AND, OR, NOR, XOR, IMPLY, NAND, NONIMPLY, and / or XNOR gates. Accordingly, the present invention may be described as providing techniques that allow the functionality of logic gates to be simulated or achieved by blockchain transactions.

[0025] The state of at least one data source can be determined by a computational agent, which can be configured to monitor a condition, which can be, for example, a condition on a computing network, or a device-related condition, or a condition of an environmental factor, or any other type of quantifiable condition.

[0026] The computing agent can communicate with a controlling computing agent, which may be referred to herein as a "controller." Redeem scripts can be generated by the controller. One or more agents can be configured to control a process or equipment.

[0027] One, some, or all of the computing agents may have a cryptographic key, which may be referred to as an agent base key. The agent base key may be derived from this base key. The cryptographic key may be generated by the agent. The cryptographic key may be derived and / or received from the control unit. One or more of the keys may be generated or derived from a base or "master" key. The key generation may be performed using deterministic key generation techniques. The method may include generating or deriving additional or separate keys for each possible state of the condition being monitored by the agent. The additional keys may be derived from the base key using techniques described below in the section entitled "Key Generation Using a Shared Secret."

[0028] The result provided by the logic may be a Boolean result or some other type of result. The logic may provide a result from a limited range of outcomes.

[0029] There may be at least two data sources. There may be two possible states for or associated with each data source. Each possible state may be associated with or represented by a public key. Thus, the list of public keys provided in the Redeem script may be used to define, represent, or describe all possible states that a data source may adopt or enter.

[0030] The method may include the following steps: For each of at least one data source, Associating a public key of the plurality of public keys with a possible state of the data source.

[0031] Thus, all possible states of a data source are represented by their respective public keys.

[0032] In other words, each possible state of each data source may be associated with or mapped to a public key, allowing the public key to be used as a (unique) identifier for that state. Thus, keys may be carefully selected to form a mapping between each key and the possible states of the data source. This may allow the keys to serve as a representation of the possible states of the data source. Analysis or determination of which private key is used to sign in the unlock script may then allow the state of the data source to be determined.

[0033] At least one data source may include a sensor. Additionally or alternatively, a data source may include a source capable of generating and / or transmitting an input signal to a computational resource or agent.

[0034] Each public key may represent a Boolean value indicating the possible state of at least one data source, for example, whether a signal is received or not, or whether the temperature is above 20 degrees Celsius.

[0035] The present invention also provides a corresponding system, which may be configured to perform any embodiment of the method described above.

[0036] The present invention provides a computer-implemented system comprising: at least one computer-based resource configured to perform the steps of any of the methods described above; A blockchain or other type of electronic ledger, or a variation of the Bitcoin ledger; This may be a distributed ledger.

[0037] At least one computer-based resource Submit the transaction to a blockchain network (which may or may not be the Bitcoin network, which may be any kind of distributed ledger); and / or Generate a transaction, and / or Digitally sign the lock script, and / or It may be configured to generate public / private cryptographic keys.

[0038] The system may be configured such that the results are used to control or influence the performance or operation of a process or equipment. The computer-based resources may be referred to as "agents."

[0039] The system may include at least one sensor or other signal / input generating component positioned / configured to provide input to at least one computer-based resource.

[0040] Any feature described in connection with one embodiment or aspect of the invention may be used in conjunction with one or more other embodiments or aspects, and any feature described in connection with a method may be applied to a system, and vice versa. [Brief explanation of the drawings]

[0041] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 shows a diagram of one embodiment of the present invention. [Figure 2] An illustrative embodiment of the present invention is shown in which multiple independent computational agents perform monitoring of the external environment to provide input to logic gate transactions. [Figure 3] 1 shows an overview of another embodiment of the present invention. [Figure 4] 1 shows an exemplary blockchain transaction in which transaction output 1 implements a NOR gate with transaction output 2 and refunds the controller, configured in accordance with one embodiment of the present invention. [Figure 5] 1 shows an overview of another embodiment of the present invention. [Figure 6] This shows a technique for generating an encryption key from a base key. [Figure 7] This shows a technique for generating an encryption key from a base key. [Figure 8] This shows a technique for generating an encryption key from a base key. [Figure 9] This shows a technique for generating an encryption key from a base key. [Figure 10] This shows a technique for generating an encryption key from a base key. DETAILED DESCRIPTION OF THE INVENTION

[0042] The present invention provides a novel and advantageous solution that uses a blockchain to perform functions. The blockchain is used to provide a record of the execution of the function and / or the results of its outcome. A function can be a subroutine or procedure (i.e., a process or piece of logic) that applies to a set of inputs and returns a set of outputs. In one possible embodiment, a function can be performed "off-block," i.e., the execution of the function does not depend on the blockchain. The function is performed by a computer-based resource.

[0043] A blockchain (e.g., Bitcoin) transaction is a transfer of value (e.g., Bitcoin) that typically references previous transaction outputs as new transaction inputs and contributes all input values ​​to the new output. Transactions are not encrypted; therefore, it is possible to view and examine all transactions ever collected into a block. However, it would be highly advantageous to be able to construct blockchain transactions that act as functions, where transaction outputs are conditional or dependent on supplied information. This could enable sophisticated behavior over the blockchain.

[0044] Important aspects of the present invention include (but are not limited to) methods for generating blockchain transactions in which functional inputs are represented by public keys used in the Redeem Script of the transaction's outputs, and actual values ​​are represented by signatures associated with one or more of the public keys.

[0045] The present invention is illustrated by the use case provided below, where blockchain (e.g., Bitcoin) transactions can be used to represent functions provided by logic gates, which can then be used to control some technological process or equipment.

[0046] The present invention provides a number of general-purpose novel features beyond blockchain, including: The ability to create agents for sensors or other signal / input generators, where the agents are controlled directly from the blockchain and do not require other network access to operate; · For transactions guaranteed by multiple signatures, the ability to determine which public keys were involved in the transaction signing process; The ability to embed a limited and distinct range of payload values ​​within the signing key that can be used to determine behavior within a Redeem script (e.g., how the code executes).

[0047] Additionally, embodiments of the present invention can utilize the elements described above to provide a logic gate (e.g., a NOR gate) where the input values ​​from A and B are embedded in or represented by the key used for signing.

[0048] <Advantages> The proposed invention offers the following advantages: · Inherently secure by design (the Bitcoin protocol does not require a trusted party); It is distributed, thus avoiding large-scale single points of failure and not vulnerable to attacks; · It is easy to manage and maintain, and the Bitcoin network is easy to use; · Not expensive (usually only small transaction fees are expected under the Bitcoin protocol); · It is global and can be used by anyone with access to the internet at any time; ·Be transparent; · Once data is written to the blockchain, anyone can see it; · It is immutable, once data is written to the blockchain, no one can change it; · Privacy is maintained and no personally identifiable information is involved.

[0049] In order for the present invention to work, the existing configuration and operation of the Bitcoin protocol and wallets must be recognized. Figure 1 shows how a standard Bitcoin transaction (TX) is constructed in accordance with one embodiment of the present invention. (Bitcoin is used for illustrative purposes only; other ledgers and associated protocols may be used and still fall within the scope of the present invention.)

[0050] <Agent configuration> One embodiment of the present invention involves the use of multiple independent (computational) agents configured to perform monitoring of the external environment to provide input to this logic gate transaction, as shown in Figure 2. Thus, the computational agents are designed to monitor some condition. The input may be received from a sensor for this purpose. For example, an agent may monitor a condition such as "Is the temperature below zero degrees Celsius?" or any other type of testable condition. Thus, the agent may be configured to monitor the state of that observed condition.

[0051] The agents communicate with a control or master agent, hereafter referred to as the “controller.” The controller is configured to operate in conjunction with the blockchain protocol.

[0052] In one or more embodiments, subordinate agents (e.g., A and B) may have keys derived from the controller. However, it should be noted that it is possible for agents A and B to have their own generated keys and not derive keys from the controller. This limits the functionality that the controller can use with the keys.

[0053] In one or more embodiments, each condition being monitored has a separate monitoring agent configured with its own key. From this key, they derive separate keys for the outputs from their monitored conditions (i.e., for each possible state). These values ​​can be deterministically derived from their base key. This can be done at the monitoring point, or the agent can pre-derive the values ​​(e.g., it may be more efficient to simply pre-define true / false sensors). Keys can be derived from the base key using techniques described below in the section entitled "Generating Keys Using a Shared Secret."

[0054] <Agent behavior> The above embodiments allow agents to have very tightly defined behavior; at their basic point, they are sensors detecting a single condition and responding to that condition as appropriate. The following table illustrates the behavior patterns of these agents: [Table 1]

[0055] Note that step 2 is the standard process for conducting a multi-signature transaction as known in the art. The novel steps are in steps 3 and 4, which allow the agent to embed the sensor values ​​into the signature returned by the agent.

[0056] <Data Value Extraction and Transaction Evaluation> The Redeem script within the transaction then allows for efficient virtual extraction of the embedded value by an autonomous agent. However, this only works if the range of possible values ​​is known in advance. Here, an example is used in which agents A and B provide "true" / "false" values, but a wider range of values ​​can also be used with this method (e.g., 1, 2, 3, 4, 5). The key is that a unique key is used to represent each possible value or state, so the Redeem script can determine based on what value the key was used to sign the unlock script. However, the method does not support an infinite range of possible values, as logic provided within the Redeem script must be configured to perform this analysis.

[0057] The method works by evaluating the signature provided by the agent against its possible derived public keys, thus determining what the public keys for each possible input value (state) were when the Redeem script was originally constructed by the controller, and including these in the payload of the Redeem script.

[0058] The script extracts this data by determining which of the public keys was used to sign the transaction, and because the script is coded to implicitly understand the value that public key represents, the script effectively extracts that value for use within the limited scope of the script.

[0059] Within the scope of the blockchain standard, the built-in OP_CHECKMULTISIG transaction function enables the evaluation of signatures to determine that sufficient signatures have been collected by the unlock script. However, this does not enable an explicit determination of which were used. Thus, the present invention provides a technique that uses a Tx to explicitly collate against keys to determine which were used, and thus enables the implementation of a great deal of complexity via the transaction, so the present invention provides an improvement over the prior art. In other words, by determining which subset of multiple keys is used in the signature process, it is possible to generate a more advanced operation via the blockchain.

[0060] For example, in the escrow function, it is possible to efficiently generate escrow by a plurality of escrow agents, but define script rules that require the preparation of signatures of either the buyer and the seller, or one of the buyer and the escrow agent, or one of the buyer and the escrow agents. This is not possible with the known standard Bitcoin protocol, as the standard configuration could allow both escrow agents to sign the transaction.

[0061] <Redeem script pseudo code> According to an embodiment of the present invention, the logic within the Redeem script may be configured as follows.

Number

[0062] <Exemplary transaction> In the exemplary transaction, transaction output (TxO) 1 implements a NOR gate with transaction output 2 and returns it to the control unit. The transaction is shown in FIG. 4.

[0063] <Redeem script> The complete Redeem script is shown below, which is then broken down into its logical components:

number

[0064] The boxed instruction code illustrates the NOR gate payload code (block 7 below) that sits on top of the signature manipulation logic required to put the data into a verifiable format.

[0065] To partition into logical "sub-functions", the script is broken down into a sequence of blocks as shown in the table below for the convenience of the reader. [Table 2-1] [Table 2-2]

[0066] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0067] <Unlock script> The required unlock script is: <sig-controller> <sig-a-used> <sig-b-used><RS Block 1> where: <sig-a-used>is one of the following: <sig-a-true>or <sig-a-false> <sig-b-used>is one of the following: <sig-b-true>or <sig-b-false>

[0068] <Example: NOR logic gate> A NOR gate is a logic gate that implements NOT OR: if both inputs are false, the output is true, otherwise the output is false. [Table 3]

[0069] The NOR gate is implemented within a single Bitcoin transaction output that requires a control signature, as well as a signature from agent A representing either a true or false value, and another signature from agent B (also either true or false). Figure 1 provides an overview of how this NOR gate can be implemented with the Bitcoin protocol.

[0070] Alternative gates can be implemented by replacing the RB block 7 as shown in later sections.

[0071] <ANDゲート> [Table 4] [Table 5]

[0072] <NANDゲート> [Table 6] [Table 7]

[0073] <ORゲート> [Table 8] [Table 9]

[0074] <XORゲート> [Table 10] [Table 11]

[0075] <XNORゲート> [Table 12] [Table 13]

[0076] <NOTゲート> The implementation of this gate is slightly more complex since it only has a single input. [Table 14]

[0077] As a result, the unlock script changes to:

number

[0078] A single input results in the following block changes: [Table 15]

[0079] A number of different embodiments may be provided as described below.

[0080] <Variation 1: Generating true and false signals> The above discussion allowed the unsigned transaction output (UTXO) representing a logic gate to be used only if the gate condition evaluated to true. However, in many situations, it may be advantageous to use the output (albeit with a different recipient address) regardless of the actual output of the circuit.

[0081] This is possible with this embodiment. Effectively, the embodiment shown in Figure 1 is modified as shown in Figure 3. In this embodiment, there is an additional parameter that is provided to the Redeem script of the first transaction (Tx). This additional parameter can be a puzzle, or a value embedded in the key, or a value that is provided explicitly (as in this example). This defines the desired output of the controller that should use the UTXO.

[0082] Thus, in a simple logic gate, the controller may attempt to use the transaction twice with the same signature, once with a predicted true output and once with a predicted false output.

[0083] The Redeem script is extended to apply an equality check of the gate's output to the output requested by the control unit at the end of the gate computation. Thus:

[0084] If the embedded gate logic returns false and the desired output is false, the Redeem script evaluates to true and the UTXO can be spent; If the embedded gate logic returns true and the desired output is true, the Redeem script evaluates to true and the UTXO can be spent; If the embedded gate logic returns true and the desired output is true, the Redeem script evaluates to false and the UTXO cannot be spent; If the embedded gate logic returns false and the desired output is true, the Redeem script evaluates to false and the UTXO cannot be spent.

[0085] <Transformation script> The complete Redeem script is shown below, which is then broken down into logical components for the convenience of the reader. Additions from the first embodiment are shown in reverse text (deletions are shown in strikethrough).

number

[0086] The boxed instruction code illustrates the NOR gate payload code above the signature manipulation logic to put the data into a verifiable format.

[0087] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0088] <Unlock script> The unlock script for this pattern of logic gates is:

number

[0089] <Variation 2: Generation of hidden true and false signals> This embodiment may essentially be the subject of the present invention. Variant 1 has the drawback that it is known (from the Redeem script) whether a true or false condition has been signaled from the script. Embedding the desired signal in the signature from the control unit avoids this problem. In this embodiment of variant 2, the control unit has two public keys derived from its primary key as shown in Figure 5.

[0090] Thus, instead of providing values ​​representing the T / F signals in the script's metadata as in variant 1, this embodiment uses public keys instead of parameters. This means that inspecting the keys does not reveal their "meaning" in terms of the desired output they represent. This embodiment provides important benefits in terms of increased security and privacy. It also provides a means of using cryptography in a novel way.

[0091] The controller still attempts to spend the transaction output twice, to different addresses, as in Variant 1 above. An equality check or comparison is also performed as in Variant 1, but using public keys instead of supplied parameters. To do this, the logic within the Redeem script is configured with explicit "knowledge" of which keys represent which desired outputs (true or false).

[0092] <Transformation script> The complete Redeem script is shown below, which is then broken down into its logical components, with additions from the first embodiment above shown in reverse text (deletions shown in strikethrough):

number

[0093] The boxed instruction code illustrates the NOR gate payload code above the signature manipulation logic to put the data into a verifiable format.

[0094] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0095] <Unlock script> The unlock script for this pattern of logic gates is:

number

[0096] <Variant 3: Single code stack> These gates can be implemented using a single stack without using the old (alt) stack.

[0097] <Redeem script: Overview and NOR> The complete Redeem script is shown below. This is then decomposed into logical components.

Number

[0098] The instruction code within the frame exemplifies the NOR gate payload code on top of the signature operation logic for formatting data into a verifiable format.

[0099] All stacks are shown in order from top to bottom.

[0100] <Lock script> The lock script is a standard Pay-to-Script-Hash model. OP_HASH160 <Redeem Script Hash> OP_EQUAL

[0101] <Unlock script> The unlock script for this pattern of logic gates is as follows (note the different order of the signature blocks): <sig-b-used> <sig-a-used> <sig-controller><RS Block 1> where: <sig-a-used>teeth, <sig-a-true>or <sig-a-false>and <sig-b-used>teeth, <sig-b-true>or <sig-b-false>is.

[0102] <Alternate gate> To implement the alternative logic gate, replace the explicit NOR code in the box with the following: [Table 16]

[0103] <Scenario: Burglar Alarm Setting (NOR Gate)> A simple example of the above embodiment utilizing a NOR gate is setting a burglary alarm.

[0104] In this example, Agent A is a door sensor on the loading door that signals true when the door is open and false when it is closed.

[0105] Agent B is also a door sensor, but is located in a safe within the building. Agent B also communicates true when a door is open and false when a door is closed. The control unit is the central alarm system and will only set an alarm if all doors in the building are closed. Therefore, the control unit broadcasts a transaction to the various monitoring agents when it is asked to set an alarm. The transaction is only complete when Agent A and Agent B communicate that their respective doors are closed.

[0106] We describe below a technique for generating new keys from the base key, as described above.

[0107] <Key generation using a shared secret> The following techniques are described with reference to Figures 6-10.

[0108] Using the following techniques, keys may be securely stored or regenerated: In particular, in the case of private keys that can be used to derive public keys, the private keys may be stored in fragments.

[0109] The user, Alice or Bob, may hold one part of their private key, the service provider may hold a second part, and the third part may be held at a remote secure site. The private key may be reconstructed using any two of the three parts, or more generally, the private key may be reconstructed using any m of the n parts.

[0110] If the private key is reconfigurable, it can be used to regenerate the public key at the point of use, and the private and public keys can again be discarded after use.

[0111] The separation of the private keys may be achieved using Shamir's Secret Sharing Scheme: a private-public key pair can be deterministically derived from a master key using the following method: This method allows secret values ​​to be shared by participants without transmitting them.

[0112] The system may generate participants' public keys using the subkey generation method described below.

[0113] 6 shows a system 1 including a first node 3 in communication with a second node 7 via a communications network 5. The first node 3 has an associated first processing device 23, and the second node 5 has an associated second processing device 27. The first and second nodes 3, 7 may include electronic devices such as computers, phones, tablet computers, mobile communications devices, computer servers, etc. In one example, the first node 3 may be a client (user) device and the second node 7 may be a server, which may be a server of a digital wallet provider.

[0114] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) The second node (7) is associated with a first asymmetric cryptographic pair having a second node master private key (V 1S ) and the second node master public key (P 1S ) In other words, the first and second nodes each possess an individual public-private key pair.

[0115] The first and second asymmetric cryptographic pairs of each first and second node 3, 7 may be generated during a registration process, such as wallet registration, and the public key of each node may be publicly shared across the communications network 5.

[0116] To determine a common secret (SC) at both the first node 3 and the second node 7, the nodes 3, 7 perform the steps of methods 300, 400 respectively, without communicating the private key over the communications network 5.

[0117] The method 300 performed by the first node 3 includes obtaining at least the first node master private key (V 1C ) and the Generator Value (GV), the first node second private key (V 2C ). The generator value may be based on a message (M) shared between the first node and the second node, which may include sharing the message over the communication network 5, as described in more detail below. The method 300 includes determining 330 at least the second node's master public key (P 1S ) and the Generator Value (GV), the second node second public key (P 2S ). The method 300 further includes determining 370 the first node second private key (V 2C ) and the second node second public key (P 2S ) to determine a common secret (CS).

[0118] Importantly, the same common secret (CS) can also be determined at the second node 7 by the method 400. The method 400 determines the first node's master public key (P 1C ) and the Generator Value (GV), the first node second public key (P 2C ). The method 400 includes a step 430 of determining the second node master private key (V 1S ) and the Generator Value (GV), the second node second private key (V 2S ). The method 400 further includes determining 470 the second node second private key (V 2S ) and the first node second public key (P 2C ) to determine a common secret (CS).

[0119] The communications network 5 may include a local area network, a wide area network, a cellular network, a wireless communications network, the Internet, etc. In these networks, data may be transmitted over communications media such as electrical wires, optical fibers, or radio waves, which may be susceptible to eavesdropping, such as by an eavesdropper 11. The methods 300, 400 enable the first node 3 and the second node 7 to both independently determine the common secret without transmitting the common secret over the communications network 5.

[0120] Thus, one advantage is that the common secret (CS) can be determined securely and independently by each node, without the need to transmit the private key over a potentially insecure communications network 5. The common secret may also be used as (or as the basis for) the private key.

[0121] The methods 300, 400 may include additional steps: The method 300 includes, at the first node 3, transmitting a message (M) and a first node second private key (V 2C ) to generate a signed message (SM1). The method 300 may further include a step 360 of transmitting the first signed message (SM1) to the second node 7 via the communication network. Meanwhile, the second node 7 may perform a step 440 of receiving the first signed message (SM1). The method 400 may further include a step 440 of transmitting the first signed message (SM2) to the first node second public key (P 2C ), and a step 460 of authenticating the first node 3 based on the result of the step of verifying the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the intended first node (where the first signed message was generated) is the first node 3. This is because only the first node 3 has the first node master private key (V 1C ), so only the first node 3 has access to the first node second private key (V 2C ) can be determined. It should be appreciated that similarly, a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3. Thus, as in a peer-to-peer scenario, the first node 3 can authenticate the second node 7.

[0122] The sharing of a message (M) between the first node and the second node may be achieved in various ways. In one example, the message may be generated at the first node 3 and then transmitted to the second node 7 over the communication network 5. Alternatively, the message may be generated at the second node 7 and then transmitted to the first node 3 over the communication network 5. In some examples, the message (M) may be public and therefore may be transmitted over an insecure network 5. One or more messages (M) may be stored in a data store 13, 17, 19. Those skilled in the art will appreciate that the sharing of a message may be achieved in various ways.

[0123] Advantageously, a record that allows for the recreation of the common secret (CS) can be maintained without the record itself having to be stored in secret or transmitted securely.

[0124] <How to register 100, 200> An example of a method 100, 200 for registration is described below, where method 100 is performed by a first node 3 and method 200 is performed by a second node 7. It includes establishing first and second asymmetric cryptographic pairs for the first node 3 and the second node 7, respectively. The asymmetric cryptographic pairs include associated private and public keys, such as those used in public key cryptography. In this example, the asymmetric cryptographic pairs are generated using properties of Elliptic Curve Cryptography (ECC) and elliptic curve arithmetic.

[0125] In methods 100, 200, this involves a first node and a second node agreeing 110, 210 on a common ECC system and using a base point (G). (Note: The base point may be referred to as a common generator, but the term "base point" is used to avoid confusion with the generator value GV.) In one example, the common ECC system may be based on secp256K1, the ECC system used by Bitcoin. The base point (G) may be selected, randomly generated, or assigned.

[0126] Turning now to the first node 3, the method 100 includes resolving 110 a common ECC system and base point (G). This may include receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 may be associated with the first node 3, allowing a user to selectively provide the common ECC system and / or base point (G). In yet another alternative, one or both of the common ECC system and / or base point (G) may be randomly selected by the first node 3. The first node 3 may send a notification to the second node 7 over the communications network 5 indicating the use of the common ECC system with the base point (G). The second node 7 may then resolve 210 by sending a notification indicating an acknowledgment to the use of the common ECC system and base point (G).

[0127] The method 100 includes a step of: 1C ) and the first node master public key (P 1C ), which is based at least in part on random integers within a specified range of tolerances in the common ECC system, and 1C ), which generates the first node master private key (V 1C ) and the base point (G) based on the elliptic curve point multiplication, the first node master public key (P 1C ) P 1C =V 1C ×G (Formula 1)

[0128] Thus, the first asymmetric crypto pair comprises: V 1C : First node master private key, kept secret by the first node. P 1C : The first node master public key, which is publicly announced.

[0129] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) may be stored in a first data store 13 associated with the first node 3. For security purposes, the first node master private key (V 1C ) may be stored in a secure part of the first data store 13 to ensure that the key remains secret.

[0130] The method 100 includes generating a first node master public key (P 1C ) to the second node 7 via the communication network 5. The second node 7 transmits the first node master public key (P 1C ) is received 220, the first node master public key (P 1C ) may be stored 230 in a second data store 17 associated with the second node 7.

[0131] Similar to the first node 3, the method 200 of the second node 7 involves the second node master private key (V 1S ) and the second node master public key (P 1S ) and generating 240 a second asymmetric cryptopair having a second node master private key (V 1S ) is also a random integer within the allowed range. Also, the second node master public key (P 1S ) is determined by the following formula: P 1S =V 1S ×G (Formula 2)

[0132] Thus, the second asymmetric crypto-pair comprises: V 1S : The second node master private key, which is kept secret by the second node. P 1S : The second node master public key, which is publicly known.

[0133] The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. The method 200 may store the second node master public key (P 1S ) to the first node 3. The first node 3 also transmits the second node master public key (P 1S ) Receive 140, store 150.

[0134] It should be appreciated that in some alternatives, each public master key may be received and stored in a third data store 19 associated with a third node 9 (such as a trusted third party). This may include a third party acting as a public directory, such as a certification authority. Thus, in some examples, the first node master public key (P 1C ) may be requested and received by the second node 7 only when a common secret (CS) is requested (and vice versa).

[0135] The registration step only needs to occur once as an initial setup.

[0136] <Session initiation and determination of a shared secret by the first node 3> An example of determining the common secret (CS) is described below. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and it may not be desirable or secure to use the same common secret (CS). Thus, the common secret (CS) may be changed between different sessions, times, transactions, etc.

[0137] The following is provided for explanation of the secure transmission techniques discussed above.

[0138] [Generate message (M) 310] In this example, the method 300 performed by the first node 3 includes the step 310 of generating a message (M). The message (M) may be random, pseudo-random, or user-defined. In one example, the message (M) is based on Unix time or a nonce (and any value). For example, the message (M) may be given as: Message (M) = Unix time + nonce (Equation 3)

[0139] In some examples, the message (M) is arbitrary. However, it should be understood that the message (M) may have alternative values ​​(such as Unix time, etc.) that may be useful in some applications.

[0140] The method 300 includes a step 315 of sending the message (M) to the second node 7 over the communication network 3. Because the message (M) does not contain information about the private key, the message (M) may be sent over an insecure network.

[0141] [320 Determine Generator Value (GV)] The method 300 further includes determining 320 a Generator Value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. An example of a cryptographic hash algorithm includes SHA-256 to generate a 256-bit Generator Value (GV), i.e., GV=SHA-256(M) (Equation 4)

[0142] It should be understood that other hash algorithms may be used. This may include other hash algorithms in the Secure Hash Algorithm (SHA) family. Some specific examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include algorithms in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A specific example may include RIPEMD-160. Other hash functions may include families based on Zemor-Tillich and Knapsack hash functions.

[0143] [First node determines second private key 330] The method 300 then calculates the second node master private key (V 1C ) and the generator value (GV), the first node second private key (V 2C ), which involves determining 330 the first node master private key (V 1C ) and a generator value (GV). V 2C =V 1C +GV (Equation 5)

[0144] Therefore, the first node's second private key (V 2C ) is not a random value, but instead is deterministically derived from the first node master private key. The corresponding public key in the cryptographic pair, i.e., the first node second public key (P 2C ) have the following relationship: P 2C =V 2C ×G (Equation 6.1)

[0145] From equation 5 to equation 6, V 2C Substituting, we obtain the following equation: P 2C =(V 1C +GV)×G (Formula 7)

[0146] Here, the “+” operator represents elliptic curve point addition. Elliptic curve cryptography algebra is distributive, and Equation 7 can be expressed as follows: P 2C =V 1C ×G+GV×G (Formula 8)

[0147] Finally, (Equation 1) is substituted into (Equation 7) to obtain the following equation: P 2C =P 1C +GV×G (Formula 9.1) P 2C =P 1C +SHA-256(M)×G (Equation 9.2)

[0148] Therefore, the corresponding first node second public key (P 2C ) is the first node master public key (P 1C ) and derivable given knowledge of the message (M). As described in further detail below with respect to method 400, the second node 7 may have the first node second public key (P 2C ) independently.

[0149] [Generate 350 a first signed message (SM1) based on the message and the first node's second private key] The method 300 includes transmitting a message (M) and a determined first node second private key (V 2C ) to generate a first signed message (SM1). Generating a signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this involves applying a first node second private key (V) to the message in an Elliptic Curve Digital Signature Algorithm (ECDSA) to obtain the first signed message (SM1). 2C Examples of ECDSA include those based on ECC systems with secp256k1, secp256r1, secp384r1, se3cp521r1.

[0150] The first signed message (SM1) is sent to the second node 7 using the corresponding first node second public key (P 2C ) This verification of the first signed message (SM1) may be used by the second node 7 to authenticate the first node 3, which is discussed below in method 400.

[0151] [Second node determines second public key 370'] The first node 3 then sends the second node second public key (P 2S ) may be determined 370. As mentioned above, the second node second public key (P 2S ) must contain at least the second node master public key (P 1S ) and a generator value (GV). In this example, the public key is determined as a private key by elliptic curve point multiplication with the base point (G) 370, so that the second node's second public key (P 2S ) can be expressed as follows, similar to Equation 6: P 2S =V 2S ×G (Equation 10.1) P 2S =P 1S +GV×G (Equation 10.2)

[0152] The mathematical proof of Equation 10.2 is that the first node's second public key (P 2C ) is the same as that described above to derive equation 9.1 for . It should be understood that the first node 3 can determine 370 the second node second public key independently of the second node 7.

[0153] [380 Determine the common secret at the first node 3] The first node 3 then receives the first node second private key (V 2C ) and the determined second node second public key (P 2S ) a common secret (CS) may be determined 380 based on the common secret (CS). The common secret (CS) may be determined by the first node 3 according to the following formula: S=V 2C ×P 2S (Formula 11)

[0154] <Method 400 Executed in Second Node 7> A corresponding method 400 performed in the second node 7 will now be described. It should be understood that some of these steps are similar to the steps performed by the first node 3 described above.

[0155] The method 400 includes a step 410 of receiving a message (M) from the first node 3 via the communications network 5. This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines 420 a generator value (GV) based on the message (M). The step 420 of determining a generator value (GV) by the second node 7 is similar to the step 320 performed by the first node 3 described above. In this example, the second node 7 performs this determining step 420 independent of the first node 3.

[0156] The next step is to create the first node master public key (P 1C ) and the generator value (GV), the first node second public key (P 2C In this example, the public key is determined as a private key by elliptic curve point multiplication with the base point (G) 430, so that the first node second public key (P 2C ) can be expressed as follows, similar to Equation 9: P 2C =V 2C ×G (Equation 12.1) P 2C =P 1C +GV×G (Equation 12.2)

[0157] The mathematical proofs of Equations 12.1 and 12.2 are the same as those given above for Equations 10.1 and 10.2.

[0158] [Second node 7 authenticates first node 3] The method 400 may include steps performed by the second node 7 to authenticate the unconfirmed first node 3 as the first node 3. As mentioned above, this includes step 440 of receiving the first signed message (SM1) from the first node 3. The second node 7 then receives the first node second public key (P 2C ) may verify the signature of the first signed message (SM1) 450.

[0159] The verification of the digital signature may be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA) mentioned above. Importantly, the first node's second private key (V 2C ) is signed by V 2C and P 2C form a cryptographic pair, the corresponding first node second public key (P 2C ) generated during the registration of the first node 3. 1C ) and the first node master public key (P 1C ), verification of the first signed message (SM1) can be used as a basis for authenticating that the unconfirmed first node sending the first signed message (SM1) is the same first node 3 being registered. Therefore, the second node 7 may further perform a step (460) of authenticating the first node 3 based on the result of the step (450) of verifying the first signed message.

[0160] [Second node 7 determines the shared secret] The method 400 is performed by the second node 7, which is configured to 1S ) and the generator value (GV), the second node second private key (V 2S ) as performed by the first node 3. Similarly to step 330 performed by the first node 3, the second node may determine a second private key (V 2S ) is calculated by the following formula: 1S ) and a generator value (GV). V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Equation 13.2)

[0161] The second node 7 then, independently of the first node 3, calculates the second node second private key (V 2S ) and the first node second public key (P 2C ), a common secret (CS) may be determined 480. S=V 2S ×P 2C (Formula 14)

[0162] [Certification of the common secret (CS) determined by the first node 3 and the second node 7] The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. A mathematical proof that Equation 11 and Equation 14 provide the same common secret (CS) is now described.

[0163] Given the common secret (CS) determined by the first node 3, Equation 10.1 can be substituted into Equation 11 as follows: S=V 2C ×P 2S (Formula 11) S=V 2C ×(V 2S ×G) S=(V 2C ×V 2S )×G (Equation 15)

[0164] Given the common secret (CS) determined by the second node 7, Equation 12.1 can be substituted into Equation 14 as follows: S=V 2S ×P 2C (Formula 14) S=V 2S ×(V 2C ×G) S=(V 2S ×V 2C )×G (Equation 16)

[0165] Since ECC algebra is commutative, Equation 15 and Equation 16 are equivalent: S=(V 2C ×V 2S )×G=(V 2S ×V 2C )×G (Equation 17)

[0166] [Common Secret (CS) and Private Key] The common secret (CS) can now be used as a private key or as the basis for a private key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7 .

[0167] The common secret (CS) is the elliptic curve point (x S ,y S ), which may be converted to a standard key format using a standard publicly known operation agreed upon by nodes 3 and 7. For example, x S The value is AES 256 It can be a 256-bit integer that can be used as a cryptographic key, which can be further converted to a 160-bit integer using RIPEMD160 for any application that requires a 160-bit long key.

[0168] The common secret (CS) may be determined as needed. Importantly, the first node 3 does not need to store the common secret (CS) because it can be re-determined based on the message (M). In some examples, the message (M) used may be stored in a data store 13, 17, 19 (or other data store) that does not have the same level of security as required for a master private key. In some examples, the message (M) may be publicly available.

[0169] However, depending on the application, the shared secret (CS) may be the first node master private key (V 1C ), the common secret (CS) may be stored in a first data store (X) associated with the first node.

[0170] Advantageously, this technique can be used to determine multiple shared secrets, which may correspond to multiple secure private keys, based on a single master key crypto-pair.

[0171] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" or "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes" or "consists of," and "comprising" means "including" or "including of." The singular reference of an element does not exclude the presence of a plurality of such elements, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means can be embodied by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0172] 3 First Node 5. Network 7 Second Node 9 Third Node 11. Eavesdropper < / sig-a-used> < / sig-b-used> < / sig-a-false> < / sig-a-used> < / sig-controller>

Claims

1. 1. A computer-implemented control method for controlling the operation of a technical process, said method comprising: providing a blockchain transaction having a Redeem script for an output, the Redeem script comprising: i) a plurality of input parameters, each input parameter uniquely associated with a possible state of at least one data source, the data source including a sensor; ii) logic, - calculations performed on the input parameters provided by the unlock script to provide intermediate results; and - comparing the target output parameters of the unlocked script to the intermediate results; and logic configured to provide a result based on the attempting to use a transaction output more than once, each attempt being made by supplying different target output parameters to the Redeem script; A method comprising:

2. The method comprises: For each data source, associating public keys of a plurality of public keys with possible states of the data source, such that every possible state of the data source is represented by a respective public key; The method of claim 1 further comprising:

3. The method of claim 1 , wherein the results are used to control or influence the performance or operation of a process or device.

4. The method of claim 1 , wherein the logic is configured to implement the functionality of a logic gate.

5. 5. The method of claim 4, wherein the logic gate is a NOT, AND, OR, NOR, XOR, IMPLY, NAND, NONIMPLY, or XNOR gate.

6. The method according to any one of claims 1 to 5, wherein the state of said at least one data source is determined by a computing agent.

7. The method of claim 6 , wherein the computing agent communicates with a control computing agent.

8. The method of claim 1 , wherein the result is a Boolean result.

9. The method of claim 1 , wherein the logic is configured to perform an equivalence check to compare the intermediate results with the target output parameters.

10. 1. A computer-implemented system comprising: at least one computer-based resource, said at least one computer-based resource configured to perform a method according to any one of claims 1 to 9; Blockchain and A system including:

11. The at least one computer-based resource: Submit a transaction to the blockchain network, Generate a transaction, Digitally signing the lock script, and / or Generate public / private cryptographic keys, 11. The computer-implemented system of claim 10, configured to:

12. 12. A system according to claim 10 or 11, wherein the results are used to control or influence the performance or operation of a process or device.

Images