This umbrella document describes a distributed platform open to public participation for managing the automation of tasks that interfaces with a Blockchain protocol. Although it is to be understood that the invention is applicable to any cryptocurrency Blockchain, throughout we will refer to the bitcoin Blockchain as the primary example. A peer-to-peer network of incentivised nodes (hosts) working in parallel to the Bitcoin network, a botnet, shall execute cellular agents that to perform a variety of duties that contribute towards the goal of completing a function.
Background
What is the technical problem that is being solved?
The overall technical problem is to design a set of protocols and processes for a Blockchain-enabled system of Autonomous Agents that can perform a variety of functions. The reason for integrating the system with the Blockchain is to benefit from its many advantages over traditional technologies. These include the potential for lower transaction fees; independence from central authority; privacy; high security; robustness against attack or natural disaster, and so on.
What is novel and inventive in respect of the solution (in terms of both the overall, “big picture”)?
The concept of a network of autonomous agents has some degree of prior art. However, there are many different ways to implement this. Many of these ways also may already have been discussed in the public domain. Nevertheless, our solution is based on using the existing bitcoin Blockchain in novel ways as a key mechanism within the design, for example, in the way cellular agents are managed and controlled; how hosts (and/or bots themselves) are paid; the way Bots are authenticated; the way bots are distributed; how bots inter-operate; the way bots are updated to latest versions (and so on).
What is the motivation for the project?
Automata-Management is essential for many of the projects and stand-alone inventions planned to be implemented — that is, the projects when in operation will be automated by deployment of Bots running on host machines distributed across the internet. The projects include P2P Exchange; DFA (any type of contract including Trusts); DAC/DASO; IoT Control.
How is Automata-Management different from relevant prior art?
There are of course competing entities that are using similar concepts and/or technologies and some of these have a head start (such as Ethereum, Zennet). Our solution is primarily designed for the bitcoin Blockchain, which confers certain advantages over rival technologies. Bitcoin is by far the largest cryptocurrency with the widest adoption. Bitcoin has a trusted development community yet remains under no central control. Bitcoin has the highest value and market capitalisation. Furthermore there are intangible factors such as the perception of its superiority in being the original crypto-currency and its current stability.
Rival entities are not yet fully accepted in the market and utilise new and less developed cryptocurrencies. The DAO was built on Etheruem but was hacked. Zennet never got off the ground and was replaced by Tau-chain. By contrast bitcoin is much more firmly established and thus provides a more stable and trusted platform for the upcoming Blockchain-based technologies.
Overview
A bot is shorthand for External Autonomous Agent. For our purposes, a bot has the following characteristics:
- External. The bot is a chunk of code that performs a specific task and usually interacts with the Blockchain, but runs externally to the Blockchain. This means the code is not contained within a cryptocurrency transaction (i.e. is not written in bitcoin Script to be executed when the transaction is spent — that technique is the subject of an alternative suite of white papers)
- Autonomous. The bot is self-controlled. That is, the host machine on which the bot runs does not control the bot but only provides computer resources for the bot to execute. The bot may be stand-alone but will usually be part of a network of interacting agents.
- Agent. The bot is expected to be executed on host machines that are part of a network of participating hosts. Therefore the bot will usually be executing logic on behalf of a client that is not the host on which it is running.
A botnet or ‘host-net’ consists of a number of Internet-connected computers that may be operating individually or in concert with other internet connected computers. The Bitcoin protocol runs on a peer-to-peer network, and a botnet hosting bots can run on another peer-to-peer network in parallel. In practice these networks will have substantial overlap, as many bots are expected to interact directly with the Blockchain and hence their executing hosts must be part of the bitcoin network. Such a botnet lends itself particularly (though not exclusively) to a distributed computing project involving public participation.
The idea of a platform for distributed computing projects involving public participation is not new, for example BOINC (Berkeley Open Infrastructure for Network Computing) includes successful projects such as SETI@home and Rosetta@home. Whilst Gridcoin is a cryptocurrency that rewards participants for participating in BOINC. Although rather than science, our focus is likely to be business and finance, for example automated contract management. Furthermore, rather than voluntary, the participants in the proposed system most likely will be remunerated. Botnets have been used since 2001 for denial-of-service attacks, spyware, email spam, click fraud and mining bitcoins. Although the term is usually associated with malicious tasks, our proposed implementation of a botnet shall not be used for malicious purposes and will engender controls to ensure this. Relevant prior art includes Ethereum and Zennet (http://zennet.sc/), a public decentralised and free supercomputer that allows the general public to profit from their hardware, which has evolved into Tau-Chain and Agoras.
Specification
This proposed scheme consists of a suite of high-level technical specifications for processes and protocols to enable participating entities to seamlessly enlist and leave at will. The following model will be used as a framework for the umbrella description:
In Figure 1 the entities are as follows:
Client. The Client is any entity that wishes to utilise the resources available on the botnet to perform a useful function, for which the Client may pay fees. For example, the Client may be a research organisation that requires massive parallel processing, or the Client may be an individual with a well-defined business idea that it wishes to automate.
Service Provider. The Service Provider is an entity such as a private company that conforms to the Automata-Management protocols and provides enabling services for clients to engage the botnet. The types of services provided would include (for example):
- Creating Bots to satisfy a Client’s requirements
- Distributing Bots to participating Hosts
- Arranging automated financial transactions (i.e. collecting payments from Clients and making payments to Hosts)
- Other administration activities (such as monitoring bot performance, security, legal/regulatory requirements, etc)
- Host. The Host is an entity such as an individual or a company willing to commit resources (mostly CPU and data storage) to the botnet, which also conforms to the Automata-Management protocols.
A Service Provider wishing to provide Bot management services will need to implement a system that conforms to all the protocols described within the Automata-Management suite of white papers. An example of a system that might be implemented by an SP is schematically depicted in Figure 2. In this diagram several potential patents have been identified (highlighted in red) and have been allocated white paper numbers.
In the following sections, each major process and/or protocol will be described at a high level. Where potential patents have been identified for these, full technical specification will be described in separate white papers. Where no patent potential has been identified the description will remain only at a high level (i.e. within this document), with an expectation that the technical specifications for these designs will be primarily an engineering problem to be addressed during a subsequent development stage.
Automaton Business Administration
Client and Host interfaces
Registration and KYC. An entity (such as a private company) that wishes to become a Automata-Management SP will need to establish interfaces for interacting with their clients and with the hosts on the hostnet. This will involve common practices such as maintaining KYC (Know Your Client) databases including login and password protocols. For a Automata-Management implementation these databases should record information important for the operation of the system. For example, the SP might wish to keep a record of the hosts’ available computer resources (i.e. their computer specifications and data storage capacity, etc.) in order to ensure that any bots to be executed by the host are able to run effectively. In addition, the hosts’ preferences may be recorded to ensure that only ‘suitable’ bots are executed by them. As part of the SP’s registration process for both clients and hosts, the SP may wish (or be required by regulation) to vet them based on (for example) reputation; credit rating, or other criterion.
Distribution (WP0303). SPs will need a way to advertise to prospective hosts that they have bots on offer to be executed. A standard protocol for this will enable any SP to make their bot offers visible to any prospective host. We will design a common protocol that allows any service provider to get into the market. This will involve designing suitable data formats and utilise decentralised techniques such as a Distributed Hash Table (DHT). Once a host has elected to execute an offered bot and has registered with the SP, a protocol is required for the secure download of the bot onto the host machine. This will most likely use a version of the secret sharing scheme to enable encrypted files to be sent and automatically decrypted. The protocol will also specify other considerations such as indemnity issues, post execution ‘clean-up’ (no residue on the host machine), etc.
Characteristics (WP0301). A standardised set of parameters will be designed that specify a bot’s characteristics, including: operating characteristics (resource requirements, execution time, operating constraints (e.g. time of day), etc); function type (e.g. business/scientific; industry sector; external data sources; etc); certifications (government or industry body); and so on. The purpose is not only for matching bots to hosts for technical suitability, but also a common protocol for the sake of client and host safety/reliability. For example, a prospective host may wish to avoid bots that work in certain industries such as tobacco or gambling.
Payment Facilities
Alternative Payment methods (WP0290). The SP will need to collect fees from the client and arrange payment (where applicable) to the host. Traditional methods of payment should not be discounted, however, the main innovations will be in using payments on the Blockchain in bitcoins. Alternative fee structures will be standardised. For example, fee amounts could be based on any number of factors relating to the bot execution, such as:
- Pay rate based on CPU usage
- Pay rate based on storage space usage
- Pay rate based on number of bot executions
- Pay rate base don length of time the bot is executing
- Payment based on a pre-determined ‘success criterion’
- Payments made if the bot triggers a particular event (for example, a BUY order is generated)
In addition, there will be several alternative payment mechanisms, including:
- ‘Normal’ bitcoin transactions
- Tokenised bitcoin transactions
- Payment channels
In some cases, payments may be directly integrated into bitcoin transactions being utilised for other purposes (such as for bot control; record-keeping; messaging; etc).
Tendering
SPs may wish to set up a facility to allow competitive tenders for both clients and hosts. For example, hosts may be able to ‘bid’ for the right to execute certain bots by offering to execute them at a lower rate than rival hosts. This process need not employ any innovative Blockchain related methods.
Automata Technical Administration
Security
There are several aspects to the issue of bot security. At the very least, bots should be encrypted during transmission — i.e. when a host is downloading a bot from the SP. Existing mechanisms could be used for this (i.e. TLS). Alternatively, we could enable this via our own secret sharing technique based on bitcoin keys. Further security is required in regard to uniquely identifying/certifying bots and (in some use cases) to maintaining bot function privacy (i.e. in which the specific function of the bot is kept secret even from the host that executes it).
Cryptographic Key Management (WP0296). Our protocol includes a unique identifier for each bot, which will consist of a BCH address. Bots will be able to securely create ECDSA cryptographic key pairs and generate their BCH address from their ‘primary’ (master) key pair. Several different levels of security strength may be employed by the bot depending on the particular security requirements. For example, knowledge of the Bot’s private key might be restricted to the SP or may be restricted to the host machine or may be unobtainable except with explicit permission from several parties (such as any number of: client, SP, host, regulatory authority; escrow service; trustee, etc.). This will be enabled using a protocol based on the key splitting technique. Protocols will be designed that enable the level of security required, by using secret sharing and key splitting techniques combined and (where appropriate) storage of key parts in different locations (e.g. one part on the SP’s server and/or another part on the host’s machine, etc).
In some cases, the bot’s BCH address may also need to be kept secure. This can be achieved by allocating the hash of the bot’s BCH-address as its unique identifier.
Function Secrecy (WP0302). Usually, the function of a bot will be publicly known. In some cases it may be desirable to keep the function of a bot secret. That is, the function is not open to public view, not even the host that executes it. This might be the case for example, if the client is executing a secret algorithm in the bot. In such cases, it will be necessary to enable hosts to execute secret bots without risk of liability or illegality or danger of harm to themselves or their resources. A protocol will be designed that (1) enable bots to be securely created, downloaded, and executed without the code ever being known; and (2) enables prospective hosts to ensure that any secret bots they execute are ‘safe’ to do so. This will be closely linked to WP0301 in that categorisation/certification of bots will be part of the solution for (2). For (1), techniques will include secret sharing, key splitting and encryption/decryption.
Internal Databases (Rules)
Any function executed by a bot will be codified to ensure re-usability. This will be particularly important for standardised wrapper modules (see below for explanation) as these form the basis for standardising the administrative functions of bots in our protocol. The intention is to design tables, parameterised functions and variables in a replicable manner that enables any atomic bot operation to be systematised. The values for the variables and parameters will be derived from higher level rules — for example, business rules or contract terms/conditions. This technique allows several options for execution of the codified function given the variable and parameter values:
1. Manual coding. A programmer can interpret the information in order to write the bot code for the function.
2. Compiled code. A Bot Compiler can be written that automatically generates the bot code based on the supplied values.
3. External Server. An Interpreter can be implemented on a trusted external server that takes the variable/parameter values as input and executes the associated logic.
For example, the way bots communicate with other entities will be codified in this way, such that the communications module of the bot can be easily derived from supplied input variables and parameters (see the section ‘Bot Communications (WP0297)’ below).
Bot Instantiation
Protocols for creating or ‘instantiating’ bots will be designed such that bots will be standardised and inter-operable. The basic model for instantiation is shown in Figure 3. The central column in Figure 3 represents a schematic of a bot: there is a core function which performs the requirements for the client and this is wrapped by several optional standard routines. Examples of the standard ‘wrapper’ routines are shown to the left of the central column; each routine is itself broken down into one or more subroutines and sub-subroutines. These routines are designed to be ‘plug-and-play’ and any of them can be plugged into the bot depending on requirements. For example, if a bot is expected to interact with the Blockchain then it will need to have the ‘Transaction Manager’ module plugged in.
The right side of Figure 3 depicts the input for the client function part of the bot. This is made up of library functions (i.e. reusable functions that other clients have requested in the past) as well as any bespoke functions that need to be created from scratch. Functions that are not already in the library will need to be created (in a flexible, parameterised fashion) and if reusable will be added to the library. The function may be manually coded by a programmer, or potentially it may be compiled directly from a set of business rules via the DFA project.
Wrapper Modules
Some wrapper modules will not require innovative techniques. For example, the ‘stats tracker’ (which will collect data such as CPU usage; data storage usage; etc., which for example might be used in the calculation of the host payment) could use existing off-the-shelf technology. Similarly, the purely admin modules such as the termination routine may not utilise any innovations. However, there are several potential innovations in other modules such as the communications protocol (which might utilise the Blockchain as a medium for messaging) and transaction manager.
Communications (WP0297). A protocol will be designed that flexibly enables any type of communication with bots. For example, between bot and another bot, bot and SP; bot and Host; etc. There are several different ways communications can be achieved with different advantages/disadvantages according to the specific communications requirement, and these options will all be included. Many of these methods will utilise innovations such as the Blockchain or DHTs. The protocols will be codified such that the implementation of a bot’s communications logic can be generated from the supplied variables and parameters. Each time a new type of communications becomes necessary (i.e. one that has not already been codified and logged into the internal database) then it will be immediately codified and logged to enable reuse. Table 1 is a sketch of the variable structure that will be used for the Bot Communications wrapper module.
For each code there will be a separate code table that lists out the available codes and their meanings/usage along with any required parameters. For example, the MSG-Protocol code table would include a code for ‘send message as bitcoin transaction’ which itself would include a list of required parameters specific to this code, such as INPUT-TX-ID (the source transaction to be ‘spent’); BCH-AMT (amount of BCH to spend); etc.
Transaction Manager (WP0305). Bots may have to interact directly with the Blockchain by creating/storing/validating/broadcasting bitcoin transactions. There are several purposes for this. For example, the bot may need to make payments (to the host on behalf of the Client or SP; to the Client as a result of some success criterion; to itself as a way to fund its own operations; etc.); or, the transaction is part of a non-payment protocol (such as a communications method; a recording of an event on the permanent ledger; an execution of a contract embedded in a transaction script; a DFA state transition; etc.). A protocol will be devised to enable any kind of transaction-related operation by a bot. The various operations will be codified and consideration (such as security, source transactions, etc) will be accounted for in the design.
Library Functions
Library functions may or may not involve innovations and this depends on the function itself. These will be designed and patents applied on a case-by-case basis. For example, it is evident that most bots will need to monitor external events of one type or another. Thus the library will contain a module (itself made up of potentially several sub-modules) for monitoring events (such as stock-price movements or weather conditions, etc.).
Configuration (WP0312)
In regard to their deployment within the hostnet there are several different potential configurations for autonomous agents. Some will utilise a ‘botnet’ strategy, some will simply use standalone bots, others may use a combination — all depending on the requirements. Some may be tightly integrated with the Blockchain (for example, when both bot control and BCH payments are deliberately synchronised) or they might be loosely integrated (e.g. where the Blockchain is used only for verifying contracts or permanently recording events, etc). It is likely that designing the protocols for these configurations will involve — in at least some cases — innovative techniques.
Some alternative bot configurations (not exhaustive):
1. A network of bots.
a. Working independently on a parallel processing task. Classic examples are SETI@home and the protein-folding initiatives. Some characteristics are:
i. Each bot has the same goal
ii. Bots are all the same
iii. A large number of bots are deployed — but not a fixed number
iv. Bots do not intercommunicate or interoperate. They only communicate their results back to a central server at the SP or direct to the client site.
b. Working independently and competing to be the first to complete a function. For example, proof-of-work algorithms or other ‘brute force’ tasks such as breaking a code. Some characteristics are:
i. Each bot has the same goal
ii. Bots may be different — e.g. different methods used to achieve the same ends.
iii. A large number of bots are deployed — but not a fixed number
iv. Bots do not intercommunicate or interoperate. They only communicate their results back to a central server.
· Or, they claim the ‘prize’ by unlocking a bitcoin transaction with the solution they found.
c. Working cooperatively and coordinating on a task. For example, a swarm of drones tasked with monitoring an area of bushland for outbreaks of fire. Note that in this example bots might reside on the drones themselves, or they might be on host machines and get signals from the drones relayed to them. Some characteristics are:
i. Each bot has the same goal
ii. Bots are the same
iii. A large number of bots are deployed — perhaps a fixed number
iv. Bots communicate with each other (e.g. their location and collected data)
2. A hierarchy of Agents and Automata.
a. Managed by a control bot, perhaps including ‘middle-manager’ bots. For example, a simple DASO (Distributed Autonomous Smart Organisation) in which all the business rules have been codified into machine-readable data structures and multiple bots created to execute each business function. Some characteristics are:
i. Each bot has a different goal
ii. Bots are different — they perform different functions
iii. A fixed number of bots are deployed (only as many as needed for all functions)
iv. Bots communicate with each other (or at least with their immediate control bot)
3. Standalone Agent— A single monolithic ‘bot’ running a set of algorithms to execute the entire requirement
a. Runs on a single machine on the client’s laptop. For example, a user downloads a program (or writes it herself) that monitors bitcoin prices at several different exchanges at which she has set up accounts. When an arbitrage opportunity is detected the ‘bot’ (i.e. a program) automatically executes the trades to lock in the profit. Some characteristics are:
i. Only one bot. (Of course it could be broken down into multiple bots)
ii. Run on a single machine. i.e. not distributed — accepts the risks/disadvantages of centralisation
b. Runs on a single machine on the Service Provider’s server. For example, a client contracts with a Service Provider to create and execute a function to monitor the inventory in a stock room (via RFIDs) and automatically places orders for stock replacement when numbers drop below a threshold. Some characteristics are:
i. Only one bot
ii. Run in a single data-center. i.e. not distributed — accepts the risks/disadvantages of centralisation
iii. Accepts the need for trust in the Service Provider
Example Scenario
The following scenario models configuration ‘2. A hierarchy of bots’ as described above in the Bot Configurations Section.
Client Alice believes that she has discovered a correlation between share prices for a set of NYSE stocks and certain extreme weather patterns in the central US. She wants to set up an automated function to buy and sell stocks according to certain triggers based on these factors. Alice contacts a Service Provider (SP) specialising in bots for stocks and shares and contracts with them to set up an automated service using her scheme. Via their website, the service provider requires Alice to register and meet certain requirements. Alice must have her own Bitcoin private/public key pair and must use this as a master key pair for this SP, and she must also install their plug-in for managing the keys (which employs the secret sharing and key-splitting schemes).
Alice registers on the service provider’s website. If Alice had been an experienced programmer, she could have elected to provide the functional bot code herself, and therefore keep her strategy secret from the SP (in which case the SP would require certain conditions to be met as per their terms and conditions to ensure that the bot code is not malicious, is legal, etc.) In this example, Alice is satisfied with the privacy and confidentiality provisions in the SP’s contract so she allows the SP to create the bot code based on her requirements (i.e. Alice provides the business rules). In effect, Alice is setting up a DASO.
Alice’s strategy requires the following information:
- the price/earnings ratios of 17 stocks listed on the NYSE
- the current NYSE stock index
- the existence of a particular weather alert for the Wisconsin region.
Alice has asked for the condition checks to be executed every hour at seven minutes past the hour (she is superstitious). The SP creates several bots to satisfy Alice’s request as follows.
1. A bot is designed to check the current price of the stock exchange index. The SP already has a codified share-price checker template bot so all that was needed was to instantiate the bot based on this template using the relevant parameters (i.e. the stock exchange website; the symbol for the index). Along with this functional logic, the instantiation of the bot includes plugging in certain standard ‘wrapper’ modules. For example, Initiation/termination routine; Cryptographic key maintenance routine; Communications Manager; (etc.)
2. A bot is instantiated to retrieve the latest company earnings. The service provider did not have an existing template bot for this purpose so they codified one from scratch. The resulting template bot created takes the following parameters:
- Company-ID;
- Source-Priority (a prioritised list of Data-Source-Codes; blank indicates ‘use default’);
- Data-Source (a DHT keyed by Date-Source-Code containing a list of websites and their associated screen scrape rules, the order of the websites is the default priority).
The bot works by reading the Data-Source file according to the supplied Source-Priority to get the highest priority website for the Company-ID, along with the rule for how to screen-scrape for the data. The bot then attempts to retrieve the required information by accessing the named website. If this does not work (for example, the website is down or the rule fails) then it tries again using the next priority source.
Note: for this example assume a separate bot is instantiated for each of the companies being tracked, making 17 such bots in all. An alternative approach would be to have all 17 companies tracked by the same bot. In practice, several factors may be taken into consideration when deciding on whether to separate out the bots or consolidate into a single bot. For example, a single bot benefits by reducing overall overhead, but multiple bots benefit from the robustness of separating and distributing the bots across different hosts.
3. A bot is instantiated to check the weather in Wisconsin. The service provider does not have a template bot for this type of function. They considered creating one from scratch, but since it was not part of their core expertise they decided instead to subcontract to a third party service provider (SP2) that specialises in weather forecasting and that use the same bot protocols. They perform the required steps to register as a client of SP2 and request the bot, providing the requirements. The requirement was to continually monitor the weather in Wisconsin and provide a ‘true’ signal if and only if there is a category EF5 tornado warning within a 57-mile radius of Stevens Point.
The first service provider was unaware of how SP2 set up the bot (i.e. they were unaware of how the information was retrieved or if multiple bots were used, etc.). They only needed to agree a few critical bits of information, such as the inter-bot communications and payments protocols, etc.
4. A bot is created to execute a ‘buy’ order. The bot has secure access to create and broadcast a bitcoin transaction when triggered by a signal from a manager bot. The transaction takes the form of an invitation using the P2P Exchange Model protocol (WP0153). That is, the transaction is broadcast and gets picked up by P2P Exchange service providers for matching with a counter party. In this case the invitation is to buy a quantity of a company’s shares in exchange for a certain amount of bitcoins, according to the rules set by Alice’s requirements. The transaction may be created with multiple outputs. In this example one of the other outputs is a ‘bonus payment’ to the service provider.
5. A manager bot is created to manage the other bots. Like the other bots, a manager bot is also instantiated from codified rules and a template. The manager bot’s instruction set directs it to communicate with the other bots to collect information and process it. Using the data securely transmitted by the first bot and the second bot set, the manager bot calculates the price/earnings ratios of the companies in question. It also collects the information from SP2’s bot to keep track of the weather signal. The information is used to determine if the condition for a ‘buy’ order has been met (according to the rules supplied by the client, Alice). If so, the manager bot sends a signal to the fourth bot to execute its function.
In addition to the bots created to execute Alice’s service, there may be additional bots set up to manage other functions, for example administrative functions such as collecting payments. These could all be standardised administrative template bots.
There were many different options for the service provider to charge Alice for this service, and this may have been done using a combination of options. Some of the options are:
- Membership fee. For example:
o Once-off joining fee (with individual services still paid for separately)
o Annual/monthly subscription, enabling services based on a schedule of prices (e.g. X bitcoins/month for up to 50 ‘level 5’ services; Y bitcoins/month for up 100 ‘level 1–4’ services — where the levels are described in the Terms and Conditions of SP1).
- Pay rate based on CPU usage
- Pay rate based on storage space usage
- Pay rate based on number of Bots instantiated
- Payments made if the service triggers a particular event (for example, a BUY order is generated as in the current example)
- Payment channel
In this particular case the service provider set up Alice with a payment channel in which Alice reserves a certain amount of bitcoin to automatically make monthly payments for a set period of time (12 months) after which the service contract would need to be renewed. The payment channel (using techniques such as a ‘payback’ transaction with a locktime, etc.) allows Alice to discontinue payment at any time, which would automatically terminate the service. In addition, the system was arranged to automatically make a ‘bonus payment’ if a ‘buy’ trade is triggered.
Once the bots have been set up, the first service provider (and separately SP2) ‘advertise’ them using the standard protocol (see WP0303). The advertisements provide all the relevant details related to the bots, including options, as per WP0301. There are several ways bots might be connected up with a host. A first example is on a first-come, first-served basis. The first host that clicks on the advertised bot ‘wins the contract’ — provided that it meets all the requirements for executing the bot. A second example is on a competitive basis. The bot may be advertised as a ‘tender’ in which rival nodes may bid for it on a range of criteria that might include price, processing speed, etc. A third example is by certain eligibility criteria. For example, reputation points (i.e. points earned for previous successful service, or linked to another Bitcoin reputation system).
Once hosts have selected bots and applied to the service provider, another registration process ensues between the host and the service provider concerned (unless of course the host has previously registered). Then a formal contract is established. This could be a new contract that is very specific to the situation. In most cases there will be contract templates that cover most of the usual terms and conditions relevant. The contract will be stored on a DHT as per previous white papers, and the associated transactions created. The payment options from the service provider to the host will be based on similar factors as used for Alice’s payment.