Transaction Signing Flag

Abstract

1. A computer program for generating inputs and outputs for a blockchain voting transaction for conducting a vote, the computer program configuring one or more processors to: receive voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options; render a user interface displaying the voting options; receive a user selection of one of the voting options; and generate an input-output pair for inclusion in the voting transaction, wherein a non-signed portion of the input includes an outpoint identifying an unspent transaction output of a blockchain transaction, and a signed portion of the input includes a signature single flag and an associated signature that signs at least the non-signed portion of the input-output pair and an output of the input-output pair but not other outputs of the voting transaction, and the output of the input-output pair includes one of the public keys.

Description

[Technical Field]

[0001] The present disclosure relates to signature flags used in blockchain transactions. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter also referred to as a "blockchain network") maintain and publicly publish duplicate copies of the blockchain. A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, except for so-called "coinbase transactions," points to the preceding transaction in the sequence. The sequence may span one or more blocks, tracing back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are generated through a process known as "mining." "Mining" involves multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Notably, a blockchain may be pruned at some nodes, and block publication can be achieved through the publication of only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: carrying digital assets (i.e., multiple digital tokens), ordering a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or chronologically ordering index pointers. Blockchains can also be used to layer additional functionality on top of them. For example, blockchain protocols may allow for the storage of additional user data or indexes to data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this could be used to store electronic documents, or audio or video data within a blockchain.

[0004] Nodes (sometimes called "miners") in the blockchain network perform a distributed transaction registration and validation process, described in detail below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) therefore remains registered and indexed at each node in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new quantity of digital assets, or tokens. Detection and rejection of invalid transactions is performed by competing nodes, who act as agents of the network and are incentivized to report and prevent illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset derivable from the preceding transaction sequence. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input in a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another, previous, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction) (but may register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction transfers by referencing absolute account balances, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention

[0009] In blockchain transactions, signatures serve three purposes: providing proof of ownership or legitimate custody of funds, authorizing expenditures, and ensuring the integrity of transaction information. The third function ensures that certain details of the transaction cannot be changed without invalidating the signature. For example, signing outputs ensures that no one can intercept a transaction broadcast to the network and change the address to which the funds are allocated.

[0010] In a given output-based transaction model, typically when signing a transaction, a signing party creates a signature that applies to all inputs and outputs defined in the transaction. However, by using different tags (called signature flags) when creating the signature, the signature can be made specific so that it only applies to or "endorses" certain elements of the transaction.

[0011] In situations where multiple parties collaborate on a single transaction, the traditional sighash-all signing approach requires initial communication between the parties to establish transaction details before signing can proceed. This is inefficient and often imposes interdependencies that do not accurately reflect the relationships between the parties. In contrast, combining different sighash flags gives parties the flexibility to sign different parts of a transaction independently.

[0012] An example of a feature where such flexibility is useful is in voting, where each voter can sign only the inputs and outputs relevant to their vote, thus allowing the vote to remain anonymous. Because all inputs and outputs must be known before signing, voting cannot be done using the standard sighash ALL signature model, which would provide voters with the opportunity to refuse to provide a signature and invalidate their vote if they are dissatisfied with the outcome of their vote.

[0013] According to one aspect disclosed herein, there is provided a computer program for generating inputs and outputs of a blockchain voting transaction for conducting a vote, the computer program being stored on a non-transitory medium and, when executed by one or more computer processors, causing the one or more processors to: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; controlling a display to render a user interface displaying said set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair for inclusion in the voting transaction with one or more other input-output pairs at different indices of the voting transaction; So, A computer program is provided in which the non-signed portion of the input of the input-output pair includes an outpoint identifying an unspent transaction output of a blockchain transaction, the signed portion of the input includes a signature single flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction, and the output of the input-output pair includes one of the one or more public keys of the voting instructions.

[0014] According to a second aspect disclosed herein, there is provided a computer program for generating a voting transaction of a blockchain, the computer program being stored on a non-transitory medium and, when executed by one or more processors, causing the one or more processors to: It receives multiple input-output pairs, Generate a voting transaction, The voting transaction is For each voting index in the set of voting indices, there is one of the received input-output pairs, In the authorization index, there is an input consisting of the voting coordinator's signature with the all signature flag, such that the voting coordinator's signature signs all inputs and outputs of the voting transaction; Output and Including, Sending the voting transaction to a blockchain; A computer program is provided that is configured to:

[0015] According to a third aspect disclosed herein, there is provided a blockchain transaction embodied on a computer-readable medium, comprising: Inputs for effectively consuming the available transaction outputs indicated within the blockchain transaction inputs; at least one output including a lock script defining signature requirements and required signature flags, which when concatenated with an unlock script in a subsequent blockchain transaction validates the signature of the unlock script, extracts used signature flags from the unlock script, compares the used signature flags with the required signature flags, and invalidates the subsequent blockchain transaction if the used signature flags do not match the required signature flags and / or the signature is invalid; A blockchain transaction including: [Brief explanation of the drawings]

[0016] To facilitate an understanding of embodiments of the present disclosure, and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic, simulated representation of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4]FIG. 2 is a schematic block diagram of specific node software for processing transactions. [Figure 5] 1 is an exemplary token issuance transaction. [Figure 6] 1 is an exemplary voting transaction for a vote requesting all voters to cast a vote. [Figure 7] 1 is an exemplary voting transaction for a quorum vote. [Figure 8] A schematic diagram of the relationship between the inputs and outputs of a token issuance transaction and a voting transaction. [Figure 9] 1 illustrates an exemplary method for providing voting using a blockchain. [Figure 10] 1 illustrates an exemplary voting method. DETAILED DESCRIPTION OF THE INVENTION

[0017] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to other blockchain nodes 104.

[0018] Each blockchain node 104 includes a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or other devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0019] A blockchain 150 includes a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes 104 in a decentralized or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing an amount of a digital asset as an asset. In this example, the output is cryptographically locked to user 103 (requiring that user's signature or other solution to unlock it and thereby redeem or spend it). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0020] Each block 151 also contains a block pointer 155 that points back to an earlier block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0021] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is sometimes referred to as a "mempool." This term, as used herein, is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated to not accept other transactions that attempt to use the same output.

[0022] For a given current transaction 152j, the inputs (or each of them) contain a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when the current transaction 152j was created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to something that precedes in the logical sequence linked by a pointer, and not necessarily to the time of creation or transmission in the chronological order. Thus, it does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0023] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and combine amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0024] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as an individual user or an organization, wants to act on a new transaction 152j (either manually or through an automated process used by a party), the acting entity sends the new transaction from its computer terminal 102 to a recipient. The acting party or recipient eventually sends this transaction to one or more blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but in principle other user terminals are also possible). In some examples, it is not excluded that the party 103 acting on the new transaction 152j can send the transaction directly to one or more blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may involve checking that a cryptographic signature or other authentication of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152j that the new transaction assigns, which condition typically includes at least checking that the cryptographic signature or other authentication in the input of new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i, or may be simply fixed in the blockchain node protocol, or a combination thereof.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0025] In an output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated (e.g., spent) is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined order of transactions, account balances have a single, defined state at a time.

[0026] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0027] A first blockchain node 104 that solves the puzzle notifies the network 106 and provides its solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The first blockchain node 104 propagates the block to the consensus of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0028] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, in the order in which the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to produce blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol for resolving possible "forks," which occur when two blockchain nodes 104 solve the puzzle within a very short time of each other, causing inconsistent views of the blockchain to propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0029] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional, approved amount of a digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow protocol rules so that this special transaction can later be redeemed. Blockchain protocol rules may require this special transaction to expire, e.g., 100 blocks, before it can be redeemed. A regular (non-generating) transaction 152 often specifies an additional transaction fee in one of its outputs, further rewarding the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is described below.

