Implementing logic gate functionality using blockchain

Abstract

This invention provides a method and control system for generating blockchain transactions in order to implement the functionality of logic gates. [Solution] A transaction includes a lock script having instructions selected to implement the functionality of a logical gate such as OR, AND, XOR, NOT, etc. The instructions may be provided in hashed form. When the script is executed (the second transaction attempts to use the output associated with the lock script), the input is processed by conditional instructions to provide a true or false output. The second transaction is sent to the blockchain network for verification and, if determined to be valid, is written to the blockchain. The validity of the second transaction can be interpreted as a true output. The lock script of the first transaction provides the functionality of the desired logical gate.

Description

[Technical Field]

[0001] This invention generally relates to distributed ledger (blockchain) technology. This invention may be any blockchain-related technology, including, but is not limited to, the Bitcoin blockchain. Aspects of this invention also relate to the field of logic gates and combinational logic. This invention may be suitable for use in conjunction with control systems or processes. [Overview of the Initiative]

[0002] In this specification, the term “blockchain” is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, sidechain and alternative chain technologies, shared ledgers, and their variations. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Bitcoin is referred to in this specification for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term “user” may refer to a human or computer-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system composed of blocks. Blocks, in turn, are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants within the blockchain system, and it includes at least one input and at least one output. Each block contains the hash of the previous block, and together the blocks form a chain, generating a permanent, immutable record of all transactions written to the blockchain from its inception. A transaction contains a small program known as a script embedded in its input and output. The script specifies how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] Transactions must be "verified" before they can be written to the blockchain. Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. Software clients installed on the nodes perform this verification work on unused transactions (UTXOs) by executing their own lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and written to the blockchain. Thus, an unlock script can provide input for the evaluation of the lock script. This is typically in the form of a signature-based input, but other input formats are known to be possible. Furthermore, many commands in scripting languages ​​are Boolean operators (e.g., OP-EQUAL) that provide true or false results. This makes it possible to construct conditions within transactions.

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementation. However, in more recent years, digital entrepreneurs have begun exploring both the use of Bitcoin-based cryptocurrency security systems and data that can be stored on blockchains to implement new systems. This invention relates to one such new and novel adaptation of blockchain technology. In particular, this invention relates to the use of blockchain to implement or emulate the functionality of logic gates, which can be used as a simple yet efficient and powerful mechanism for generating systems that can be implemented by a wide range of computers. Such systems may include control units that control processing and / or direct the operation of devices and systems.

[0006] The fundamental element of a control unit is a logic gate. By constructing gate logic within blockchain transactions (Tx), powerful processing can be implemented that leverages the benefits provided by blockchain technology. These benefits include, but are not limited to, enhanced cybersecurity, decentralized device / system / process control, possible integration with legacy systems, and immutability / persistence of records.

[0007] Therefore, it is desirable to provide or emulate the functionality of logic gates or to provide a solution via blockchain. In such a solution, logic gates can be implemented by lock scripts for blockchain transactions. Extensions to the basic structure of logic gates can be provided to allow any number of inputs and any number of outputs.

[0008] Such improved solutions have been devised. Accordingly, according to the present invention, solutions as defined in the appended claims are provided.

[0009] Embodiments of the present invention may provide computer-implemented methods and corresponding systems. These may be described as control methods / systems.

[0010] The present invention may provide a method for providing or using a blockchain transaction (TX1) having a lock script, wherein the lock script executes a portion of code selected and configured to implement and / or emulate the functionality of a logic gate. The execution of the portion of code may be performed after evaluation of at least one condition that generates an input to the portion of code.

[0011] The evaluation of at least one condition may generate a Boolean input. Parts of the code may have one or more instructions. These may be opcodes. Opcodes may push data onto the stack or pop data from the stack. Parts of the code may be configured to be executed using the results of one or more conditions. Parts of the code may be selected by the user (i.e., the programmer or the creator of the transaction), particularly for the purpose of emulating a logic gate.

[0012] As an addition or alternative, the method may have a step of providing a lock script within the first blockchain transaction. The first (and / or further) transactions may be generated by an automated process, i.e., by a computer without human intervention.

[0013] A lock script may have at least one instruction (i.e., a portion of code) configured to process at least one Boolean input. In one or more embodiments, at least one instruction may be provided within the lock script as a hash of at least one instruction. Thus, the instruction may be in a hashed form. At least one instruction may process a Boolean input by using the Boolean input in a computation or by performing some operation on the Boolean input.

[0014] A Boolean input may be generated by evaluating a condition before executing a portion of the code. The condition may include an equivalence test between a hash value and a stored hash value. The pre-stored hash value may be provided in the lock script. Alternatively, the condition may be implemented by one or more instructions / opcodes provided in the lock script.

[0015] The method may include a step of providing a further blockchain transaction having an unlock script. The unlock script may have a redeem script. At least one instruction may be provided as a hash within the lock script so that the actual instruction is provided by the unlock (redeem) script. Here, the hash of the provided instruction must match the hash within the lock script for the output of the transaction to be used.

[0016] The method may have the step of processing at least one input signal in order to provide at least one Boolean input. The input signal may be received from or derived from any source.

[0017] The method may include a step of using at least one Boolean input to execute a lock script and an unlock script for the first and subsequent blockchain transactions, respectively.

[0018] The step of processing at least one input signal to provide at least one Boolean input may be performed by an unlock script for a further blockchain transaction.

[0019] Alternatively or additionally, it may be executed by at least one computing resource or agent before being used as input to the unlock script. The computing resource may be an "off-block" resource, meaning it is not part of the blockchain network.

[0020] The method may further include the step of sending further transactions and / or the first transaction to a blockchain network for evaluation. The network may be the Bitcoin network.

[0021] The method may include a step of monitoring or searching the network's blockchain to determine whether or not further transactions exist.

[0022] The method may include the step of providing computing resources configured to affect the operation of a device or process based on the detection of further transactions within the blockchain.

[0023] The method may include a step of interpreting the validity of further transactions as the true output provided by a logical gate. Validity may be determined by a control agent or by monitoring the blockchain and / or blockchain network.

[0024] Further determination of transaction validity may act as a trigger to cause the action to be executed by the computing resources / agent.

[0025] Further verification of transactions within the blockchain network may rely on the execution of an unlock script.

[0026] The method may include a step of controlling the activity or operation of an apparatus, system, or process based on a determination of the presence or absence of further transactions within the blockchain. This may be any kind of apparatus, system, or technical process. The controlled apparatus, system, or process may be carried out outside the block, i.e., away from or separate from the blockchain network.

[0027] At least one instruction within the lock script may be configured to implement the truth table for a logic gate.

[0028] The gate may be an OR gate, XOR gate, NAND gate, NOR gate, NOT gate, or XNOR gate. The gate may be an AND gate. The gate may be an IMPLY gate (also known as a logical condition, substantial condition, or substantial implication). The gate may be a Converse implication gate.

[0029] At least one input signal may have a numerical value, a constant value, the result of a hash function, a cryptographic key, a blockchain puzzle, and / or other blockchain-related addresses of Bitcoin.

[0030] The first and / or further transactions may be generated and / or sent to the blockchain network by an automated process running on computer-based resources.

[0031] At least one instruction may have a Boolean condition or operator. At least one instruction may be written and / or executed using a stack-based programming language.

[0032] The present invention may also provide a system implemented by a computer configured to carry out any version of the above-described method.

[0033] The present invention provides a control system that incorporates Boolean calculations or conditions performed using or on a blockchain, wherein the Boolean calculation or operation has a blockchain transaction having a lock script, and the lock script has at least one instruction selected to implement the functionality of a Boolean truth table by processing at least one input to provide at least one Boolean output.

[0034] The truth table may be the truth table for OR gates, XOR gates, NAND gates, NOR gates, and NOT gates or XNOR gates. The truth table may be the truth table for IMPLY gates (also known as logical conditions, substantial conditions, or substantial implications). The truth table may be the truth table for AND gates.

[0035] According to another aspect of the present invention, a computer-implemented control method may be provided that substantially follows "Technology 3" described below. Such a method may include the steps of: providing a lock script in each of a plurality of first blockchain transactions, wherein each lock script has at least one instruction configured to process at least one input signal; providing a further blockchain transaction having an unlock script; processing at least one input signal to generate at least one transaction output; and using at least one transaction output to execute lock and unlock scripts for the first and further blockchain transactions.

[0036] The step of processing at least one input signal to generate at least one transaction output may be performed i) by an unlock script for further blockchain transactions, or ii) by at least one computing resource or agent.

[0037] The method may include the steps of: sending further transactions and / or the first transaction to a blockchain network for evaluation; and / or monitoring or searching the blockchain or blockchain network to determine the presence or absence of further transactions; and / or providing computing resources configured to influence the operation of the device or process based on the detection of further transactions in the blockchain or blockchain network and / or the validity of the further transactions.

[0038] The method may include the step of interpreting the detection of further transactions within the blockchain or blockchain network as the true output of a logical gate. Verification of further transactions within the blockchain network may depend on the execution of an unlock script.

[0039] The method may include the step of controlling a device or process based on the validity of a further transaction, wherein the validity is determined or established by monitoring the blockchain network to determine whether it has been verified by a computer-based control agent or by a network node, or by monitoring the state of the blockchain to determine whether the transaction has been written to the blockchain.

[0040] At least one instruction in the lock script may be configured to implement a truth table for an AND gate. At least one input may have a number, a constant value, the result of a hash function, a cryptographic key, a blockchain puzzle, and / or other blockchain-related addresses of Bitcoin. The first and / or further transactions may be generated and / or sent to the blockchain network by an automated process running on a computer-based resource. At least one instruction may have a condition or conditional operator and / or be written and / or executed using a stack-type programming language. The present invention may provide a system implemented by a computer configured to carry out any method according to this aspect of the invention.

