Computer-implemented system and method for generating and extracting user-related data stored on a blockchain

Abstract

A computer-implemented system and method are described that provides user-related data, such as reputation information, about users of a blockchain associated with a transaction. The method includes an approach to assess the satisfaction of a transaction, particularly in the context of a contract, and then provide a record of it on the blockchain through reputation information. As a result, at a later time, this reputation information can be retrieved. Similar reputation information for other transactions can be retrieved and linked to the same user, for example, based on the use of a hash of the user's master public key. Aggregate reputation information can be calculated from the retrieved pieces of reputation information.

Description

[Technical Field]

[0001] The present invention relates generally to computer-implemented systems and methods, and in particular to computer-implemented systems and methods for providing data about users associated with transactions. The present invention is particularly suitable for use in providing data such as scores, accuracy, or quality indicators in connection with aspects of transactions on a blockchain, although not exclusively. Examples include providing reputation information about users associated with a transaction, and particularly, but not exclusively, providing reputation information about users of smart contracts implemented on a blockchain. [Background technology]

[0002] As used herein, the term "blockchain" is used to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

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

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure each transaction is valid; invalid transactions are rejected by the network. A software client installed on a node performs this validation work on unspent transactions (UTXOs) by running its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction; if the transaction is verified, the node relays the transaction to other nodes in the network; ii) be added to a new block constructed by miners; and iii) be mined, i.e., added to the public ledger of past transactions.

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

[0006] One area of ​​current research is the use of blockchain for the implementation of "smart contracts," which are computer programs designed to automate the execution of machine-readable transactions or terms of agreements. Unlike traditional transactions, which may be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce an outcome and can cause actions to be performed depending on that outcome.

[0007] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") for the representation and transfer of real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow the real-world items to be referenced from the blockchain.

[0008] Various conventional methods for managing user-related data, such as reputation data or credit information, within a network are known, and examples of such conventional methods are briefly described below.

[0009] The presentation "OpenBazaar—Ratings, Reviews, and Reputation" by Chris Pacia et al. discloses a blockchain-based reputation system. Slide 55 shows that when an item is received, a buyer generates a rating immediately before releasing capital to the vendor. The rating data is attached to a Ricardian contract. The rating data includes a score provided by the buyer based on the following parameters: feedback, quality, description, shipping date, customer service, and reviews. Slide 63 shows that OP_RETURN has the vendor's Globally Unique Identifier (GUID) embedded, which is used to filter related multi-signature transactions from the blockchain when scanning for ratings. Furthermore, it shows that of these tagged multi-signature transactions, only those with the vendor's GUID signature in the scriptsig are considered valid, "as this is indelible evidence that the vendor was involved in the transaction."

[0010] Note that in the system disclosed in OpenBazaar, reputation data is provided by users (buyers). This reputation information can, in principle, be misused (e.g., by a competitor entering bad reputation information). To prevent abuse of the reputation system in OpenBazaar, the system only uses transactions that are signed by the vendor and therefore represent actual transactions. However, this does not prevent a competitor from legitimately buying goods or services with transactions signed by the vendor and then providing bad reputation information in an attempt to deter others from buying the vendor's goods or services.

[0011] WO2015 / 085393 discloses a rating system for rating the transaction history of a digital currency. The rating system includes a storage system that stores transaction information for the digital currency, an interface that receives an identifier of at least one account associated with the digital currency and a request to rate the transaction history of the at least one account, and a processor that communicates with the storage system and the interface. The processor identifies transactions for the at least one account from the transaction information stored in the storage system and accesses the destinations of the identified transactions to generate a rating for the at least one account. The document further discloses that the rating system can access the amount and age of the identified transactions, and that the rating system can be useful, for example, for peer-to-peer digital currencies. The storage system does not appear to include a blockchain, and further, the user-specific transactions simply include the amount, date, and destination of the identified transactions.

[0012] US2006149745 discloses a system and method for providing feedback data within a distributed feedback system of an electronic commerce system. Feedback data describing electronic commerce transactions is generated by buyers of goods and services and corresponding sellers of the goods and services. The feedback data is stored and maintained in a collection of feedback servers organized in a peer-to-peer (P2P) network of distributed devices. The feedback data is organized into groups of feedback data stored in database storage associated with each of the P2P network nodes. Buyers and sellers can retrieve feedback data from these distributed data sources to obtain reputation data associated with parties with whom they propose to enter into new transactions for goods and services. A blockchain system by which user-related data is transmitted, stored, searched, and extracted is not disclosed.

[0013] US2015302400 discloses a decentralized cryptocurrency reputation system and method that includes monitoring a cryptocurrency public ledger. Current cryptocurrency transactions are detected in the cryptocurrency public ledger, and in response, reputation markers can be assigned to both the payer and the payee associated with the current cryptocurrency transaction. At least a portion of the reputation markers can then be determined to be transferred from the payer to the payee and from the payee to the payer. When a request for reputation information for the payer or the payer is received, a transfer of at least a portion of the reputation markers can then be provided from the payer to the payee or from the payee to the payer.

[0014] CN106230808 discloses storing personal credit information from many different institutions on a blockchain. Summary of the Invention

[0015] A problem with existing systems and methods for providing data about users of a system, such as reputation information, is that the systems, and therefore the data, are susceptible to attack and manipulation or are not suitable for implementation in a distributed system.

[0016] It is therefore desirable to provide solutions that include, among other objectives, systems and / or methods that are more robust against attacks or manipulation.

[0017] It is therefore desirable to provide, among other objectives, solutions that include systems and / or methods that are more suitable for implementation in distributed systems.

[0018] It is therefore desirable to provide a solution that includes, among other objectives, a system and / or method suitable for use in a blockchain or Bitcoin blockchain-type implementation.

[0019] Furthermore, it would be desirable to provide a more objective solution in terms of generating user-relevant information.

[0020] A still further object is to provide an efficient and effective way to create, store, and retrieve user-related data on a blockchain.

[0021] Such an improved system is contemplated. The invention is defined in the appended claims and / or in the description of the invention and / or in the features, options and possibilities set out herein.

