Access control using transactions

Abstract

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 comprising an input and an output, where the input of the first blockchain transaction comprises a signature of the second party, and wherein the output of the first blockchain transaction is locked to a public key of the first party; performing an action including at least one of receiving an access authorization to a product or service, issuing an access authorization to a product or service, providing a product or service, receiving a product or service; in response to performing the action, as part of a first input of a second blockchain transaction, a signature of the first party is provided to unlock the output of the first blockchain transaction.

Description

Technical Field

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

[0002] A blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"), and the copy is widely disclosed. The blockchain includes a series of data blocks, where each block includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in the sequence, which can span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is generally referred to as "mining", which involves each of the plurality of nodes competing to perform a "proof of work", that is, solving a cryptographic puzzle based on a representation of a set of defined ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the release of blocks can be achieved by only releasing block headers.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtual ledger or registry; receiving and processing timestamp entries; and / or sorting index pointers by time. Hierarchical additional functions on the blockchain can also be implemented using the blockchain. For example, the blockchain protocol can allow additional user data or data indexes to be stored in transactions. There is no predefined limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0004] In an “output-based” model (sometimes called 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 specifying an amount of digital assets, which can be derived from the ongoing sequence of transactions. A spendable output is sometimes called a UTXO (“unspent transaction output”). An output can also include a locking script that specifies the future redemption conditions of the output. The locking script is a predicate that defines the conditions necessary to verify 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 in a previous transaction and can also include an unlocking script for unlocking the locking script that points to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second (or “target”) transaction. The first transaction includes at least one output specifying an amount of digital assets and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, where the at least one input includes a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0005] In such a model, when the second (target) transaction is sent to a blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier 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 may register the invalid transaction) nor include the transaction in a new block to be recorded in the blockchain.

[0006] Another type of transaction model is the account-based model. In this case, each transaction does not define the amount of the transfer by referring to the UTXOs of previous transactions in the past transaction sequence, but rather by referring to the absolute account balance. The current state of all accounts is stored separately by nodes into the blockchain and is continuously updated.

[0007] Semi-transparent database

[0008] A "translucent database" is a term used in "Peter Wayner, Translucent Databases 2nd Edition: Obfuscation, Misdirection, Randomness, Sharing, Authentication, and Steganography for Privacy - January 8, 2009" to describe a technique for designing a privacy - protected database at low complexity cost. Linux password files are commonly used as a practical example of a translucent database. The salted hash of the user's password is saved, rather than the plain - text password. To grant access, the user enters their password into the system, which hashes the password and compares it to the stored password. Only the user knows the password. The system retains the salted hash, not the pre - image (i.e., the plain - text password). Anyone other than the password owner has to guess the pre - image. The system is more resistant to internal attacks because anyone with access to the password file can only find the hash. Thus, the core idea is to store hash(password) and use it to grant access, rather than storing and using password itself.

[0009] Merkle proof

[0010] It has been shown that the Merkle proof of a transaction not only proves the existence of the said transaction on the blockchain, but also proves the existence of the transactions whose output points are spent in the said transaction. Figure 3 An exemplary transaction graph is shown. As Figure 3 shown, if a transaction tx i has two input outpoints j = txId j |index and outpoint k = txId k |index, then the Merkle proof of tx i can prove the existence of these inputs (i.e., that this tx i is a confirmed transaction in the blockchain). Additionally, if the existence of tx i is proven and its raw transaction form is provided, this can also prove the existence of tx j and tx k . Call the transaction tx i a sub - transaction and the transactions tx j , tx k parent transactions. Additionally, if tx j in its raw transaction form is available, this can also prove the existence of all the parent transactions of tx j , and so on.

[0011] In Figure 3 the transactions are represented by circles. Arrows point from parent transactions to sub - transactions (e.g., tx iis tx j and tx k of the sub - transaction). To prove the existence of tx m 、tx l 、tx j 、tx k , it is not necessary to provide the Merkle proof for each transaction. Instead, only the Merkle proof of tx i and the original transaction forms of tx i 、tx j and tx l should be provided. It should be noted that the original transaction forms of tx k and tx m are not required, only their txIDs (the hashes of the transactions) are needed. It should also be noted that proving the existence of tx l does not prove the existence of its sub - tx n .

[0012] Three-party key generation

[0013] When two parties, Alice and Bob, want to conduct secure communication, they can use the Diffie - Hellman key - exchange protocol to generate a secret key K symetric , and use it for symmetric - key encryption. In this setup, Alice and Bob respectively have public - private key pairs (s A , K A = s A G) and (s B , K B = s B G), where K A 、K B 、G are elliptic - curve points.

[0014] Alice and Bob can generate an asymmetric key in one round of communication.

[0015] 1. Alice sends her public key K A ,

[0016] 2. Bob sends his public key K B ,

[0017] Alice uses K symmetric = s A K B to calculate the symmetric key,

[0018] Bob uses K symmetric = s B K A to calculate the symmetric key.

[0019] The symmetric key is obtained through K symmetric= s A K B = s B K A = s A s B Given by G. It should be noted that Alice and Bob have never shared their private keys. It should also be noted that assuming the integrity of the channel is maintained, i.e., Alice and Bob ensure that they obtain each other's public keys.

[0020] To allow for three-party key generation among Alice, Bob, and Charlie, the three-party key agreement protocol DHP can be chosen. For example, the symmetric key can be given by the following equations:

[0021] K symmetric = s A s B s C G = s B s C K A = s A s B K C = s A s C K B

[0022] This can be obtained through two rounds of calculations.