[0041] Any feature described above in relation to one embodiment or aspect may be used in relation to another embodiment or aspect. For example, any feature described in relation to a method may be applicable to a system, and vice versa.

[0042] The above-described and other aspects of the present invention are evident from the embodiments described herein and are taught with reference to those embodiments. Embodiments of the present invention are described below with reference to the accompanying drawings, merely as examples. [Brief explanation of the drawing]

[0043] [Figure 1] A system comprising one embodiment of the present invention, relating to an explanatory use case, is shown. [Figure 2] The truth table for the control system shown in Figure 1 is presented. [Figure 3] The steps for processing an unlock transaction for the example in Figure 1 are shown below. [Figure 4] This document describes techniques that can be used to share secrets and generate public or private keys. [Figure 5] This document describes techniques that can be used to share secrets and generate public or private keys. [Figure 6]This document describes techniques that can be used to share secrets and generate public or private keys. [Figure 7] This document describes techniques that can be used to share secrets and generate public or private keys. [Figure 8] This document describes techniques that can be used to share secrets and generate public or private keys. [Figure 9] To generate a Boolean output X, two Boolean inputs A and B are evaluated within the lock script of the first transaction, illustrating the functionality of an embodiment for the explanation of the present invention. [Figure 10] An outline of one embodiment of the present invention, having first and second transactions, is shown. [Figure 11] The process is shown using one embodiment of the present invention. [Figure 12] An outline of one embodiment according to "Technical 1" of the present invention, which will be described later, is shown below. [Figure 13] An outline of one embodiment according to "Technical 2" of the present invention, which will be described later, is shown below. [Figure 14] An outline of one embodiment according to "Technical 3" of the present invention, which will be described later, is shown below. [Figure 15] This document provides a description of how lock and unlock scripts are evaluated using conventional techniques. [Modes for carrying out the invention]

[0044] The present invention provides a mechanism for using a lock script of a blockchain transaction to implement the logic of a particular truth table. As conventionally known, such truth tables are used to implement logic gates. Typically, a basic gate has two inputs A and B and a single output X. Figure 9 schematically shows a structure generated by an embodiment for the explanation of the present invention, in which the two inputs A and B are evaluated within a transaction to produce output X. The input values ​​A and B are provided via an unlock script of a blockchain transaction that seeks to use the output of a previous transaction associated with a lock script containing logic gate code. The unlock script may have a redeem script in one or more embodiments. Thus, at least two transactions are required to implement any embodiment of the present invention. A first transaction locks a Bitcoin or other cryptocurrency amount by a lock script with embedded gate logic. A second transaction uses the output of the first transaction by presenting the A and B values ​​(possibly together with a signature).

[0045] In a traditional gate, A, B, and X are binary and take values ​​equivalent to true (1) or false (0). However, according to one embodiment of the present invention, the traditional gate is replicated and extended to include more complex variations. In particular, the input to a blockchain gate does not have to be the “true” or “false” input itself, but can be any of several different values, formats, or types of values. For example, A and B can be integers, hash values, cryptographic keys, BTC addresses (etc.), and the true values ​​of A and B may be evaluated within a transaction to generate an output. The output is not necessarily binary in the sense that the transaction can be valid (“true”) or invalid (“false”).

[0046] However, the output may function as any of several more complex functions. For example, the output may represent a significant payment that is conditional on satisfying a set of conditions, or it may be an ordinary payment but not act as a secure, permanent record of the event. Further examples of using variations of blockchain gate will be discussed later.

[0047] There are many different types of logic gates, all of which are included in the scope of this invention. Generally, there are several basic two-input gates that are important for any circuit configuration. These are, in no particular order, as follows: 1. AND 2. OR 3.XOR Exclusive OR 4. NAND (negative AND) 5. NOR (Negative OR) 6.XNOR Exclusive NOR 7. IMPLY Logical Condition 8.NOT-IMPLY Substantial non-inclusion.

[0048] Another commonly used gate is the NOT gate, which has only one input and whose output is the opposite of the input. Gates are usually presented in the form of a "truth table" that provides all possible combinations of input values ​​and associated output values. For example, Table 1 shows the AND gate and the NOT gate. [Table 1] Truth table for AND gates and NOT gates [Table 1]

[0049] All eight basic two-input gates are shown in Table 2. [Table 2] 8 2-input gates [Table 2]

[0050] In reality, given two binary inputs, there are 16 different possible ways to produce a sequence of outputs. Many of these may prove useful depending on the required application. Each of these can be generated as a single gate. Therefore, if the truth table is implemented by a single blockchain script (e.g., "Technology 1" below), any of the 16 possibilities may be coded within the transaction lock script. Of course, some of these possibilities may have little or no practical use. For completeness, Table 3 shows the 16 possibilities for the first six gates. [Table 3] All possible 2-input, 1-output "gates" [Table 3]

[0051] As described above, the present invention presents a solution in which blockchain transactions are generated to implement at least a portion of the functionality of a logical gate. The functionality of this gate is emulated in a transaction lock script. Such a lock script may be referred to in this specification as a "blockchain gate" or "Bitcoin gate" for convenience. Furthermore, while Bitcoin may be referred to in some examples for convenience, alternative blockchain protocols and platforms may be used.

[0052] It should be noted that, according to known technology, blockchain transactions can be configured to utilize a multi-signature option for n out of m signatures. This effectively acts as a logical gate with respect to the number of signatures required for a transaction. When n=m, the multi-signature operation behaves as a logical AND gate. However, this is a limited implementation of logical gates, as it is related only to or influenced only by the number of signatures supplied in the input and does not allow evaluation of logical gates implemented by blockchains for any other kind of input. The present invention, on the other hand, allows the gate function to operate on a broader set of parameterized inputs.

[0053] According to various embodiments of the present invention, a lock script for a first blockchain transaction (TX1) is used to provide the functionality of a selected logic gate. In other words, a lock script provided within a first transaction includes some code that, when executed, uses presented input values ​​to provide an output that conforms to the truth table of a particular logic gate. Thus, the instructions within the lock script are selected and configured to implement the truth table of a desired gate. The lock script is associated with the output (TXO) of the first transaction.

[0054] The second transaction (TX2) is then generated. The second transaction has an unlock script or an associated input. The unlock script may be used to release the lock script of the first transaction in order to use the output (TXO). Verification causes the lock and unlock scripts of the first and second transactions to be executed. Thus, specific values ​​A and B are used. Refer to Figure 15 for an illustration of a conventionally known method in which lock and unlock scripts are evaluated during transaction verification.

[0055] If the execution of lock and unlock scripts results in a valid transaction, the validity of the transaction can be interpreted as the true output of the logic gate. Conversely, if the transaction verification fails, this can be interpreted as the false output of the logic gate. According to known blockchain technologies and several other technologies, a failed script is simply that, so this is an extension of the prior art. However, according to the present invention, a failed script (i.e., one that did not succeed in verification) allows for the detection of a "false" input and subsequent responses to "false" inputs. Therefore, since a particular procedure of operation depends on the output of the blockchain gate, regardless of what output occurs, the present invention allows for the induction and initiation of meaningful subsequent operations, regardless of whether the input is true or false.

[0056] The validity of a transaction can be determined by the following: • Computation agent, • One or more nodes on the blockchain network, • Detection of transactions within blocks on the blockchain. As described above, when a second transaction is presented to the (Bitcoin) network in order to attempt to use the output from the first transaction, the mining nodes perform their verification task. If the transaction is valid, it is written to the blockchain; otherwise, it is rejected. Thus, the computing agent can monitor the state of the blockchain to determine whether or not the transaction will be submitted to the ledger. If it is detected in the blockchain, this means that the transaction was valid. This can be interpreted by the computing agent as the true output from the logic gate.

[0057] The probability of validity or invalidity may act as a trigger for the execution of some action. This action may be performed by an agent. The agent may control or influence the operation of a device, system, or process.

[0058] As shown in Figures 12, 13, and 14, the first transaction (TX1) can be referred to as "preparing the logic gate" in that it defines the function of the gate to be emulated. The second transaction (TX2) can be referred to as "evaluating the logic gate" in that it provides the values ​​used when evaluating the gate output via the unlock script.

[0059] As will be discussed later with reference to Figures 10-14, various technologies exist to achieve the above-mentioned objectives.

[0060] <Technology 1> Figure 12 provides an overview of Technique 1. Attributes defining the key: Input signals A and B are provided to the unlock script for the transaction input of a single transaction (TX2); A and B are a "(Bitcoin) puzzle" and may be accompanied by one or more signatures; The unlock script for TX2 is used to attempt to use the output of the previous transaction TX1, which in turn causes the unlock and lock scripts for TX2 and TX1 to be executed, respectively; A and B are processed within the TX2 unlock script to evaluate their true / false nature; The related logic, i.e., the code for the selected gate (provided in the TX1 lock script), is then executed using these processed values; The script evaluation then executes other logic and instructions, such as multisig; note that the multisig operation is separate from the code for the selected logic gate, as is conventionally known, and is executed after the execution of that code.

[0061] Each puzzle represents a true or false condition, which is evaluated during the execution of the lock script as follows: First, the solution, i.e., the unlock script, will present the puzzle values ​​for the lock script; The lock script hashes the presented value and then compares it to the hash value stored internally ("stored internally" means the hash is written as part of the lock script); equality between the hash of the presented value and the stored hash means "true," and inequality means "false"; therefore, for each puzzle, the hash comparison provides an intermediate result; The intermediate results of the two evaluated conditions are then applied to the associated gate logic code provided in the lock script to provide a final result representing the output X of the logic gate; if the final result is true, the associated signature is verified using a multisig operation.

