Access Control Using Transactions

Abstract

1. A method performed by a first party, the method comprising: receiving information of a first blockchain transaction from a second party, the first blockchain transaction including an input and an output, the input of the first blockchain transaction including a signature of the second party, and the output of the first blockchain transaction being locked to the public key of the first party; performing an action including at least one of receiving authorization for access to a product or service, issuing authorization for access to the product or service, providing the product or service, or receiving the product or service; and in response to performing the action, providing the signature of the first party to unlock the output of the first blockchain transaction as part of a first input of the second blockchain transaction.

Description

[Technical Field]

[0001] The present disclosure relates to databases and the use of databases. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in the sequence, which may span one or more blocks 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 often created by a process called "mining," which involves multiple nodes competing to solve a cryptographic puzzle based on a "proof-of-work"—a representation of a defined set of ordered, confirmed, pending transactions awaiting inclusion in a new block on the blockchain. Note that the blockchain may be pruned at some nodes, and the publication of blocks may be achieved simply by publishing the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: transferring digital assets (i.e., some digital tokens), ordering a collection of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or time-ordering index pointers. Blockchains can also be utilized to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storing additional user data or indexes to data in transactions. There is no predefined limit on the maximum amount of data that can be stored in a single transaction, and thus, more and more complex data can be incorporated. For example, this may be used to store electronic documents, audio, or video data on a blockchain.

[0004] 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. Every spendable output includes an element specifying the amount of a digital asset derivable from the ongoing sequence of transactions. A spendable output is sometimes called a UTXO ("unspent transaction output"). An output may further include a locking script that specifies the conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to approve and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Consider a pair of transactions, called 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 that includes a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

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

[0006] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by looking backwards at the UTXOs of previous transactions in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain.

[0007] Translucent Database Translucent databases are a type of database architecture developed by Peter Wayner in Translucent Databases 2002 to describe techniques for designing privacy-preserving databases at the cost of low complexity. ndThis term was introduced in "Edition: Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy - January 8, 2009." A common example of a translucent database is the Linux password file. Instead of the plaintext password, a salted hash of the user's password is stored. To grant access, the user enters their password into the system, which hash it and compares it to the one it stores. Only the user knows the password. The system keeps the salted hash, not the preimage (i.e., the plaintext password). Anyone other than the password owner must guess the preimage. Since anyone with access to the password file finds only the hash, the system is more secure against insider attacks. Thus, the main idea is to store hash(password) and use that hash(password) to grant access, rather than the password itself.

[0008] Merkle proof It has been shown that a Merkle proof of a transaction proves the existence of the transaction on the blockchain and the existence of transactions whose outpoints are consumed in the transaction. Figure 3 shows an example transaction graph. As shown in Figure 3, transaction tx i There are two input outpoints j = txID j |index and outpoint k = txID k |If it has index, tx i The Merkle proof of i is a confirmed transaction on the blockchain. iIf the existence of is proven and its raw transaction form is provided, this is tx j and tx k We also prove the existence of transaction tx i is called a child transaction, and transaction tx j , tx k is called the parent transaction. Furthermore, the raw transaction form tx j If available, this is the tx j We also prove the existence of all parent transactions of