[0030] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0031] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation attributed to a blockchain node 104 may be performed by software executing on the processing unit of each computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0032] Also connected to the network 101 are computing devices 102 for each of a number of parties 103 that act as consumer users. These users can interact with the blockchain network but do not participate in validating transactions and constructing blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0033] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") can be said to be part of the system that includes the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 can exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as "first party" and "second party," respectively.

[0034] Each party's 103 computing device 102 includes a respective processing unit that includes one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's 103 computing device 102 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units that use one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on each party's 103 computing device 102 stores software, including a respective instance of at least one client application 105, configured to operate on the processing unit. It will be understood that any actions attributed to a party 103 given herein may be performed using software executing on the processing unit of each party's 102 computing device. Each party's 103 computing device 102 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0035] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, for example a CD or DVD ROM, or removable optical drive.

[0036] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amounts defined among the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0037] NOTE: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in two or more different application suites, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0038] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0039] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 with the best connection to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0040] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of the blockchain maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the network 106.

[0041] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, the blockchain nodes 104 begin competing to solve a proof-of-work puzzle for the latest version of their respective pools of transactions, including the new transaction 152. (Note that other blockchain nodes 104 attempt to solve the puzzle based on different pools 154 of transactions, but whoever comes first defines the set of transactions included in the latest block 151.) Eventually, the blockchain nodes 104 will solve the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 containing the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0042] Different blockchain nodes 104 may initially receive different instances of a given transaction and may therefore have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not yet published in a block 151).

[0043] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In an account-based model, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0044] <UTXOベースのモデル> Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0045] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. Among other information, a UTXO may also include the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input and output fields 202 and 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the node 104.

[0046] For example, suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." It incorporates the amount of the digital asset locked to Alice into the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0047] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and submitted to the network 106, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may be equivalently replaced by "preceding" and "successor," or "ancestor" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0048] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the quantity of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the quantity to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

[0049] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies the information needed to consume a transaction output 203, e.g., requirements for Alice's signature. An unlock script appears in the transaction output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction input 202.

[0050] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <SigP A The data (or "message") that Alice needs to sign to provide a valid signature may be defined by the lock script, or by the node protocol, or a combination of these.

[0051] When a new transaction Tx1 arrives at a blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts.

number

[0052] The message m is derived from certain details of the transaction being signed, and since this message must be identical from signing to validation, this process ensures that the transaction data contained in the message cannot be changed without invalidating the signature. [Table 1]

[0053] The message is generated by concatenating certain elements of transaction information in a set order, as described above. During signature verification, the message is not explicitly transmitted, but rather recreated by the verifier based on data in the broadcast transaction. The transaction information is concatenated via the same process used in signing and double-hashed to generate a message digest, e. If any part of the transaction used to recreate the message has been altered since the signature was generated, the message is no longer identical and verification fails.

[0054] This process of using transaction details in the signature message provides a key element of security during the delay between the broadcast of the transaction and the time it is published to the blockchain. However, because any element of the transaction that is signed (i.e., included in the signature message) cannot be updated without invalidating the signature, some transaction fields cannot be included in the signature message. These fields are the unlock script for each input, which must be updated to include the signature after generation, and the transaction ID (TxID), which is a double hash of the complete transaction (including the signature in the unlock script). Because both fields must contain (or be derived from) the signature, they cannot be finalized until the signature is generated.

[0055] The details of authentication using public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then another entity, such as node 104, given Alice's public key and the message in plaintext, can authenticate that the message must have been signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging the message as the signature, allowing the owner of the public key to authenticate the signature. Thus, in embodiments, reference to signing a particular piece of data, portion of a transaction, etc., may mean signing a hash of the piece of data or portion of a transaction.

[0056] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby causing it to propagate throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines it as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0057] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0058] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" some of the amount defined in the UTXO while another amount is spent. However, amounts from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0059] In particular, Alice must typically also include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will likely be rejected by the blockchain nodes 104, and thus, although technically valid, it will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, the difference between the total amount indicated by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0060] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, a given party 103's assets are dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0061] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a specific function. "OP_...." represents a specific opcode in a scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of a lock script, is an opcode in a scripting language to generate an unspent output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

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

[0063] Using six different flag types, signatures can be selectively endorsed, thereby confirming the details of either all inputs and outputs, or various subsets. The different sets are shown below, based on the signature unlocking the input in index 2. Guaranteed inputs and outputs are shown in bold. [Table 2]

[0064] The flag name at the top of each table indicates the outputs (ALL, NONE, or SINGLE) included in the message. Each flag has two variants, signaling which inputs are included in the signed message. The "standard" variant (top row of the table in Figure 2: ALL, NONE, SINGLE) includes all inputs, while the "anyone can pay" or ACP variants (bottom row: ALL|ACP, NONE|ACP, SINGLE|ACP) include only the inputs that the signature unlocks. Note that for single flag variants (SINGLE or SINGLE|ACP), the single output being signed is the one at the index position matching the input being unlocked.

[0065] The fields in the message that are affected by the selection of the sighash flag are Hash(Outpoints), Hash(nSeqs), Hash(Outputs), and the sigHashFlag field itself. When computing the hash field, the inputs and outputs that are not included (based on the sighash flag) are empty, and the remaining data is concatenated and hashed in order. For example, for a sighash ALL|ACP signature, the inputs and outputs that are not included are hashed at index 0 (Outpoints). i ) and index 1 (Outpoint j ) input information is removed, but all output details are preserved, resulting in the following hash fields:

number

[0066] For the sighash SINGLE signature, all inputs are kept, but only one output (the output at index 2 that matches the signature position) is kept, resulting in:

number

[0067] Other fields in the message string are not affected by the sighash flag. The version and locktime fields (which are always included in the signature message) are the same for all signatures based on the same transaction, regardless of which inputs the signature allows. The remaining fields (outpoint k , lockScriptLength k , lockScript k , value k , and nSeq k) is directly related to the input being signed and therefore changes depending on which input the signature was created to unlock, but is unaffected by the choice of sighash flag, since the unlocking input must always be signed.

[0068] The signed message is passed to the ECDSA signing algorithm with the matching private key to produce the signature (r, s). To include this signature in a blockchain transaction, it must be converted into a single string that is placed in the unlock script field of the approving input. The string is created by concatenating the two elements of the signature, r and s, and encoding them into byte form using the DER standard.

[0069] In the message, sighash flags are added as the last byte, and each sighash flag is represented by a specific value as shown in the table below, indicating the following serialized signature:

number

[0070] The six sighash flags provide the flexibility to "sign" (by including in the signature message) anything from a single input (NONE|ACP) to all inputs and outputs (ALL). For flags other than sighash ALL, this means that the transaction information excluded from the signature message can be changed without invalidating the signature. This allows for more flexibility than the standard method of using sighashALL. For example, the anyone can pay flag variant places no restrictions on the details of inputs other than those being signed, allowing other parties to add inputs (i.e., "pay") to the transaction without invalidating each other's signatures.

[0071] A lock script is sometimes referred to as a "scriptPubKey," indicating that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," indicating that it typically provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions for redeeming a UTXO include authenticating a signature. More generally, a scripting language may be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" are preferred.

[0072] <Side Channel> As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the invitation of either party or a third party). The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, it may be used to exchange transactions 152 between Alice and Bob without them being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” The transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0073] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established over a different network, such as a local area network, such as a mobile cellular network or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, the side channel 107 referred to anywhere herein may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when Alice and Bob are said to exchange particular information, pieces of data, etc., over the side channel 107, this does not necessarily mean that all of these pieces of data need to be transmitted over exactly the same link or the same type of network.

[0074] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the disclosed techniques. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform the underlying transaction-related functionality of the client 105, e.g., to form transactions 152, receive and / or send transaction and / or other data via side channels 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106, as described in more detail in accordance with the schemes described above. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 includes functionality 403 configured to perform one or more of the following: -generating the tokens by generating a token issuance transaction; Initiating a vote by defining voting options, assigning public keys to the vote, and sending the voting options and public keys to the voters; -generating an input-output pair corresponding to the vote of one of the voters and sending the input-output pair to the voting coordinator; - Generate a voting transaction containing the received input-output pair, -Determine whether the voting conditions have been met.