[0062] The TX1 lock script may be the P2SH lock script known in the Bitcoin protocol, or an equivalent function from an alternative protocol. According to known techniques, the P2SH lock script contains a hash of the Redeem script, and the TX1 output can only be used by presenting the correct script that matches the hash stored in the lock script when hashed. Thus, with respect to pay-to-script hash transactions, the actual logic is presented in the unlock script, but the lock script "knows" the logic that will be provided later. Those skilled in the art will understand that the operation of the lock script in such a transaction must be known, but that the actual instruction set can be provided as part of the unlock script using cryptographically secure techniques. The advantage of this technique is that the solution is actually presented by the Redeem script as an initial hash, and the initial hash is hashed again during the execution of the lock script to perform the comparison, so the contents of the Redeem script or the stored hash cannot be identified. Thus, privacy and security can be improved or maintained.

[0063] In another variation, A and B do not need to be hashed, and instead of an equivalence test of hashes, a different test is applied to derive true and false. For example, A may be the current Dow Jones index, and the script may test for A > (some predetermined threshold). This method does not use the P2SH transaction type to compare hashes to arrive at an intermediate result for A and B, but instead uses a "condition evaluation code" in the lock script to evaluate some other kind of predetermined condition. In this method, many different kinds of conditions may be tested for true / false. The intermediate result resulting from the condition evaluation code is then passed to the gate logic part of the lock script, and finally to signature verification. The signature verification process is performed according to conventionally known techniques. It should be noted that in this particular example, the values ​​of A and B are not hashed, so the method is not suitable when the condition being tested needs to be kept secret.

[0064] <Technology 2> Figure 13 provides an overview of Technique 2. Attributes defining the key: Inputs A and B are included in the unlock script and presented to the lock script for a single transaction input (e.g., by the control agent); A and B may be "true" or "false" and may be accompanied by a signature; The conditions represented by A and B are pre-evaluated outside the transaction by a dedicated computer-based agent to derive true / false values, and then securely transmitted to the control agent; The control agent generates further transactions, including an unlock script that presents values ​​A and B (and signatures) to the lock script.

[0065] Therefore, Technique 2 is the same as Technique 1, except that the conditions are evaluated by the computation agent before being presented to the unlock script. Similar to Technique 1, the code emulating the logical gate function is provided in the lock script of the first transaction, and the actual values ​​of the inputs are provided during verification by the unlock scripts of subsequent transactions.

[0066] <Technology 3> Figure 14 provides an overview of Technique 3. Attributes defining the key: A and B are presented to the lock script for two separate transaction inputs (for the same transaction); A and B are a "(Bitcoin) puzzle" and may be accompanied by a signature; Using relevant combinations of SIGHASH flags (e.g., ANYONECANPAY), two separate agents present A and B separately to a transaction template (which is ultimately confirmed by the control agent); A and B are evaluated as true / false within their respective lock scripts, and each lock script then executes its associated gate logic; Each script then performs other logic, such as signature checking, which follows established practices.

[0067] For the entire transaction to be valid, each input must be valid. This implements an AND truth table. The same technique can be used for any number of inputs. That is, instead of evaluating two conditions A and B, conditions A, B, C, ... can be set as requirements for generating a transaction.

[0068] <Template Transaction> In one or more embodiments, a transaction template may be provided. The transaction template is copied and then inputted with inputs A and B to generate a transaction that can be broadcast to the blockchain network. If the broadcasted transaction is accepted by the network as valid, this can be interpreted as a “true” output, as described above, and also serves to provide a permanent, immutable record on the blockchain. A and B typically represent conditions that can be evaluated as true or false. Any kind of condition can be evaluated, and any kind of data can be used to evaluate the condition. For example, a condition may include a real-world event, the reception or absence of a signal, the success of a computation, a match between two or more data items or electronic entities, etc. The list is infinite, but the following presents a very small number of indicative samples of different kinds of conditions that can be tested.

[0069] Exemplary conditions that can be tested for true / false status for use in BlockchainGate: 1. The current date is June 30, 2025; 2. The 1,000,000th Bitcoin block has been reached; 3. The entity sent an encoded signal (for example, Bob said "Go!" to use the transaction); 4. The temperature at location X is lower than Y°C; 5. The Dow Jones Industrial Average is currently above 20,000; 6. A person identifiable as Juanita Shalala Morgensen-Smythe was married; 7.(etc).

[0070] Blockchain gates may be created by any entity. However, a preferred embodiment involves configuring one or more automated software agents to perform the functions associated with the creation, maintenance, and transmission of blockchain gates. The term “automated” may be interpreted to mean that the tasks are performed entirely by program execution without human intervention. In a preferred embodiment, these agents can perform a variety of functions, some of which are listed below.

[0071] Exemplary functions that can be performed by an agent in relation to BlockchainGate: 1. Monitor real-world events, and when a "trigger" is detected, perform a specific action according to the configured rules; 2. Triggers monitor the blockchain, and when a "trigger" is detected, they perform a specific action according to the configured rules; 3. Make copies of the transaction templates, insert inputs and / or outputs into them based on the configured rules, and broadcast the transactions to the blockchain network; 4. When triggered, it performs other types of actions, such as sending an alert to an interested party or communicating with other agents to send or receive data.

[0072] There are many possible and end uses for implementing logical gates within blockchain transactions. Details of how gates or combinations of gates are generated and deployed to implement these uses are beyond the scope of this specification. However, the present invention can be used, for example, in the control of electronic devices. This may include IoT (Internet of Things) devices such as alarm systems, vehicle deactivation systems, home appliance switches, wireless sensor networks, SCADA (Securely), factory control, inverters, transaction lock systems, time-based safety, water supply systems, etc. It can also be used for the deployment and calculation of automated payment systems. For example: a. Send Output 1 if payment is received on time, and Output 2 otherwise, and calculate the amount and interest separately; b. AnyoneCanPay blockchain transactions that increase or decrease over time.

[0073] <Several possible variations of "gates" used in blockchain transactions> 1. A and B may be in binary (as in classical gates); X may be in binary, meaning that the transaction is "true (valid)" or "false (invalid)"; 2. A and B may be cryptographic signatures; 3. A and B may be any numerical values ​​that represent meaningful values; for example, dates; 3. A and B may be hashes of meaningful values; 5. A and B may be a "puzzle" in the sense of Bitcoin (a solution for a specific hash); 6. A and B may be any combination of two or more of the above (e.g., signature + puzzle); 7. A and B may be of different types (for example, A = signature + meaningful value; B = puzzle). 8. Multiple inputs A, B, C, ... may exist; 9. X = True (Valid) may mean that a third party has been paid some bitcoins; for example, if certain conditions are met, such as those represented by A and B and the logic gate, then bitcoins will be paid to the recipient; 10. X = True (Valid) means that the output Bitcoin is simply returned to the payer, and the purpose of the transaction is unrelated to payment (see example below); 11. X = True (Valid) may mean that an event is triggered (for example, a monitoring agent may be triggered to perform a configured action such as controlling an IoT device); 12. X = True (Valid) means that the event w is registered; that is, the purpose of the transaction is to act as a secure, immutable, permanent record of the event; 13. There may be multiple inputs X, Y, ...; this may mean that several recipients have been paid in Bitcoin, or that several triggers have been met, or a combination thereof; 14. A single transaction may contain, or be a single transaction that implements a gate; this is done within a lock script.

[0074] <Exemplary implementation of one embodiment of the present invention> In this explanatory example, we use Technique 1 described above to implement an XOR gate used for device control applications.

[0075] A Blockchain IoT Device (BIT) is a computing agent configured to execute predetermined instructions that are securely stored outside the BID and accessed via cryptographic keys. "Off-BID" means that the instructions are not provided within the BID itself, but are stored elsewhere and accessed as needed. These instructions are selected and configured to perform a selected task or a set of tasks. Once executed, the instructions can control and influence the operation of the IoT device. The BID resides within the IoT itself, meaning the BID is installed in memory located within or on the IoT device. However, in other embodiments, the BID may reside outside the device and have an internet connection to the device.

[0076] IoT devices possess their own encryption keys (and IP addresses) and are therefore capable of securely communicating and interacting with other devices or DHTs, etc. Their "operating system" is a simple, general-purpose system with several embedded functions (at least, not limited to) the following:

[0077] ·Cryptographic calculation, • Reading instructions from an external source (such as DHT), • Performing simple actions such as toggle switches (i.e., those found on physical IoT devices).

[0078] Therefore, IoT devices or their associated BIDs do not contain their own built-in instructions and "don't know" what they do or how they do it. A BID only contains a mechanism for securely reading instructions from elsewhere. A BID can only execute a simple set of operations (the following is for illustrative purposes only and not an limitation): • Access to their own master private key and public key pair. They also possess their own (derivable) BTC address. The ability to send data to and receive data from an IP address. • Secret sharing protocol calculation (described later). In a preferred embodiment, these may be implemented in machine code. • Searching for and interpreting blockchain events. • Operation and control of attached physical devices (essentially via a standard API, which is simply a set of switches).

[0079] Incoming and outgoing BID communications are encrypted using a security mechanism described below. This allows keys to be generated using a shared secret. This enables the following: (i) Major security measures against "hacking". (ii) A simple, general-purpose software upgrade protocol. (iii) Apparatus agnosticism.

[0080] Embodiments of the present invention therefore provide a general-purpose operating system usable in any IoT device. The device itself is not programmed; all programs are stored separately and loaded into the device during setup (or, in some embodiments, during execution).

[0081] Referring to Figure 1, system 100 includes first and second client devices numbered 102a and 102b, respectively, and a BID control system 104 that receives input from the first client device 102a and the second client device 102b and transmits information to the first client device 102a and the second client device 102b. In this exemplary use case, the first and second client devices 102a and 102b are radio frequency identification devices (RFIDs) detectable by the BID control system 104. The control system 104 operates to use a blockchain and to transmit output to the blockchain.