[0009] In Figure 3, transactions are represented by circles. Arrows point from parent transactions to child transactions (e.g., tx i , tx j and tx k (child of ). tx m , tx l , tx j , tx k To prove the existence of , we do not need to provide a Merkle proof for each transaction. Instead, we can provide a i Merkle proof of tx i , tx j , and tx l We only need to provide the raw transaction form of tx k and tx m Note that we do not need the raw transaction form, only their txID (the transaction hash). l Proving the existence of tx n Note also that we do not prove the existence of

[0010] Three-party key generation When two parties, Alice and Bob, want to communicate secretly, they use the Diffie-Hellman key exchange protocol to negotiate a secret key, K symmetricIn this situation, Alice and Bob have a public-private key pair (s A , K A = s A G) and (s B , K B = s B G), and K A , K. B , G is a point on the elliptic curve.

[0011] Alice and Bob can generate the asymmetric keys in one round of communication. 1. Alice sends Bob her public key K A Send 2. Bob sends his public key K to Alice. B Send Alice is K symmetric = s A K B Calculate the symmetric key using Bob is K symmetric = s B K A Calculate the symmetric key using The symmetric key is K symmetric = s A K B = s B K A = s A s B G. Note that Alice and Bob never shared their private keys at any point. Note also that we assume that channel integrity is preserved, i.e., Alice and Bob have securely obtained each other's public keys.

[0012] To enable three-party key generation between Alice, Bob, and Charly, we can optionally use the three-party key agreement protocol DHP. For example, the symmetric key is K symmetric = s A s B s C G = s B sC K A = s A s B K C = s A s C K B This can be calculated in two rounds. 1. In the first round: a. Alice tells Bob A Send b. Bob gives Charly a K B Send c. Charly gives Alice K C Send 2. In the second round: a. Alice tells Bob A K C and Bob sends it to K symmetric = s B s A K C can be calculated b. Bob tells Charly B K A and Charly sent it to K symmetric = s C s B K A can be calculated c. Charly tells Alice C K B and Alice sends it to K symmetric = s A s C K B can be calculated At the end of the second round, each party can compute a symmetric key, and note that the private key is not shared.

[0013] The encryption key

number

[0014] Here, each of the three participants is K symmetric To compute ∑ k = 1 ⁢ ⁢ ⁢ k ⁢ ... k ⁢ ⁢ ⁢ ⁢ k ⁢ ⁢ ⁢ k ⁢ ⁢ ⁢ k ⁢ ⁢ ⁢ k � Summary of the Invention [Means for solving the problem]

[0015] According to one aspect disclosed herein, a method is provided that is executed by a first party. The method includes receiving information of a first blockchain transaction from a second party, the first blockchain transaction including an input and an output, the input of the first blockchain transaction including a signature of the second party, and the output of the first blockchain transaction being locked to the public key of the first party. The method may also include performing an action including at least one of receiving authorization for access to a product or service, issuing authorization for access to the product or service, providing the product or service, or receiving the product or service. The method may also include providing the signature of the first party to unlock the output of the first blockchain transaction as part of a first input of the second blockchain transaction in response to the execution of the action.

[0016] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made by way of example only to the accompanying drawings, in which: [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2]FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 2 illustrates an exemplary transaction graph. [Figure 4] FIG. 2 illustrates an exemplary transaction graph. [Figure 5] FIG. 2 illustrates an exemplary transaction graph. [Figure 6] FIG. 2 illustrates an exemplary stream of events. [Figure 7] FIG. 2 illustrates an exemplary stream of events. [Figure 8] FIG. 1 illustrates an exemplary method for creating a child-of-all transaction. [Figure 9] FIG. 1 illustrates an exemplary method. DETAILED DESCRIPTION OF THE INVENTION

[0018] 1. Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, 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 near-complete graph. Thus, each blockchain node 104 is tightly connected to the other blockchain nodes 104.

[0019] Each blockchain node 104 includes a peer computing device, with different ones of the 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 field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units employing 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.

[0020] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing all of the blockchain 150. Instead, the blockchain 150 may be pruned, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain includes one or more transactions 152, with a transaction in this context referring 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 an amount representing the amount of digital assets as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backward to the output of a previous transaction 152, thereby linking the transactions.

[0021] Each block 151 also contains a block pointer 155 that points back to previously created blocks 151 in the chain, defining a chronological order up to block 151. Each transaction 152 (other than coinbase transactions) contains a pointer back to the previous transaction, defining an order in the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0022] A blockchain node 104 may be configured to forward a transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 throughout the network 106. A blockchain node 104 may be configured to create a block 151 and store a respective copy of the same block 150 in its respective memory. A blockchain node 104 may also maintain an ordered collection (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered collection of transactions that a node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions that attempt to consume the same output.

[0023] For a given current transaction 152j, the (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be fulfilled or "consumed" in the current transaction 152j. Consuming or fulfilling does not necessarily mean the transfer of financial assets, although that is certainly one common use. More broadly, consuming may be described as spending an output or allocating an output to one or more outputs of another onward transaction. In general, a previous transaction may be any transaction within the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be approved for the current transaction to be valid. Thus, "predecessor" herein refers to a predecessor in a logical sequence linked by pointers, and not necessarily to a time of creation or transmission in a temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may also be referred to as an antecedent or predecessor transaction.

[0024] The input of the current transaction 152j also includes the input's 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 the 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 as 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 also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

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

[0026] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role or roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that all actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective 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.

[0027] Further connected to the network 101 are computing devices 102 for each of a number of participants 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in approving transactions or constructing blocks. Some of these users or agents 103 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 participants 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).

[0028] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not fulfill the required role of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. For illustrative purposes, two participants 103 and their respective devices 102 are shown: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many additional such participants 103 and their respective computing devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party" respectively.

[0029] The computing equipment 102 of each participant 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each participant 103 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 employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment 102 of each participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing unit. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each participant 103 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 equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

[0031] The client application 105 includes 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 then submit transactions 152 to one or more Bitcoin nodes 104 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second function involves aggregating the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0032] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; rather, any client function described herein may instead be implemented in a suite of two or more different applications that interface via an API, or where one is a plug-in to the other, for example. More broadly, 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.