[0023] 1. In the first round:

[0024] a. Alice sends K A ,

[0025] b. Bob sends K B ,

[0026] c. Charlie sends K C .

[0027] 2. In the second round:

[0028] a. Alice sends s A K C , and Bob can then calculate K symmetric = s B s A K C ,

[0029] b. Bob sends s B K A to Charlie, and Charlie can then calculate K symmetric = s C s B K A ,

[0030] c. Charlie sends s to Alice C K B , and then Alice can compute K symmetric = s A s C K B .

[0031] At the end of the second round, the parties can compute the symmetric key. It should also be noted that there is no shared private key.

[0032] A bilinear mapping can be used such that the encryption key is given by .

[0033] Here, each of the three parties only needs its own secret key and the public keys of the other two parties to compute K symmetric . It should be noted that the bilinear mapping is not applicable to Secp256k1 parameters. SUMMARY OF THE INVENTION

[0034] According to one aspect disclosed herein, a method performed by a first party is provided. The method includes: receiving, from a second party, information about a first blockchain transaction, the first blockchain transaction including an input and an output, wherein the input of the first blockchain transaction includes a signature of the second party, and wherein the output of the first blockchain transaction is locked to a public key of the first party. The method may further include performing an action including at least one of the following: receiving authorization to access a product or service; issuing authorization to access a product or service; providing a product or service; receiving a product or service. The method may further include: in response to performing the action, providing, as part of a first input of a second blockchain transaction, a signature of the first party to unlock the output of the first blockchain transaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] To assist in understanding the embodiments of the present disclosure and to illustrate how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0036] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0037] Figure 2 schematically shows some examples of transactions that can be recorded in a blockchain;

[0038] Figure 3 shows an exemplary transaction graph;

[0039] Figure 4 shows an exemplary transaction graph;

[0040] Figure 5 shows an exemplary transaction graph;

[0041] Figure 6 shows an exemplary event flow;

[0042] Figure 7 shows an exemplary event flow;

[0043] Figure 8 shows an exemplary method for creating a full sub - transaction;

[0044] Figure 9 shows an exemplary method. Detailed Description

[0045] 1. Exemplary system overview

[0046] Figure 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet - switched network 101, typically a wide - area internet such as the Internet. The packet - switched network 101 includes a plurality of blockchain nodes 104, which 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. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0047] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes processing means, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field - programmable gate arrays (FPGAs), and other devices, such as application - specific integrated circuits (ASICs). Each node also includes a memory, namely a computer - readable memory in the form of a non - transitory computer - readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid - state drives (SSDs), flash memories, or electrically erasable programmable read - only memories (EEPROMs), and / or optical media such as optical disk drives.

[0048] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in a distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can be data-pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A specific transaction protocol is used throughout a given blockchain. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies the amount of a digital asset represented as property, an example of which is the user 103 to whom the output is cryptographically locked (requiring the user's signature or other unlocking to redeem or spend). Each input points to an output of a previous transaction 152, thus linking these transactions.

[0049] Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (other than a coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to a genesis block (Gb) 153, which is the first block in the blockchain. One or more early, original transactions 152 in the blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0050] The blockchain nodes 104 can be configured to forward transactions 152 to other blockchain nodes 104, thereby causing the transactions 152 to propagate throughout the network 106. The blockchain nodes 104 can be configured to create blocks 151 and store a corresponding copy of the same blockchain 150 in their respective memories. The blockchain nodes 104 can also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is commonly referred to as a "mempool". In this document, the term is not intended to be restricted to any specific blockchain, protocol, or model. The term refers to an ordered set of transactions that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0051] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming the output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid in order to ensure the validity of the current transaction, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, in this document, "previous" refers to the predecessor in a logical sequence linked by a pointer and not necessarily the creation time or send time in a time sequence, and thus does not necessarily rule out the case of unordered creation or sending of transactions 152i, 152j (see the discussion of orphan transactions below). The previous transaction 152i can equally well be referred to as the antecedent transaction or the predecessor transaction.

[0052] The input of the current transaction 152j also includes an input authorization, such as the signature of the user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can 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 152 can have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a for the purpose of making a change). In some cases, a transaction can also have multiple inputs, aggregating the amounts in the multiple outputs of one or more previous transactions and reallocating them to one or more outputs of the current transaction.

[0053] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0054] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its respective role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in the application layer or in one or more applications at a lower layer such as the operating system layer or the protocol layer or any combination of these layers.

[0055] The computer devices 102 of each party 103 that play the role of consumer users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0056] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. Users of the blockchain network (often referred to as "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 roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 to utilize the blockchain 150 by connecting to a blockchain node 106 (i.e., communicating with a blockchain node 106). For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not shown for convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein can be replaced by "first party" and "second party" respectively.

[0057] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes corresponding instances of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may further include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0058] The client application 105 can initially be provided to the computer device 102 of any given party 103 through, for example, a suitable computer-readable storage medium downloaded from a server, or through a removable storage device such as a removable SSD, a flash drive, a removable EEPROM, a removable disk drive, a floppy disk, or a magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical disk drive.

[0059] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, and then propagate it in the network of blockchain nodes 104, so as to be included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party scattered in the blockchain 150.

[0060] Note: Although various client functions can be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein can be implemented in a suite consisting of two or more different applications, such as through API connections or one application being a plugin of another application. More generally, client functions can be implemented at the application layer or a lower layer such as the operating system or any combination of these layers. The following will be described in terms of the client application 105, but it should be understood that this is not restrictive.