[0022] According to a first aspect of the present invention, there is provided a method of calculating aggregate user-related data, said method comprising: (a) constructing a user-related data transaction, the user-related data transaction including a representation of user-related data from a previous transaction associated with the user; (b) broadcasting the user-related data transactions to a blockchain; (c) repeating steps (a) and (b) for multiple previous transactions and / or multiple users; (d) selecting a user for which aggregated user-related data is requested to provide the selected user; (e) generating a filter associated with the selected user; (f) searching the blockchain for user-related data transactions to which the filter is applied; (g) calculating aggregate user-related data for the selected users from the reputation transactions to which the filter is applied.

[0023] The method may provide that the aggregated user-related data is aggregated reputation information. The user-related data transaction may be a reputation transaction. The user-related data transaction may include an expression of satisfaction of a previous transaction related to the user. The user-related data from a previous transaction may be an expression of satisfaction of a previous transaction related to the user.

[0024] The method may provide that the calculated aggregate user-related data is evaluated, and preferably the evaluation results in a decision, most preferably a decision that results in an action and / or change. One or more evaluations may be made. One or more decisions may be made. One or more actions may be taken. One or more changes may be made.

[0025] The calculated aggregate user-related data may be evaluated against thresholds and / or ranges. A value for a first aspect of the threshold may result in a first decision. A value for a second aspect of the threshold may result in a second decision, preferably different from the first decision. A value within the range may result in the first decision. A value outside the range may result in the second decision.

[0026] The decision and / or action and / or change may result in a change to one or more inputs to one or more further transactions, such as blockchain transactions. The decision and / or action and / or change may result in a change to one or more outputs from one or more further transactions, such as blockchain transactions. The decision and / or action and / or change may result in a change to a deterministic finite automaton (DFA), such as a DFA that performs one or more further transactions.

[0027] The decisions and / or actions and / or modifications may provide feedback to modify and / or optimize the DFA, for example, the performance of the DFA.

[0028] The decisions and / or actions and / or changes may provide feedback to modify and / or optimize the design and / or production and / or storage and / or distribution and / or consumption of services and / or goods.

[0029] The decisions and / or actions and / or changes may provide feedback to modify and / or optimize the processing of services and / or goods, for example, for design and / or manufacturing and / or storage and / or distribution and / or consumption.

[0030] The decisions and / or actions and / or changes may provide feedback to modify and / or optimize a contract, such as a smart contract.

[0031] The user-related data may be time. The time n may be the occurrence time of an event. The event may be the completion time of a transaction or state transition or blockchain transaction resulting from a DFA, and / or the time of a state change within a DFA when performing a DFA operation.

[0032] The user-related data may be a representation of precision and / or accuracy. The precision and / or accuracy may result from measurements input into, used by, or output by the DFA. The measurements may be one or more physical parameters such as size, volume, shape, mass, area, or other quantitative values. The precision and / or accuracy for the physical parameters, e.g., within a predetermined tolerance, may be evaluated and recorded. The evaluation may relate to a true value, a deviation or error from a target and / or true value. The evaluation may be the presence or absence of a defect or other undesirable feature.

[0033] The user-related data may relate to a physical shape. The physical shape may relate to a physical shape input to, used by, or output by the DFA, such as the physical shape itself and / or a quantity of the physical shape, such as size, volume, shape, mass, area, or other quantitative value. The user-related data may be a type of product or service.

[0034] The user-related data may relate, for example, to the quantity of goods and / or services provided using a transaction, possibly a transaction performed through the DFA. The quantity may relate to the performance of the transaction itself. The quantity may be specification quality and / or conformance quality. The quality may be used in a quality control process, for example, by providing feedback that affects one or more variables of the DFA and / or the transaction and / or its subsequent configuration after performance by the DFA. The feedback may be regarding the presence or absence of one or more of defects, problems, glitches, faulty operations, faulty state transitions. The quality may be used in a quality control process, for example, by providing feedback that affects the design and / or operation of the DFA and / or the transaction and / or its subsequent configuration after performance by the DFA. The quality control process may be a quality assurance process. The feedback may affect one or more of the intensity of the process and / or process steps, the stability of the process and / or process steps, and the format of the process and / or process steps. The feedback may increase to the extent that the transaction conforms to its original purpose and / or rights in future configurations of the transaction.

[0035] User-related data may relate to a user's capabilities, such as the user's ability to complete a transaction and / or generally their portion of a transaction potentially implemented by a DFA. Capability may be a record of one or more of evidence of authority, knowledge, skill, experience, aptitude, certification, and particularly evidence of evaluation of one or more of these. Capability may be one or more of recognition and / or approval by a third party, such as membership in an organization and / or regulated body, a supervisory authority and / or legal entity, presence in a registry operated by a third party.

[0036] In the context of a contract, potentially as represented / implemented by a DFA, the contract may relate to a range of financial instruments. Possible financial instruments may include cash, evidence of ownership, and contractual rights to receive or distribute cash (such as bonds). Possible financial instruments may include cash instruments, possibly including one or more of stocks, securities, bonds, cash instruments, certificates, inventory, options, futures, and current assets. Possible financial instruments may include derivatives, possibly including one or more of assets, indexes, interest rates, loans, deposits, certificates of deposit, spot rates, and spot exchange rates.

[0037] A computer-implemented system and method are therefore provided for providing user-related data, such as reputation information, about users of a blockchain associated with a transaction. The method includes an approach that evaluates the satisfaction of a transaction, particularly in the context of a contract, and then provides a record of that on the blockchain through reputation information. As a result, at a later time, this reputation information is retrievable. Similar reputation information for other transactions can be retrieved and linked to the same user, for example, based on the use of a hash of the user's master public key. Aggregate reputation information can be computed from the retrieved pieces of reputation information.

[0038] In a preferred embodiment, particularly in the context of contracts, the provision of reputation and records can be implemented using a deterministic finite automaton (DFA). The method considers, for each user associated with each smart contract, the DFA not only configures and allows for the execution of the smart contract, but also the extent to which the terms of the smart contract are satisfied. Thus, the DFA generates reputation information associated with each user in each smart contract. In the derivatives example, this is actually credit rating information. The DFA provides for this reputation information to be published to, and therefore stored on, the blockchain.