[0033] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for which each party 103 is the recipient of any transactions (or, in embodiments, to verify 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 of each computing device 102 is configured to assemble and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve transactions 152 according to the blockchain node protocol and forward transactions 152 to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol 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 by all nodes 104 in the network 106.

[0034] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based system, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a previous transaction backward in a sequence 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 the account's running transaction tally (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be assigned to a transaction. This data field may point backward to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0035] 2. UTXO-based Model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a 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 a limitation to all possible embodiments. Note that the exemplary UTXO-based protocol is described in relation to Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0036] 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 is not already fulfilled). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0037] Suppose Alice 103a wishes to create transaction 152j to send the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." Transaction 152j takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and sends at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 may point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0038] The terms “predecessor” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions within a sequence defined by transaction pointers specified in the transaction (e.g., which transactions point backward to which other transactions). These terms may be equivalently substituted by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which those transactions are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a predecessor transaction (ancestor transaction or “parent”) will not be approved until and unless the parent transaction is approved. A child that arrives at a blockchain node 104 before its parent is considered an orphan. The child may be discarded or buffered for a certain time to wait for its parent, depending on the node protocol and / or node behavior.

[0039] One of the one or more outputs 203 of prior transaction Tx0 includes a particular UTXO, here labeled UTXO 0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the subsequent transaction's input 202 for the subsequent transaction to be approved and, therefore, for the UTXO to be successfully fulfilled.

[0040] 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 what information is required to consume a transaction output 203, for example, the need for Alice's signature. A lock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script's criteria. For example, an unlock script might include Bob's signature. An unlock script appears in the transaction's input 202.

[0041] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must contain Alice's signature Sig P for UTXO0 to be fulfilled (or, more precisely, for any subsequent transaction attempting to fulfill UTXO0 to be valid). A Requires a lock script [Checksig P 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 that points back into Tx0 (e.g., by Tx0's 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, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P AThe data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0042] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria).

[0043] Note that script code is often represented generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, can store data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data on the blockchain 150. For example, the data could include a document that is desired to be stored on the blockchain.

[0044] Generally, the input to a transaction is a public key P A In an embodiment, 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 some or all of the transaction outputs. The specific portions of the outputs that the signature signs depend on the SIGHASH flag, which is a 4-byte code typically included at the end of the signature (and therefore fixed at the time of signing) to select which outputs are signed.

[0045] A lock script may be referred to as a "scriptPubKey," generally referring to the fact that it contains the public key of the party to whom each transaction is locked. An unlock script may be referred to as a "scriptSig," generally referring to the fact that it provides the corresponding signature. However, more broadly, it is not required in all applications of blockchain 150 that the condition for a UTXO to be fulfilled include authenticating the signature. More broadly, a scripting language may be used to define any condition or conditions. Therefore, the broader terms "lock script" and "unlock script" may be preferred.

[0046] 3. Blockchain Database Examples illustrate creating a database securely on a blockchain. In some examples, the database includes a semi-transparent blockchain database. In some examples, the database creates a secret, decentralized system used to access and allocate products / services while also preserving the privacy of participants.

[0047] Some examples relate to medical / pharmaceutical databases used to access and allocate medications.

[0048] The first example (Section 3.1) provides intersecting event streams (sequences of events). Each actor (e.g., doctor, pharmacist, and patient) has its own event stream for their actions, and each event can be recorded in a blockchain transaction. When an interaction occurs between two or more actors, the interaction is mapped as the intersection of the event streams of those actors. The activities of each actor can be tracked by following the transaction graph.

[0049] According to the second example (Section 3.2), the mapping between a sequence of events and blockchain transactions is hidden from public observers. The mapping can be hidden only off-chain or on-chain as well. One way to have an on-chain mapping is to hide the current events

number

number

number

number

number

number

number

number

[0050] The second example improves privacy, but does not allow a person to efficiently prove that an event occurred. When EPTs have a child-parent relationship, proving the existence of a child transaction (by providing its Merkle proof) proves the existence of the parent transaction (without having to provide a Merkle proof of the parent transaction). When EPTs do not have a child-parent relationship, this method cannot be used to prove the existence of a parent transaction, and therefore, in one solution, a Merkle proof for each EPT may be provided to prove existence. In some examples, a child-of-all transaction tx that consumes outgoings from each EPT may be used. coa is created. coa A Merkle proof of tx can be used to prove the existence of all EPTs. coa In some cases, to minimize privacy risks, we combine EPTs of different streams into a single transaction. coa Combine in.

[0051] In the third example (Section 3.4), unspent transaction outputs are used as tokens to control access to a database. Unspent outputs indicate valid tokens, and spent outputs indicate invalid ones. In the example, we show how a patient (owner of the data record) using these tokens can grant access to doctors and pharmacists to view and update the patient's database record. We also show that these tokens can be used to hide the signer's identity.

[0052] 3.1 Intersecting Event Streams ("First Layer Solution") An exemplary graph is shown in Figure 4. The circles represent transactions, and the arrows pointing into and out of the circles represent inputs and outputs, respectively.