[0061] An instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This can enable the wallet function of the client 105 to send a transaction 152 to the network 106. The client 105 can also contact the blockchain node 104 to query any transaction in which the corresponding party 103 is the recipient in the blockchain 150 (or actually check the transactions of other parties in the blockchain 150, since in the embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send a transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify the transaction 152 according to the blockchain node protocol and forward the transaction 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0062] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the transferred amount by referring to the UTXO of a previous transaction in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is separately stored in the blockchain by the nodes of the network and is continuously updated. In such a system, transactions are sorted using the running transaction record (also called "position") of the account. This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0063] 2. UTXO-based model

[0064] Figure 2An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described by referring to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although an exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other example blockchain networks.

[0065] 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 for the inputs 202 of another new transaction (if the UTXO has not been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0066] For example, Alice 103a wishes to create a transaction 152j that transfers a relevant amount of digital assets to Bob 103b. In Figure 2 , Alice's new transaction 152j is labeled "Tx1". This new transaction obtains the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. In Figure 2 , the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels, which do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0067] As used in the context of the present transaction sequence, the terms "previous" and "subsequent" refer to the order of transactions in the sequence as defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They could equally well be replaced by terms such as "predecessor" and "successor", "ancestor" and "descendant", or "parent" and "child". This does not necessarily refer to the order in which they were created, sent to the network 106, or arrived at any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. A child that arrives at the blockchain node 104 before its parent is considered orphaned. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time while waiting for the parent.

[0068] One of the one or more outputs 203 of the previous transaction Tx0 includes a particular UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO.

[0069] The locking script (also known as scriptPubKey) is a piece of code written in a domain - specific language recognized by the node protocol. A particular example of such a language is called "Script" (with S capitalized), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The locking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain - specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0070] Thus, in the example shown, the UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P A , which requires Alice's signature Sig P A in order to redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A contains the representation (i.e., hash) of the public key P A in Alice's public - private key pair. The input 202 of Tx1 includes a pointer to Tx1 (e.g., via its transaction ID (TxID0), which in an embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes the index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes the unlocking script <Sig P A>, the unlocking script includes Alice's encrypted signature, which is created by Alice by applying the private key in her key pair to a predetermined portion of data (sometimes referred to as a "message" in cryptography). The data (or "message") for which Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0071] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria).

[0072] It should be noted that script code is usually represented schematically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when prefixed with OP_FALSE at the beginning of the locking script, creates an unspendable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data can include a file to be stored in the blockchain.

[0073] Generally, the input of a transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select the output to be signed (and thus fixed at the time of signing).

[0074] The locking script, sometimes referred to as "scriptPubKey", means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script, sometimes referred to as "scriptSig", means that it usually provides the corresponding signature. However, more generally speaking, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying the signature. More generally speaking, the script language can be used to define any one or more conditions. Therefore, it is preferable to use the more general terms "locking script" and "unlocking script".

[0075] 3. Blockchain database

[0076] Examples describe how to securely create a database on a blockchain. In some examples, the database includes a semi-transparent blockchain database. Some examples create a secret distributed system for accessing and distributing products / services while maintaining the privacy of participants.

[0077] Some examples relate to medical / pharmaceutical databases for accessing and dispensing medications.

[0078] According to the first example (Section 3.1), intersecting event streams (sequences of events) are provided. Each actor (e.g., doctor, pharmacist, and patient) has their own event stream of actions, where 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 traced by following the transaction graph.

[0079] According to the second example (Section 3.2), the mapping between the event sequence and the blockchain transaction is hidden from the public observer. The mapping can be hidden only off-chain or on-chain. One way to implement an on-chain mapping is to publish the current event in an event-publishing-transaction (EPT) i.e., the hash of the unspent output point Hash(outpoint )). Then, the output point outpoint a can be used as the input for the EPT a publishing the next event in stream A. That is, the information about the EPT for publishing the next event is hidden in the EPT publishing the current event. It should be noted that the outputs are not spent , i.e., there is no parent-child relationship between them.

[0080] While the second example improves privacy, it cannot efficiently prove the events that occurred. When there is a parent-child relationship between EPTs, proving the existence of a child transaction (by providing its Merkle proof) proves the existence of the parent transaction (without providing the Merkle proof of the parent transaction). When there is no parent-child relationship between EPTs, this method cannot be used to prove the existence of the parent transaction, so in one scenario, Merkle proofs of each EPT can be provided to prove existence. In some examples, a child-of-all tx coa is created, which spends the output points of each EPT. The Merkle proof of tx coa can be used to prove the existence of all EPTs. In some examples, tx coaSize reduction. In some examples, to minimize privacy risks, the EPTs of different streams are merged into a single tx coa .

[0081] In the third example (Section 3.4), unspent transaction outputs are used as tokens to control access to a database. An unspent output indicates that the token is valid, and a spent output indicates that the token is invalid. In one example, it shows how a patient (data record owner) using these tokens can allow doctors and pharmacists to access and update the patient's database records. It also shows that these tokens can be used to hide the identity of the signer.

[0082] 3.1 Intersecting event streams ("first-layer solution")

[0083] Figure 4 An exemplary diagram is shown. The circles represent transactions, and the arrows pointing into and out of the circles represent inputs and outputs, respectively.

[0084] Figure 4 Four parties 450, 452, 454, and 456 are provided. Signatures can be used to authenticate events. Signatures can be included in the unlocking script of a transaction. Each entity 450, 452, 454, and 456 can have its own blockchain wallet. Each entity 450, 452, 454, and 456 can use a registered key pair related to the identity and role of the corresponding entity to prove its identity. Party 450 can include a trusted institution (e.g., Kensei). The trusted institution can include a trusted identity and authentication institution. According to some examples, party 452 can include a provider of products and / or services. According to some examples, party 454 can include a user of products and / or services. According to some examples, party 454 can include an access authorizer for the provider and / or service.