[0039] Thus, according to certain configurations, user-related data, such as reputation information, is generated by the system itself, rather than by the user. An example of such an automated system is the use of DFA, as described above. However, in principle, this can be implemented by any automated blockchain system where the system, rather than the user, provides the reputation data. For example, reputation data may be generated by the blockchain system according to how well a user fulfills the terms when executing a digital smart contract on the blockchain system. This method provides more objective data than user-entered data, and is generated and stored in a more efficient and reliable manner.

[0040] The method is: (a) defining a transaction between at least one user and at least one further user; (b) performing the transaction; (c) providing user-related data from the transaction, such as an expression of satisfaction with the transaction by at least one of the users or at least one of the further users, thereby providing a user-related data representation, such as a user satisfaction expression; may further provide one or more of, for example, thereby providing the user-related data representation, such as a user satisfaction expression, for use in constructing a user-related data transaction, such as a reputation transaction, the user-related data transaction, such as the reputation transaction, including a user-related data representation, such as an expression of satisfaction with a previous transaction related to the user.

[0041] According to a second aspect of the present invention, there is provided a method of generating a record of user-related data, said method comprising: (a) defining a transaction between at least one user and at least one further user; (b) performing the transaction; (c) providing user-related data from the transaction for at least one of the users or at least one of the further users, thereby providing a user-related data representation; (d) constructing a user-associated data transaction, said user-associated data transaction including said user-associated data representation; (e) broadcasting the user-related data transactions to a blockchain.

[0042] The method may provide that the user-related data is reputation information. The user-related data from a transaction may be an expression of satisfaction with a transaction associated with the user. The user-related data transaction may be a reputation transaction. The user-related data transaction may include an expression of satisfaction with a previous transaction associated with the user. The user-related data expression may be a user satisfaction expression.

[0043] The second aspect of the invention may include any of the features, options and possibilities described in the first aspect of the invention.

[0044] According to a third aspect of the present invention, there is provided a method of calculating aggregate user-related data, said method comprising: (a) selecting a user for whom aggregated user-related data is requested to provide a selected user; (b) generating a filter associated with the selected user; (c) searching the blockchain for user-related data transactions to which the filter is applied; (d) calculating aggregate user-related data for the selected users from the user-related data transactions to which the filter is applied.

[0045] The method may provide that the aggregated user-related data is aggregated reputation information. The user-related data transaction may be a reputation transaction. The user-related data transaction may include an expression of satisfaction of a previous transaction related to the user. The user-related data from a previous transaction may be an expression of satisfaction of a previous transaction related to the user.

[0046] The third aspect of the invention may include any of the features, options and possibilities described in the first aspect of the invention.

[0047] According to a fourth aspect of the present invention, there is provided a computer-implemented system, including a system configured to perform the method of the first aspect of the present invention, and possibly to perform any of the functions, options and possibilities described elsewhere herein.

[0048] The system comprises: (a) a user digital wallet; (b) at least one computational agent configured to implement the DFA via a blockchain; (c) a blockchain platform.

[0049] The fourth aspect of the invention may include any of the features, options and possibilities described in the first aspect of the invention.

[0050] According to a fifth aspect of the present invention, there is provided a computer-implemented system, including a system configured to perform the method of the second aspect of the present invention, and possibly to perform any of the functions, options and possibilities described elsewhere herein.

[0051] The system comprises: (a) at least one computational agent configured to implement a DFA via a blockchain; (b) a blockchain platform.

[0052] The fifth aspect of the invention may include any of the features, options and possibilities described in the first aspect of the invention.

[0053] According to a sixth aspect of the present invention there is provided a system, preferably computer-implemented, configured to perform the method of the third aspect of the invention, and optionally including a system configured to perform any of the functions, options and possibilities described elsewhere herein.

[0054] The system comprises: (a) a user digital wallet; (b) at least one computational agent configured to implement the DFA via a blockchain; (c) a blockchain platform.

[0055] The sixth aspect of the invention may include any of the features, options and possibilities described in the first aspect of the invention.

[0056] Thus, according to the invention, options, possibilities and features may be provided or further provided from among the following:

[0057] The present invention may further provide, in particular in relation to the first, second, fourth and fifth aspects of the invention, but generally: The term "reputation information" may be substituted herein by the term "user-related data". The term "reputation transaction" may be substituted herein by the term "user-related data transaction". The term "expression of satisfaction of a previous transaction" may be substituted by the term "expression of user-related data".

[0058] The user satisfaction expression may be defined as a satisfaction score that quantifies the degree of satisfaction of the user with the transaction. The user satisfaction expression may reflect whether the transaction was completed or not. The user satisfaction expression may be a satisfaction value. The user satisfaction expression may be a satisfaction score, for example, a binary score.

[0059] The reputation transaction further includes attribute information about the user to which the user satisfaction expression relates. The attribute information about the user may be the user's address, such as a Bitcoin address. The attribute information may be the user's signature script or a hash thereof. The attribute information about the user may be the user's address, such as a Bitcoin address, and / or the user's signature script or a hash thereof. The attribute information may result from deterministic key generation performed for and / or on behalf of the user.

[0060] The reputation transaction may further include the transaction type of the transaction for which the user satisfaction expression was obtained. The transaction type may detail the content of the transaction. The transaction type may detail the transaction template used. The transaction type may be a contract type, for example a smart contract type. The transaction type may be one of a known list of transaction types according to which the transaction is typed.

[0061] The user satisfaction expressions may be included in the metadata of the reputation transaction. The user satisfaction expressions and / or attribute information and / or transaction type may be included in the metadata of the reputation transaction.

[0062] A reputation transaction may be a Pays To Script Hash (P2SH) transaction. A reputation transaction may be a multi-signature transaction. A reputation transaction may be addressed to an address controlled by a third party, for example, controlled by a DFA. A reputation transaction may send dust.

[0063] A reputation transaction may implement Figure 1. A reputation transaction Redeem script may implement Figure 2.

[0064] Reputation transactions may be implemented by a deterministic finite automaton DFA.

[0065] The method or system may include using a deterministic finite automaton DFA for one or more of defining a transaction, conducting a transaction, providing an expression of satisfaction, and configuring a reputation transaction. The method or system may include using a common deterministic finite automaton DFA for defining a transaction, conducting a transaction, providing an expression of satisfaction, and configuring a reputation transaction.

[0066] One or more of the transactions may be a contract, for example a smart contract.

[0067] The present invention may further provide, in particular in relation to the first, third and sixth aspects of the invention, but generally, in particular:

[0068] A user may be selected from users providing a transaction. A user may be selected by a select user. Multiple users may be selected by a select user, for example. A select user may be a user who is considered to enter into one or more transactions.

[0069] The selection may be made using the user's digital wallet, which may be provided with an interface for the user's selection, and which may be provided with an interface for displaying the aggregated reputation information and / or its further processing format.

[0070] The calculation of aggregate reputation information may be calculated for one or more or all of the selected users.

[0071] The filter may be constructed by obtaining an address hash from the selected user and / or a signature script from the selected user. The filter may be constructed from an address hash resulting from the selected user's public key and / or a signature script resulting from the selected user's public key. The filter provides a hash of the selected user's master public key.

[0072] The method and / or system may further provide users with access to and / or parsing of the blockchain.

[0073] The method and / or system may further provide that reputation transactions in the blockchain are considered using a filter, preferably to collect all reputation transactions picked up by the filter, for example to collect all reputation transactions including metadata picked up by the filter, most preferably to collect all reputation transactions picked up by the filter as being associated with the selected user's master public key and all derived public keys therefrom.

[0074] The aggregate reputation information may be subjected to further processing, which calculates one or more of a numerical reputation score, a reputation score, or a reputation rating relative to other users.

[0075] The aggregated reputation information and / or further processed forms thereof may be calculated selectively and / or just in time for presentation of a score together with an offer from a user and / or prior to any selection and / or prior to any transaction offer by a user.

[0076] The method of calculating aggregate reputation information may provide a method further comprising the step of presenting the aggregate reputation information to users, particularly users for whom the wallet has calculated the aggregate reputation information.

[0077] The method for calculating aggregate reputation information may further include a step in which a user makes a decision, the decision including consideration of the aggregate reputation information. The decision may include a decision to enter into a transaction with a selected user.

[0078] The method for calculating aggregate reputation information may further include a step in which the user and / or selected users perform an action. The action may include one or more of the following steps: providing information to the selected user; receiving information from the selected user; the selected user manufacturing a product for the user; the user selecting a product for the selected user; the selected user providing the product to the user; the user providing the product to the selected user; the selected user sending, shipping, or transporting the product to the user; and the user sending, shipping, or transporting the product to the selected user. The product may be a service and / or a good. [Brief explanation of the drawings]

[0079] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] Here is an implementation of a Bitcoin transaction. [Figure 2]The Bitcoin Transaction Redeem script associated with the Bitcoin transaction in Figure 1 is shown. [Figure 3] Shows the link between a transaction and the validation of the transaction. [Figure 4] Shows the flow of information from transaction to blockchain and then to wallet query. [Figure 5] 1 shows a schematic of a system in which the present invention may be incorporated; [Figure 6] We present a blockchain-based DFA implementation. DETAILED DESCRIPTION OF THE INVENTION

[0080] The proposed invention is the implementation of a user-related data recording system on a blockchain, more specifically the Bitcoin blockchain, and user-related data recovery and processing from the blockchain.

[0081] The method includes or provides an approach to providing a user-related data rating and then a record of the user-related data rating on a blockchain through a user-related data record.

[0082] In a preferred embodiment, the evaluation and provision of records can be implemented using a deterministic finite automaton (DFA). In the detailed example provided below, this is illustrated in a specific embodiment featuring a peer-to-peer derivatives trading platform, although other contexts in which user-related data is relevant are equally possible.

[0083] The method is that for each user involved in each transaction, the DFA not only configures and allows the transaction to be carried out, but also considers user-related data resulting from the transaction result, state. Thus, the DFA generates user-related data in each transaction. The DFA provides that this user-related data is published to the blockchain and thus stored.

[0084] As a result, at a later time, this user-related data is retrievable. Furthermore, as explained below, similar user-related data for other transactions can be retrieved and linked to the same user. In a preferred embodiment, this is based on the use of a hash of the user's master public key. The aggregate user-related data can be processed to provide a user value for that user. The user value can then be used in later evaluations and / or decisions and / or modifications.

[0085] In one embodiment, each user may utilize their Bitcoin wallet to retrieve user-related data from the blockchain and then process aggregate user-related data. The aggregate user-related data may then be displayed to the user through a wallet interface. This provides useful information to users, indeed customer users, counterparty users, and vendor users, which, among other possible benefits, helps users decide whether or not to enter into a proposed transaction.

[0086] The proposed solution is robust, efficient, decentralized, and anonymous.

[0087] The proposed invention offers the following possible advantages: It is distributed, thus avoiding large-scale single points of failure and not vulnerable to attacks; Free (usually only small transaction fees are expected under the Bitcoin protocol); · It is global and anyone with internet access can participate at any time; Once data is written to the blockchain, it is visible to everyone and is transparent; · It is immutable, once data is written to the blockchain, no one can change it; · Decentralized data record, storage, and retrieval system.

[0088] Although the following implementation details are provided in the context of reputation being an important type of user-related data, the present invention is applicable to a wide variety of user-related data.

[0089] User-related data arises as a result of inputs to blockchain transactions (e.g., user presence and participation) and as a result of outputs of blockchain transactions (e.g., user influence on the conduct and outcome). This allows the user-related data to be processed, user-related data evaluation, and obtain user-related data worth recording in the blockchain (in user-related data blockchain transactions). These individual pieces of user-related data are thus immediately available in the blockchain for later retrieval and collection, giving aggregate user-related data. This aggregate user-related data can then be processed. Processing can involve various subsequent stages, including: Possible evaluation of aggregated user-related data; and / or one or more decisions based on aggregated user-related data; and / or For example, changes to future blockchain transactions or processing variables, possibly affecting future blockchain transactions.

[0090] The decisions and / or changes may be likely to improve future transactions and / or cause future transactions to be successful or have a more successful outcome compared to previous transactions.

[0091] In various embodiments, for example, user-related data may relate to time. This may be the completion time of a blockchain transaction resulting from the DFA and / or the time of a state change within the DFA when performing a DFA operation. Multiple such times may be generated from the DFA as it operates. Retrieval of multiple records of such user-related data, including time, may be used to analyze DFA usage (as aggregate user-related data) and / or optimize the performance of the DFA, including the operations it performs. This may include optimizing the timing of services or goods passing through operations, for example, to improve throughput. Optimization may relate to people accessing locations, etc., by using control of variables during operation to effect timing changes. Time may inform reliability of operations, when available, what maintenance or services must be provided, etc.