[0053] In FIG. 4, four parties 450, 452, 454, and 456 are provided. A signature may be used to authenticate an event. The signature may be included in the transaction's unlock script. Each entity 450, 452, 454, and 456 may have its own blockchain wallet. Each entity 450, 452, 454, and 456 may be able to prove its identity using a registered key pair linked to the entity's identity and role. Party 450 may include a trusted authority (e.g., Kensei). The trusted authority may include a trusted identification and authentication authority. According to some examples, party 452 may include a provider of a product and / or service. According to some examples, party 454 may include a user of a product and / or service. According to some examples, party 454 may include an authorizer of access to the provider and / or service.

[0054] 4, party 450 includes a trusted authority, party 452 includes a pharmacy, party 454 includes a patient, and party 456 includes a doctor. However, it should be noted that these are merely examples, and that in other examples, each party may include a different type of entity.

[0055] Each transaction may publish events. Events may include, for example: 1. Registration: Each actor's public key is paired to that actor's identity. 2. Authorization: The authorizer reviews the consumer's history and issues authorization for the product or service. 3. Collection: The provider checks the consumer's history, checks that the authorization is signed by an authorized actor, and gives the product / service to the consumer. 4. Audit: Auditors check that each actor is performing their duties honestly.

[0056] In a medical example, events may include, for example: 1. Registration: Each actor's public key is paired to that actor's identity. 2. Issuing a prescription: The doctor reviews the patient's history and issues a prescription. 3. Retrieval: The pharmacist checks the patient's history, checks that the prescription is signed by an authorized actor, and gives the prescription to the patient. 4. Audit: Auditors check that each actor is performing their duties honestly.

[0057] Figure 4 shows three registration EPTs (identification and authentication EPTs). The registration event is a transaction

number

[0058] for example,

number

number

number

[0059] Figure 4 shows

number

number

number

number

[0060] Figure 4 shows

number

number

number

number

[0061] In some examples, the retrieved data (e.g., prescription details) may be hidden using OP_RETURN. Following OP_RETURN, the prescription details may be encrypted and inserted in a separate non-consumable output, e.g., OP_FALSE OP_RETURN < cipher > or in the consumable output of the consumer 454, e.g. P2PKH< patient_Address > OP_RETURN < cipher > and cipher = Enc(key, m = < prescription >).

[0062] The encryption can be through the use of a symmetric key-based scheme (e.g., Advanced Encryption Standard (AES)), and a shared encryption key can be determined from a Diffie Hellman key exchange between the consumer 454 and the authorizer 456 or provider 452. The cipher can be decrypted by the consumer 454, authorizer 456, and provider 452. The consumer 454, authorizer 456, and provider 452 can do this using keys derived from the identity public keys of the consumer 454, authorizer 456, and provider 452.

[0063] In some cases, the encryption key is K symmetric = Hash((s patient K dr )|nonce) = Hash((s dr K patient )|nonce), and s patient , s dr is the private key (scalar value) of the consumer 454 and the authorizer 452, and K patient , K. dr are the corresponding public keys (elliptic curve points) of the consumer 454 and authorizer 452. The nonce is a value agreed upon by the patient and physician to ensure that a different encryption key is used for each transaction.

[0064] The public key pair (s, K) used may be chosen to be the same keys used to sign the transaction inputs of those parties.

[0065] It may be that the encryption key also has to be shared with the trusted authority 450 in order to allow access to the provider 452 and / or at least one auditor. In this case we can optionally use the three-party key agreement protocol DHP. For example, the symmetric key is K symmetric = s dr s patient s TA G = s dr s patientK TA = s patient s TA K dr = s dr s TA K patient can be given by

[0066] In other instances, redemption details (e.g. prescription details) are cryptographically hashed and the hash value inserted into the transaction, while the actual details are kept off-chain in a secure database.

[0067] Figure 5 illustrates another example involving an EPT. Figure 5 references a specific example medical context with a doctor 556 (a product / service authorizer), two patients 554a and 554b (product / service consumers), a pharmacy 552 (a product / service provider), and a trusted authority 550. However, it will be understood that the features of Figure 5 may be generalized to any type of EPT with a parent-child relationship. In particular, it will be understood that the features of Figure 5 may be generalized to an example where a product / service is authorized, redeemed / used, and provided.

[0068] When a physician 556 issues a new prescription to a patient 554a or 554b, he or she can track the patient's entire history (issued and redeemed prescriptions) by tracking the patient's transaction graph.

[0069] Similarly, an auditor checking the activities of physician 556 can track physician 556's transaction graph and ensure that all prescriptions are authorized and issued to authorized patients. An auditor checking the activities of pharmacist 552 can track pharmacist 552's transaction graph and ensure that all withdrawn prescriptions are signed by an authorized physician (e.g., physician 556) and given to authorized patients (e.g., patient 554a and / or patient 554b).