[0082] The operation of the control system 104 will be explained using the example of two dogs named Archimedes (A) and Bertrand (B), both named Carol. The two dogs are left alone in the backyard all day, and they get along well with each other as long as they do not eat at the same time. However, for some reason, eating at the same time makes them aggressive and causes them to fight. Both A and B have identifiable RFID collars, namely the first RFID collar 102a and the second RFID collar 102b, which are detectable by the IoT (Internet of Things) device 101. This IoT device is an auto-feeder that distributes a specified amount of food consumed by one dog. In other words, the BID control system 104 controls the operation of the IoT feeding device.

[0083] In this example, BID104 is a software resource or component provided on the IoT auto feeder that interfaces with the feeder to control the feeder's functions.

[0084] A BID begins its life cycle by downloading and installing its instructions from the DHT. It does not need to do this again until these instructions are changed. This may occur, for example, when the BID needs to be upgraded, or when the operation of the BID should be completely changed, for example, when the BID's instruction set can be changed to detect three or more RFID signals.

[0085] The control agent uses the value sent by the BID to generate a blockchain transaction and, as described later, shares the BID and a new secret after each iteration.

[0086] The functionality of the BID control system 104 is implemented using blockchain transactions that are locked using the following lock script. OP_HASH160<unlocking script hash> OP_EQUAL Transactions are generated to provide a set of instructions for controlling IoT auto-feeder devices (via metadata linked to a distributed hash table (DHT)) and may include instructions to established computing resources as described below. Rather than storing the instructions within the transaction itself, the metadata may include pointers or references to locations where the instructions can be accessed. Therefore, the instructions may be held "off-block".

[0087] Blockchain not only provides a mechanism to control activities, but also records information about events that have taken place. For example, blockchain can count the number of feedings, the time of feeding, which dogs ate, whether the maximum food allocation was distributed, and so on. Blockchain also provides cryptographic security.

[0088] A key function of the transaction is to ensure that food is distributed only when one dog is present in the feeder at a time. Therefore, some condition needs to be built into the transaction script. This is achieved by the truth table of the XOR function shown in Figure 2. If neither A nor B is present in the feeder, no food will be distributed. If A is present in the feeder but B is not, distribute the food. If B is present in the feeder but A is not, distribute the feed. If both A and B are present in the feeder, do not distribute the feed.

[0089] When A or B is present at the feeder, an RFID signal is transmitted from the respective client device, i.e., the first RFID collar 102a or the second RFID collar 102b, to the auto-feeder control system 104 to unlock the dog's secure current puzzle solution (which is securely replaced by a new puzzle solution after each iteration). Alternatively, if A or B is not present at the feeder, a random number is transmitted from the respective RFID collar to the feeder. In other words, a dog being "present at the feeder" means that its RFID collar is within the feeder's detectable range. In this case, the associated puzzle is unlocked for transmission. If not present, the default value is a random number.

[0090] The puzzle solution is data that, when hashed, results in a value that matches the value stored in the (Bitcoin) script. In other words, the process is as follows: The secret value ("solution") is hashed and stored in the lock script for later comparison. The secret is presented to the lock script to unlock it. The lock script first hashs the presented value and then compares it to its own stored hash. If the comparison determines that they are equal, the result of the comparison is "true". In practice, the stored value is the double hash of the secret, and the presented value is the single hash of the secret. This allows a secret of any length to be shortened to a standard manageable size (i.e., always 160 bits long) as input to the script.

[0091] The autofeeder BID executes its own instructions read from the DHT using a lookup key associated with the BID's key / pair. The control agent manages the data flow to and from the BID (i.e., data related to the RFID signal but not to the BID's instruction set). Thus, the autofeeder BID monitors its own state. The autofeeder BID stores two secret values ​​(S1 and S2) received from a separate control agent 103. The control agent 103 may be a appropriately programmed computing resource configured to oversee the feeding process. Secret values ​​S1 and S2 are used conditionally when a dog's RFID collar is detected within range. Based on its own instructions read from the appropriate DHT, when it detects an RFID within range (along with other conditions related to the time of day, previous feedings, other restrictions, etc.), it sends a signal to a general-purpose agent acting as its control agent (described later). The signal includes: If Archimedes' RFID is detected, S1 (=solution to puzzle A); otherwise, a random number. If Bertrand's RFID is detected, S2 (=solution to puzzle B); otherwise, a random number.

[0092] The autofeeder BID then does the following: The autofeeder checks the validity of a transaction, and in some embodiments, it may check for valid transactions on the network (which may or may not have been issued on a block, but in either case, must be valid). This transaction is generated and broadcast by the control agent. This transaction is valid if it passes an embedded XOR test. If it fails, this transaction is invalid and will not propagate beyond the first "hop" on the blockchain network. Therefore, this transaction will not be detected by the BID. Alternatively, if the BID is the first hop and therefore the transaction is detected, a part of the BID function (with respect to any other node) verifies the transaction. Thus, it is possible to detect whether the transaction is valid before taking any resulting action. A valid transaction also ensures that the necessary information, i.e., information regarding the feeding event, is stored and recorded on the blockchain. If the above answer is true, BID will execute its conditional command. In this example, BID will distribute some food. • Receives a transmission from control agent 103, enables the sharing of two secrets (S1 and S2 as described below), and internally updates these secret values ​​in preparation for the next iteration.

[0093] The lock script for Bitcoin transactions is given by: OP_HASH160 <puzzle-a>OP_EQUAL OP_SWAP OP_HASH160 <puzzle-b>OP_EQUAL OP_NUMEQUAL OP_NOT OP_VERIFY OP_1 metadata1 PubK-Carol OP_2 OP_CHECKMULTSIG Herein lies the following: Puzzle A is an equivalent result of OP_HASH160 (solution to Puzzle A). Puzzle B is the equivalent result of OP_HASH160 (solution to Puzzle B). metadata1 contains a reference to an encoded instruction stored in the DHT. PubK-Carol is Carol's public key.

[0094] It should be noted that the agent's programming may be hardcoded, or it may read its own instructions from the DHT. The encoded instructions may be stored and accessed according to the procedure described later, which references transactions from blockchain transactions using metadata. Carol's public key may be securely held or regenerated using the process described later.

[0095] The following script is required to unlock the blockchain transaction described above: Sig-Carol Puzzle-B-solution Puzzle-A-Solution<unlocking script> Refer to Figure 3 for an explanation of the following steps.

[0096] In step S300, the control system 104 hashes the presented solution to puzzle A and compares it with a stored version of puzzle A read from the memory (this version is the hash of the solution). The stored version of puzzle A may be stored in a memory device local to the control system 104 or in any other suitable storage medium. If they are equal, the top of the stack is 1. If they are different, the top of the stack is 0.

[0097] In step S302, the top of the stack is then swapped with the second item of the stack, which is the solution to puzzle B. This is hashed and compared with the stored version of puzzle B read from the storage device, and here again, as with the result from S300, a 1 or 0 is pushed to the top of the stack. The stored version of puzzle B may be stored in a storage device located locally in the control system 104, or in any other suitable storage medium.

[0098] Here, the top two stack items are either 0 or 1. In step S304, OP_NUMEQUAL returns 1 if the numbers are equal, and 0 otherwise. This is the exact opposite of the XOR truth table.

[0099] In step S306, OP_NOT flips the top item on the stack to generate the required XOR result.

[0100] In step S308, OP_VERIFY checks if the top item on the stack is 1, and if not, i.e., the XOR operation fails, it returns a puzzle solution where one more input from the first and second client devices matches, so the transaction is immediately marked as invalid. As a result, there are more dogs than 1 in the IoT distributor, and therefore no food is distributed from the IoT distributor. In other words, the output of control system 104 is controlled by the execution of the underlying Bitcoin transaction.

[0101] If OP_VERIFY returns 1, the control system 104 returns to the script's multisig, and in step S310, the existence of Carol's signature is checked.

[0102] The stack operations performed by the control system 104 when analyzing the unlock script are shown below. First, the control system 104 hashes the unlock script using OP_EQUAL in order to compare the hash with the hash of the unlock script. After this, the unlock script is executed. [Table 4-1] [Table 4-2]

[0103] <Generate keys using shared secrets> Keys may be stored or regenerated securely. In particular, private keys that may be used to derive a public key may be stored in a disassembled form.

[0104] A user, such as Alice or Bob, may hold a portion of their private key; a service provider may hold a second portion; and a third portion may be held at a remote secure site. The private key may be reconstructed using any two of the three portions. Or, more generally, the private key may be reconstructed using any m of the n portions.

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

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

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

[0108] Figure 4 shows a system 1 including a first node 3 that communicates with a second node 7 via a communication network 5. The first node 3 has an associated first processing unit 23, and the second node 5 has an associated second processing unit 27. The first and second nodes 3 and 7 may include electronic devices such as computers, telephones, tablet computers, mobile communication 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. The server may be a server for a digital wallet provider.

[0109] Node 3 is the first node master secret key (V 1C ) and the first node master public key (P 1C The second node (7) is associated with the first asymmetric cryptographic pair having the second node master secret key (V). 1S ) and the second node master public key (P 1S It is associated with a second asymmetric cryptographic pair having ). In other words, the first and second nodes each possess their own public-key-private key pairs.

[0110] 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. The public key of each node may be publicly shared across the communication network 5.

[0111] In order to determine a common secret (SC) at both the first node 3 and the second node 7, nodes 3 and 7 perform steps 300 and 400 of method 300 and 400, respectively, without communicating the secret key over the communication network 5.