[0092] In various embodiments, for example, user-related data may relate to accuracy and / or precision. Thus, user-related data regarding the accuracy and / or precision of user contributions may be collected and recorded. Accuracy and / or precision may relate to measurements input to, used by, or output by the DFA, such as physical parameters, e.g., size, volume, shape, mass, area, or other quantitative values. Thus, in the context of a DFA performing a screening process to accept or reject goods or services, physical parameters may be considered. Precision or precision, e.g., within a predetermined tolerance range, for the physical parameters may be evaluated and recorded. The evaluation may relate to a true value, a deviation or error relative to a target or true value, etc. The evaluation may be the presence or absence of defects or other undesirable characteristics. Multiple such results may then be considered together (as aggregate user-related data), for example, to identify rejection rates for different processes and / or to provide feedback to the control of the process to improve future processes.

[0093] In various embodiments, for example, user-related data may relate to physical shape. Thus, user-related data regarding the physical shape of a user's contribution may be collected and recorded. Physical shape may relate to a physical shape input to, used by, or output by a DFA, such as the physical shape itself and / or the quantity of the physical shape, such as size, volume, shape, mass, area, or other quantitative value. Thus, in the context of a DFA performing a logistics operation, physical shape may be considered. A particular physical shape may then influence or control operations within a logistics operation, such as the maximum mass (as aggregate user-related data) that can be handled by a particular size unit and / or inventory level. Similar principles are applicable to user-related data that is a type of good or service. Thus, user-related data may reflect outgoing sales and incoming replenishment supplies of a certain type of good and provide inventory levels (as aggregate user-related data).

[0094] In various embodiments, for example, the user-related data may relate to the quality of goods and / or services provided using, for example, a transaction, possibly a transaction conducted through a DFA. The quality may relate to the performance of the transaction itself. The quality may be specification quality and / or conformance quality. The quality may be used in a quality control process, for example, by providing feedback that affects one or more variables of the DFA and / or the transaction and / or its subsequent configuration after performance by the DFA. The feedback may be regarding the presence or absence of one or more of defects, problems, glitches, faulty operations, faulty state transitions. The quality may be used in a quality control process, for example, by providing feedback that affects the design and / or operation of the DFA and / or the transaction and / or its subsequent configuration after performance by the DFA. The quality control process may be a quality assurance process. The feedback may affect one or more of the intensity of the process and / or process steps, the stability of the process and / or process steps, and the format of the process and / or process steps. The feedback may increase to the extent that the transaction conforms to its original purpose and / or rights in future configurations of the transaction.

[0095] In various embodiments, for example, user-related data may relate to a user's capabilities, such as the user's ability to complete a transaction and / or generally their portion of a transaction potentially implemented by a DFA. Capability may be a record of one or more of evidence of authority, evidence of knowledge, evidence of skill, evidence of experience, evidence of aptitude, evidence of certification, and particularly evidence of evaluation of one or more of these. Capability may be one or more of approval and / or accreditation by a third party, such as membership in an organization and / or regulated body, a supervisory authority and / or legal entity, presence in a registry operated by a third party.

[0096] In the context of a contract, potentially as represented / implemented by a DFA, the contract may relate to a range of financial instruments. Possible financial instruments may include cash, evidence of ownership, and contractual rights to receive or distribute cash (such as bonds). Possible financial instruments may include cash instruments, possibly including one or more of stocks, securities, bonds, cash instruments, certificates, inventory, options, futures, and current assets. Possible financial instruments may include derivatives, possibly including one or more of assets, indexes, interest rates, loans, deposits, certificates of deposit, spot rates, and spot exchange rates.

[0097] In the context of a reputation system, the user-related data may be reputation information, and / or consideration of the user-related data may include assessing satisfaction with a transaction, and / or the transaction may be a contract, and / or the aggregate user-related data may be aggregate reputation information, and / or the user value may be a reputation expression or score.

[0098] In the context of reputation, there are various other situations that benefit from the use of reputation information associated with public keys. The meaning of reputation information or score depends on the context. For example, the meaning could be a score associated with playing an online game.

[0099] Reputation information, e.g., reputation scores, may be applied to hotels, restaurants, e-commerce sellers, contractors, or peers. It may be applied at the company, department, division, or individual level. It may be applied to all of a user's products (services or goods), or just to a collection of such products, or even to a single product. For example, with the right data, it may be possible to calculate a scientific research influence index, the h-index.

[0100] Reputation information, e.g., reputation score, may be an integer or real number. It may be weighted by recency. It may be an absolute rating or a ranking relative to peers.

[0101] As illustrated above, the principles of the present invention are applicable to a wide variety of user data. Although the detailed implementation below is provided in the context of reputation being an important type of data, the present invention may be implemented with other data as well, and therefore this embodiment does not limit the scope of the present invention or its implementation.

[0102] Trust is the very foundation of many aspects of social and economic life. When currency is a form of real capital, trust is a crucial form of social capital. However, how can you learn to trust someone you don't know but who wants to transact with you over the internet?

[0103] A reputation system is a program that allows users to rate each other within an online community in order to quantify trust and encourage trustworthy behavior through reputation.

[0104] Reputation systems are essential for decentralized applications like e-commerce websites, where users need to trust each other. Reputation measures how much a community trusts you and is calculated based on your previous transactions and interactions with other users within the community and / or ecosystem.

[0105] One aspect of your reputation can be measured by your satisfaction with the contracts you enter into with other users, or counterparties. The higher your reputation, the more trustworthy you appear to be on the network, which encourages interaction with you. Furthermore, a user's online reputation will likely lead most users to choose to behave more honestly on the network.

[0106] The reputation system calculates and publishes reputation information, which can take many forms such as a score, a credit rating, a credit score, a rating, etc. The reputation information can be associated with a collection of services.

[0107] Reputation has an excellent track record of enabling collaboration in a wide variety of settings, e.g., online marketplaces like eBay or blockchain-based auctions. It is therefore not surprising that many peer-to-peer (P2P) systems employ some form of reputation scheme to reward good behavior and / or punish bad behavior by peers.