[0085] In Figure 4 In the specific example shown, party 450 includes a trusted institution, party 452 includes a pharmacy, party 454 includes a patient, and party 456 includes a doctor. However, it should be noted that these are only examples, and in other examples, each party can include different types of entities.

[0086] Each transaction can publish an event. For example, events can include:

[0087] 1. Registration: The public key of each actor is paired with its identity.

[0088] 2. Authorization: The authorizer views the consumer's history and issues authorization for a product or service.

[0089] 3. Collection: The provider checks the consumer history, checks if the authorization is signed by the authorizing actor, and provides the product / service to the consumer.

[0090] 4. Audit: The auditor checks if each actor is performing their duties diligently.

[0091] In a medical example, for instance, events can include:

[0092] 1. Registration: The public key of each actor is paired with their identity.

[0093] 2. Prescription: The doctor reviews the patient's medical history and issues a prescription.

[0094] 3. Collection: The pharmacist reviews the patient's medical history, checks if the prescription is signed by the authorizing actor, and gives the prescription to the patient.

[0095] 4. Audit: The auditor checks if each actor is performing their duties diligently.

[0096] Figure 4 Three registration EPTs (Identification and Authentication EPTs) are shown. The registration event is issued in the transaction Each transaction is signed by a trusted authority 450 and contains relevant information about the identified subject and role. The output of each transaction can only be used by the identified subject. The input of each identification and authentication event transaction can include the signature of the trusted authority 450. The output of the transaction can be locked to the public key of the party identified in the registration event.

[0097] For example: Having an input that includes the signature of the trusted authority 450 and an output locked to the public key of the participating party 456 (e.g., the authorizer of the product / service, such as a doctor); Having an input that includes the signature of the trusted authority 450 and an output locked to the public key of the participating party 454 (e.g., the consumer of the product / service, such as a patient); Having an input that includes the signature of the trusted authority 450 and an output locked to the public key of the participating party 452 (e.g., the user of the product / service, such as a pharmacy).

[0098] Figure 4 Also shown is the authorization EPT at. In Figure 4 the specific example of, the authorization event is a prescription issuing event between the authorizer 456 (e.g., a doctor) and the consumer 454 (e.g., a patient). The authorization issuance event contains authorization details (e.g., prescription details) and is signed by the authorizer 456. The authorization issuance event has an output that can be spent by the consumer 454. In Figure 4 In, Having two inputs and two spendable outputs The spendable outputs can only be spent by the authorizer 456 and the consumer 454 respectively. In this case, the signature of the authorizer is required. The signature of the consumer 454 is optional, but it allows for easier tracking of the consumer's interactions on the transaction graph. An action can be performed, and in response to performing the action, the signature of the party performing the action can be provided to unlock the output of the previous blockchain transaction. Then, the output of the previous blockchain transaction can be used as the input of a blockchain transaction that includes information describing the action.

[0099] Figure 4 Also shown is the collected EPT in The EPT contains the signatures of the product / service provider 452 (e.g., pharmacy) and the product / service consumer 454 (e.g., patient), as well as details about the collected product / service (e.g., prescription). This transaction has two inputs and two spendable outputs

[0100] In some examples, OP_RETURN can be used to hide the collected data (e.g., prescription details). The prescription details can be encrypted and inserted after OP_RETURN. Or in a separate non-spendable output, e.g.:

[0101] OP_FALSE OP_RETURN <cipher>,

[0102] Or in the spendable output of consumer 454, for example:

[0103] P2PKH<patient_Address>OP_RETURN <cipher>,

[0104] where cipher = Enc(key, m = <prescription>)。

[0105] Encryption can be performed by using a symmetric-key-based scheme (e.g., Advanced Encryption Standard (AES)), and the shared encryption key can be determined by a Diffie Hellman key exchange between the consumer 454 and the authorizer 456 or the provider 452. The cipher can be decrypted by the consumer 454, the authorizer 456, and the provider 452. The above parties can use the key derived from their identity public key to complete this operation.

[0106] In some examples, the encryption key can be obtained through K symmetric = Hash((s patient K dr )|nonce) = Hash((s dr K patient )|nonce), where s patient , s dr are the secret keys (scalar values) of the consumer 454 and the authorizer 452, and K patient , K dr are the corresponding public keys (elliptic curve points). The nonce is a value agreed upon by the patient and the doctor to ensure that different encryption keys are used in each transaction.

[0107] It can be optionally used that the public key pair of (s, K) is the same as the key used to sign its transaction input.

[0108] The encryption key may also need to be shared with the trusted institution 450 to allow access to the provider 452 and / or at least one auditor. In this case, the three-party key negotiation protocol DHP can be optionally used. For example, the symmetric key can be given by the following equation:

[0109] K symmetric = s dr s patient s TA G = s dr s patient K TA = s patient s TA K dr

[0110] = s dr s TA K patient

[0111] In other examples, the collected details (e.g., prescription details) are hashed in an encrypted manner and the hash value is inserted into the transaction, while the actual details are saved in a secure database in an off-chain manner.

