Eliminating Government: The Design of an Application of Mass Bargaining

Introduction

The goal of my research is to end the government.

The common reaction that people have is to wonder, Without the government, who will build the roads?

First, private construction companies build the roads, not the government. Furthermore, people make money, not the government. The government is the intermediary that currently takes the people's money and gives it to the private companies.

This book presents an application design that provides public goods and services. The application does not help the government provide the public goods; the intent is to replace the government.

The application allows us to start building roads, and anything else, without the government. After that, we can revert the question to With roads, who will build the government? At least, the executive branch of the government is replaced.

If you like this goal, then, please, fund the research by buying the book, not copying. Buy more than one; spread the word; give it to your friends, or send the web page. This book can be read by anyone with a background in mathematics.

If you are reading this book in electronic format, then you may need to switch to continuous flow mode if the browser cannot display the formulas in paged mode.

The application

The goal

The application is a mass bargaining system for trading public goods and services. The application takes the place of the intermediary between the individuals and the firms. The individuals send messages with their demands to the application, while the firms supply the projects. The people give their money to the application, the application gives their money to the private companies.

The diagram shows a mechanism between the individuals and the firms.

What is a mechanism? The mechanism makes the decision of which projects should be run.

Definition: A mechanism is a mathematical function, where the domain of the function is the set of possible messages that the individuals can send and the image of the function is the set of decisions that affects the individuals.

Let m∈ℕ be the number of individuals in the society.

Let M be the set of messages an individual can send to the mechanism.

The domain set is the Cartesian product of all the sets of possible messages that each individual can send. In the mechanism designed here, there is nothing special about any individual. They all have the same set of possible messages. When these sets are the same, the product becomes the Cartesian power:

M×M×⋯×M⏟m=Mm

Let D be the set of decisions the mechanism can make affecting one individual.

Similarly, we apply the same rules for all, thus, the image set is Dm .

Let m1,m2,…,mm∈M be the messages sent by the individuals 1,2,…,m .

Let d1,d2,…,dm∈D be the decision that affects the individuals 1,2,…,m .

Let the function of the mechanism be declared by:

mechanism:Mm→Dm(m1,m2,⋯,mm)⟼(d1,d2,⋯,dm)

It is necessary for an application to support the mechanism; the application takes care of the communication and the execution of the decisions made by the mechanism.

The application collects the messages:

m1,m2,⋯,mm

The application runs the mechanism function:

(d1,d2,⋯,dm)=mechanism(m1,m2,⋯,mm)

The application performs the decisions:

d1,d2,⋯,dm

The application and the mechanism in this book are designed specifically to provide public goods and services.

Definition: Mechanism design is a field in economics that takes an engineering approach to design economic games with incentives toward desired objectives. The mechanism is a game. The goal is given, while the game is unknown. Therefore, it also is called reverse game theory.

The individuals who use the application also are called users. The individuals who play a game also are called players.

The individual

Definition: An individual can be a person or a firm. The individual can behave like a person or behave like a firm, simultaneously.

The individuals are shown like this in the application:

The individual generates a pair of keys of the RSA cryptosystem. One key is the public key that the individual sends to the application to be stored online. The other is the private key that the individual keeps offline. The length of the key can be 512 bits, 1024 bits, or longer. The keys are encoded in the base 64. For example, this is a key:

MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEAhe0h+Dp9MJim5f095dO824lyFwUodTZUKig9u7xO/IVHQuhE0m3CkZ9psUDCHAu4ppZgFNBnOZjU4QElXt1bbQIDAQABAkAgcFmkCHa+SJtUZcySWIEMI/Sqgt1T1r73ulhJmsj+/OVKqrHX3TosDNJhaO2lmhvhmc1UcFF7qFw3p5bm0vH5AiEA6FjDPExoJ8/b4NJp4PZO+VzVtmjZ+kKpzCYiCM6AdacCIQCTj2oUtN6kH0jNHb7uEp1XFIGfmrfyV2dodahV1yFwywIgWEJ3j20613y2+pUTUThfUYw5RnxX6R/vnjQSE6RV2dsCIB/1ZbJKYhYFuIzELn/9hBpCFLjul3xjNcBIC0dcKp/1AiEAqG1vaLdK/4tsecc+ccgu92aBakkRfy1De4UJsGWT+5g=

The private key is used to sign the data, while the public key is used to verify the signature.

The application must provide a checking account for the deposit of money that will be debited automatically to pay the projects. The individual makes deposits into this account.

The application should allow the user to withdraw the remaining balance upon request.

The asset

Definition: An asset in the application is a file that holds documents, images, videos, diagrams, and whatever is necessary to describe the asset.