[0108] However, there are issues with the reliability of such reputation systems, their susceptibility to attack or manipulation, and the breadth of context in which they can be used.

[0109] Certain embodiments described herein relate to P2P derivatives such as options, futures, or futures trading on the Bitcoin blockchain as part of a P2P derivatives reputation ecosystem. In this particular embodiment, the DFA provides reputation information to the blockchain, while user wallets generate aggregate reputation information and then process it into a quantified reputation, a measure of trust in the user.

[0110] The implementation of the present invention is described through the following: Generate transactions that include attribute information; Processing and recording reputation transactions that include reputation information on the blockchain together with attribute information; For the selected user, extracting attribute information of the selected user, and consequently reputation information of the selected user, by the customer user's wallet; Processing the reputation information to provide aggregate reputation information and thus a quantified reputation by wallet of the customer user.

[0111] Vendor wallets and sources of measurement information In this example, based on the derivatives, there may be a set of user-provided contracts that may or may not be selectable for entry by another user. For ease of identification, the user who offers the contracts is designated as the vendor user, and the user who selects the contracts is designated as the customer user. Of course, both users may offer and accept contracts. A contract may involve many more than two users, and therefore these designations are not a limitation on the scope of the present invention.

[0112] The vendor-user has a wallet, and the vendor-user's wallet contains the information needed to conduct a transaction, which in this case is a contract, including the public and private key pair needed for the transaction. As a piece of software, the vendor's digital wallet acts as a container and provider of public keys, usually implemented as a structured file or simply a database.

[0113] An increasingly popular method of generating key pairs is deterministic key generation. These make it relatively easy to generate a large number of keys from a single "seed." The generation uses the seed to generate a master key. The master key can be used to generate a set of child keys, where each child key can generate a set of grandchild keys, and so on through many generations. All keys are linked by a hierarchy. Only a single master key is needed to generate the entire hierarchy of keys.

[0114] There are numerous advantages to using deterministic key generation, and particularly hierarchical deterministic key generation, which encourage their adoption and use. Therefore, the properties they possess, upon which the present invention is built, are those that utilize the majority of the keys.

[0115] Full details of a suitable approach for generating keys in this way are available from the methods described in the BIP0032 standard, Wuille, P. (2012), BIP 32: Hierarchical deterministic wallets, see GitHub.

[0116] Transactions conducted with DFA As mentioned above, the present embodiment relates to smart contracts, including the construction and execution of smart contracts by associated users that play a role in reputation information in conjunction with the present invention. A deterministic finite automaton (DFA) represents one possible way of executing smart contracts for each user participating in P2P derivatives trading on the Bitcoin blockchain.

[0117] Further details on the use of DFAs in implementing smart contracts are provided in the section "Using DFAs in Smart Contracts" provided at the end of this specification.

[0118] We used DFAs in our example because they are useful tools for managing the state of (financial) contracts, but we could add the functionality of the present invention to a Bitcoin wallet that does not use DFAs.

[0119] A significant number of users may be associated with a contract that is structured and implemented using DFA. Each user is associated with their private and public key pair that is used to effect transactions. The previous section explained that these can be generated by a deterministic wallet and thus relate back to a master key.

[0120] In the case of a vendor user, the seed is used to generate a master private key. The master private key is used to generate a master public key, which is used to generate one or more generations of other public keys. The vendor user's wallet selects one of these other public keys to fulfill the transaction represented by the contract. As a recipient, the vendor user must provide a Bitcoin address.

[0121] A Bitcoin address is obtained by taking the other public key to be used and running it through a cryptographic hashing algorithm to obtain a hash of the other public key. More specifically, this is the calculation of a SHA256 hash followed by a RIPEMD160 hash. The resulting hash of the other public key is typically encoded using Base58Check before being used as the other public key's Bitcoin address for use in a contract such as a transaction.

[0122] Once a contract is constructed, its enforcement and outcomes occur over time. The outcomes indicate that user X associated with the contract has satisfied the conditions imposed on them by the contract, or that user X has not satisfied the conditions imposed on them by the contract. Because such contracts are complex and may involve multiple users, the outcomes of satisfaction may be visible to all these parties.

[0123] In addition to structuring, executing, and resulting from transactions, the DFA may also execute further transactions to reflect the observed satisfaction position of the user with respect to the contract.

[0124] Satisfaction is reflected in a satisfaction value, or preferably a satisfaction score, which in a preferred form is a binary score for the user with the contract.

[0125] If the contract clauses applicable to our vendor user are satisfied, a score of 1 is generated. If satisfaction does not occur for at least one of the contract clauses applicable to our vendor user, a score of 0 is generated. Satisfaction, and more specifically the score in this embodiment, may be determined by the DFA in parallel with the processing of the contract.

[0126] The DFA can also determine the transaction type, for example, from the specification of the transaction or transaction template used. In this particular example, the transaction is a contract, but the transaction type is more specific than, for example, a particular type of P2P derivatives contract can be used as the transaction type.

[0127] Finally, the DFA is, of course, provided with the Bitcoin address of the vendor user for the contract being implemented. This constitutes attribute information in the sense that it is linked to the vendor user. This is a property of a Bitcoin address. In the alternative where the user is a paying user who is also a customer user, the DFA is provided with a public key or signature script that is also attribute information in the sense that it is linked to the customer user.

[0128] Given this transaction information, the method uses the DFA to perform a further transaction, a reputation transaction, in which the DFA provides that the reputation transaction metadata includes three pieces of metadata: the transaction type of the contract, attribute information associated with the contract (e.g., a Bitcoin address or signature script), and the satisfaction of the contract for the vendor user (e.g., a score).

[0129] The DFA then generates a reputation transaction, which in this embodiment is Bitcoin transaction T1, that includes this metadata along with 1-of-4 P2SH multi-signature outputs and sends "dust" from itself (a negligible amount of Bitcoin) to an address also controlled by the DFA agent. Figure 1 shows the implementation of the Bitcoin transaction. Figure 2 shows the Bitcoin transaction Redeem script. Figure 3 shows the links between the various transactions. It can be seen that all transactions are standard P2PKH or P2SH multi-signature transactions and are valid.

[0130] A key advantage of storing this reputation transaction, and therefore the reputation information it contains, on a blockchain is that the blockchain is immutable, which reduces the opportunity for unfair reputation attacks. While reputation transactions are a useful intermediate form in their own right, they also enable the later advantages of the present invention.