[0070] In Figure 5, the related events of each actor can be tracked by following the corresponding transaction graph. Some events involve more than one actor, and therefore there are transactions common to each actor's graph. Figure 5 shows the following four transaction graphs: The transaction graph for Doctor 556 is (connected by solid arrows):

number

number

number

number

[0071] When the pharmacist 552 checks the license and certification of the doctor 556, the graph transaction of the doctor 556 is

number

number

number

number

number

number

number

number

number

number

number

[0072] for example,

number

number

number

number

number

number

number

number

number

number

[0073] A reused nonce impacts the signer's privacy because it allows an observer to link the signer's different messages. A reused nonce may also leak information about the signer's private key. A possible mitigation is to use an unused output as a nonce, in which case its usage status (used / unused) indicates its validity, i.e., nonce = txid|index = outpoint. In such an example, the doctor 556 could, for example,

number

[0074] [Table 1]

[0075] outpoint x When used as a nonce, outpoint x should be consumed, which may be done in the same (or a different) transaction that carries the signature. To illustrate, let the signer sign transaction tx nonce Create an unused output outpoint nonce Then the signer creates an outpoint in one input. nonce A transaction tx that carries a signature that consumes sig Create and tx sig private key, which can be in a separate input unlock script or OP_RETURN Dr + Hash(outpoint nonce ), the latter of which is shown in the table below.

[0076] [Table 2]

[0077] Immunity against replay attacks by guaranteeing the uniqueness of signed messages Note that in some cases, the implicit property of block transactions (which consume outputs exactly once) means that replay attacks are computationally infeasible, since every signed message should contain a string (unspent output) that can be spent exactly once. Therefore, messages signed using the unlock script's signature are immune to replay attacks. If the signature is embedded in the transaction as a separate data string (i.e., after OP_RETURN), the signed message should include the outpoint consumed in the transaction in the form of a nonce, i.e., the signed message includes the outpoint.

[0078] 3.2 "Second Layer Solutions" One undesirable aspect of the solution considered in Section 3.1 is that the activities and interactions of all actors can be tracked by following the actor's transaction graph. For example, in the example in Figure 5, it is relatively easy to track the number of prescriptions given by a doctor since registration, the number of patients of the doctor, and the number of prescriptions issued for each patient. When the solution is applied more broadly, it is relatively easy to know how many authorizations for products / services an authorizer has made, how many consumers the authorizer is responsible for, and how many products / services have been issued by the provider to each consumer. In addition to the privacy aspect, each actor must have a wallet to sign and receive transactions, which introduces an extra layer of complexity.

[0079] In an exemplary "second layer solution," the actor's signature is inserted as data included in the transaction, and the lock and unlock scripts for the transaction (presc, collect, etc.) are generated by a service provider (e.g., Kensei) independently of the actor.

[0080] We assume that the service provider has a cache of unspent transaction outputs (linking transaction outputs) ready to be used in creating events-carrying transactions.

[0081] It is expected that most of these linked transaction outputs will be easily linked to service providers, which may pose a privacy risk in some cases. However, privacy can be preserved by scaling. The increasing number of events and clients makes it more difficult for an outsider to associate which transaction carries which event for which client.

[0082] Actor Event Links An actor (which may be a product / service licenser, a product / service consumer, a product / service provider, or in a medical context, a doctor, a patient, or a pharmacist)

number

number

number

number

number

number

number

number

number

[0083] As shown in FIG. 6, when a first party performs a first action e1, a first signature of the first party is added to a first event transaction.

number

number

number

[0084] Second Event Transaction

number

[0085] The off-chain solution is to use the records e1, e2, and e3 of the actors.

number

[0086] Events where the service provider is not involved

number

number

[0087] In some instances, forged events are inserted into transactions in a way that does not allow an attacker to determine genuine information from the false and forged data. These instances employ misdirection to confuse potential attackers.

[0088] 3.3 Proving the Existence of an Event Two methods of mapping events from an event stream to blockchain transactions are discussed above. 1. Event Publishing Transactions (EPTs) are linked such that one consumes the other. An example of this was shown in 3.1 (First Layer Solution). In this case, all EPTs in an event stream are linked by child-parent relationships, so it is possible to track events by tracing the transaction graph. In Figure 9, the Event

number

number

[0089] When providing a proof of the existence of an event, we provide a second party with a Merkle proof of that event's EPT and the raw transaction itself, indicating the event data (or the event hash, if the event hash is what is publicly available). If the EPT of an event stream has a child-parent relationship, we can replace the Merkle proofs of all transactions by providing only the Merkle proofs of the most recent child transactions. When the number of events is large, this can be a welcome optimization. To illustrate (see Figure 7), if we want to prove the existence of events e1 through e4, the following may be provided: 1.

number

number

number