[0112] Figure 5 Another example including an EPT is shown. Figure 5 It relates to an example of a specific medical environment, which includes a doctor 556 (the authorizer of the product / service), two patients 554a and 554b (the consumers of the product / service), a pharmacy 552 (the provider of the product / service), and a trusted institution 550. However, it should be understood that Figure 5 the features can be generalized to any EPT where there is a parent-child relationship. Specifically, it should be understood that Figure 5 the features can be generalized to examples of authorizing, collecting / using, and providing products / services.

[0113] When doctor 556 writes a new prescription for patient 554a or 554b, she can trace all of the patient's history (prescriptions written and collected) by tracing the patient's transaction graph.

[0114] Similarly, an auditor checking the activities of doctor 556 can trace doctor 556's transaction graph and ensure that all prescriptions are written for certified and authorized patients.

[0115] An auditor checking the activities of pharmacist 552 can trace pharmacist 552's transaction graph and ensure that all prescriptions collected are signed by an authorized doctor (e.g., doctor 556) and written for certified patients (e.g., patient 554a and / or patient 554b).

[0116] In Figure 5 , the relevant events of each actor can be traced by tracking the corresponding transaction graph. Some events involve more than one actor, and thus there are common transactions in the graphs of each actor. Figure 5 The following four transaction graphs are shown:

[0117] ● The transaction graph of doctor 556 is (connected by solid arrows),

[0118] ● The graph of the first patient 554a is (connected by dashed-dashed arrows),

[0119] ● The graph of the second patient 554b is (connected by dashed-dot-dashed arrows),

[0120] ● The graph of pharmacist 552 is (connected by dashed-dot-dot-dashed arrows).

[0121] When pharmacist 552 checks the authorization and certification of doctor 556, it is not necessary to trace doctor 556's graph transactions back to to complete the operation. By taking The output (which can be spent by the private key of doctor 556) is associated with the transaction that carries prescription data by reference in That is, by establishing a rule that includes the transaction identifier (txid), the pharmacist 552 (or other verifier) can obtain and check whether it is issued by the trusted institution 550, thus verifying the identity of doctor 556, and check the public key signed in whether it is related to the signature used by doctor 556 in In other words, the transaction should spend the output that requires the signature of doctor 556 to allow this exemplary method, that is, to check the authorization and authentication of doctor 556.

[0122] For example, if the authentication key pair of doctor 556 is then the private key used by doctor 556 to sign can be given by the function of or or such as where nonce sig has been informed to the pharmacist 552. This nonce can be securely sent off-chain by doctor 556, shared with a trusted third party, or encrypted as metadata within the transaction itself. The pharmacist 552 checks whether the public key used in the unlocking script in is equal to and is convinced that it is signed by doctor 556 identified in The same method should be applied to authenticate other signature action executors. In some examples, the verification process is performed by a service provider.

[0123] Reusing a nonce affects the privacy of the signer because it enables an observer to link different messages of the signer. It may also leak information about the signer's private key. A possible mitigation measure is to use an unspent output as the nonce, where its spent status (spent / unspent) indicates validity, i.e., nonce = txid|index = outpoint. In such examples, for instance, doctor 556 can use the key given by

[0124]

[0125] Table 1 - Create a transaction that creates a spendable output to be used as a nonce in the transaction signature and spend it after use.

[0126] Once an outpoint x is used as a nonce, it should be spent, which can be done in the same (or a different) transaction carrying the signature. For illustration, the signer conducts transaction tx nonce , thus creating an unspent output outpoint nonce . Then, the signer conducts transaction tx sig that spends outpoint nonce in one of its inputs, and tx sig includes a signature with the private key s Dr +Hash(outpoint nonce ), which can be in another input unlocking script or in OP_RETURN. The latter is shown in the following table.

[0127]

[0128] Table 2- A transaction that carries a signed message and at the same time spends the output used as a nonce.

[0129] Resisting replay attacks by ensuring the uniqueness of signed messages

[0130] It should be noted that in some examples, the implicit property of block transactions (spending an output only once) means that replay attacks are computationally infeasible because each signed message should contain a string (unspent output) that can only be used once. Therefore, a message signed using the signature in the unlocking script can resist replay attacks. In the case where the signature is embedded in the transaction as a separate data string (e.g., after OP_RETURN), the signed message should include the output point spent in the transaction as a nonce, i.e., the signed message contains outpoint.

[0131] 3.2 "Second-layer solution"

[0132] An undesirable aspect of the scheme discussed in Section 3.1 is that the activities and interactions of all actors can be traced by tracking the transaction graph. For example, in the Figure 5 example, it is relatively easy to trace the number of prescriptions written by a doctor since registration, the number of the doctor's patients, and the number of prescriptions written for each patient. When the scheme is applied more widely, it is relatively easy to determine how many times an authorizer has authorized a product / service, how many consumers the authorizer is responsible for, and how much product / service the provider has issued to each consumer. In addition to privacy aspects, each actor must have a wallet to sign and receive transactions, which adds additional complexity.

[0133] In the example of the "second layer solution", the signature of the actor is inserted as data included in the transaction, and the locking script and unlocking script (presc, collect, etc.) of the transaction are generated by a service provider (e.g., Kensei) independent of the actor.

[0134] Assume that the service provider has a cache of unspent transaction outputs (linked transaction outputs) that can be used to create transactions carrying events.

[0135] It should be noted that most of these linked transaction outputs are expected to be easily linked to the service provider, which may pose a privacy risk in some examples. However, privacy can be maintained through extensions. As the number of events and clients increases, it becomes increasingly difficult for outsiders to associate which transactions carry which events for which clients.

[0136] Linking events of action executors