[0131] Typically, a transaction cannot be broadcast prior to adoption of the proposed invention for it to be considered by the DFA mechanism and used in determining reputation information from the transaction. However, each time a Bitcoin transaction is unlocked, the public key is exposed in the signing script, and therefore the history of transactions associated with a particular public key is always available.

[0132] Use of customer wallets for extraction and processing The embodiment now turns to the perspective of a customer user. The customer, in this example, is interested in P2P derivatives trading over the Bitcoin blockchain. They may therefore be offered a large number of such transactions from a large number of users, including the vendor users mentioned above in the example. The contracts offered may be the same or very similar in terms of their format, risk profile, and price, as well as other such variables between different users offering transactions.

[0133] Through the customer user's digital wallet, the customer user may be able to make one or more of a number of inquiries. These may relate to a particular user offering a transaction, or to each of users offering the same type of transaction. Using the example of an inquiry about a single user, our customer user is interested in contracts offered by our vendor user. Therefore, the customer user may select the vendor user through a wallet function in the customer user's wallet to begin researching the vendor user's reputation.

[0134] The customer user's wallet knows the Bitcoin address of the vendor user providing the transaction because the Bitcoin address is part of the contract in which it is provided. The Bitcoin address is a hash of a specific public key provided in the contract and therefore relates back to the master public key. As a result, the customer user's wallet can determine the vendor user's master public key, which is behind the specific other public key. In this regard, any hash function, such as SHA-256, may be used to hash the master public key.

[0135] The customer user's wallet can then access and parse the blockchain to search for past reputation transactions within the blockchain and filter those transactions by the hash of the master key obtained for the selected vendor user. Each of the reputation transactions within the blockchain can thus be found using a derivation of the common master public key associated with the vendor user selected in the customer user's query. Thus, the wallet extracts reputation information from the blockchain for each transaction linked to the master public key and therefore to the vendor user.

[0136] Upon extracting the reputation information, the customer user's wallet may then further process the information. For example, a reputation calculation algorithm may perform calculations on the retrieved reputation information. This may result in an aggregate reputation score for the user. The results are displayed within the customer user's wallet. For example, in the case of reputation information for a single selected user, the wallet may consider the total number of reputation transactions before recording a positive reputation result from the transaction and the total number of reputation transactions before recording a negative reputation result from the transaction. The wallet may represent the balance of positive and negative reviews for the customer user as a trust score. The process may consider information for other users not selected and provide a relative rating. The process may consider the total number of reputation transactions that result (in this case, this number is small and therefore not very robust) and provide a weight for the score and / or an indication of the reliability of the score.

[0137] The aggregate reputation score based on users through hashes of their master public keys may be calculated at any time, for example, by choice, in conjunction with the time of presentation of the score with an offer from the user, or prior to any choice or user offering of the transaction to the customer user. The timing may reflect a choice balance or trade-off between speed and accuracy and / or recency of the score.

[0138] The flow of information is shown in Figure 4. As a result of the execution of a transaction by the DFA, the DFA provides a record of reputation information to the blockchain through an additional and new reputation transaction. When needed or requested, the reputation information flows from the blockchain to the customer user's wallet for processing.

[0139] While implementations of the present invention have been described above in the context of public keys hierarchically derived from a common master public key, the present invention can be practiced in the context of wallets other than deterministic wallets. For example, a user has a number of options for implementing the approach. These include: (1) using the same public key for each transaction, which can then be used as their master key, but preferably generating a separate address for each transaction (reusing the same Bitcoin address for multiple transactions is not recommended for security reasons); or (2) using a random public key each time, both of which are identified by the same "master key" each time. However, preferably, a user has a hierarchical deterministic wallet, since there is an automatic master key and the inherent advantage of such a wallet is not present for the user to back up.

[0140] Using DFA in smart contracts This chapter is provided to provide background on how DFA enforces smart contracts.

[0141] In the context of this description, a definition of a DFA is provided that models a contract-like process or task. A DFA interacts with an associated system of computational resources, which may be referred to as computational agents or "bots." These computational agents are configured to generate transactions and submit them to a blockchain. While this embodiment of a DFA relates to contracts, the use of a DFA is not limited to contracts.

[0142] Referring to FIG. 5, the present invention provides a processing implementation as an abstract DFA embodied on a computing platform—a blockchain—which includes hardware and software components.

[0143] Figure 5 provides an overview of a system configured in accordance with an illustrative embodiment of the present invention. The system has computational agents 3 that can interact with other entities 4 (e.g., humans or other computers) to receive instructions. These instructions may be, for example, which smart contracts to create and execute. Thus, the computational agents 3 implement the present invention by interacting with the physical world to respond to and generate events in the "real world" outside of themselves.

[0144] The specification of the contract itself may be provided in any machine-executable format, for example xBRL, and stored in a secure and decentralized manner, for example in a distributed hash table (DHT) 5 on the torrent network. From the contract specification, a computational agent constructs a DFA 2, which is later instantiated on the blockchain 1 by one or more agents.

[0145] The DFA2 itself is specified as a finite set {S, I, t, s0, F}, where S is the (finite) set of possible states that the contract / DFA can be in, and I is the (finite) set of inputs (also known as alphabet), which in the context of this specification mean any event or condition that can occur in connection with the contract, such as a payment being made, a security reaching maturity, a counterparty defaulting, etc. In our mechanism, these input signals are received / generated by one or more agents, which then determine the next state (possibly the same state) of the system.

[0146] The third component of a DFA is the transition function t: S × I → S. The term "determinism" in "DFA" refers to the uniqueness of the decision: given a state and inputs, there exists one and only one new state (possibly the same state). Thus, given an initial state (S0) and a history of inputs, the outcome of a computation (contract) is a unique one among the set of all possible final outcomes (F ⊆ S). Once all these elements are established, the DFA is fully defined by a transition table, which specifies all possible current and future states for all possible input signals. The states of a DFA are themselves associated with unspent transaction outputs (UTXOs) on the blockchain. As is known in the art, the Bitcoin network keeps track of all available UTXOs. According to an embodiment, the mechanism by which a DFA transitions from one state to another is embodied (implemented) in accordance with the present invention by blockchain transactions. In effect, a transaction on the blockchain consumes UTXOs associated with one state (the inputs of the previous transaction) and generates UTXOs associated with the next state (the output).