Example: Suppose a firm offers many different projects for a streetlight. The streetlight has different qualities and different aesthetic values. In this case, there are different assets. The firm should create one asset for each proposal.

The assets are shown like this in the application:

The same asset can be referenced by many firms. The competitor can make a reference to the same asset, or the competitor can copy and paste the description to offer a slightly different asset.

The assets are immutable, i.e., once created, they cannot be changed. For example, the asset's documents, images, diagrams, and description all should be ready at the time of creation. Nevertheless, another asset can be created.

All the constant data is used to calculate the SHA-1 hash code. The hash code is the fingerprint of the data. The length of the hash code is 160 bits. It is encoded as a hexadecimal number of 40 digits long. For example, this is a hash code: 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.

The data is verified when the hash code calculated again is equal to the original hash code. It proves that nobody has changed the data.

The instrument

The instruments hold the contract that performs an operation over the assets, for example, to buy or to sell.

Definition: An instrument is a tuple (x,y,z) in the space of contracts that specifies an underlying entity (x), the firm (y), which is a counterpart of the trade, and the price (z) of the contract.

The asset that is bought or sold is the underlying entity of an instrument.

We say that the price is a strike price, not a market price, because it is a parameter, not a variable. It is the price in which the contract will be exercised regardless of the market price. However, the firms will probably create instruments with prices close to the market price.

The instrument holds the terms and conditions to buy or sell the underlying asset. For example, the instrument specifies the schedule of deliveries and the cash flow. The cash flow may be conditional to the deliveries or not.

The instrument specifies the signatories of the instrument. The required signatures prevent the premature execution of the instrument. The instrument specifies a threshold of the minimum amount of signatures that are required among the signatories. The application cannot execute an instrument if the number of signatures is less than the threshold.

The instruments are shown like this in the application:

The application can execute an instrument based on the users' messages. The execution of the instrument performs a transaction, and the transaction transfers money from multiple parties to multiple parties. The transaction also transfers the asset from multiple parties to multiple parties.

The same asset can be the underlying entity of many instruments. For example, suppose a firm offers many different projects of the same streetlight, but the projects deliver in different times with different prices. The firm should create one instrument for each proposal.

The instruments are immutable, i.e., once created, they cannot be changed. For example, the firm cannot change the price z of an instrument, the terms and conditions, the cash flow, the signatories or anything else. Nevertheless, another instrument can be created.

The immutable characteristic is a business requirement, not a limitation. The users do not know if they agree with an update of the instrument. The benefits or the costs of the update are private information. There is no centralized solution to make such a decision. The instrument itself is a public good. The update of an instrument should be the project of another instrument. An instrument can be the underlying entity of another instrument. But, it is easier to create another instrument.

All the constant data is used to calculate the hash code by the SHA-1 algorithm.

The signature is the hash code encrypted by the RSA cryptosystem with the private key. The signature is a little bit longer than the hash code. It is encoded in the base 64. For example, this is a signature:

so3LBAbFsw4u7C/JfAawiHfaHFTRWh5qxOxNPFuQh6Z7UtH5Cmrk0V97YeGNcYhftNVzMIdNxuthyhHMzPNg8w==

The signature is verified when the decryption of the signature by the public key is equal to the hash code. It proves that only someone with the private key could have generated that signature.

The form

The form of a user is shown like this in the application:

The form requires a bid and a utility.

Definition: A bid is the highest price that a buyer (i.e., bidder) is willing to pay for a good. The bid will probably be a value less than or equal to his utility.

Definition: The utility is a measure of welfare, well-being, or happiness. The utility of a good to an individual is measured in some amount of money; it is how much the good is worth to the individual.

Example: The utility of the streetlight for the consumer is $25, and his bid is $20. This means that the consumer could pay up to $25 for the streetlight, but he is trying to pay $20.

Individuals will have to fill out the form for all the instruments. This requirement simplifies the application for the overview, but it will become impractical as the number of instruments grows. We will improve the application later.

The mechanism

The individual searches the firms' offers and chooses the proposals he prefers. He makes an effort to pull the society's decisions toward his preferences. The individual's effort has a direction and a magnitude.

The mechanism for multiple projects works similar to the game tug of war.

The magnitude of the effort is the amount of money that the individual sends to the application voluntarily, and the directions are the utilities that he assigns to each instrument.

We assume the hypothesis that the players are rational; this means that a player only applies resources in one direction voluntarily to receive utility greater than or equal to the cost of these resources.

The credit risk

TheApplication-CreditRisk Credit risk is the possibility that the players do not pay their bids after the close of a deal. The application is an online infinitely repeated game. There is no specific time and place for the participants to meet for bureaucratic procedures. In this