[0137] Assume that the actor (which can be the authorizer of a product / service, the consumer of a product / service, the provider of a product / service, or in a medical context can be a doctor, patient, or pharmacist) participates in the following sequence of events e1, e2, e3, which are respectively published in Note that these transactions may be in the same transaction chain, but do not have to immediately spend each other (there is no parent-child relationship). As Figure 6 shown, by including the hash of the output point that will be spent in the transaction (containing information about the current event e1) in (containing the next event e2), the association between these events can be privately established on the chain. Thus, for example, contains (e1,Hash(outpoint b )) and spends outpoint b and contains the next event (e2). By including the hash of the output point that will be spent in the transaction (containing information about the current event e2) in (containing the next event e3), the association between these events can be privately established on the chain. Thus, for example, contains (e2,Hash(outpoint c )) and spends outpoint c and contains the next event (e3).

[0138] As Figure 6 As shown, when a first party performs a first action e1, the first signature of the first party can be included as data in a first event transaction . The first event transaction can include the hash of the first output point (outpoint b ) of a first linking transaction tx b . When the first party performs a second action, the second signature of the first party is included as data in a second event transaction , where the second event transaction includes the first output point (outpoint b ) as an input.

[0139] The second event transaction can include the second output point (outpoint c ) of a second linking transaction. In response to the first party performing a third action, the third signature of the first party can be included as data in a third event transaction, where the third event transaction includes the second output point (outpoint c ) as an input. The first output point (outpoint b ) and the second output point (outpoint c ) can be generated by a service provider.

[0140] An off-chain scheme is to store an index based on the records e1, e2, e3 of the action performer .

[0141] If a service provider incorrectly spends an output point outpoint in an unrelated event b , there may be a mechanism to detect and correct the error. Some exemplary mechanisms are as follows:

[0142] 1. Application level - Embed the scheme in event e i :

[0143] a. Use error correction and detection codes to detect and correct errors,

[0144] b. Use authentication techniques.

[0145] 2. Service provider level

[0146] a. The off-chain record should have a flag for indicating whether an error has occurred.

[0147] b. Include the hash of the address being spent, rather than the output point itself (in addition to the output point), i.e., for example, Hash(P2PKH<P b >).

[0148] c. Map error events in an incorrect transaction In the case of, the service provider issues a corrective transaction, which will include signatures associated with the signatures used in past correct transactions to prove the authenticity of the corrective transaction. For example, if the service provider uses secret keys s1, s2 when issuing transactions t1, t2 for a message, the service provider can prove that it is the signer of these transactions by creating two signatures using s1 + nonce1 and s2 + nonce2 in the corrective transaction and sending (nonce1, nonce2) to the verifier.

[0149] In some examples, forged events are inserted into the transaction in such a way that the attacker cannot determine the real information in the false forged data. These examples adopt misleading means to confuse potential attackers.

[0150] 3.3 Proof of event existence

[0151] Two methods of mapping events from an event stream to a blockchain transaction were discussed above.

[0152] 1. Event Publication Transactions (EPTs) are linked to each other such that one event publication transaction spends another. An example of this is shown in 3.1 (the first layer scheme). In this case, events can be traced by tracing the transaction graph because all EPTs of the event stream are linked by a child-parent relationship. In Figure 9 In Events are published in All events can be traced by tracing the transaction graph.

[0153] 2. The EPTs of the event stream are not linked by a child-parent relationship, as discussed in 3.2. As Figure 6 shown. This design choice provides privacy protection because external observers cannot easily trace the EPTs of the event stream.

[0154] When providing proof of the existence of an event, a Merkle proof of the EPT of that event and the original transaction itself are provided to a second party; this is used to show the event data (if the hash of the event is published, the event hash is shown). If there is a child-parent relationship between the EPTs of the event stream, only the Merkle proof of the latest child transaction can be provided, thus replacing the Merkle proofs of all transactions. This may be a welcome optimization when the number of events is large. For illustration (see Error! Reference source not found), if one wants to prove the existence of events e1 to e4, the following may need to be provided:

[0155] 1. The Merkle proof of

[0156] 2. to The original transaction format.

[0157] However, if the EPTs are not associated through a parent-child relationship, the following may be required:

[0158] 1. A Merkle proof for each EPT,

[0159] 2. The original transaction for each EPT.

[0160] The size of the proof can be reduced by creating a transaction that spends the outputs of all EPTs. Call this transaction the "full child transaction" (tx coa ) or the event summary transaction - see Figure 8 ). In this case, all events can be proven by:

[0161] 1. The Merkle proof of tx coa ,

[0162] 2. The original transaction format of tx coa ,

[0163] 3. The original transaction for each EPT.

[0164] This reduces the size of the proof. This scheme links all EPT transactions on the blockchain. To address privacy concerns, obfuscation techniques can also be employed (e.g., false EPTs can be used to provide tx coa along with the real EPTs).

[0165] In some examples, tx coa can spend the outputs of all EPTs from all different streams. Service providers (such as Kensei) that publish events from different streams in blockchain transactions can use this method to provide a degree of privacy. In Figure 7 , there are two event streams A and B. There is no parent-child relationship between any two EPT transactions. Create tx coa , which spends the output of each EPT. Event stream A includes Event stream B includes

[0166] One advantage of tx coa is that it is universal for all event streams whose EPTs have output points that are spent within them. That is, tx coa can be easily shared among different customers of the service provider. This is like the block header chain data, which must be provided along with the Merkle proof when proving the existence of any transaction.

[0167] However, tx coa The size can be very large, especially when privacy is desired by combining output points from different streams of EPTs.