[0147] Example: Discount (zero coupon) bonds For illustrative purposes, we consider a discount (zero-coupon) bond, a simple class of bond typically purchased at a price (usually a discount to its face value) and then held for a specified time until the principal is repaid at maturity. The possible states we consider are S = {s0,f0,f1}, which denote the holding state (s0), the successful (lucky path) or happy ending of the contract (f0), and the failed, e.g., litigation, state (f1). The final state of the system is therefore F = {f0,f1}. The alphabet we consider is I = {r,d,e}, which denote the repayment of principal at (or before) maturity (r), the issuer's default at (or before) maturity (d), and the expiration of the contract without repayment (e), respectively. The transition matrix for this simple contract is shown in Table 1.

[0148] [Table 1] DFA transition table for zero-coupon bonds

[0149] [Table 1] It should be noted that the final states represent the completion of the contract, and therefore no further states need to be specified from them (currently shown as "-" in the transition table, but these lines could be omitted). In principle, more states and / or inputs (and actions) could be defined for this instrument, but this is not done herein for the sake of simplicity and clarity, in order to explain the basic novel aspects of the invention rather than inserting distracting details related to the complexity of the contract.

[0150] Figure 6 shows an embodiment of a zero-coupon bond DFA on the (Bitcoin) blockchain. States are represented by circles, and Bitcoin transactions that move the machine from one state to another are represented by triangles. Note that in Figure 6, inputs received by the agent are omitted, but in each state, one or other transitions should occur according to these inputs, and this is reflected in the diagram by the composition of one or other Bitcoin transactions (e.g., t0 or t1 in state s0); transitions that do not change state do not require transactions, and therefore are omitted. The transition transactions (t i ), plus the initial occurrence transaction (o) and the transaction corresponding to the completion of the contract (c i ) is possible.

[0151] In what follows, we focus on the flow of funds in a transaction (origin, transition, and completion). Importantly, we note that due to the finite nature of DFAs and (financial) contracts, the process is completed after a number of transitions. This does not necessarily mean that the maximum cost of establishing and executing a contract is joint and can be determined in advance, e.g., at the time of establishing the DFA (assuming some finite fees for the computational agents and Bitcoin miners involved). It is given by the total amount of funds required to execute the contract along the longest possible path. This, of course, precludes the possibility of infinite loops during execution, but we note that this is not relevant for current (financial) contracts; even contracts such as perpetual bonds, despite their name, are obligations that must be completed at a specific point in the future, e.g., when the indebted entity disappears or inflation makes the payment negligible.

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

[0153] 1. Blockchain 3 Agent 4 World

Claims

1. 1. A computer-implemented method for generating aggregate user-related data, the method comprising: (a) selecting a user for whom aggregate user-related data is requested to provide a selected user; (b) generating a filter based on the public keys of the selected users; (c) applying the filter to search a blockchain for user-related data transactions to obtain the user-related data transactions associated with the selected user; (d) extracting user-related data representations from one or more of the retrieved user-related data transactions associated with the selected user to generate aggregate user-related data for the selected user; A method comprising:

2. The method comprises: (a) defining a transaction between at least one user and at least one further user; (b) performing the transaction; (c) determining a user-related data representation resulting from (b) that is associated with at least one of the users or at least one of the further users; The method of claim 1 , further comprising one or more of:

3. 1. A computer-implemented method for generating aggregate user-related data, the method comprising: (a) selecting a user for whom aggregate user-related data is requested to provide a selected user; (b) generating a filter based on the public key of the selected user; (c) applying the filter to search a blockchain for user-related data transactions to obtain user-related data transactions associated with the selected user; (d) extracting user-related data representations from one or more of the retrieved user-related data transactions associated with the selected user to generate aggregate user-related data for the selected user; A method comprising:

4. The method of claim 1 , further comprising providing an evaluation of the generated aggregated user-related data, the evaluation providing a decision and / or action and / or modification.

5. The decisions and / or actions and / or changes are (a) the modification of one or more inputs to one or more further transactions, such as blockchain transactions; (b) a change in one or more outputs from one or more further transactions, such as blockchain transactions; (c) Deterministic Finite Automata (DFA) Variation; 5. The method of claim 4, wherein the method results in one or more of:

6. The decisions and / or actions and / or changes are (a) feedback to modify and / or optimize the design and / or production and / or storage and / or distribution and / or consumption of services and / or goods; (b) feedback to modify and / or optimize processes for the design and / or production and / or storage and / or distribution and / or consumption of services and / or goods; 6. The method of claim 4 or 5, further comprising providing one or more of:

7. 7. The method of any of claims 4 to 6, wherein the decisions and / or actions and / or modifications provide feedback for modifying and / or optimizing a contract, such as a smart contract.

8. The method according to any one of claims 1 to 7, wherein the users are selected from users who offer transactions.

9. The method of any preceding claim, wherein the filter is constructed from address hashes derived from the public keys of the selected users.

10. The method of any preceding claim, wherein the filter comprises a signature script derived from the public key of the selected user.

11. The method of any preceding claim, wherein the filter is a hash of the selected user's master public key.

12. The method of claim 1 , wherein the filter collects all reputation transactions that include metadata related to a selected user's master public key and all derived public keys therefrom.

13. The method of any preceding claim, wherein the selection is made using a user's digital wallet.

14. A method according to any preceding claim, wherein the method comprises selecting a plurality of users and generating aggregate user-related data for each of the plurality of users.

15. The method of claim 1 , wherein the aggregated user-related data is aggregated reputation information.

16. 16. The method of claim 1, wherein the user-related data transaction is a reputation transaction and / or the user-related data transaction comprises an expression of satisfaction with a previous transaction related to the user.

17. A system configured to perform the method according to any one of claims 1 to 2.

18. The system comprises: (a) a user digital wallet; (b) at least one computational agent configured to implement the DFA via the blockchain; (c) a blockchain platform; and 20. The system of claim 17, comprising:

19. A system configured to perform the method according to any one of claims 3 to 14.

20. The system comprises: (c) at least one computational agent configured to implement the DFA via the blockchain; (d) a blockchain platform; and 20. The system of claim 19, comprising:

Images