[0075] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user computing device 102, including outputting information to each user 103 by user output means of the device 102 and receiving input from each user 103 by user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screen) to provide visual output, one or more speakers to provide audio output, and / or one or more tactile output devices to provide tactile output, etc. The user input means may include, for example, one or more touchscreen input arrays (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice recognition algorithms for receiving voice or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0076] Note: Although various functions are sometimes described herein as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in two or more different suites of applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or in the functionality of a given module, or the transaction engine 401 may be split among more than one application. Also, this does not exclude some or all of the described functionality being implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, it is understood that this is merely by way of example, and more generally, the described functionality may be implemented in any form of software.

[0077] 3B provides a simulated representation of an example user interface (UI) 300 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by any other party's client 105b, Bob's device 102b, or any other party's device.

[0078] 3B illustrates UI 300 from Alice's perspective. UI 300 may include one or more UI elements 301, 302, 303 that are rendered as separate UI elements via user output means.

[0079] For example, the UI elements may include one or more user-selectable elements 301, such as different buttons on a screen or different options in a menu. The user input means is configured to allow the user 103 (Alice 103a in this case) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: "manual" as used here simply means the opposite of automatic and is not necessarily limited to the use of hands). The options allow the user (Alice) to select one of a predefined set of voting options provided in the voting instructions for casting a vote, select one or more recommended voting options when defining voting options, select received input-output pairs to include in a complete voting transaction, or select a user group from a user directory for which to generate a token.

[0080] Alternatively or additionally, the UI element may include one or more data entry fields 302 in which the user can enter data to be included in the OP_RETURN or text defining voting options to be included in the voting instructions. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touchscreen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0081] Alternatively or additionally, the UI elements may include one or more information elements 303 that are output to output information to the user, which may for example be drawn on a screen or rendered audibly.

[0082] For example, this / these may be rendered on the screen or audibly rendered. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 300 shown in FIG. 3 is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for the sake of brevity.

[0083] <Node software> FIG. 4 illustrates example node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx imay be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 held by the node 154. i In either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0084] The script engine 452 therefore i Lock script and Tx j 2, but the same can be applied to any pair of transactions. The script engine 452 executes the two scripts together as described above, which includes placing data on the stack 453 and retrieving data according to the stack-based scripting language (e.g., Script) being used.

[0085] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output that the lock script is contained in. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0086] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more additional protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of digital assets specified in the output of Tx does not exceed the total amount pointed to by its input; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually validated, the decision engine 454 then activates one or both of the agreement module 455C and the propagation module 455P to perform their respective blockchain-related functions as Tx j , which may choose to control the execution of Tx in each of the nodes' ordered transaction sets 154 for incorporation into block 151. j and a consensus module 455C that adds Tx to another blockchain node 104 in the network 106. j Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both the transaction being declared and sufficient transaction fees remaining.

[0087] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (the overall outcome is considered to convey true if both individual outcomes are true).

[0088] token Some transactions include inputs associated with different users, such as voting transactions described next. To restrict which users can contribute to a transaction, tokens are issued to authorized contributors, allowing them to provide inputs and outputs within the transaction.

[0089] Tokens are described with reference to their use in voting.

[0090] An example of a token issuance transaction is shown below and in Figure 5. The transaction is generated by the device of the party responsible for the transaction generated using the token. In the case of voting, the party is the voting coordinator. [Table 4]

[0091] The token issuance transaction 500 has a single input including an outpoint 504 identifying the transaction ID and index of the unspent transaction output, and an unlock script 506 containing the signature of the voting coordinator with the sighash ALL flag such that all inputs and outputs of the token issuance transaction 500 are signed by the signature of the voting coordinator.

[0092] The token issuance transaction 500 has multiple outputs: a set of tokens 510, one for each voter, and an output associated with the voting coordinator, which includes unspent transaction outputs and a locking script that locks the UTXO to the coordinator's public key.

[0093] Figure 5 shows three tokens, each with a corresponding lock script 508 that identifies the eligible voters to whom the token is locked. The tokens are unspent transaction outputs with low or nominal values, such that they may be considered dust UTXOs. This means that if a voter does not vote, only a small amount of digital assets is lost by the voting coordinator, leaving the voter with little incentive to not vote. The lock script also contains signature conditions that define the sighash flag that voters must use when voting with their tokens. For quorum voting, where only a portion of voters are required to vote and therefore the inputs cannot be known before voting, the signature conditions define that the SINGLE|ACP sighash flag must be used. On the other hand, if all voters are required to know all inputs before voting, the signature conditions can define either a single sighash flag: SINGLE|ACP or SINGLE.

[0094] When using tokens, a signing condition checks whether the last byte of the signature, which indicates the sighash flag used in the signature, is equal to a specific value associated with the defined signing condition. For example, to ensure that the sighash SINGLE|ACP (byte value 0x83) is used, you can include the following sequence of opcodes at the beginning of your lock script:

number

[0095] A description of this code is provided in Appendix A. It is understood that the code given is only one example of SCRIPT code and that those skilled in the art will know of other SCRIPT code that can be used to achieve the same result.

[0096] Eligible voters can then use their tokens in a voting transaction by providing an outpoint identifying the token issuance transaction and the voter's locked UTXO, the signature of the voter whose token was locked, and the sighash flag indicated in the token's locking script.

[0097] The above tokens can be used in other transactions where multiple parties contribute to the same transaction. The tokens provide a way to restrict the parties that can contribute to a transaction and provide an easy way to identify contributions from unauthorized parties.

[0098] How to vote In voting, multiple parties contribute to a single transaction.

[0099] When applying a signature using sighash ALL, the entire transaction, including all input and output details, must be defined before signing can begin, as once a signature with the ALL flag has been applied, no further editing of the inputs or outputs is possible. This means that all parties must first jointly define the transaction and then sign it a second time. In contrast, using different sighash flags provides a degree of autonomy between parties, as they can individually set different outputs and apply signatures without having to define all transaction details upfront.

[0100] Because parties vote at different times and it is desirable for each party's chosen voting option to remain anonymous, parties sign their inputs with a single sighash flag so that only the outputs they provided are included in the signature message. To prevent a voter from removing another voter's vote from a transaction without the other voters' knowledge, the transaction is generated by a voting coordinator, who compiles the voting transaction and approves it with the ALL sighash flag after all votes have been received and included.

[0101] The ACP flag variant allows inputs to be defined independently, making it suitable for use in situations where multiple inputs are present. Similarly, the SINGLE flag variant allows specific outputs to be signed without modifying the other outputs. These two features mean that the SINGLE|ACP flag can be used to sign input-output pairs that exist at matching index positions without placing restrictions on the details or number of other inputs and outputs. This allows considerable flexibility for combining pairs into a single transaction. Because all inputs and outputs are signed, the only requirement for the complete transaction to be valid is that the combined value of the inputs be sufficient to cover all allocated outputs and the appropriate transaction fee. For example, the transactions Tx and Tx' shown below, formed from a set of four independently signed pairs, are both valid if the input value exceeds the output value. [Table 5] [Table 6]

[0102] However, while sighash SINGLE|ACP is highly flexible, it also leaves room for potential flexibility. Any input-output pair signed using SINGLE|ACP can be copied and included in a conflicting transaction without invalidating the original signature. If an interceptor broadcasts a modified transaction to the network, it is uncertain which version of the transaction will be published to the blockchain, as some nodes on the network may receive the modified version before the original transaction. This is particularly problematic when the value of the input in a signed pair is greater than the output. This means that the modified transaction could assign the extra value to the interceptor's address. Therefore, to mitigate interference, SINGLE|ACP signed pairs should never leave their input values ​​unassigned.

[0103] Definition of Voting The voting coordinator defines the voting.

[0104] A poll has a predefined set of options and requires the voter to select one of the predefined options. An example of this would be an election poll where the voter selects one of the candidates running for office. Polls may include an "other" option and may allow users to enter their own answer.