[0090] However, if the EPTs are not linked in a child-parent relationship, the following may need to be provided: 1. Merkle Proof of Each EPT 2. Raw transactions for each EPT

[0091] It is possible to reduce the size of the proof by creating a transaction that consumes outputs from all EPTs. We call this transaction the child-of-all transaction (tx coa ) or event summary transaction—see Figure 8. In this case, every event can be proven by providing: 1. TX coa Merkle proof of 2. TX coa Raw transaction format 3. Raw transactions for each EPT

[0092] This reduces the size of the proof. This solution links all EPT transactions on the blockchain. To address privacy concerns, misleading techniques can be employed (e.g., fake EPTs are distributed along with real EPTs in tx coa can be used to provide

[0093] In some cases, tx coacan consume the outputs from all EPTs from all the different streams. Using a service provider (such as Kensei) that publishes events from different streams in blockchain transactions, it is possible to provide some degree of privacy using this method. In Figure 7, we have two event streams A and B. There is no child-parent relationship between any two EPT transactions. We have tx that consumes the outputs of each EPT. coa Event stream A is created as follows:

number

number

[0094] tx coa One advantage of tx coa But, tx coa The EPT is common to all event streams that have an outpoint consumed within tx coa The key feature is that it can be easily shared between different customers of a service provider, much like the block header chain data that must be provided along with a Merkle proof when proving the existence of any transaction.

[0095] However, especially when we want to preserve privacy by combining out-points from EPTs from different streams, tx coa The size of can be very large.

[0096] Additionally, we need to have a consumable output point in each EPT. It is possible to insert event data into a consumable output without having to create a new data-specific output in each EPT. coaOne way to reduce the size of the unlock script is to use the Hash function instead of OP_CHECKSIG. The lock script should be OP_HASH160<RIPEMD160(SHA256(v))> and for this lock script the unlock script can be of the form <v> It is possible for the form

[0097] The minimum length of v should be 128 bits (16 bytes). This reduces the size of the unlock script from 106.5 bytes (used in P2PKH) to just 16 bytes. The average size of a P2PKH input is about 147.5 bytes: 40 bytes to reference the UTXO and sequence number, a 1-byte varint to encode the size of the unlock script, and a 106.5-byte unlock script. The average size is now 57 bytes. This also reduces the size of the lock script (in the EPT) from 25 bytes (for the P2PKH lock script) to about 20 bytes.

[0098] In addition to replacing OP_CHECKSIG with OP_HASH160, the outpoint value (coins) (from each EPT) should be the smallest possible (e.g., 1 satoshi). This is because removing OP_CHECKSIG allows any entity to consume the output in a different transaction. This attack can be performed by tx coa This can only be performed before the time is confirmed. To mitigate this risk, we make the outpoint value very low, so that it is not worthwhile for an attacker to perform such an attack. coa The size of tx coa large enough that it requires consuming P2PKH inputs to fund the transaction and pay the miner's fees. See Table 3.

[0099] Table 3 tx from EPT coa The unlock script for

number

number

number

number

[0100] [Table 3]

[0101] In some cases, time T i Child-of-all transactions in

number

number

number

number

number

[0102] 3.4 Access Control Using Transactions In this section, we assume that we have a database that holds records (eg, patient records).

[0103] In some instances, there are three different actors: Oracle, the patient, and the doctor (or pharmacist). Oracle is responsible for allowing and preventing access to the database. Patients have the right to grant access to their records. Oracle is responsible for enforcing access control. Doctors and pharmacists want to access the data.

[0104] An example use case is a patient granting a doctor (or pharmacist) access to read or edit the patient's record.

[0105] The database contains the patient record and the patient's public key P Pt The patient may prove ownership of the public key by presenting the signature corresponding to the public key to the oracle. The doctor (or pharmacist) is granted access to the patient's record by the oracle only if the patient's signature provided corresponds to the public key. The patient's public key can be used to identify the patient's record. P Pt Instead of Hash(P Pt ) can also be used.

[0106] The patient wants to send an access token to the doctor. The oracle grants access when a valid token is presented. The access token may expire after use.

[0107] A transaction signed by a patient may include a token. The outpoint of the transaction is used to indicate the validity of the token. If the outpoint is unused, the token is valid; otherwise, the token is invalid.

[0108] Outpoint as a database access control token The signed message is the hash of the unspent output m = Hash(outpoint x ), which is consumed by the agent after it grants access. x Once m is consumed, the token is considered expired. See Figure 9. Here, the patient signs a message m and gives it to the doctor (or pharmacist) to grant access. At 851, the doctor / pharmacist sends the signed message m together with the access request to the oracle (access agent). At 853, the oracle checks the patient's signature. At 855, the oracle issues an outpoint x Check that is in the UTXO set and outpoint x If so, the agent will grant access to the doctor / pharmacist in 859 and outpoint in 861. x Consume and outpoint x Remove from the UTXO set. x If is not in the UTXO set, the oracle denies the doctor / pharmacist access at 857.

[0109] Some example options include: a. Output outpoint x can be spent by either the agent or the patient (1 / 2 multisig), which allows either of the two parties to invalidate the token or revoke access. b. The signed message is then converted into a consumable output concatenation m = Hash(outpoint x |outpoint y ), one consumable by the patient and the other consumable by the agent, where access is granted using one of these rules. i. As long as both outputs are unused, access is granted, otherwise it is denied. ii. Access is denied only if both outputs are in use.

[0110] Outpoints as identity-hiding tokens The oracle provides outpoints that can be consumed by agents. T = txid|index may be periodically and safely announced. When communicating with the agent, the patient Pt + Hash(outpoint T ) to sign the message. The agent must know that the corresponding public key is P Pt + Hash(out T ).G or not, and outpoint T In the next time interval, the oracle checks that out T consumes the new unspent output and generates the next token out T+1 Select as.

[0111] 4. Further Special Notes Other variations or use cases of the disclosed technology will be apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0112] For example, some embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply broadly to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More broadly, all references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to 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 described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 above.