[0168] In addition, spendable output points are required in each EPT. Event data can be inserted into the spendable output without creating new data-specific outputs in each EPT. One way to reduce the size of the unlocking script in tx coa is to use a hash function instead of OP_CHECKSIG. The locking script can take the following form:

[0169] OP_HASH160<RIPEMD160(SHA256(v))>

[0170] The unlocking script can take the following form:

[0171] <v>

[0172] The minimum length of v should be 128 bits (16 bytes). This reduces the size of the unlocking script from 106.5 bytes (used in P2PKH) to only 16 bytes. The average size of a P2PKH input is approximately 147.5 bytes: 40 bytes for referencing the UTXO and sequence number, 1 byte of variable-length integer for encoding the size of the unlocking script, and 106.5 bytes for the unlocking script. The average size now becomes 57 bytes. This also reduces the size of the locking script (in EPT) from 25 bytes (the locking script in P2PKH) to approximately 20 bytes.

[0173] In addition to using OP_HASH160 to replace OP_CHECKSIG, the value (currency) of the output point (for each EPT) should also be as small as possible (e.g., 1 satoshi). This is because removing OP_CHECKSIG allows any entity to spend the output in different transactions. This attack can only be carried out within the time before confirming the tx coa To mitigate this risk, the value of the output point is set very low so that it is not worth the attacker to carry out such an attack. The size of the tx coa is large enough such that it is necessary to spend P2PKH inputs to fund the transaction and pay the miner's fees. See Error! Reference source not found.

[0174] In Error! Reference source not found, the unlocking script in the tx of EPT coa is given by A single v i value (per stream or across all streams) can be set to allow for compact off-chain storage and transmission of the tx coa . Alternatively, there can be a deterministic relationship between different such that compression can still be carried out. For example, or

[0175]

[0176] Table 3 : full sub-transaction

[0177] In some examples, a full sub-transaction at time T i can be created whose Merkle proof can prove the existence of all EPTs with outputs spent therein. and There may be a child-parent relationship. Continuously replace this Merkle proof with the latest Merkle proof. Thus, as long as the original transaction of the latest full and its Merkle proof are available, the existence of any EPT can be proven.

[0178] 3.4 Using transactions for access control

[0179] In this section, it is assumed that there is a database that stores records (e.g., patient records).

[0180] In some examples, there are three different actors: the oracle, the patient, and the doctor (or pharmacist). The oracle is responsible for allowing and blocking access to the database. The patient has the right to grant access to their records. The oracle is responsible for enforcing access control. The doctor and pharmacist want to access the data.

[0181] An exemplary use case is that the patient grants the doctor (or pharmacist) access rights to read or edit the patient's records.

[0182] The database contains the patient's records and the patient's public key P Pt . The patient can prove their ownership of the public key by presenting a signature corresponding to the public key to the oracle. The oracle will only grant the doctor (or pharmacist) access to the patient's records if the provided patient's signature corresponds to the public key. The patient's public key can be used to identify the patient's records. Additionally, Hash(P Pt ) can be used instead of P Pt .

[0183] The patient wants to send an access token to the doctor. The oracle grants access after being presented with a valid token. The access token may expire after use.

[0184] The transaction signed by the patient can include the token. The output point of the transaction is used to indicate the validity of the token. If the output point has not been spent, the token is valid; otherwise, it is invalid.

[0185] Output points as database access control tokens

[0186] The signed message contains the hash of the unspent output m = Hash(outpoint x ), and the proxy will spend this hash (output point) after granting access. Once outpoint x is spent, the token is considered expired. See Figure 9 . Here, the patient signs the message m and passes it to the doctor (or pharmacist) to allow access. At 851, the doctor / pharmacist sends the signed message m along with the access request to the oracle (access proxy). At 853, the oracle checks the patient's signature. At 855, the oracle checks whether outpoint x is in the UTXO set. If it is in the UTXO set, the proxy grants the doctor / pharmacist access at 859 and spends outpoint at 861 x to remove it from the UTXO set. If the outpoint x is not in the UTXO set, the oracle rejects to grant the doctor / pharmacist access at 857.

[0187] In addition, there are the following exemplary options:

[0188] a. The output outpoint x can be spent by the proxy or the patient (1 / 2 multi-signature). This allows either of them to invalidate the token or revoke the access right.

[0189] b. The signed message is the concatenation of spendable outputs m = hash(outpoint x |outpoint y ), where one can be spent by the patient and the other by the proxy. Here, one of the following rules is used to grant access.

[0190] i. Access is granted as long as neither of the two outputs has been spent, otherwise access is refused.

[0191] ii. Access is refused only when both of the two outputs have been spent.

[0192] Output points as identity hiding tokens

[0193] The oracle can periodically and securely announce the outpoint T = txid|index that can be spent by the proxy. When communicating with the proxy, the patient signs the message using s Pt +Hash(outpoint T ). The proxy checks whether the corresponding public key is P Pt +Hash(out T ).G, and whether the outpoint T is in the UTXO set. In the next time interval, the oracle spends out T , and selects a new unspent output as the next token out T+1 .

[0194] 4. Further comments

[0195] Once the disclosure of this article is given, other variations or use cases of the disclosed technology may become obvious to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims.

[0196] For example, some of the above embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of the blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced by reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0197] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin node 104 performs at least all of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing the blocks (keep in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

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

[0199] Even more generally, any reference above to the term "Bitcoin node" 104 can be replaced by the term "network entity" or "network element", where such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functions of such a network entity / element can be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0200] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and any type of suitable consensus mechanism may be used in general embodiments, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to generate the next block 151. The selected node is typically referred to as a validator. A blockchain node may lock its tokens for a period of time in order to have the opportunity to become a validator. Generally, the node that locks the maximum stake for the longest time is most likely to become the next validator.