[0105] The voting coordinator defines a set of options, such as a list of candidates. The voting coordinator can assign a different public key to each option. These assignments are stored in a database. The public keys can be used to generate addresses. When a voter selects one of the defined voting options, unspent transaction outputs are locked to the public key associated with the selected option.

[0106] The voter may be able to provide other user-defined inputs, for example, the voter may provide further comments for inclusion in the voting results by selecting a voting option and entering the comment in a data entry field.

[0107] The voting coordinator defines that voters are allowed to enter text. Once a voter participates in a vote, the vote's unspent transaction output is locked to the public key of the selected voting option, and the text is rendered in the transaction's OP_RETURN.

[0108] Complete Group Voting Consider a group that wants to institute a secret ballot in which all members of the group must vote. Voting options need to be pre-defined by the voting coordinator as described above, and voters should not be able to see each other's choices until all votes have been cast. Individual votes can be represented in a transaction by the details of a single output (e.g., by associating all voting choices with a specific output address) if the output can be set and signed independently by a single voting party. To enable this, a voting transaction needs to include input from each voter and a matching output signed with a single sighash flag. The inputs can be voting tokens of nominal value that are issued to each member of the group prior to voting.

[0109] For example, a group of three voters (Alice, Bob, Charlie) and a coordinator (Delilah) can vote as follows:

[0110] 1. Delilah creates a transaction that creates three dust UTXOs that act as voting tokens, and allocates one each to Alice, Bob, and Charlie. [Table 7]

[0111] 2. Delilah adds these token UTXOs, along with additional inputs she controls that contain enough funds to cover the transaction fees, as inputs to a voting transaction template. She sends this template to Alice, Bob, and Charlie, along with a list of output addresses corresponding to each voting choice. [Table 8]

[0112] 3. Alice, Bob, and Charlie each set their nominated output details to reflect their voting choice, create a signature using Signing SINGLE, and place it in the input unlock script. Signing SINGLE places no restrictions on the outputs set in other indexes, so they do not need to know the voting choices of other parties to create a valid signature. All voters must return partially signed transactions (representing their votes) to Delilah. For example, Bob's vote would be of the form: [Table 9]

[0113] 4. Once Delilah receives all of her votes, she combines them into a single vote transaction, uses sighash ALL to create a signature validating the use of her input, and broadcasts the transaction, providing an immutable record of the votes. [Table 10]

[0114] Delilah must set the voting template and collate votes, but has no opportunity to interfere with the outcome. By pre-defining the inputs before the parties sign, the group ensures that all parties must provide a vote to create a valid transaction. Similarly, because inputs can only be validated by parties holding pre-specified keys, votes cannot be tampered with by other parties (including Delilah).

[0115] Figure 6 is an example of a voting transaction 600 for a complete group vote, where voting tokens are issued using the token issuance transaction of Figure 5. Voting transaction 600 includes four inputs and four outputs.

[0116] The 0th index contains the first input-output pair provided by the first voter. The input includes a non-signed portion and a signed portion. The non-signed portion includes an outpoint indicating the token at index 0 of the token issuance transaction in Figure 5, and the signed portion includes the signature of the first voter whose public key the token is locked to and a SINGLE sighash flag. The output includes a digital asset value equal to the token value and a lock script containing the address of the voting option selected by the user—voting option 1. The signature signs all inputs of voting transaction 600 and the output at index 0 of voting transaction 600, but does not sign any other outputs of voting transaction 600. That is, the signature message includes only the four inputs and the output at index 0.

[0117] Similar input-output pairs are provided for the first and second indices, respectively, where the input-output pair for the first index indicates the token at index 1 of the token issuance transaction with the second voter's signature and the SINGLE sighash flag, an unspent transaction output value equal to the token's output value, and the address of voting option 3 selected by the second voter, and the input-output pair for the second index indicates the token at index 2 of the token issuance transaction with the third voter's signature and the SINGLE sighash flag, an unspent transaction output value equal to the token's output value, and the address of voting option 1 selected by the third voter.