[0113] 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 described functions of creating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0114] In other embodiments of the 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 creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or propagate those blocks 151 to other nodes.

[0115] Even more broadly, all references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with blockchain node 104.

[0116] Some embodiments have been described in terms of blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes may lock up their blockchain node's tokens for a specific amount of time in order to have a chance to become a validator. In general, the node that locks up the largest stake for the longest period of time has the greatest chance to become the next validator.

[0117] It will be appreciated that the above embodiments have been described by way of example only. More broadly, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0118] Statement 1: A method performed by a first party, the method comprising: receiving information of a first blockchain transaction from a second party, the first blockchain transaction including an input and an output, the input of the first blockchain transaction including a signature of the second party, and the output of the first blockchain transaction being locked to the public key of the first party; performing an action including at least one of receiving authorization for access to a product or service, issuing authorization for access to the product or service, providing the product or service, or receiving the product or service; and in response to performing the action, providing the signature of the first party to unlock the output of the first blockchain transaction as part of a first input of the second blockchain transaction.

[0119] Statement 2: The method according to Statement 1, where the second party includes a trusted authority.

[0120] Statement 3. The method according to Statement 1 or Statement 2, wherein the second input of the second blockchain transaction includes a signature of a third party.

[0121] Statement 4. The method according to statement 3, wherein the second blockchain transaction includes the first output locked to the public key of the third party.

[0122] Statement 5. The method according to statement 3 or statement 4, wherein the second blockchain transaction includes a second output locked to the first party's second public key.

[0123] Statement 6. The method according to any of statements 3 through 5, wherein the first party includes an authorizer of access to the product or service and the third party includes a user of the product or service, or the first party includes a user of the product or service and the third party includes an authorizer of access to the product or service.

[0124] Statement 7. The method according to any of statements 3 through 5, wherein the first party includes a product or service provider and the third party includes a product or service user, or the first party includes a product or service user and the third party includes a product or service provider.

[0125] Statement 8. The method according to Statement 4 or Statement 5, including the steps of signing an output of a second blockchain transaction and providing the signed output of the second blockchain transaction as an input to a third blockchain transaction, the third blockchain transaction including a further input signed by a fourth party, a first output that requires the signature of the first party to consume the first output of the third blockchain transaction, and a second output that requires the signature of the fourth party to consume the second output of the third blockchain transaction.

[0126] Statement 9. The method according to statement 8, wherein the first party includes a user of the product or service, the third party includes an authorizer of access to the product or service, and the fourth party includes a provider of the product or service.

[0127] Statement 10. The method according to any preceding statement, including at least one of submitting the second blockchain transaction to one or more nodes of the blockchain, transmitting the second blockchain transaction to a fifth party for transmission to the one or more nodes of the blockchain.

[0128] Statement 11. The method according to any preceding statement, wherein the first blockchain transaction includes data describing the action or an encrypted version of that data.

[0129] Statement 12. The method according to statement 11 when dependent on statement 3, wherein the data is encrypted using an encryption key derivable by the first party and a third party.

[0130] Statement 13. The method according to any preceding statement, wherein the second blockchain transaction and / or the fourth blockchain transaction includes a transaction identifier of the first blockchain transaction.

[0131] Statement 14. The method according to any preceding statement, including determining the first party's private key for the fifth blockchain transaction as a function of a hash of the first party's private key for the first blockchain transaction and a nonce value; and sending the nonce value to the second party.

[0132] Statement 15. The method according to statement 14, wherein the output of the fifth blockchain transaction is locked to a public key corresponding to the first party's private key for the fifth blockchain transaction.