[0112] Method 300 performed by the first node 3 includes at least the first node master secret key (V 1C Based on the ) and the Generator Value (GV), the second secret key of the first node (V 2C includes a step 330 of determining 1S ). The generator value may be based on a message (M) shared between the first node and the second node. This may include the step of sharing the message via the communication network 5, as detailed below. Method 300 is based on at least the second node master public key (P 2S ) and the generator value (Generator Value: GV), and further includes a step 370 of determining the second node second public key (P 2C ). Method 300 includes a step 380 of determining a common secret (CS) based on the first node second private key (V 2S ) and the second node second public key (P

[0113] Importantly, the same common secret (CS) can also be determined at the second node 7 by method 400. Method 400 includes a step 430 of determining the first node second public key (P 1C ) based on the first node master public key (P 2C ) and the generator value (Generator Value: GV). Method 400 further includes a step 470 of determining the second node second private key (V 1S ) based on the second node master private key (V 2S ) and the generator value (Generator Value: GV). Method 400 includes a step 480 of determining a common secret (CS) based on the second node second private key (V 2S ) and the first node second public key (P 2C ).

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

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

[0116] Methods 300 and 400 may include additional steps. See Figure 8. Method 300 involves the first node 3 receiving a message (M) and the first node's second secret key (V). 2C Method 300 may include the step of generating a signed message (SM1) based on the first signature message (SM1). Method 300 further includes the step of sending the first signed message (SM1) to the second node 7 via a communication network. Meanwhile, the second node 7 may perform the step 440 of receiving the first signed message (SM1). Method 400 may send the first signed message (SM2) to the first node's second public key (P 2C The process further includes step 450, which verifies the first signature message (SM1) using the first node master secret key (V), and step 460, which authenticates the first node 3 based on the result of the step 450, which verifies the first signature message (SM1). Conveniently, this allows the second node 7 to verify that the intended first node (where the first signature message was generated) is the first node 3. This means that only the first node 3 can verify the first node master secret key (V). 1C Therefore, only the first node 3 has access to the first node's second secret key (V) for generating the first signed message (SM1). 2C This is based on the assumption that it is possible to determine that ). It should be understood that, similarly, the second signed message (SM2) can be generated at the second node 7 and sent to the first node 3. Thus, as in the peer-to-peer scenario, the first node 3 can authenticate the second node 7.

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

[0118] Advantageously, the record that enables the regeneration of the Common Secret (CS) can be retained without the record itself needing to be stored secretly or transmitted securely.

[0119] <Registration Methods 100, 200> Examples of registration methods 100 and 200 are described with reference to Figure 6. In Figure 6, method 100 is performed by the first node 3, and method 200 is performed by the second node 7. This includes the step of establishing first and second asymmetric cryptographic pairs for the first node 3 and the second node 7, respectively.

[0120] An asymmetric cryptographic pair includes an associated secret key and public key, similar to those used in public-key cryptography. In this example, the asymmetric cryptographic pair is generated using an elliptic curve cryptography system (ECC) and the properties of elliptic curve operations.

[0121] Methods 100 and 200 include a first and second node, which agree on a common ECC system and use 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). For 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.

[0122] Considering the first node 3, method 100 includes step 110 of resolving the common ECC system and base point (G). This may include the step of receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, the user interface 15 is associated with the first node 3, so that the user can 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 via the communication network 5 indicating that it will use the common ECC system with the base point (G). The second node 7 may resolve this by sending a notification indicating an acknowledgment of the use of the common ECC system and base point (G) 210.

[0123] Method 100 involves the first node 3 obtaining the first node master secret key (V 1C ) and the first node master public key (P 1C The step 120 further includes generating a first asymmetric cryptographic pair having the first master secret key (V) which is at least partially based on a random integer within a specified tolerance range in a common ECC system. 1C This includes the step of generating the first node master secret key (V) according to the following formula. 1C Based on the multiplication of the elliptic curve points of ) and the base point (G), the first node master public key (P 1C This further includes the step of determining ). P 1C =V 1C ×G (Formula 1)

[0124] Therefore, the first asymmetric cryptographic pair includes: V 1C : The first node master secret key, which is kept secret by the first node. P 1C : The publicly disclosed first node master public key.

[0125] Node 3 is the first node master secret key (V 1C ) and the first node master public key (P 1C The first node master secret key (V) may be stored in the first data store 13 associated with the first node 3. For security purposes, the first node master secret key (V) may be stored in the first data store 13 associated with the first node 3. 1C The keys may be stored in a secure portion of the first data store 13 to ensure that the keys remain secret.

[0126] Method 100 is as shown in Figure 6, using the first node master public key (P 1C The step 130 further includes sending the first node master public key (P) to the second node 7 via the communication network 5. The second node 7 then receives the first node master public key (P) 1C When ) is received, 220, the first node master public key (P 1C ) may be stored in the second data store 17 associated with the second node 7 230.

[0127] Similar to the first node 3, the method 200 of the second node 7 is the second node master secret key (V 1S ) and the second node master public key (P 1S The step 240 includes generating a second asymmetric cryptographic pair having the second node master secret key (V 1S ) is also a random integer within an acceptable range. In addition, the second node master public key (P 1S ) is determined by the following formula. P 1S =V 1S ×G (Formula 2)

[0128] Therefore, the second asymmetric cryptographic pair includes: V 1S : The second node master secret key, which is kept secret by the second node. P 1S : The publicly disclosed second node master public key.

[0129] The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. Method 200 is the second node master public key (P 1S The step further includes sending the second node master public key (P) to the first node 3. The first node 3 also sends the second node master public key (P) to the first node 3. 1S ) received 140, and can be stored 150.

[0130] It should be understood that in some alternatives, each public master key may be received and stored in a third datastore 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 The Common Secret (CS) may be requested and received by the second node 7 only when the CS is requested (and vice versa).

[0131] The registration step only needs to occur once as part of the initial setup.

[0132] <Session start and determination of the common secret by Node 1-3> An example of determining a Common Secret (CS) is shown here with reference to Figure 7. The Common Secret (CS) may be used for a specific session, time, transaction, or other purpose between Node 1 3 and Node 2 7, and it is desirable or secure not to use the same Common Secret (CS). Therefore, the Common Secret (CS) may be changed between different sessions, times, transactions, etc.

[0133] The following is provided to explain the secure transmission techniques mentioned above.

[0134] [Generate message (M) 310] In this example, the method 300 performed by the first node 3 includes a 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 follows: Message (M) = Unix time + Nonce (Equation 3) In some examples, the message (M) is arbitrary. However, it should be understood that the message (M) may have a selective value (such as Unix time, etc.) which may be useful in some applications.

[0135] Method 300 includes step 315 of sending message (M) to second node 7 via communication network 3. Since message (M) does not contain information about the secret key, message (M) may be sent over an insecure network.

[0136] [Determining the Generator Value (GV) 320] Method 300 further includes step 320 of determining a Generator Value (GV) based on the message (M). In this example, this includes the step of determining the cryptographic hash of the message. An example of a cryptographic hash algorithm includes SHA-256 to generate a 256-bit generator value (GV). That is, GV = SHA-256(M) (Equation 4)

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

[0138] [330: Determine the second secret key for the first node] Method 300 then involves the second node master secret key (V 1C Based on the generator value (GV), the second secret key (V) of the first node is generated. 2C This includes step 330, which determines the first node master secret key (V) according to the following formula. 1C ) and the generator value (GV) are obtained based on scalar addition. V 2C =V 1C +GV (Equation 5)

[0139] Therefore, the first node's second secret key (V 2C ) is not a random value, but is instead 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 The following relationships exist: P 2C =V 2C ×G (Formula 6)

[0140] From equation 5 to equation 6, V 2C Substituting this, we obtain the following equation. P 2C =(V 1C +GV)×G (Formula 7) Here, the "+" operator represents elliptic curve point addition. Elliptic curve cryptographic algebra is distributive, and equation 7 can be expressed as follows: P 2C =V 1C ×G+GV×G (Formula 8)

[0141] 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)

[0142] Therefore, the corresponding first node second public key (P 2C ) is the first node master public key (P 1C ) and the message (M) may be derivable given knowledge. As will be further detailed below with respect to method 400, the second node 7 obtains the second public key (P) of the first node. 2C Having such knowledge is beneficial in order to independently decide on ).

[0143] [350 generates the first signed message (SM1) based on the message and the first node's second secret key] Method 300 involves the message (M) and the determined first node second secret key (V). 2C The step 350 further includes generating a first signed message (SM1) based on ). The step of 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 secret key (V) to the message in an Elliptic Curve Digital Signature Algorithm (ECDSA) in order to obtain the first signed message (SM1). 2C This includes the step of applying ). An example of ECDSA is based on an ECC system having secp256k1, secp256r1, secp384r1, and se3cp521r1.

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

[0145] [Determine the second public key for the second node 370'] Node 1 3 then sends the second public key (P) to Node 2. 2S ) can be determined 370. As mentioned above, the second node second public key (P 2S ) is at least the second node master public key (P 1S ) and the generator value (GV) may be used as the basis. In this example, the public key is determined as the secret key by elliptic curve point multiplication with the base point (G), so 370', the second public key of the second node (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)

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

[0147] [380: Determine the common secret at Node 1-3] Node 3 then receives the Node 2 secret key (V 2C ) and the determined second node second public key (P 2S Based on the above, the Common Secret (CS) may be determined.380 The Common Secret (CS) may be determined by the first node 3 using the following formula. S=V 2C ×P 2S (Formula 11)

[0148] <Method 400 Executed at the Second Node 7> The corresponding method 400 executed at the second node 7 is described herein. It should be understood that some of these steps are similar to the above steps executed by the first node 3.

[0149] Method 400 includes a step 410 of receiving a message (M) from the first node 3 via the communication network 5. This may include the message (M) transmitted by the first node 3 in step 315. The second node 7 then determines a generator value (GV) based on the message (M) at 420. The step 420 of determining the generator value (GV) by the second node 7 is similar to the step 320 executed by the above-described first node. In this example, the second node 7 executes this determining step 420 independently of the first node 3.

[0150] The next step is a step 430 of determining a first node second public key (P 1C ) based on the first node master public key (P 2C ) and the generator value (GV). In this example, since the public key is determined as a secret key by elliptic curve point multiplication with the base point (G) at 430’, 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) The mathematical proofs of Equations 12.1 and 12.2 are the same as those described above for Equations 10.1 and 10.2.

[0151] [The Second Node 7 Authenticates the First Node 3] Method 400 may include steps executed by the second node 7 to authenticate that the unconfirmed first node 3 is the first node 3. As described above, this includes step 440 of receiving a first signed message (SM1) from the first node 3. The second node 7 may then verify the signature of the first signed message (SM1) with the first node second public key (P 2C ), 450.

[0152] Verification of the digital signature may be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA) described above. Importantly, the first signed message (SM1) signed with the first node second private key (V 2C ) should only be correctly verified by the corresponding first node second public key (P 2C ), since V 2C and P 2C form a cryptographic pair. These keys are determined in the first node master private key (V 1C ) and the first node master public key (P 1C ) generated during the registration of the first node 3, so verification of the first signed message (SM1) can be used as a basis to authenticate that the unconfirmed first node sending the first signed message (SM1) is the same first node 3 as during registration. Thus, the second node 7 may further perform step 460 of authenticating the first node 3 based on the result of step 450 of verifying the first signed message.

[0153] [The second node 7 determines a common secret] Method 400 may further include step 470 in which the second node 7 determines a second node second private key (V 1S ) based on the second node master private key (V 2S ) and the generator value (GV). Similar to step 330 executed by the first node 3, the second node second private key (V 2S ) follows the following equation, the second node master private key (V 1S ) and the generator value (GV) are obtained based on scalar addition. V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Equation 13.2)

[0154] The second node 7 then, independently of the first node 3, obtains the second secret key (V) of the second node based on the following formula. 2S ) and the second public key of the first node (P 2C Based on this, the Common Secret (CS) may be determined. S=V 2S ×P 2C (Formula 14)

[0155] [Proof of the Common Secret (CS) determined by Node 13 and Node 27] 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 equations 11 and 14 provide the same common secret (CS) is given here.

[0156] Considering 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)