[0118] The input at index 3 contains an outpoint pointing to the voting coordinator's UTXO and the voting coordinator's signature with the ALL signature flag. The output at index 3 contains a UTXO with a value equal to the UTXO indicated in the input minus the transaction fee (because the full value of each token is locked in the voting option's public key) and a lock script containing the voting coordinator's public key. If the UTXO values ​​of the outputs for votes at index 0 through 2 are less than the values ​​indicated in the inputs and each vote contributes to transaction fees, then the difference between the UTXO referenced in the input at index 3 and the UTXO in the output at index 3 need only be equal to the amount of transaction fees not covered by the individual votes.

[0119] The indices in the input-output pairs provided by the voters are sometimes called voting indices. In the example of Figure 6, these are indices 0, 1, and 2. The indices at which the voting coordinator provides a signature, here index 3, are sometimes called endorsement indices because the voting coordinator signs all inputs and outputs. It can be seen that the voting and endorsement indices can be provided at any index in transaction 600, as long as the voting coordinator simply signs the inputs and outputs after all voting indices have been provided.

[0120] The vote transaction 600 also includes a transaction ID, an incount of 4, and an outcount of 4.

[0121] Figure 8 illustrates the relationship between a voting transaction 600 and a token issuance transaction 500. Each input in the voting transaction 600, corresponding to a vote (index 0 through 2), represents an output of the token issuance transaction 500, as described above. When the voting transaction 600 is validated by a blockchain node, the locking script and unlocking script associated with the same UTXO are executed together to ensure that the unlocking script meets the requirements of the locking script. This includes checking the sighash flag value if the token's locking script includes such a signature condition.

[0122] The input of token issuance transaction 500 is shown to point to the output of a previous blockchain transaction 800 that locks a UTXO to the voting coordinator's public key. The previous transaction may include an input to spend a UTXO (not shown) associated with a previous vote so that the digital asset used for the previous vote is reused.

[0123] In a full group vote, either the SINGLE or SINGLE|ACP sighash flag can be used. If tokens are used, the voter can use the SINGLE sighash flag because the input is known to the voting coordinator before the vote transaction is generated, as shown above and in Figure 6. A user can also use the SINGLE|ACP sighash flag in this scenario without affecting other voters' ability to vote.

[0124] Alternatively, no tokens are issued, thereby eliminating step 1 above, and voters vote by consuming unspent transaction outputs of a predefined value that have been previously assigned to them. This means that the "cost" of voting is not provided to the voter by the voting coordinator, and the voter must pay to vote. The cost of voting in this case may be nominal to encourage voting. The outpoint provided by the voter when casting a vote is not known to the voting coordinator before the vote, so the SINGLE|ACP sighash flag is used by the voter.

[0125] The above tokens have a small "dust" UTXO value. Such small values ​​may be created, for example, when a very small amount is left as change from a transaction. These dust UTXOs may not contain enough value to cover the transaction fee and will not function on their own. If the token is not spent, the voting coordinator will only lose a small amount.

[0126] quorum vote In some cases, it may not be necessary for all parties to return an answer, but instead agree that a vote is valid as long as a threshold (quorum) of members in the group participate. In this case, the exact input cannot be predefined (since it is unknown which voters will return a vote), so the voting token must be signed with the SINGLE|ACP flag.

[0127] 1. The coordinator must issue voting tokens to all voters. These must have additional spending requirements (defined in the lock script), such as having to be signed with the SINGLE|ACP flag. [Table 11]

[0128] This signature condition is an additional condition in the lock script that checks whether the last byte of the signature (which indicates the sighash flag used in the signature) is equal to a specific value. For example, to ensure that the sighash SINGLE|ACP (byte value 0x83) was used, you can include the following sequence of opcodes at the beginning of your lock script:

number

[0129] A description of this script is provided in Appendix A.

[0130] 2. Eligible voters who choose to vote must return their signed voting token to the coordinator by the voting deadline. If necessary, voters can set a lock time to prevent their vote from being valid before the voting deadline. [Table 12]

[0131] 3. Once the voting deadline has passed, the coordinator collects all submitted votes into one transaction. It must ensure that all tokens used are valid for this vote and that the required quorum is reached. This can be done manually or via a smart contract. For example, it can be done by ensuring that all voting inputs refer to Tx0 and that the sum of the token inputs equals the required value (n Q ×BSV, where nQ If these conditions are met, the coordinator adds the final inputs and outputs that cover the transaction fee, signs it using sighash ALL, and broadcasts the final voting transaction. [Table 13]

[0132] If the coordinator makes a mistake and does not include an eligible vote, the coordinator can simply create a second transaction that includes the missing vote. Similarly, if for some reason the SINGLE|ACP vote is included in a separate transaction and mined before the main vote transaction, the coordinator can add a reference to the TxID that included the vote in the OP_RETURN of the final output.

[0133] FIG. 7 shows an example of a voting transaction 700 for a quorum vote using the token issued in FIG. 5. Voting transaction 700 is similar to voting transaction 600 for a full vote, but only two voters have voted. Because the second voter did not vote, only the input-output pairs of the first and third voters are included in voting transaction 700 at indexes 0 and 1, but votes can be provided in any order and at any index. Index 2 includes the input and output associated with the voting coordinator, as does the third index in voting transaction 600 in FIG. 6. Thus, the in-count and out-count for voting transaction 700 are both 3.

[0134] As with full group voting, in some embodiments, no tokens may be issued. Instead, voters provide outpoints, which represent unspent transaction outputs with predefined values ​​to cover the cost of voting. In some cases, this cost may be minimized to encourage voting. In other instances, the cost may be substantial to discourage voters with little interest in voting from participating or from voting multiple times to skew the outcome of the vote.

[0135] A specific example of quorum voting is a poll. In this example, the party to vote for cannot be defined in advance, so the input must be signed with the SINGLE|ACP flag. A poll configuration could work as follows:

[0136] 1. Poll originator Alice publicly posts details of two or more poll choices, each of which must be associated with an address that Alice can unlock.

[0137] 2. Anyone who wants to register a vote in the poll can create a SINGLE|ACP signed input-output pair with the following properties: -The output must be one of the poll choice addresses defined by Alice. -Inputs should have minimum values ​​to prevent spam votes. -The output value must match the input. -Lock time should be set to coincide with the poll deadline.

[0138] 3. Each pair of "votes" is sent directly to Alice, who combines them into a single transaction. She adds a final input to fund the transaction fees if necessary, and signs sighash ALL.

[0139] 4. Once the transaction is validated by the blockchain nodes and published to the blockchain, it provides a record of the poll results. Alice benefits from the value contributed by each respondent through their input, regardless of which poll option was selected.

[0140] The flexibility of the SINGLE|ACP flag, in contrast to the SINGLE flag, means that when Alice broadcasts her final transaction, someone could intercept it before it reaches the network and create an alternative transaction based on the subset of eligible votes that are still valid. However, because the output address is fixed and the values ​​match the input values, an eavesdropper cannot redirect the values ​​provided by poll respondents, as the only potential impact would be to change the poll outcome. In this situation, it is still possible for Alice to create a second transaction containing the excluded poll responses, allowing her to collect the values ​​provided by those inputs. Nevertheless, instead of protecting against this flexibility, it may be worthwhile to introduce a service provider that takes a percentage of each poll value. For example, via an agreement with a block producer (or a service's own block production function), poll transactions could be sent directly to the core network without the need for a wider broadcast.

[0141] Figure 9 shows an example method for providing voting using a blockchain. Actions on the left are actions performed outside the blockchain, and actions on the right are actions performed on the blockchain by blockchain nodes.

[0142] In step S902, the voting coordinator defines voting options and assigns at least one public key to the vote. If one public key is assigned, the voting option selected by the voter is returned in the OP_RETURN of the transaction, and all UTXOs of the vote are locked to the one public key of the vote. In the case of multiple public keys, one public key is associated with each voting option so that the UTXOs of the vote are locked to the public key of the selected voting option. The association between the voting option and the public key is stored. The voting coordinator sets the time by which the vote must be received. The voting coordinator defines the voting options via a user device running a computer program that renders a user interface such as that shown in Figures 3A and 3B.

[0143] In step S904, the voting coordinator also defines the voters and signature requirements. The voting coordinator defines who is eligible to vote and the number of voters required, i.e., whether it is a full group vote or a quorum vote. The signature requirements depend at least in part on whether the vote is a full group vote. The voting coordinator also defines vote weights and other special voting privileges, such as veto power, in this step.

[0144] In step S906, the voting coordinator generates a token issuance transaction 500 based on the voter requirements defined in step S904. In step S908, the token issuance transaction 500 is received by a blockchain node, which validates the transaction in step S910 and publishes the transaction to the blockchain in step S912.

[0145] Once verified and issued, the token is locked to the voter's public key. The voter is said to receive the token in step S914.

[0146] In step S916, the voting coordinator distributes the voting options and the defined public keys to the voters. Other information, such as the voting cost, the voting deadline, and the transaction ID of the token issuance transaction 500, may be included in the distributed voting information.

[0147] Each voter wishing to participate in the vote defines an input-output pair indicating their chosen voting option and providing a signature for using the voting token along with any required sighash flags, which are sent to the voting coordinator's device, which receives the input-output pair in step S918.

[0148] Once the deadline for casting a vote has passed or all votes have been received, the voting coordinator verifies that the required number of participants have submitted input-output pairs and that the inputs include an outpoint identifying the token issued for the vote. If these voting conditions are met, the voting coordinator generates a voting transaction 600, 700 in step S920 that includes all received input-output pairs. If an invalid input-output pair is received, for example, if it is received from a party not eligible to vote or if the token was not used to vote, the invalid input-output pair can be ignored and discarded.

[0149] In step S922, the voting transaction 600, 700 is received by the blockchain node, which validates the transaction in step S924 and publishes the transaction to the blockchain in step S926.

[0150] Once issued, the voting coordinator can access the voting data in step S928. If each voting option is associated with a different public key, the voting data or results can be determined by accessing the different addresses associated with the public keys. The amount of UTXO at each address, or the amount received at that address as a result of the voting transaction 600, 700, is proportional to the number of votes received for each voting option, including the vote weight. This provides an efficient and accurate method of vote counting.

[0151] Alternatively, the voting data can be accessed by accessing the voting transaction 600, 700 itself stored on the blockchain, which provides a way to view the data in OP_RETURN. Votes cast using OP_RETURN are counted by the voting coordinator or its computing device.

[0152] The voting coordinator can then distribute the voting results to the voters in step S930.

[0153] Publishing votes on the blockchain as described above makes it easier to track voting results and voting participants, and because votes are immutable, the results are more reliable than manually counted votes.

[0154] The term "voting coordinator" is used above to refer to both a user controlling a user device and a computer program running on the user device configured to implement the steps of the method on the computer device.

[0155] It is understood that some of the steps of the method of Figure 9 may be implemented in a different order or simultaneously. For example, step S904 of defining voters may be the first step or may be performed simultaneously with step S902. Step S902 of defining voting options may not be performed until step S914, after the token has been received by the voter. Other alternative orderings of method steps will be apparent to those skilled in the art.

[0156] 10 illustrates an exemplary method for voting by a voter. The method is implemented on the voting party's user device by executing a computer program on the device's processor. The voter provides input using client application 300.

[0157] In step S1002, voting instructions are received from a voting coordinator. The voting instructions include voting options defined by the voting coordinator and public keys associated with the voting options. In step S1004, the voting options are rendered as user selections 301 on the display of the user device.

[0158] The user selects or enters a voting option of their choice, and this selection is detected in the UI 300 in step S1006.

[0159] In step S1008, a public key associated with the selected voting option is determined using the received voting instructions.

[0160] In step S1010, an input-output pair for the voter's vote is generated: the input includes the outpoint and the party's signature with the single signature flag, and the output includes the public key associated with the voting option selected by the user and the required digital asset amount.

[0161] The user device then sends the input-output pair to the voting coordinator for inclusion in the voting transaction, step S1012.

[0162] If the voting coordinator also generates a voting token, the voting instructions include information about the token, such as an outpoint identifying the token and the value of the vote (if the voter can divide the token and cast multiple votes). The input generated by the user device in step S1010 includes an outpoint identifying the token, and the output includes a value proportional to the number of votes the party wants to allocate to the selected voting option.

[0163] However, if no tokens are minted, the voting instructions include the cost of the vote, and the input includes an outpoint that identifies a UTXO with a value equal to the cost.

[0164] If only one public key is associated with the vote, step S1008 of determining the public key is deleted from the method and the output includes the one public key associated with the vote.

[0165] As previously mentioned, a voter may be able to input user-defined comments or voting options in the form of voter-provided text via data entry field 302 of UI 300. The voter-provided text is included in the output for inclusion in the OP_RETURN of the vote transaction.

[0166] Transform Anonymity: In the setup described here, voters know the ID associated with each voting token, so that parties' voting choices can be identified once the final transaction is broadcast. However, secret voting can occur if the coordinator does not need to publicly identify which tokens were issued to each voter, and tokens are issued to addresses not yet publicly linked to voters.

[0167] Reusable / Transferable Votes: Instead of indicating a vote via an output address, the voting choice can also be represented in the output's OP_RETURN data. This allows tokens to be assigned to the same user (by setting the output address as unique) and allows them to be reused in subsequent votes. This streamlines the process in situations where the same set of parties are expected to vote regularly, as it removes the need for the coordinator to issue tokens for each vote. This also provides a voting history for each member (which can be abstracted from the voter's ID, as described above, if desired). The system allows votes to be transferable: if a voter appoints a proxy to vote, they can transfer their tokens to the proxy's address on their behalf.

[0168] Weighting: Votes do not have to be distributed equally among voters. Tokens can be issued in a weighted manner, for example to implement hierarchies based on seniority or investment. Weighting can be implemented via the number of tokens issued to each user, or by issuing a single token of variable value to each voter. When tokens are issued in variable amounts, voters can divide their tokens to vote for multiple options, with one vote having a predefined value. Thus, voters with more power can decide whether to vote for multiple options, one option with greater weight, or a combination of the two.

[0169] Granular Voting: When multiple tokens are issued per voter (whether these are weighted or equal among members), this gives voters the opportunity to divide their votes to indicate their preferences. For example, out of 10 tokens, a voter could choose to allocate 8 to option A, 0 to option B, and 2 to option C.

[0170] Special tokens: Tokens with special conditions can be issued. For example, veto tokens can be issued to senior members of a group. These can be sent instead of (or in addition to) regular tokens and may have the effect of, for example, invalidating the entire vote or selected voting options. Special tokens can be identified by the voting coordinator or smart contract based on the UTXO, and the terms of use can be written in OP_RETURN when the token is created.

[0171] Embedding additional information: Including data in the OP_RETURN of each output allows for more nuanced responses than simply choosing between a predefined set of options. This space can be used to allow optional comments on the voting choice or, more formally, to request feedback from each voter. For example, in academic research, many journals require peer review by multiple independent experts before approving a paper for publication. This can be implemented with voting as described here, with the output address reflecting the overall recommendation (reject, revise, resubmit, accept, etc.) and OP_RETURN providing space for full comments. The transaction representing the manuscript decision is not valid until all reviewers have returned their votes and comments, providing an immutable record of the decision-making process. Alternatively, if feedback is required, for example, a vote can be defined such that the voting coordinator does not provide a voting option, but the voter provides one in OP_RETURN. In this case, only one address needs to be defined for the vote, and all vote values ​​are sent to that address.

[0172] Multipurpose Voting Token Transaction: A token issuance transaction can include additional information in the lock script associated with each token, provided in the transaction's OP_RETURN. This additional information can be voting instructions. When a token issuance transaction is issued and a user signals that a token has been issued, a program on the voter's device accesses the voting instructions provided in OP_RETURN and renders the appropriate information to the user. This allows the voting instructions to be immutably stored when a token is issued.

[0173] Token / Voter Checking Software: Software such as the client application 105 on the voter or voting coordinator device may be responsible for checking whether a voter is eligible to vote and / or whether the correct sighash flag was used. To check voter eligibility, the software can check that the signature of the input-output pair is associated with an eligible voter. For example, it can compare it to a list of eligible voters or, if a token is issued, check that a valid token is used. The software can check the sighash flag used against predefined sighash rules stored in a program or the like, or against sighash flag conditions defined in the token issuance transaction. In this scenario, a sighash flag condition can be defined in the OP_RETURN of the token issuance transaction, which is accessed by the software when checking the sighash flag used against the requirement. The input-output pair is then only sent to the voting coordinator or included in the voting transaction if the criteria are met, so that a missing input-output pair invalidates the voting transaction.

[0174] The signing procedure above provides a comprehensive example of how multiple sighash flags can be combined to realize an advanced signing system. In particular, the system described here provides individuals with the opportunity to collaborate on joint transactions without compromising their independence. It also outlines how the exchange of partially formed, partially signed transactions can serve as a form of communication in place of the preliminary dialogue required when signing sighash ALL, significantly streamlining the signing procedure.

[0175] <Conclusion> Other variations or uses of the disclosed technology may become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0176] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchain, blockchain network, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0177] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there are other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0178] In other embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to generate and publish blocks 151 but does not store and / or propagate the blocks 151 to other nodes.