[0133] Statement 16. The method according to statement 14 or statement 15, including the step of generating a nonce transaction, the nonce transaction including an output, and the nonce value based on a transaction identifier of the nonce transaction and an index of the output.

[0134] Statement 17. A computing apparatus comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured to perform the method of any of statements 1 to 16 when on the processing device.

[0135] Statement 18. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 16 when executed on one or more processors.

[0136] According to another aspect disclosed herein, there may be provided a method including a first party action. According to another aspect disclosed herein, there may be provided a system including a first party computer device.

[0137] According to another aspect disclosed herein, there may be provided a method including an action of a second party. According to another aspect disclosed herein, there may be provided a system including a computer device of a second party.

[0138] According to another aspect disclosed herein, there may be provided a method including the action of a third party. According to another aspect disclosed herein, there may be provided a system including a computer device of a third party. [Explanation of symbols]

[0139] 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a Computer Equipment 102b Computer Equipment 103 Users, Parties, and Agents 103a User, Original User or Entity, First Party, Alice 103b New user or entity, second party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client application or software, client 106 Peer-to-peer (P2P) networks, blockchain networks 150 Blockchain, Bitcoin Blockchain 151 blocks 152 transactions 152i Predecessor Transaction 152j Current Transaction, New Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input 203 Output, UTXO 450 Parties, Entities and Trusted Authorities 452 Parties, Entities, Product / Service Providers 454 Stakeholders, Entities, Product / Service Consumers 456 Parties, Entities, and Authorizers 550 Trusted Authorities 552 Pharmacy 554a patient 554b patient 556 Doctors< / v>

Claims

1. A method performed by a first party, comprising: receiving information of a first blockchain transaction from a second party, the first blockchain transaction including an input and an output, the input of the first blockchain transaction including a signature of the second party, and the output of the first blockchain transaction locked to the public key of the first party; performing an action including at least one of receiving authorization to access a product or service, issuing authorization to access a product or service, providing a product or service, or receiving a product or service; In response to execution of the action, providing a signature of the first party to unlock the output of the first blockchain transaction as part of a first input of a second blockchain transaction; A method comprising:

2. The method of claim 1 , wherein the second party comprises a trusted authority.

3. 3. The method of claim 1 or 2, wherein a second input of the second blockchain transaction includes a signature of a third party.

4. 2. The method of claim 1, wherein the second blockchain transaction includes a first output locked to the public key of the third party.

5. 5. The method of claim 3 or 4, wherein the second blockchain transaction includes a second output locked to a second public key of the first party.

6. The first party includes an authorizer of access to a product or service, and the third party includes a user of the product or service; or 6. The method of claim 3, wherein the first party comprises the user of the product or service, and the third party comprises an authorizer of access to the product or service.

7. The first party includes a provider of a product or service and the third party includes a user of the product or service; or 6. The method of claim 3, wherein the first party comprises the user of the product or service, and the third party comprises the provider of the product or service.

8. signing an output of the second blockchain transaction and providing the signed output of the second blockchain transaction as an input of a third blockchain transaction, wherein the third blockchain transaction comprises: A further input signed by a fourth party, the first output of the third blockchain transaction requiring the signature of the first party in order to consume the first output; the second output of the third blockchain transaction requiring the signature of the fourth party in order to consume the second output. The method of claim 1 , comprising the steps of:

9. the first party includes a user of a product or service; the third party includes an authorizer of access to the product or service; The method of claim 8 , wherein the fourth party includes a provider of the product or service.

10. submitting the second blockchain transaction to one or more nodes of a blockchain; sending the second blockchain transaction to a fifth party for transmission to one or more nodes of the blockchain; 11. The method of claim 1, further comprising at least one of:

11. 12. The method of claim 1, wherein the first blockchain transaction includes data describing the action or an encrypted version of the data.

12. 12. The method of claim 11, which recites claim 3, wherein the data is encrypted using an encryption key derivable by the first party and the third party.

13. 13. The method of claim 1, wherein the second blockchain transaction and / or the fourth blockchain transaction includes a transaction identifier of the first blockchain transaction.

14. determining a private key of the first party for a fifth blockchain transaction as a function of a hash of the private key of the first party for the first blockchain transaction and a nonce value; transmitting said nonce value to said second party.

14. The method of any one of claims 1 to 13, comprising:

15. 15. The method of claim 14, wherein an output of the fifth blockchain transaction is locked to a public key that corresponds to the private key of the first party for the fifth blockchain transaction.

16. 16. The method of claim 14, comprising generating a nonce transaction, the nonce transaction including an output, the nonce value being based on a transaction identifier of the nonce transaction and an index of the output.

17. a memory including one or more memory units; a processing device including one or more processing units; 17. A computing device comprising: a processor; a memory for storing code arranged to be executed on the processor; and the code configured, when on the processor, to perform the method of any one of claims 1 to 16.

18. 17. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 16 when executed on one or more processors.

Images