[0157] Considering 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)

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

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

[0160] The common secret (CS) is the elliptic curve point (x S ,y S ) may be in the form of ). This may be converted to a standard key format using standard publicly known operations agreed upon by nodes 3 and 7. For example, x S The value is AES 256 It may be a 256-bit integer that can be used as an encryption key. This can further be converted to a 160-bit integer using RIPEMD160 for any application requiring a 160-bit key.

[0161] The Common Secret (CS) may be determined as needed. Importantly, since the Common Secret (CS) can be re-determined based on the Message (M), the first node 3 does not need to store the Common Secret (CS). In some examples, the Message (M) used may be stored in datastores 13, 17, 19 (or other datastores) that do not have the same level of security as required for the master private key. In some examples, the Message (M) may be publicly available.

[0162] However, depending on the application, the Common Secret (CS) is the first node master secret key (V 1C The common secret (CS) can be stored in the first datastore (X) associated with the first node, provided that it is kept as secure as the first datastore (X).

[0163] Advantageously, this technology can be used to determine multiple common secrets that can correspond to multiple secure private keys, based on a single master key cryptographic pair.

[0164] <Hierarchical structure of generator values ​​(keys)> For example, a series of consecutive generator values ​​(GVs) may be determined, where each consecutive GV may be determined based on the previous generator value (GV). For example, instead of repeating steps 310-370, 410-470 to generate consecutive dedicated keys, by prior agreement between nodes, previously used generator values ​​(GVs) may be repeatedly rehashed by both parties to establish a hierarchical structure of generator values. In fact, a generator value based on the hash of a message (M) can become the next-generation message (M-cast) for the next-generation generator value (GV). Doing so enables the sequential generation of shared secrets to be computed, eliminating the need for transmissions established by further protocols, particularly the transmission of multiple messages each time a common secret is generated. The next-generation common secret (CS') can be computed as follows:

[0165] First, both the first node 3 and the second node 7 independently determine the next-generation generator value (GV'). This is similar to steps 320 and 420, but is applied by the following formula. M' = SHA - 256(M) (Equation 18) GV' = SHA-256(M') (Equation 19.1) GV' = SHA-256(SHA-256(M)) (Equation 19.2)

[0166] The first node 3 then sends the next generation second public key (P) to the second node 2. 2S ') and the second secret key of the first node (V 2C ') may be determined in the same manner as in steps 370 and 330 above, but applied by the following formula. P 2S '=P 1S +GV'×G (Equation 20.1) V 2C '=V 1C +GV' (Equation 20.2)

[0167] The second node, 7, then receives the next generation's first node's second public key (P 2C ') and the second secret key of the second node (V 2S ') may be determined in the same way as in steps 430 and 470 above, but applied by the following formula. P 2C '=P 1C +GV'×G (Equation 21.1) V 2S '=V 1S +GV' (Equation 21.2)

[0168] The first node 3 and the second node 7 may then each determine the next-generation common secret (CS'). In particular, the first node 3 determines the next-generation common secret (CS') using the following formula. CS'=V 2C ×P 2S ' (Formula 22)

[0169] Node 7 (the second node) determines the next-generation common secret (CS') using the following formula. CS'=V 2S ×P 2C ' (Formula 23)

[0170] Further generations (CS'', CS''', etc.) can be computed in the same way to generate the chain hierarchy. This technique requires that both the first node 3 and the second node 7 do not lose track of the original message (M) or the initially computed generator value (GV) and which node it relates to. Since this is publicly known information, there are no security issues with holding this information. Therefore, this information can be stored in a "hash table" (linking hash values ​​to public keys) and freely distributed across the network 5 (e.g., using Torrent). Furthermore, if any individual common secret (CS) in the hierarchy has not yet been resolved, this is linked to the private key V. 1C , V 1S If it remains secure, it does not affect the security of any other common secrets in the hierarchical structure.

[0171] <Key tree structure> Similar to the chain (linear) hierarchical structure described above, a hierarchical structure in the form of a tree structure can be generated. According to the tree structure, various keys for different purposes, such as authentication keys, cryptographic keys, signing keys, payment keys, etc., may be determined. These keys are then all linked to a single, securely maintained master key. This is illustrated in Figure 12, which shows a tree structure 901 with various different keys. Each of these can be used to generate secrets shared with other parties. Branching trees can be achieved in several ways, three of which are described below.

[0172] (i) Master key spawning In a chain hierarchy, each new "link" (public / private key pair) is generated by adding the multiplied and re-hashed message to the original master key. For example (for clarity, only the private key of node 3 is shown), V 2C =V 1C +SHA-256(M) (Formula 24) V 2C '=V 1C +SHA-256(SHA-256(M)) (Formula 25) V 2C ’’ = V 1C + SHA-256(SHA-256(SHA-256(M))) (Equation 26) and so on.

[0173] To generate a branch, any key can be used as a sub-master key. For example, V 2C ’ can be used as a sub-master key (V 3C ) by adding a hash, as is done for a regular master key. V 3C = V 2C ’ + SHA-256(M) (Equation 27) The sub-master key (V 3C ) may itself have a next-generation key (V 3C ’). For example, as shown in the following equation. V 3C ’ = V 2C ’ + SHA-256(SHA-256(M)) (Equation 28)

[0174] This provides the tree structure 903 using the master key spawning method shown in FIG. 13.

[0175] (ii) Logical association In this method, all nodes (public / secret key pairs) in the tree are generated as a chain (or in any other way), and the logical relationship between the nodes in the tree is maintained by a table in which each node in the tree is simply associated with its parent node in the tree using a pointer. Therefore, the pointer can be used to determine the associated public / secret key pair to determine the common secret key (CS) of the session.

[0176] (iii) Message diversity A new public / private key pair can be generated by introducing a new message at any point in the chain or tree. The message itself can be arbitrary or convey some meaning or function (for example, it may relate to a "real" bank account number, etc.). It may be desirable that such a new message for forming a new public / private key pair be held securely.

[0177] <Coding scheme> Transaction metadata may be used to access instructions stored in documents outside the block. These documents are sometimes referred to as "deals" or "contracts." The metadata used to reference a deal can be formatted in various ways; however, a suitable coding scheme is described here.

[0178] A transaction is transferable if the rights defined in the transaction are gifted to the holder or owner of the transaction. An example of a non-transferable transaction is one in which the participants are designated; that is, the rights are gifted to a specific designated entity rather than the holder of the transaction. Only transferable transactions are discussed in this coding scheme.

[0179] A token represents a specific transaction that details or defines the rights that are granted through the transaction. In accordance with this invention, a token is a transaction representation in the form of a Bitcoin transaction.

[0180] This coding method uses metadata with three parameters or data items. This data may represent: i) The amount of shares available under the transaction (This is sometimes referred to as "NumShares" in this specification.) ii) The amount of transfer units that should be transferred from the sender to at least one receiver (this is sometimes called "ShareVal") iii) A factor for calculating the value of the transfer unit (this is sometimes called the "pegging rate").

[0181] The advantage of this coding scheme is that it can be used to encapsulate or represent transactions as tokens on the blockchain using only the three parameters mentioned above. In fact, a transaction can be specified using as few of these three data items as possible. Since this coding scheme can be used for any type of transferable transaction, a common algorithm can be devised and applied. Further details of these metadata items are provided below.

[0182] A divisible token is one in which the value on the transaction output can be subdivided into smaller amounts that are allocated across multiple tokens (i.e., across multiple transactions). A typical example is tokenized fiat currency. A divisible transaction is defined as a transaction that specifies a non-zero pegging rate. In a divisible transaction, the tokenized value transferred within the transaction output is pegged to the underlying Bitcoin (BTC) value by the pegging rate. In other words, the transaction specifies the holder's rights in terms of the pegging rate. In a non-divisible token, there is no pegging rate, and the transaction specifies the holder's rights in terms of a fixed value (for example, a bearer bond that says "this transaction can be cashed for exactly $1000," or a voucher that says "this transaction is exchangeable for 1 haircut"). In a non-divisible transaction, the underlying transaction BTC value is independent of the transaction value.

[0183] The expression "Base BTC Value" represents the amount of Bitcoin (BTC) to be added to the transaction output. In the Bitcoin protocol, each transaction output must have a valid, non-zero BTC value. In practice, the BTC value must be greater than the minimum value ("dust") currently set at 546 satoshis at the time of writing. One Bitcoin is defined as equal to 100 million satoshis. Since Bitcoin transactions are used in this specification solely as a means to facilitate the exchange of ownership, the actual base BTC value is arbitrary. The true value lies within the transaction specification. Theoretically, all tokens can be transmitted by dust.

[0184] In accordance with the coding scheme of the present invention, specifically, in a divisible token, the base BTC value has the following meaning: the relationship to the transaction value is carried by the pegging rate. The pegging rate is arbitrary in itself and is chosen to keep the base BTC amount small. The reason for using the pegging rate rather than the underlying token transaction which simply has dust is that the protocol of the present invention achieves visibility. When a token is divided into several smaller transaction outputs, there is no need to adjust the original transaction. Rather, the transaction value of each subdivided token is simply calculated based on the pegging rate and the subdivided amount of the base BTC value.

[0185] A limited token is a token whose total issuance value is fixed (or "limited") by a fixed non-zero number of shares determined by a quantity called NumShares. Therefore, no further shares will be issued under a limited transaction. For example, a transaction for co-ownership of a racehorse is limited to 100% of the racehorse (e.g., 100 shares at 1% each, or 10 shares at 10% each, etc.). An unlimited transaction means that the issuer can subscribe to the issuance of further shares, for example by adding the requested amount of fiat currency to their Reserve Account. NumShares must be explicitly stated in all transactions. A limited transaction must have NumShares > 0. An unlimited transaction is indicated by setting NumShares = 0.

[0186] A typical example is monetary reserves (similar to gold reserves), where the total value held in a reserve deposit account matches the total value of existing promissory notes (i.e., unredeemed tokens). This concept extends beyond monetary reserves to include inventory stocks. For example, the issuer of authorized printed T-shirt tokens may start with an inventory of 10,000 T-shirts and issue divisible tokens representing these 10,000 T-shirts (where each share = 1 T-shirt). The original tokens can be subdivided, and each subdivided token is redeemable for the number of T-shirts according to the underlying BTC value of the transaction output determined by the pegging rate. However, if demand increases, the issuer may decide to issue additional shares (i.e., increase the number of circulating shares by another 10,000). In such a case, it is the issuer's obligation to deposit an additional 10,000 T-shirts in the issuer's reserve account (i.e., inventory warehouse) to undertake the further issuance. Therefore, the total number of T-shirts in stock is always equal to the total number of outstanding shares (where stock acts as a "reserve account").

[0187] The pegging rate applies only to divisible transactions. Here, the share value (represented by a quantity called ShareVal) is pegged to the base BTC value. For example, a transaction may specify that the issuer promises to redeem tokens at a rate of $10,000 for every base 1 BTC. This could mean that a transaction with a tokenized base output value of 15,400 satoshis (for example) is redeemable for $1.54. A value of 0 for the pegging rate indicates that the transaction is indivisible (i.e., only the whole is transferable, like a bearer bond). When the pegging rate is set to 0 (meaning an indivisible token), the base BTC value is independent of the transaction value and can be set to any amount. Typically, in this case, it is desirable to keep the base BTC value as small as possible (i.e., set to dust) to minimize operational costs.

[0188] NumShares is the total (fixed) number of shares available under a (limited) deal. In a limited deal, NumShares must be a total number greater than zero. In an unlimited deal, NumShares is not fixed because more shares can be issued at any time (if they are accepted). This is indicated by setting the value to 0.

[0189] Shares are defined as transfer units, and ShareVal is the value of that unit. For example, in fiat currency, the transfer unit may be set to 1 cent. Alternatively, for example, the transfer unit may be set to 50 cents, in which case transfers can only be made in "lots" of 50 cents. ShareVal can also be expressed as a percentage. For example, if a breeder wants to sell a racehorse for 10 equal shares, setting ShareVal=0 is 10%. ShareVal must be greater than 0 and must be defined in the transaction.

[0190] TotalIssuance represents the total value of the issued shares. This value is only relevant to restricted transactions. For unrestricted transactions, the issuance is not fixed and more shares may be issued. When the shares are expressed as a percentage, by definition TotalIssuance = 0 is set to 100%.

[0191] In restricted transactions, NumShares, ShareVal, and TotalIssuance are related as follows. NumShares × ShareVal = TotalIssuance A value of 0 for TotalIssuance means an unrestricted transaction. An example of an unrestricted transaction is fiat currency (therefore, TotalIssuance is set to 0). Examples of restricted transactions are (i) limited edition commemorative coins (1000 are minted and 1 share = 1 coin), TotalIssuance = 1000 × 1 = 1000 coins, (ii) seats in a venue with tickets, TotalIssuance = total available seats.

[0192] Circulation is defined as the total value of the unused tokens (i.e., determined by the transactions in the UTXO (Unused Transaction Output)). The complete set of all unused transactions is held in a list available to all Bitcoin nodes. For example, if the issuer initially issues $10,000 as fiat currency type tokens and over time tokens with a value of $5500 are redeemed, the circulation = $4500 (the value of the outstanding tokens). This value should be adjusted to the balance of the relevant reserve account.

[0193] <Example for the description of computing resources (an "agent") suitable for use with embodiments of the present invention> The present invention can utilize appropriately configured computing resources (herein an "agent") to execute an automated aspect of a desired process. An example of a suitable and preferred agent is provided below, but other implementations may be used.

[0194] An agent may operate in conjunction with a blockchain, using the blockchain as an immutable tape in an implementation of a Turing machine. This agent runs in parallel with the blockchain network, supervising and handling the execution of (loop) processes. Loop processes are designed to perform given tasks, such as automating the processing or control of a device or system. This parallel resource can monitor the state of the blockchain and write transactions to the blockchain. In a sense, this utilizes the blockchain as an immutable tape of a Turing machine and has the following definitions and characteristics.

[0195] 1. A blockchain acts as the tape of a Turing machine. Each transaction in the blockchain represents a cell on the tape. This cell can contain symbols from a finite alphabet.

[0196] 2. The tape head can read information from blocks that have already been written to the blockchain.

[0197] 3. The tape head can write new blocks containing many transactions to the end of the blockchain. However, they cannot write to blocks that already exist; thus, the blockchain tape is immutable.

[0198] 4. It can be stored as part of the P2SH (pay-to-script-hash) transaction of the multi-signature of each transaction.

[0199] A key function of the agent is to act as an automated entity that monitors the current state of the blockchain. It can also receive signals or inputs from any off-block source. Depending on the blockchain state and / or the inputs received, the agent may perform certain actions. The agent determines which actions should be performed. These may or may not include actions in the "real world" (i.e., off-block) and / or actions on the blockchain (such as generating and broadcasting new transactions). The actions taken by the agent may be triggered by the blockchain state. The agent may also decide about the next set of transactions to be broadcast to the Bitcoin network and subsequently write them to the blockchain.

[0200] The agents' actions are executed in parallel and simultaneously on the blockchain (e.g., Bitcoin) network. In a sense, this stores the functionality of the blockchain (e.g., Bitcoin) script. This continuous monitoring implements a "loop" control flow configuration that creates a Turing completeness for the combined agents and blockchain system.

[0201] A Turing machine includes the following two stacks:

[0202] • Data stack: This is represented by the blockchain, as mentioned above.

[0203] • Control Stack: This is represented by agent functionality. It stores information related to the iterative control flow functionality.

[0204] Separating the control stack from the data stack offers the advantage of preventing infinite loops from occurring in the Bitcoin core and mitigating denial-of-service attacks.

[0205] The agent manages and executes a loopable subroutine using any type of loop configuration (e.g., FOR-NEXT, REPEAT UNTIL, etc.). Embodiments for the purposes of this specification include processing using an example of a “repeat” configuration. The user may specify an index (i) and a limit (J), which represent the current iteration number (typically counted starting from 0) and the total number of iterations of the repeating loop, respectively.

[0206] For each iteration, 1. The index increases by 1. The termination condition is that the iteration stops when the index reaches its limit. 2. A code block containing the statement "if condition then action" (ICTA) is executed. The action can be any action on or outside the blockchain. 3. The cryptographic hash of this subroutine is calculated. This can be stored on the blockchain as part of the transaction. Since the hash is unique to each code, it allows verification of which code is being used.

[0207] The loop body contains a code block. Each code block contains an "if condition then action" (ICTA) statement. This monitors the current state of the blockchain for transactions that match the following: • Start or trigger conditions (for example, when a specific date is reached), • Repeating conditions (i.e., metadata or hash associated with the previous iteration), • Termination condition (i.e., the last iteration of the loop).

[0208] The ICTA statement allows an agent to make decisions about the next transaction based on the current state of the blockchain. Generating the next transaction involves broadcasting the transaction to the Bitcoin network and writing the new transaction to the blockchain. This acts as a record that this iteration has been performed. Once the transaction is written to the blockchain, the manager will then know that the previous iteration has been performed and written to the blockchain, and will perform the next iteration. The latter continues until the loop persists, when the index (i) reaches the limit (J) specified in the code block.

[0209] Each transaction is stored on the blockchain in a reusable manner. In the Bitcoin implementation, each signature in a transaction is marked with the SIGHASH flag. This flag can take on different values. Each of these values ​​indicates whether other parts of the transaction can be modified without the involvement of the owner of this signature. Reusable transactions have the SIGHASH flag "SigHash_AnyoneCanPay" in one of their transaction inputs. This allows anyone to contribute to the transaction input. This parameter allows the agent's ICTA function to be executed and repeated multiple times with different inputs. The use of this function can be restricted to the authorization party, for example, by duplicating reusable transactions.

[0210] The "If condition" portion of an ICTA code block can monitor any type of condition. This is similar to other programming languages ​​(e.g., C, C++, Java) and is not limited to information stored on the blockchain. For example, it could monitor a date and time (i.e., when a specific date and time is reached), or the weather (i.e., when the temperature is below 10°C and it is raining), or the conditions of a transaction or credit (i.e., when company A buys company B).

[0211] The "Then action" portion of an ICTA code block can perform a number of actions. The present invention is not limited to the number or types of possible actions. Actions are not limited to transactions on the blockchain, but transactions containing metadata related to the action may be written to the blockchain.

[0212] Metadata can be in any format. However, in one embodiment, metadata may store hyperlinks to files containing more data or instructions related to the operation. Metadata may store both hyperlinks to hash tables containing more data or instructions related to the operation, and hashes of the operation that act as search keys for the hash tables.

[0213] The agent's control stack can be implemented in numerous ways, tailored to each user's specific needs. For example, the control stack's iterative loop can be based on any Turing-complete language. One possible language choice is one based on a Forth-type stack. The advantage of using this language is that it ensures consistency in the control stack with the known and widely used Bitcoin script and programming type.

[0214] <Using BitcoinScript's Alternate Stack as the data storage space> Bitcoin scripts include commands and opcodes that are called. These allow users to move data into alternating stacks known as "alt stacks."

[0215] The opcodes are as follows: • OP_TOALTSTACK. This moves data from the top of the main stack to the top of the alt stack. • OP_FROMALTSTACK. This moves data from the top of the alt stack to the top of the main stack.

[0216] This involves storing data from intermediate computation steps in an alt stack, similar to the "memory" function that allows a computer to store data. In one embodiment, the alt stack is used to construct a Bitcoin script to solve a small computation task and to return the result to the computation.

[0217] <Use code registers to manage agents> The agent also manages a registry of all the code it owns and executes. This registry is structured like a lookup table or dictionary that maps specific keys to specific values. Each key-value pair is represented by the hash (H1) of the code block and the IPv6 address of the location where the code is stored, respectively. To retrieve a code block using key H1, the lookup table is used to retrieve the associated value (which is the location where the code is stored) and, accordingly, the source code. The implementation of the code registry may vary.

[0218] <Transaction metadata in agent code, and loop respawning> The information needed to respawn the agent's loop in a specific iteration is stored as metadata within the transaction recorded on the blockchain.

[0219] Thus, a transaction on the blockchain stores or provides access to information about a given iteration of a loop being executed on an agent. This information may include the values ​​of any variables associated with the loop, such as index i, and any other necessary information, such as the values ​​of parameters used within the code block or location-related data of the location where further requested information is accessible.

[0220] The metadata itself is stored as part of the multi-signature P2SH (pay-to-script-hash) script within the transaction. The metadata recorded with the transaction also gives it the ability to record an audit trail of how the code has been executed in the past.

[0221] There are several ways in which an agent can respawn loop code blocks in each iteration. The code block may be hardcoded in the agent itself, stored in a secretly or publicly available file, stored as an entry in a secretly or publicly available hash table file, or a combination thereof. The code block may contain parameters that are fixed to hardcoded variables, or fixed but portable. Parameters may be single values ​​in any data format, small code chunks, or a combination thereof. Parameters can be portable by reading them directly from metadata within a transaction (e.g., a Bitcoin transaction), or from an external source such as an internal database, a secret / public file, a hash table, or any combination thereof. Pointers to external sources of parameter values ​​may be stored in the metadata within a transaction.

[0222] The following steps provide an example of how an agent can respawn a loop code block in the i-th iteration. In this example, the code registry is a hash table, where the hash value acts as the lookup key for the table and is stored in the transactional metadata. 1. The agent monitors the blockchain for transactions that contain hashes of code blocks that match entries in the code registry. 2. The agent finds the transaction containing the corresponding hash (H1). 3. The agent reads the "metadata-CodeHash," obtains the CodeHash field to get H1, and uses H1 to read the code (C1). If RIPEMD-160(SHA256(C1)) is equal to H1, the code has not changed and it is safe to proceed to the next step. 4. The agent reads the "metadata-CodeHash" that stores index I and respawns the code in the i-th iteration. In other words, the loop is "reloaded" in the appropriate iteration. 5. To verify the origin of the metadata, the user's signature is included in the P2SH command. 6. If this data is needed for this iteration of the loop, the agent reads "metadata-OutputHash" and "metadata-OutputPointer" and retrieves the output from the previous step.

[0223] It should be understood that, based on different combinations of the above-mentioned variations, there are many different patterns for implementing BitcoinGate. The following is merely a selection of patterns for illustrative purposes and is not intended to be limiting. Each pattern may be suitable for implementing one, more, or all types of gates, depending on the specific attributes of the pattern and the intended use of the gate logic.

[0224] It should be noted that the embodiments described above do not limit the invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. No reference numerals enclosed in parentheses in the claims should be considered limiting. The terms “comprising” or “comprises,” etc., do not exclude the existence of elements or steps other than those enumerated in any claim and specification as a whole. In this specification, “comprises” means “includes” or “consists of,” and “comprising” means “including” or “including of.” A singular reference to an element does not exclude the existence of multiple elements of that element, and vice versa. The invention may be carried out by hardware having multiple distinct elements or by a appropriately programmed computer. In claims for an apparatus that enumerates multiple means, these multiple means may be implemented by a single identical hardware element. The fact that certain quantities are described in different dependent claims does not mean that combinations of these quantities cannot be used advantageously. [Explanation of symbols]

[0225] 100 Systems 101 IoT devices 102 Client Devices 103 Control Agent 104 BID control system

Claims

1. A control method implemented by a computer, A step of providing a lock script in a first blockchain transaction, wherein the lock script includes at least one instruction configured to process at least one Boolean input, The step of providing further blockchain transactions that have an unlock script, A step of processing at least one input signal to provide at least one Boolean input, The steps include executing the lock script and unlock script for the first blockchain transaction and any further blockchain transactions using the at least one Boolean input, The control method includes, A step of monitoring or searching a blockchain or blockchain network to determine the existence of the further blockchain transaction, The steps include providing computing resources configured to affect the operation of a device or process based on the detection of further blockchain transactions within the blockchain or blockchain network, It further includes, The processing or device affected by the computing resources is not part of the blockchain network, The control method described above is The steps include sending the aforementioned further blockchain transactions and / or the first blockchain transaction to the blockchain network for verification, The steps include interpreting the detection of further blockchain transactions within the blockchain or blockchain network as the true output of a logic gate, A method that includes this.

2. The step of processing the at least one input signal to provide the at least one Boolean input is: i) By the unlock script of the further blockchain transaction, or ii) Using at least one computing resource or agent, The method according to claim 1, which is implemented.

3. The method according to claim 1 or 2, wherein the step of providing computing resources configured to affect the operation of the device or process is further based on the validity of the further blockchain transaction.

4. The method according to any one of claims 1 to 3, wherein the validity of the further blockchain transaction within the blockchain network depends on the execution of the unlock script.

5. A step of controlling an apparatus or process based on the validity of the further blockchain transaction, wherein the validity is determined or established by a computer-based control agent or by monitoring the blockchain network to determine whether it has been validated by a network node, and / or by monitoring the state of the blockchain to determine whether the further blockchain transaction has been written to the blockchain. The method according to any one of claims 1 to 4, including the method described above.

6. The method according to any one of claims 1 to 5, wherein the at least one instruction in the lock script is configured to implement a truth table for a logic gate.

7. The method according to claim 6, wherein the logic gate is at least one of an OR gate, AND gate, XOR gate, NAND gate, NOR gate, NOT gate, XNOR gate, IMPLY gate, or inverse inclusion gate.

8. The method according to any one of claims 1 to 7, wherein the at least one Boolean input includes a number, a constant value, the result of a hash function, a cryptographic key, a blockchain puzzle, and / or other blockchain-related addresses of Bitcoin.

9. The method according to any one of claims 1 to 8, wherein the first blockchain transaction and / or further blockchain transactions are generated and / or transmitted to a blockchain network by an automated process executed on computer-based resources.

10. The aforementioned at least one instruction is, Having a Boolean condition or operator, and / or Written and / or executed using a stack-based programming language, The method according to any one of claims 1 to 9.

11. A system implemented by a computer configured to implement the method described in any one of claims 1 to 10.

12. A control system incorporating Boolean calculations or operations implemented on or using a blockchain, wherein the Boolean calculations or operations are: The first blockchain transaction and Further blockchain transactions with unlock scripts, Includes, The first blockchain transaction is, At least one Boolean input and At least one instruction selected to perform the function of a Boolean truth table by processing the at least one Boolean input and providing at least one Boolean output, Includes, The control system is further configured to monitor or search the blockchain or blockchain network to determine the existence of further blockchain transactions, and to provide computing resources configured to influence the operation of the device or process based on the detection of further blockchain transactions within the blockchain or blockchain network. The processing or device affected by the computing resources is not part of the blockchain network, The control system is The aforementioned further blockchain transactions and / or the first blockchain transaction are sent to the blockchain network for verification. The detection of further blockchain transactions within the blockchain or blockchain network is interpreted as the true output of the logic gate. A control system further configured as follows.

13. The control system according to claim 12, wherein the Boolean truth table is at least one truth table from among OR gates, AND gates, XOR gates, NAND gates, NOR gates, NOT gates, IMPLY gates, NOT IMPLY gates, or XNOR gates.

14. The output is either a Boolean value or The at least one instruction is provided in a script associated with the first blockchain transaction, and the script is a lock script. The control system according to claim 12 or 13.

Images