[0179] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such entities / elements are configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0180] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided in accordance with any one or more of the following:

[0181] (Statement 1) A computer program for generating inputs and outputs of a blockchain voting transaction for conducting a vote, the computer program being stored on a non-transitory medium and, when executed by one or more computer processors, causing the one or more processors to: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; controlling a display to render a user interface displaying said set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair for inclusion in the voting transaction with one or more other input-output pairs at different indices of the voting transaction; So, a non-signed portion of an input of the input-output pair including an outpoint identifying an unspent transaction output of a blockchain transaction; a signed portion of the input including a signature single flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction; and the output of the input-output pair including one of the one or more public keys of the voting instructions.

[0182] (Statement 2) The computer system of statement 1, wherein the one or more processors are further configured to send the input-output pair to the voting coordinator to generate the voting transaction.

[0183] (Statement 3) The computer program of Statement 1 or 2, wherein each voting option of the set of voting options is associated with a different public key, the one or more processors are further configured to determine a public key associated with a selected voting option, and the output includes the determined public key.

[0184] (Statement 4) A computer system described in any of Statements 1 to 3, wherein the voting instructions further include a voting token that identifies an unspent transaction output, and an outpoint of an input of the input-output pair identifies the voting token.

[0185] (Statement 5) The computer program of any of Statements 1 to 4, wherein the input-output pair is associated with one voter of a predefined set of voters, a subset of the predefined set of voters is required to generate each input-output pair, and the single signature flag is a single-anyone can pay signature flag such that the signature signs only the input and output of the input-output pair and does not sign any other input or output of the voting transaction.

[0186] (Statement 6) The computer program of any of Statements 1 to 5, wherein the one or more processors are further configured to receive a user-defined input including information to include in OP_RETURN, and the output of the input-output pair further includes the information.

[0187] (Statement 7) A computer program for generating a voting transaction of a blockchain, the computer program being stored on a non-transitory medium and, when executed by one or more processors, causing the one or more processors to: receiving a plurality of input-output pairs according to any one of statements 1 to 6; Generate a voting transaction, The voting transaction is For each voting index in the set of voting indices, there is one of the received input-output pairs, In the authorization index, there is an input consisting of the voting coordinator's signature with the all signature flag, such that the voting coordinator's signature signs all inputs and outputs of the voting transaction; Output and Including, Sending the voting transaction to a blockchain; A computer program configured to:

[0188] (Statement 8) The computer program of statement 7, wherein the one or more processors are further configured to determine whether a predefined number of input-output pairs have been received.