[0201] It should be understood that the above embodiments are 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 statements.

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

[0203] Statement 2. The method according to statement 1, wherein the second party includes a trusted institution.

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

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

[0206] Statement 5. The method according to statement 3 or 4, wherein the second blockchain transaction includes a second output that is locked to a second public key of the first party.

[0207] Statement 6. The method according to any one of Statements 3 to 5, wherein: the first party includes an access authorizer of a product or service, and the third party includes a user of the product or the service; or, the first party includes the user of the product or the service, and the third party includes an access authorizer of the product or the service.

[0208] Statement 7. The method according to any one of Statements 3 to 5, wherein: the first party includes a provider of a product or service, and the third party includes a user of the product or the service; or, the first party includes the user of the product or the service, and the third party includes the provider of the product or the service.

[0209] Statement 8. The method according to Statement 4 or 5, the method comprising: signing an output of the second blockchain transaction and providing the signed first output of the second blockchain transaction as an input to a third blockchain transaction, wherein the third blockchain transaction includes: another input signed by a fourth party; a first output, the first output requiring a signature of the first party to spend the first output of the third blockchain transaction; a second output, the second output requiring a signature of the fourth party to spend the second output of the third blockchain transaction.

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

[0211] Statement 10. The method according to any one of the preceding statements, wherein the method includes at least one of the following: submitting the second blockchain transaction to one or more nodes of a blockchain; sending the second blockchain transaction to a fifth party for sending to one or more nodes of a blockchain.

[0212] Statement 11. The method according to any one of the preceding statements, wherein the first blockchain transaction includes data for describing the action or an encrypted version thereof.

[0213] Statement 12. The method according to Statement 11, which is subordinate to Statement 3, wherein the data is encrypted using an encryption key that can be derived by the first party and the third party.

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

[0215] Statement 14. The method according to any one of the preceding statements, wherein the method comprises: determining the private key of the first party for a fifth blockchain transaction based on a hash of the private key of the first party for the first blockchain transaction and a nonce value; and sending the nonce value to the second party.

[0216] Statement 15. The method according to statement 14, wherein the 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.

[0217] Statement 16. The method according to statement 14 or 15, the method comprising: generating a random number transaction that includes an output, wherein the nonce value is based on a transaction identifier of the random number transaction and an index of the output.

[0218] Statement 17. A computer device, the computer device comprising: a memory that includes one or more memory units; and a processing device that includes one or more processing units, wherein the memory stores code configured to run on the processing device and, when run on the processing device, perform the method according to any one of statements 1 to 16.

[0219] Statement 18. A computer program embodied on a computer-readable memory and configured to, when run on one or more processors, perform the method according to any one of statements 1 to 16.

[0220] According to another aspect disclosed herein, a method can be provided that includes actions of the first party. According to another aspect disclosed herein, a system can be provided that includes a computer device of the first party.

[0221] According to another aspect disclosed herein, a method can be provided that includes actions of the second party. According to another aspect disclosed herein, a system can be provided that includes a computer device of the second party.

[0222] According to another aspect disclosed herein, a method can be provided that includes actions of the third party. According to another aspect disclosed herein, a system can be provided that includes a computer device of the third party.< / v> < / prescription> < / cipher> < / cipher>

Claims

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

2. The method according to claim 1, wherein the second party includes a trusted institution.

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

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

5. The method according to 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 method according to any one of claims 3 to 5, wherein: The first party includes an access authorizer of a product or service, and the third party includes a user of the product or the service; or The first party includes the user of the product or the service, and the third party includes an access authorizer of the product or the service.

7. The method according to any one of claims 3 to 5, wherein: The first party includes a provider of a product or service, and the third party includes a user of the product or the service; or The first party includes the user of the product or the service, and the third party includes the provider of the product or the service.

8. The method according to claim 1, the method including: 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 includes: Another input signed by a fourth party; A first output that requires a signature of the first party to spend the first output of the third blockchain transaction; A second output that requires a signature of the fourth party to spend the second output of the third blockchain transaction.

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

10. The method according to any of the preceding claims, wherein the method includes at least one of the following: Submitting the second blockchain transaction to one or more nodes of a blockchain; Sending the second blockchain transaction to a fifth party for sending to one or more nodes of a blockchain.

11. The method according to any one of the preceding claims, wherein the first blockchain transaction includes data describing the action or its encrypted version.

12. The method according to claim 11, dependent on claim 3, wherein the data is encrypted using an encryption key that can be derived by the first party and the third party.

13. The method according to any one of the preceding claims, wherein the second blockchain transaction and / or the fourth blockchain transaction includes the transaction identifier of the first blockchain transaction.

14. The method according to any one of the preceding claims, wherein the method includes: determining the private key of the first party for a fifth blockchain transaction based on the hash of the private key of the first party for the first blockchain transaction and a random value; sending the random value to the second party.

15. The method according to claim 14, wherein the output of the fifth blockchain transaction is locked to the public key corresponding to the private key of the first party for the fifth blockchain transaction.

16. The method according to claim 14 or 15, the method includes: generating a random number transaction, the random number transaction including an output, wherein the random value is based on the transaction identifier of the random number transaction and the index of the output.

17. A computer device, the computer device includes: a memory, the memory including one or more memory units; and a processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured to, when run on the processing device, perform the method according to any one of claims 1 to 16.

18. A computer program, the computer program being embodied on a computer-readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 16.

Images