[0189] (Statement 9) The one or more processors: Generate voting instructions; rendering the voting instructions accessible to a user device of each voter in the set of voters; The process of generating the voting instructions is configured to: Detecting a user input initiating a vote; associating at least one public key with said vote; 9. The computer program according to statement 7 or 8, comprising:

[0190] (Statement 10) The computer program of Statement 9, wherein the one or more processors are configured to generate a set of tokens, each token in the set of tokens being an unspent transaction output associated with one of the voters in the set of voters.

[0191] (Statement 11) The computer program of statement 10, wherein the voting instructions include a token associated with a recipient voter of a computing device on which the voting instructions are accessible.

[0192] (Statement 12) The computer program according to statements 7 to 11, wherein the one or more processors are further configured to access an address of each of the at least one public key.

[0193] (Statement 13) The computer program described in Statements 7 to 12, wherein the one or more processors are further configured to access the voting transaction after the voting transaction has been validated by the blockchain node.

[0194] (Statement 14) The one or more processors are further configured to determine whether the unspent transaction output indicated by the outpoint of the received input-output pair is sufficient to cover the transaction fee; 14. The computer program of any of statements 7 to 13, wherein if the unspent transaction output is not sufficient to cover the transaction fee, an authorization index input includes an outpoint indicating sufficient unspent transaction output to cover the amount of the transaction fee not covered by the input-output pair.

[0195] (Statement 15) The computer program of any of Statements 1 to 14, wherein the unspent transaction output identified by the outpoint of the input of the input-output pair has a value proportional to the number of votes, with one vote having a predefined value.

[0196] (Statement 16) The token is associated with a lock script that defines a signature flag that must be used when signing unsigned portions of an input containing the token. A computer program according to Statement 4 or 11, any of Statements 5-6 that depend from Statement 4, or any of Statements 12-15 that depend from Statement 11.

[0197] (Statement 17) A blockchain transaction embodied on a computer-readable medium, Inputs for effectively consuming the available transaction outputs indicated within the blockchain transaction inputs; at least one output including a lock script defining signature requirements and required signature flags, which when concatenated with an unlock script in a subsequent blockchain transaction validates the signature of the unlock script, extracts used signature flags from the unlock script, compares the used signature flags with the required signature flags, and invalidates the subsequent blockchain transaction if the used signature flags do not match the required signature flags and / or the signature is invalid; Blockchain transactions, including:

[0198] (Statement 18) The blockchain transaction of Statement 17, wherein the signature flag is indicated by the last byte of the signature, and the step of comparing the used signature flag with the required signature flag includes comparing the last byte of the signature with a value indicating the required signature flag defined in the lock script, and when the last byte of the signature is equal to the value indicating the required signature flag, the used signature flag and the required signature flag match.

[0199] (Statement 19) The blockchain transaction of Statement 17 or 18, wherein the tokens are for use in a voting transaction and the spendable output has a value proportional to the number of votes.

[0200] (Statement 20) The blockchain transaction described in any of Statements 17 to 19, wherein the blockchain transaction includes outputs associated with each party of a set of authorized parties, and the authorized parties are authorized to provide inputs and outputs for subsequent blockchain transactions.

[0201] (Statement 21) The blockchain transaction of Statement 20, wherein a subset of the set of authorized parties is required to provide inputs and outputs for the subsequent blockchain transaction, and the required signature flag is a single-anyone can pay signature flag to authorize only inputs and outputs provided at the same index in the subsequent blockchain transaction.

[0202] (Statement 22) The blockchain transaction of Statement 20, wherein all parties in the set of authorized parties must provide inputs and outputs for the subsequent blockchain transaction, and the required signature flag is a single-all signature flag to authorize all inputs and only outputs at the same index as a provided unlock script for the subsequent transaction.

[0203] (Statement 23) The blockchain transaction of any of Statements 17 to 22, wherein the blockchain transaction is a token issuance transaction and the output of the token issuance transaction defines a nominal amount of digital assets sufficient solely to record the blockchain transaction on a blockchain.

[0204] (Statement 24) A method for generating inputs and outputs of a blockchain voting transaction for voting, the method comprising: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; rendering a user interface displaying the set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair for inclusion in the voting transaction with one or more other input-output pairs at different indices of the voting transaction; Including, the non-signed portion of the input of the input-output pair includes an outpoint identifying an unspent transaction output of a blockchain transaction, the signed portion of the input includes a signature single flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction, and the output of the input-output pair includes one of the one or more public keys of the voting instructions.

[0205] (Statement 25) A method for generating a voting transaction of a blockchain, the method comprising: receiving a plurality of input-output pairs according to any of the preceding statements; generating a voting transaction, said voting transaction comprising: For each voting index in the set of voting indices, one of the received input-output pairs, and In the authorization index, there are inputs and outputs containing the voting coordinator's signature with the all signature flag, so that the voting coordinator's signature signs all inputs and outputs of the voting transaction. and sending the voting transaction to a blockchain; A method comprising:

[0206] (Statement 26) A computer system, at least one computing device configured to execute a computer program according to any of statements 1 to 6 or statement 16 dependent on statement 4; at least one computing device configured to execute the computer program according to statements 7 to 15, or statement 16 dependent on statement 7; A computer system comprising:

[0207] (Statement 27) A computer program for generating a blockchain transaction, the computer program being stored on a non-transitory medium and, when executed by one or more processors, configuring the one or more processors to generate the blockchain transaction, the blockchain transaction comprising: an input for effectively consuming the spendable transaction outputs indicated in the input of the blockchain transaction; at least one output including a lock script defining signature requirements and required signature flags, which when concatenated with an unlock script in a subsequent blockchain transaction validates the signature of the unlock script, extracts used signature flags from the unlock script, compares the used signature flags with the required signature flags, and invalidates the subsequent blockchain transaction if the used signature flags do not match the required signature flags and / or the signature is invalid; a computer program comprising:

[0208] Appendix A: This section describes SCRIPT code that can be added before the standard P2PKH locking script to create an additional check that a UTXO is signed with a specific sighash flag when it is spent.

[0209] Digital signatures created using ECDSA and encoded for Bitcoin transactions begin with a byte indicating the length of the signature sequence and end with a byte indicating the sighash flag. For example, a signature totaling 47 bytes signed with the SINGLE|ACP flag would end with 0x47 <sig>83. To check if a particular sighash flag was used when signing, check that the last byte of the signature is equal to a particular value.

[0210] In this example, we assume that the lock script following the sighash check code is a P2PKH script. Therefore, the unlock script is <sig> where both items are pushed onto the stack before the lock script is executed.

[0211] The next lines represent the items on the stack, from bottom (left) to top (right), with each item enclosed in square brackets. Indented blue text indicates the next opcode. Each opcode is followed by a brief description of its function the first time it is used.

[0212] The unlock script pushed the signature and associated public key onto the stack:

number

Claims

1. A computer program for generating inputs and outputs of blockchain voting transactions for conducting voting, the computer program being stored on a non-transitory medium and, when executed by one or more computer processors, causing the one or more processors to: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; controlling a display to render a user interface displaying said set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair for inclusion in a voting transaction with one or more other input-output pairs at different indices of the voting transaction; So, a non-signed portion of an input of the input-output pair including an outpoint identifying an unspent transaction output of a blockchain transaction; a signed portion of the input including a single signature flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction; and the output of the input-output pair including one of the one or more public keys of the voting instructions.

2. The computer program product of claim 1 , wherein the one or more processors are further configured to send the input-output pair to the voting coordinator to generate the voting transaction.

3. 3. The computer program of claim 1, wherein each voting option in the set of voting options is associated with a different public key, and the one or more processors are further configured to determine a public key associated with a selected voting option, and the output includes the determined public key.

4. 4. The computer program product of claim 1, wherein the voting instructions further include a voting token that identifies an unspent transaction output, and an outpoint of an input of the input-output pair identifies the voting token.

5. 5. The computer program product of claim 1, wherein the input-output pair is associated with one voter from a predefined set of voters, a subset of the predefined set of voters is required to generate each input-output pair, and the single signature flag is a single-anyone can pay signature flag such that the signature signs only the input and output of the input-output pair and does not sign any other input or output of the voting transaction.

6. 6. The computer program product of claim 1, wherein the one or more processors are further configured to receive a user-defined input, and wherein an output of the input-output pair further includes information of the user-defined input and an opcode for disabling the output.

7. 1. A computer program for generating voting transactions for a blockchain, the computer program being stored on a non-transitory medium and, when executed by one or more processors, causing the one or more processors to: receiving a plurality of input-output pairs according to any one of claims 1 to 6; Generate a voting transaction, The voting transaction is For each voting index in the set of voting indices, one of the received input-output pairs and In the authorization index, inputs and outputs containing the voting coordinator's signature with the all signature flag, so that the voting coordinator's signature signs all inputs and outputs of the voting transaction. Including, Sending the voting transaction to a blockchain; A computer program configured to:

8. 8. The computer program product of claim 7, wherein the one or more processors are further configured to determine whether a predefined number of input-output pairs have been received.

9. the one or more processors: Generate voting instructions; rendering the voting instructions accessible to a user device of each voter in the set of voters; It is configured as The process of generating the voting instructions includes: Detecting a user input initiating a vote; associating at least one public key with said vote; 9. A computer program according to claim 7 or 8, comprising:

10. 10. The computer program product of claim 9, wherein the one or more processors are configured to generate a set of voting tokens, each voting token in the set of voting tokens being an unspent transaction output associated with one of the voters in the set of voters.

11. 11. The computer program product of claim 10, wherein the voting instructions include a voting token associated with a recipient voter of a computing device on which the voting instructions are accessibly rendered.

12. The computer program product of any of claims 9 to 11, wherein the one or more processors are further configured to access an address of each of the at least one public key.

13. 13. The computer program product of claim 7, wherein the one or more processors are further configured to access the voting transaction after the voting transaction has been validated by a blockchain node.

14. the one or more processors are further configured to determine whether the unspent transaction output indicated by the outpoint of the received input-output pair is sufficient to cover the transaction fee; 14. The computer program of claim 7, wherein if the unspent transaction output is not sufficient to cover the transaction fee, an input of an authorization index includes an outpoint indicating sufficient unspent transaction output to cover the amount of the transaction fee not covered by the input-output pair.

15. 15. The computer program of claim 1, wherein an unspent transaction output identified by an outpoint of an input of the input-output pair has a value proportional to the number of votes, one vote having a predefined value.

16. A computer program according to any one of claims 4, 10, claims 5-6 depending on claim 4, or 11-15 depending on claim 10, wherein the voting token is associated with a lock script that defines a signature flag that must be used when signing an unsigned portion of an input that includes the voting token.

17. A blockchain transaction embodied on a computer-readable medium, comprising: Inputs for effectively consuming the available transaction outputs indicated within the blockchain transaction inputs; at least one output including a lock script defining signature requirements and required signature flags, which when concatenated with an unlock script in a subsequent blockchain transaction causes a computer to perform the steps of: validating the signature of the unlock script; extracting a used signature flag from the unlock script; and comparing the used signature flag with the required signature flag, such that if the used signature flag does not match the required signature flag and / or the signature is invalid, the subsequent blockchain transaction is invalid; Blockchain transactions, including:

18. 18. The blockchain transaction of claim 17, wherein the signature flag is indicated by the last byte of the signature, and wherein the step of comparing the used signature flag with the required signature flag includes comparing the last byte of the signature with a value indicating the required signature flag defined in the lock script, and wherein the used signature flag and the required signature flag match if the last byte of the signature is equal to the value indicating the required signature flag.

19. A blockchain transaction as described in claim 17 or 18, wherein voting tokens are used in voting transactions and the usable output has a value proportional to the number of votes.

20. 20. The blockchain transaction of any of claims 17 to 19, wherein the blockchain transaction includes outputs associated with each party of a set of authorized parties, the authorized parties being authorized to provide inputs and outputs for subsequent blockchain transactions.

21. 21. The blockchain transaction of claim 20, wherein a subset of the set of authorized parties is required to provide inputs and outputs for the subsequent blockchain transaction, and the required signature flag is a single-anyone can pay signature flag for authorizing only inputs and outputs provided at the same index in the subsequent blockchain transaction.

22. 21. The blockchain transaction of claim 20, wherein all parties in the set of authorized parties are required to provide inputs and outputs of the subsequent blockchain transaction, and the required signature flag is a single-all signature flag to authorize only all inputs of the subsequent transaction and outputs at the same index as a provided unlock script.

23. 23. The blockchain transaction of any of claims 17 to 22, wherein the blockchain transaction is a token issuance transaction, and an output of the token issuance transaction defines a nominal amount of a digital asset sufficient solely to record the blockchain transaction on a blockchain.

24. A method for generating inputs and outputs of a blockchain voting transaction for voting, the method comprising: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; rendering a user interface displaying the set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair to include in the voting transaction with one or more other input-output pairs at different indices of the voting transaction; Including, a non-signed portion of an input of the input-output pair including an outpoint identifying an unspent transaction output of a blockchain transaction; a signed portion of the input including a single signature flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction; and the output of the input-output pair including one of the one or more public keys of the voting instructions.

25. 1. A method for generating a voting transaction for a blockchain, the method comprising: receiving a plurality of input-output pairs according to any one of claims 1 to 6; generating a voting transaction, said voting transaction comprising: For each voting index in the set of voting indices, one of the received input-output pairs, and In the authorization index, there are inputs and outputs containing the voting coordinator's signature with the all signature flag, so that the voting coordinator's signature signs all inputs and outputs of the voting transaction. and sending the voting transaction to a blockchain; A method comprising:

26. 1. A computer system comprising: a first at least one computing device configured to execute a computer program for generating inputs and outputs of a blockchain voting transaction for conducting a vote, the computer program being stored on a non-transitory medium and, when executed by the first at least one computing device, causing the first at least one computing device to: receiving voting instructions from a voting coordinator, the voting instructions including one or more public keys and a set of voting options defined by the voting coordinator; controlling a display to render a user interface displaying said set of voting options; receiving a user selection of one voting option from the set of voting options defined by user input at the user interface; generating an input-output pair for inclusion in a voting transaction with one or more other input-output pairs at different indices of the voting transaction; So, a first at least one computing device, wherein a non-signed portion of an input of the input-output pair includes an outpoint identifying an unspent transaction output of a blockchain transaction, a signed portion of the input includes a single signature flag and an associated signature that signs at least the non-signed portion of the input-output pair and the output of the input-output pair but not other outputs of the voting transaction, and the output of the input-output pair includes one of the one or more public keys of the voting instructions; and a second at least one computing device configured to execute a computer program for generating a voting transaction for a blockchain, the computer program being stored on a non-transitory medium and, when executed by the second at least one computing device, causing the second at least one computing device to: It receives multiple input-output pairs, Generate a voting transaction, The voting transaction is For each voting index in the set of voting indices, one of the received input-output pairs and In the authorization index, inputs and outputs containing the voting coordinator's signature with the all signature flag, so that the voting coordinator's signature signs all inputs and outputs of the voting transaction. Including, Sending the voting transaction to a blockchain; and at least one second computing device configured to: A computer system comprising:

27. 1. A computer program for generating a blockchain transaction, the computer program stored on a non-transitory medium, the computer program, when executed by one or more processors, configuring the one or more processors to generate the blockchain transaction, the blockchain transaction comprising: an input for effectively consuming the spendable transaction outputs indicated in the input of the blockchain transaction; at least one output including a lock script defining signature requirements and required signature flags, which when concatenated with an unlock script in a subsequent blockchain transaction validates the signature of the unlock script, extracts used signature flags from the unlock script, compares the used signature flags with the required signature flags, and invalidates the subsequent blockchain transaction if the used signature flags do not match the required signature flags and / or the signature is invalid; a computer program comprising:

Images