MyCHIPs Digital Money

Software Implementation

NOTE: this chapter was written in 2018-2019 in preparation for a functional software design.

In March of 2020 a software prototype implementation was publicly released on Github. While this chapter still provides some useful background, many of the concepts discussed here are no longer accurate. Those interested in the implementation details may want to jump into the system documentation itself.

Rev 0.04

We will now descend into some of the more detailed aspects of how MyCHIPs will be implemented. As we do, the level of uncertainty also goes up. Many of these assertions are not yet proven. Some points may not yet be fully consistent or complete. Other points may simply be questions, in search of a suitable answer.

You are encouraged to challenge the assertions. If you can, show exactly how to defeat the proposed model. Your thoughtful feedback will be very helpful in getting to an eventual RFC.

If you have landed on this page first, you may want to first read the previous articles in this section. And for more background, feel free to check out the original presentation in the book.

Finally, the ideas presented here are specific to a MyCHIPs implementation. A CHIP, or Credit Hour in Pool, could certainly be implementd in a number of different ways. But in the context of this presentation, it means a CHIP, as implemented in the MyCHIP, digital credit exchange protocol.

Money as a Contract

Up until this time, we have described money as credit, a debt, or a promise. While it is all these things, we will now start to use a more specific term: a contract. This will help us understand some of the technical aspects of what the MyCHIPs software must accomplish.

Although blockchain technology has evolved to support the idea of a contract, a digital coin itself is not a contract. Rather it is an abstract thing—a token that can be discovered and thus owned, given sufficient computing effort. Once owned, it can then can be spent, or transferred to other people. All these transactions are recorded publicly in the blockchain database so there are no disagreements about who owns what coins.

Like gold, there is a limited supply of possible tokens—at least for any given specie of cryptocurrency. And once discovered, one’s coins must be safely stored and protected or they can be stolen or even lost forever.

A CHIP is different in that it represents a contract between two parties, debtor and creditor. It can be created out of nothing except a mutually acceptable agreement, and it can be destroyed by fulfilling that agreement. Imagine a pair of equal and opposite charges—an electron and a positron, created out of the vacuum of space. But when the collide, they combine back into nothing again.

This type of private credit is really nothing new. In fact, it has existed as a means of tracking value exchange throughout human history. Before continuing, read this linked article and then optionally, this wikipedia description of a split tally.

The split tally was an early form of credit money based on this simple concept of money as a contract. Consider how it had two halves which identifiably belonged to each other. And think how a debt was documented by issuing one half of the stick to each of the parties to the contract.

The notches on the stick identified the value of the tally. But the unique placement of the notches, and the random tear resulting from splitting the stick, produced a security measure to prevent fraudulent tampering.

It would be virtually impossible to change the value (the notches) of the tally undetected, unless you were physically in possession of both halves of the stick. And it would be even harder to manufacture a new stock or foil meant to go along with the other genuine half of the stick. It would never match up perfectly at the seam and so would be identifiable as an obvious forgery.

You can think of MyCHIPs as a digital implementation of the split tally. In fact, we will even adopt some of its nomenclature. But with the help of computers, we can make it work even better than its wooden predecessor.

A MyCHIPs tally represents a trading relationship between two entities, or nodes on the MyCHIPs network. It consists of an encrypted string, or file of data containing, at least, these components:

A universally unique transaction code identifying this particular tally
The type and version of the tally
The date the tally was created
The identity of the issuer, or holder of the foil (the expected debtor)
The signature of the issuer which validates the tally and indicates acceptance of the terms
The identity of the recipient, or holder of the stock (the expected creditor)
The signature of the recipient which validates the tally and indicates acceptance of the terms
References to, and hashes of, any external contracts which may govern the contract
Any credit limit applicable to the issuer (the most positive CHIPs authorized to accrue on this tally)
Any credit limit applicable to the recipient (the most negative CHIPs authorized to accrue on this tally, which may often be zero.)
Call terms, such as how/when a recipient can require an outstanding balance to be redeemed
Put terms, such as how/when an issuer can require an outstanding balance to be redeemed
A list of signed transactions indicating the sign and number of CHIPs for each and the date and time transferred

A digital tally also consists of two halves, a stock and a foil—just like a historical tally stick. But they are just complementary strings, essentially two copies of a single digital contract, secured by asymmetric cryptography. The stock is encoded so only the holder can read it, using his private key. Likewise, the foil is encoded so only the issuer can read it.

More importantly, the tally contains signed hashes of all the relevant contract terms for the tally. This way, anyone in possession of either half of an unencrypted tally can prove exactly what terms the parties had agreed to.

There is another important way a MyCHIPs tally is different from a historical split tally stick. Normally we think of money as a token—something that travels from one person to another. You give me some money for something, and then I spend that same money for something else. The money has traveled from you, to me, and then on to another person.

There is nothing really to prevent a traditional split tally from being fully transferrable. If you were the holder of the stock, you could easily give it to someone else, making them the new holder, entitled to whatever amount the foil was obligated for. But a MyCHIPs tally is generally non-transferable.

The only exception to this is a case where a tally could be executed from the outset to be transferred, but only to one or more predetermined recipients. This will be important in the case of a third party who certifies credit for a credit issuer. We will explain more about that later. For now, just think of a tally as an agreement where a certain debtor is obligated to pay a specified value to a certain creditor, and no one else.

In other words, it doesn’t matter if you possess the stock, but rather if you are the designated beneficiary of the stock. You must be the very person or company the promise was originally made to. Otherwise, the tally has no value to you. This is an important feature that makes MyCHIPs credits more resistant to theft.

Someone may hack your computer and discover your files. They might even discover your private key. But that doesn’t mean they are a legitimate party to the tally. So a debtor has no obligation to a spoofed, or otherwise illegitimate holder of a tally.

Once a tally contract has been established between two parties, they can begin to trade credits back and forth according to the terms of their agreement. Just think of a tally as an open account established between two parties. They can trade IOU’s back and forth by appending digitally signed debits or credits (chits) to the tally. The tally can remain open until such time as the parties decide they don’t want to do business with each other any more, or they decide to establish a new tally on different terms and conditions.

Basic Security Model

The MyCHIPs architecture is also intended to solve the scalability problem notable with Bitcoin and similar cryptocurrencies. Under traditional blockchain architecture, everyone has to have a full copy of the community database. While there are technologies being developed to mitigate this problem, still scalability is a continuing issue for blockchain based money.

But MyCHIPs is designed to be more fully distributed and de-centralized. For the most part, nodes (individual network servers) only have to maintain data about their own transactions, and other nodes they regularly do business with.

This is just like the paper contracts we are already quite familiar with. Each party keeps his own copy of the contract and can produce it as evidence should it be necessary to enforce the deal.

Participating nodes agree to accurately advertise to, and exchange traffic with, and on behalf of, other nodes they may associate with. So if you hold a credit issued by a badly behaving node that refuses to honor its obligations under the contract, other relevant parties will be able to know about the breach so they can avoid doing business with the untrustworthy node.

If all such on-network mechanisms fail to keep participants honest and accountable, a creditor may be able to take remedial action in the real world. For example, if someone modifies his software to mask traffic to and from complainers, he is very likely in breach of a compliance contract.

If it is a good one, it will contain provisions to collect attorneys fees, and any other losses of the creditor. It could even include additional punative measures if the parties have agreed to it.

The system should thoroughly document any bad behavior of non-compliant nodes with an auditable transaction trail. This will allow the victim to take the matter to a court in the real world, assuming the size of the claim warrants it.

In addition to relying on individual nodes to accurately relay traffic regarding their own behavior, it is expected certain auditor nodes will develop for collecting and publishing information about badly behaving nodes. We will discuss certain possible methods for disseminating such information in a decentralized model.

Finally, the MyCHIPs system is best represented as a protocol, rather than as a single implementation of software. Although an official reference server should be coded, nodes should be able to operate their own choice of software, as long as they are fully compliant to the published communication protocol.

There are no centralized or otherwise specially authorized nodes. And there is no single clearinghouse for transactions. All nodes operate strictly on their own as peers with all other nodes in the network.

Identities

An identity (ID) is a digital string that tells uniquely who you are on the MyCHIPs network. In an ideal world, a single person or company might have a single ID throughout its entire life. But this is probably not realistic, so the system should be able to properly handle a person changing his ID, or even trading on the network under multiple IDs.

In addition to knowing a trading partner’s ID, other nodes will need to know a reliable URL where transactions can be conducted with that entity. So one possible approach is simply to use a valid domain name as the ID.

This scheme has the advantage of using the existing DNS system for resolving a host location from a symbolic ID name. It also can benefit from the existing identity certification authority infrastructure to prevent rogue sites from spoofing legitimate ones.

Such a strategy would work well for most existing business entities who already maintain a website. They will likely want their MyCHIPs interface to be associated with their regular domain name anyway. Expected complications include one business being acquired by another, or a company otherwise undergoing a branding change.

Assuming existing tallies need to persist through a change of domain name, a company may have to continue keeping the old domain registered and active on the web, as they normally do today anyway. The old domain could simply redirect to the new one. Once there, the authoritative MyCHIPs server can publish and recognize all such aliases it may operate under.

Using DNS might be less convenient for individual MyCHIPs users, however. For example, if you started out with an ID like: chip://fred_jones_9876.goochips.com, you might someday get tired of using goochips as your provider and want to switch. But another provider probably couldn’t host you using the same url. It might instead, have to be something like: chip://fred_jones_9876.yahchips.com.

A more portable idea would be to register a more universally unique domain like fred_jones_19980301.com. But then, you have the cost and trouble of maintaining a separate domain name for everyone in the world who wants to use MyCHIPs.

One possibility is to set up a new top-level domain so personal URLs could look something like: chip://fred_19980301.jones.chip or just: chip://fredjones-19980301.chip. That would at least free up some new name space dedicated just to personal MyCHIPs users. Depending on the registrar managing the domain, perhaps it could become affordable for many users.

An even better option would be to create a decentralized name resolution system dedicated just for MyCHIPs. Let’s call it the CHIPs Name System, or CNS. CNS could function side-by-side with DNS so corporate users could still use a paid, authority-based system and personal users would have the choice of using a free alternative.

This is one area where blockchain technology might prove useful for MyCHIPs. Blockchain is a great system for documenting ownership of uniquely identifyable things. That’s why it works so well for a tokenized money system like Bitcoin. MyCHIPs isn’t tokenized, meaning it doesn’t use uniquely identifiable coins. So we don’t need a blockchain to document financial transactions between participants.

But the digital ID of each person on a MyCHIPs network is a token. So blockchain certainly would be one way to create a consensus system for registering your MyCHIPs ID. Just come up with an unused ID string you like, and record it in the blockchain. If you got it first, it’s yours for life.

Although this does pose some potential scalability problems, it is not nearly as bad as that inherent in Bitcoin. An ID registration database would only have to hold one transaction for every participant, rather than every transaction of every particpants. An IP number resolution database would only get a new record when you point your ID to a new server. Both of these cases would be many magnitudes of order smaller than what is demanded by existing coin-based cryptocurrencies.

Another promising technology is called Sovrin. This system provides a framework for establishing web identities that are self published and self maintained. If such a system could be adapted to establish a unique MyCHIPs identity, it would likely be much more scalable.

Multiple Identities

As mentioned, it would be pretty easy for someone to make more than one MyCHIPs identity for himself—particularly in an environment where ID’s are self-assigned. In some cases, this could be someone trying to do something dishonest or fraudulent on the network. But as we will see, simply having more than one MyCHIPs ID does not automatically mean you are cheating anyone—particularly if you don’t make any representations to the contrary. As long as all issued tallies are faithfully honored, and all issued CHIPs fully redeemed, no promises will have been broken, and no one will have been harmed.

The main case where multiples ID’s would be a problem is if you issue your own credits onto the network, and you attempt to use a single collateral asset to secure separate obligations issued under multiple ID’s. Many users may choose not to issue their own credit, but instead will just deal in the credits of other, more public entities.

But in such instances where it is important that a single ID correspond uniquely to a single real-world identity, a number of possible real-world methods could be used to certify this uniqueness. For example, a corporate entity could publish information about its legal jurisdictions of incorporation, along with publicly verifiable tax ID numbers for each one.

Private individuals who want to issue their own credit might pay for credit certification, or insurance issued by a known and trusted entity who has access to the individual’s private tax ID number but can also keep that information confidential from the public. Examples might include an employer, a life insurance company or a bank where you regularly do business.

Confidentiality

With the advent of Bitcoin, many felt it would offer the ultimate in confidentiality. In fact, some have criticized it as being mostly good for drug dealers, gamblers and others involved in illicit activities.

It is true, when trading using cryptocurrencies, you are off the traditional central banking grid. However, to say your transactions are entirely private is a gross overstatement.

The blockchain is first, and foremost, a public database. But if someone discovers your digital identity, it is pretty easy to see how many coins you own. And any trades you conduct can easily be seen by others.

The MyCHIPs produces a healthier balance between confidentiality and transparency. In most respects, it is much more private than a blockchain. Your transactions are stored only on your own node, and the nodes of your immediate trading partners. So no one entity can automatically determine your net holdings, simply by querying some public store of data.

Yet under MyCHIPs, it is also difficult to engage in fraudulent, or even shameful transactions. The only way to connect to the network is by developing credit relationships with trusted trading partners. These are the partners you depend on to keep you connected and operational in the system.

If you do default on your credit obligations, it will be these direct partners who you are hurting. They are not likely to put up with that for long. So ultimately you will be hurting yourself and your ability to trade.

The public will not see what your transactions are, but your trading partners may—at least to some degree. And they know who you are and where you live. If they are your creditors, they may even own security in collateral assets you hold. This is great incentive for everyone to deal honestly on the network.

This dynamic is akin to the paper contracts we often still use today. Parties create a contract, and as long as it is not breached, others in the world may never see it or even know it exists. Rather, the documents are securely stored in a filing cabinet or computer somewhere on the private property of each of the parties to the contract.

If one of the parties needs to bring a contract public in order to enforce it, such can be done by choice of the aggrieved party. And if law enforcement wants to see a contract, a ledger, or other chain of activity, they can obtain a search warrant as the local jurisdiction may allow, deliver it to the parties in the real world, and cause them to decrypt the data as appropriate for review.

Agent Server

In the abstract, an ID represents a real world asset, or the net total of a group of assets—a balance sheet, if you will. For a company, the value of the asset could include products and services, in demand, which it will render in exchange for credits. For a person, the value will often be future work which can be performed, past work which has already been banked in the system, or other real-world assets which can be traded or leveraged in exchange for credits.

The server representing one’s ID has the duty to faithfully transact all business on behalf of its real-world entity. Most transactions will only be carried out by the direct and explicit authority of the controlling entity, meaning the person, or an authorized agent within the company. For example, if money is to be spent (net credits issued), the server will obey whatever set of authentication rules the user has set up for himself in order to authorize that expenditure.

If you are paying for a meal in a restaurant, an app on your phone might pop up and ask you to validate the transaction. This would presumably include entering a password or scanning a fingerprint.

If you are approving a payroll run for your company, you might even have a more stringent protocol such as entering a number from an electronic token, or taking an iris scan. These would all be functions of auxiliary, or helper applications which would authenticate with your MyCHIPs server using established, secure protocols. Normal precautions can also be taken, such as texting and emailing you any time a credit is issued, or your profile is accessed or changed.

Certain other functions of the server can be more autonomous. For example, part of your compliance contract can be an obligation to relay encoded communication packets to and from from your other trading partners. Using this protocol, one of your parters could effectively ask all your other partners questions about how well you have honored your agreements. Because the communications are encoded, you won’t be privy to what is being reported.

If you fail to move the data, or you withhold critical information about a node, likely to give a negative report, you may be in breach of your compliance agreement. If so, you could be guilty of fraud by deception. And the fraud has been committed against an immediate trading partner—someone who knows exactly who you are. The chances of them taking remedial legal action can be quite real.

It is important to recognize, not everyone has to agree to such stringent compliance contracts, and not on every tally you execute. In fact, most private users will choose not to in most circumstances. And they can function on the network just fine without doing so.

It is the issuers of credit who have to take risks and disclose information about themselves. Those who deal primarly using the credits of others, don’t have to make risky commitments or disclosures.

Said another way, if you want to borrow money, you will likely have to prove yourself to the people you are borrowing from. They will want to know things about the assets you hold, and your reputation with others you have borowed from. The more you disclose, the more you are likely to get the credit you seek.

For businesses, this means clearly publishing information about assets and liabilities held, as well as the position, or priority of all issued CHIPs, relative to any other debt that might be secured by the company’s assets. Individuals might only have only a few relationships that include borrowing. For example, many people would have a long term credit relationship to finance the purchase of a home. Some might have shorter term credit instruments to buy a car. And many could have very short term arrangements much like the credit cards we use today.

Where it is appropriate to disclose credit information, the agent server is responsible for doing so. And it must do it according to the parameters set by the owner entity it represents.

In addition to quality queries and complaints, the server will need to conduct credit lifts autonomously, as will be discussed in more detail later. In short, each server must publish information about the CHIPs it knows to be in demand to be bought, or available for sale. Maintaining an honest and ample list of this data will also likely be a part of a strong quality rating.

Credit lifts involve conducting high speed trades, which net to zero, but which effectively reallocate your CHIPs according to parameters established in advance by the owner. In other words, it allows you to sell off the CHIPs you have, but don’t need and instead, collect the ones you want but don’t yet have. These trades will have to be possible without the delays that would be interjected by manually approving each one as they occur. But because they net to zero, and operate according to your pre-defined parameters, they can be conducted without this manual interaction. More on this later.

Consequences of Decentralization

A primary design goal of MyCHIPs is to be completely decentralized. One important reason is to facilitate unlimited scaling. Another, perhaps more important reason is to avoid creating a center of control that could get appropriated or misused.

In such a widely distributed system, some functions may seem difficult to achieve. For example, what if someone wants to query the entire system to find out where all their CHIPs are? Or what if you want to ask someone authoritative, about the reputation of a potential trading partner? What if I want to find every instance of a particular CHIP issuance for sale?

It turns out, the non-transferrable nature of MyCHIPs makes some of these functions a lot less important than one might think. For example, it is not that hard to figure out where all your CHIPs are—even if you lose your copy of your database. Since CHIPs are not transferable, all your credits have to be held by your immediate trading partners. And if you don’t know how to contact them, you can be pretty sure they (i.e. your creditors) will be contacting you.

In a truly decentralized system, it is important that all nodes are equal, purely as peers. There are no authorities or controlling nodes. Furthermore, each node is only guaranteed to know about the other nodes with which it has an existing credit relationship, established in the real world.

So queries that potentially involve the whole network will have to happen in some kind of recursive way. A node could only transmit messages to its immediate trading partners, with a request to propagate the message onward until it reached its desired destination. Each node would have to contain logic to determine when and where to pass along such messages so as not to bog down the entire network.

Another consequence of decentralization is, all transactions must be completely voluntary. Because there is no central authority, there is no authority-based enforcement mechanism. What keeps the system honest is, everyone needs the cooperation of their peer nodes in order to be successful on the network.

If you don’t deal honestly, you are not going to hurt a stranger somewhere. You will be damaging a valued trading relationship you need in order to prosper. So there is an incentive to behave yourself.

You don’t need to be on the same network with everyone else doing MyCHIPs, either. Two or more entities should be able to establish a trading relationship with each other, totally independent of the rest of the world. They don’t have to agree to anyone else’s compliance contracts either. They can just come up with whatever is agreeable to them both. And no one has to publish any financial or other data they don’t want, unless it becomes necessary to procure the cooperation of other parties they want to do business with.

Ideally, each node will only possess direct knowledge of the other nodes it has a direct connection, or tally with. However, to facilitate credit lifts, nodes do need a way to establish contact with other nodes, more distant on the network.

In order to preserve a reasonable amount of privacy, it is proposed to facilitate indirect communication by sending information through your direct partners. Remote nodes would be identified by using a hash of the their real ID. For example, your immediate partner A, may report to you that he knows about another partner (B) who you might want to include in a credit lift. He gives you a hashed ID for B—not B’s real ID.

You can communicate with B even though you don’t really know who he is. You just pass an encoded message through A, specifying B’s hash ID (HID) as the message destination. That way, B’s ID can be kept somewhat confidential and A won’t be able to listen in on what you are talking about. This mechanism is also very helpful if you are collecting auditing information about A!

We should note, B’s identity can not readily be derived simply from its hash. However, if you guess B’s real identify, you could confirm your guess is correct if the hash is a known algorithm. Therefore, each node should generate its own HID with a randomized component, known only to itself. Direct partners would ask the node for its HID and communicate with other neighbors only using that information.

Since each node is responsible for passing traffic onto other nodes, each one can employ its own policy in conformance with its own compliance documents. In other words, it can decide what to pass along and what to discard. This can reduce or possibly eliminate unwanted or unsolicited traffic on your local network.

Data Storage

As mentioned, each server should only have to store data related to the tallies it is a party to. But there can be exceptions, including the following:

One desirable quality is, a node should be able to suffer a complete loss of data and still reinitialize itself from scratch knowing nothing but its private key and a few basic network relationships. In other words, your server could be destroyed in a fire. And as long as you have your private key stored in a safe deposit box, you can plug in a new server, access the private key, and point the server to a few known peers on the network. It will be able to find its bearings and eventually restore its entire database as it had been before.

This implies the need for backup data to be stored on the cloud. And one ideal place would be right on on your peers’ servers. Most people wouldn’t want their data available to be read on other people’s servers though, whether friendly or not. So some kind of data slicing model and encryption would be necessary so no one site could really make any sense of the data it warehouses for its associates.

There would also need to be a protocol for negotiating with other sites, to store their backup data, and have them likewise store yours. One job of the server would be to periodically checksum externally stored backup data to make sure all peer sites are doing their job and storing your data as agreed.

Ideally a node would store every transaction it had ever taken part in, throughout its lifetime, and possibly beyond. While this is much much smaller than what is required in the blockchain model, still it could grow to a large size for some large organizations.

Consideration should be given to the question of whether redeemed CHIPs can safely be pruned out of the database-either right away, or after some period of time has elapsed. Certainly if a fraud is detected after some time has passed, it would be desirable for all legitimate parties to the transaction to have access to the truth of what happened.

In light of the aforementioned constraints, ultimately the choice must be up to the individual user and the compliance contracts he agrees to.

If you lose the record of a tally which is in a debit balance, you may not be able to enforce the debt—at least not without some cooperation from the debtor, or some other party to the transaction. If you delete or lose the record of a completed closed tally, it may never matter, unless you discover a fraud later on and want to document it. If you lose the record of a tally with a credit balance, nothing really changes. Your creditor can still enforce it against you whether you know it or not.

Quality Rating

Just as all credit-issuing entities are responsible to present trust-worthy data about themselves, it is up to potential trading partners to interpret that data as they will. Each entity will have a potential character we will call “quality.” It should be understood, this quality will be in the eye of the beholder—that is, whoever is doing the evaluation.

For simplicity, we will refer to quality as a real number between 0 and 1, or for presentation, a percentage from 0 to 100%. But this number, if it exists, will be generated according to an individual user’s preferences. In other words, entity A may evaluate entity C’s quality at 85%, while entity B might view entity C as having an 80% rating.

The data published by entity C is the same, and seen the same by A and B. But A and B are free to place different values on different parts of the data, and interpret it is they see fit.

In practice, it is likely specialists will emerge who publish recommended formulae for computing a quality rating. Most people will not be sophisticated enough to come up with their own algorithms and so will adopt an algorithm from another trusted party.

Nodes or companies who wish to discuss their own quality rating would therefore qualify it, as in: “My Standard and Poor’s quality rating is 97.5%.”

Each server may optionally make any of the following data available about itself:

Server software release and version in use
Compliance contracts the node prefers and/or is willing to abide by
Date of first issuance
Total CHIPs issued to date
Total CHIPs satisfactorily redeemed
Total CHIPs outstanding or unredeemed
Qualification partner IDs
Insurance partner IDs
Published auditor endorsements
Published financial reporting
Money market data (CHIPs held and known for sale, wanted, or known wanted, with pricing)
A portal for communicating with neighboring nodes
Confirmation requests for validating existing tallies
Financial data, balance sheets, collateral values, etc.
Other?

To reiterate, this information is optional. But entities may want to reveal certain things in order to facilitate the trades they want to take part in.

For example, if you only want to exist on the network as a consumer, you may not need to entice others to accept your credit. But you can still establish trading relationships.

For example, you might establish a tally with Wal-Mart. They may not let you spend your CHIPs to buy things. But you can certainly collect their CHIPs through credit lifts, and then spend them later for the things you want to buy.

In this example, you are lending value to Wal-Mart, by buying their CHIPs. But they may not be willing to lend you value if you can’t prove to them you can be trusted to redeem your credits later for the kind of CHIPs they ultimately want.

In practice, a consumer might establish just few credit relationships with entities such as their employer or mortgage holder. Tallies held with other entities would allow trading, but not necessarily credit, or going into debt.

On the other hand, many companies would be happy to publish their fiscal data as widely as possible, if that means access to inexpensive credit. Each one of their CHIPs acquired represents free credit obtained from willing participants. The company is free to use that debt for their own capital needs as long as the CHIP is outstanding, or until it is redeemed in exchange for goods, services, or other CHIPs.

Part of an entity’s quality might involve the total number of CHIPs successfully redeemed, compared to the number currently outstanding. A quality algorithm might also take into account how long the node has been successfully trading CHIPs.

An entity’s quality can be further enhanced by including a reference from a well known auditor. In this case, a quality algorithm would contact the auditing entity directly to ask about the entity claiming the endorsement. The auditor could return a signature indicating its approval of the data published by the entity.

Credit qualifiers and insurers would work similarly. However, these relationships are binding. The guarantying entity would, essentially co-sign tallies on behalf of the debtor entity. That way, if the entity defaults, the qualifier or insurer would be obligated itself to fulfill the obligation itself.

Ideally, each representation made by a server would be subject to some kind of independent verification. This way freelance auditor nodes could query a server, try to validate the information, and then have a way to communicate problems to holders, or potential holders of the issuer’s credit.

Subject to a compliance contract, nodes may be required to publish the HID’s of any entities that have outstanding CHIPs and have still not been made whole, to their complete satisfaction. It will then be up to a quality evaluation algorithm to query those ID’s for further metrics, should they want to provide them. There might well be a counter-complaint from the original entity. Then it may be up to the algorithm to see which of the two parties have more complaints from other, un-related parties.

In the case of a non-compliant node, a disgruntled holder of credit might report his problem directly to someone who specializes in auditing. His tally will prove the consent of the issuer. Yet if the issuer refuses to report the disgruntled node itself, it can be proven to be in violation of its contract, and redress can be sought in the outside world.

Others should also be able to independently query other ID’s you claim as insurers, auditors or credit certifiers. Once you provide the proper authority, you should be able to get any relevant data from those entities. By performing recursive quality ratings on those entities, you should be able to compute a composite quality rating for the original entity.

Compliance contracts should normally refer to standardized contracts, known and recognized by the community so a quality algorithm can know how to apply a weight to it. But it is possible to make up your own contracts and publish them as well. If they catch on, they could become known and understood by other quality scorers.

Here are some examples of the kinds of things that can be represented in standard compliance contracts.

The party agrees to value a CHIP according to the specified definition for standardized unskilled labor.
The party agrees to maintain an active server as long as there are outstanding CHIPs, or open tallies
The party agrees to only engage in transactions that are completely voluntary on the part of both parties.
The party agrees to only engage in transactions that are completely informed on the part of both parties.
The party agrees to only engage in transactions that are completely competent (capable adult) on the part of both parties.
The party agrees to submit to binding mediation, provided by other members of the network, chosen at random by a pre-identified jury pool service.
The party agrees to reimburse all time, costs, if he loses a network mediation battle.
The party agrees to reimburse all time, collection costs and attorney fees in the outside world, if he loses a claim.
The party agrees to pay treble damages for misrepresentation or fraud.
The party agrees to honor the published protocol: release version.
The party certifies its server software has not been modified from the published release.
The party agrees all transactions will involve activities that are legal within his own jurisdiction.
The party agrees not to use bankruptcy to avoid or discharge debts accrued on the network.
The party agrees it has, and will ever have, only a single ID on the MyCHIPs network.
This site will submit itself to outside freelance audits

This model for assessing quality and reputation is completely de-centralized. If it proves inadequate, a good backup would be to maintain a blockchain database for reporting the bad behavior of non-compliant nodes. This way, it would be pretty easy to scan for the equivalent of consumer reports on credit sources you may wonder about before buying their credits.

Credit Partitions

Within a single identity, it should be possible to create a number of smaller partitions, or separate credit containers. In a corporate setting, these could be used to associate a block of credit with a particular employee or manager who has spending authority with that money. For example, payroll might have certain established limits to how much can be spent each week. Similarly, accounts payable could be authorized from a separate partition, and for different purposes.

This granularity could conceivably go to any level, such as “Bob’s meal account.” But these distinctions should not have much to do with the entity’s obligations when viewed by the outside world. Primarily, they would be for the purpose of internal tracking and controls.

For a personal entity, it might be nice to have a partition for normal monthly expenses, such as you would put on a credit card. If someone steals your phone, or otherwise compromises your private key, it would be better to have the potential damage capped at 100 CHIPs, for example, than worrying someone might try to buy a new car or house on your credit.

A larger partition, which you may actually use to buy a home or car, could have different rules than your day-to-day partition. For example, you might need to make a phone call to a specified contact. Or you might even have to show up in person to authorize certain larger expenditures.

Your profile should keep track of your settings, and not allow issuance of credit in any given partition without respecting the specified authorization protocol and credit limit. Furthermore, provisions should exist to cross-check your security settings with known or published trading partners who cache your information. That way, a potential hacker would have to break two or more sites to falsify your credit authorization.

Key Security

As mentioned, tallies use a private/public key strategy, not only to keep transactions private from outside parties, but also to establish the consent of the parties to the contract. This leads to the important question: What happens if a party loses his private key, or the private key becomes known to an outside party?

In the real world, parties can lose their copy of a contract and often still enforce it—as long as they can find a copy, or otherwise prove the existence and terms of the contract. This gives us a hint that a MyCHIPs user should be able to recover from a lost private key. However, any programmatic provisions for a lost key would also introduce unwanted security weaknesses. So we will have to instead rely on some human intervention.

Let us consider an example: Assuming your data is stored unencrypted, you should still be able to establish who all your creditors and debtors are. But you would not be able to create new tallies, nor add new transactions to existing ones.

To solve this problem, you would start by establishing a new private/public key pair. Then, you will have ot do some real-world negotiation and cooperation with your established trading partners.

A partner holding a tally in debit balance is someone you owe money to. You would need to contact them and request a new, empty tally be established using your new keys. Then you would create a replacement transacation of indebtedness to the creditor on the new tally. As return consideration, the creditor would have the ability to unilaterally endorse the old tally in such a way that it becomes remitted back to you.

You would be wise to retain the endorsed, and remitted tally forever so you can prove the debt had been discharged. Otherwise, the creditor could later produce an earlier, unsigned version of the tally and be able to assert an indebtedness.

A partner holding a tally in credit balance (a debtor) owes money to you. This is little trickier case because you are the only one who could rightly discharge the debt on the old tally, and you no longer have the key required to do so in a valid way.

This is one case where it will be helpful if the agent server can carry on certain net-zero trades without the authority of the private key of the account owner. If so, a lift can probably be generated which would have the net effect of moving the balance from the old tally to the new one. Such a lift could only be signed by your service provider, using a key valid only for lifts.

If, rather than being lost, a private key is stolen or otherwise exposed, the problem is potentially more serious. But the non-transferrable nature of MyCHIPs gives us some additional security measures.

Private keys are used to sign, or certify the binding agreement inherent in the tally. If someone else uses your private key, it is akin to forging your signature on a paper document.

Legally, you shouldn’t be liable for an expense in the real world incurred by an imposter who is forging your identity. But it may involve some effort to prove you are not the originator of a contract bearing your signature.

So one question to consider is, how can we best secure the secrecy of private keys in the first place? Then, how can we best design the server so the damage will be minimized to a user whose private key has been compromised? Finally, how can the system track and record bogus transactions so fraudulent parties can be held accountable in the real world?

Presumably, an attacker in possession of your private key would try to use it to enrich himself at your expense, or the expense of your trading partners. This could be done by creating a new tally between you and him, or another node he somehow controls. He would then populate the tally with one or more transactions, presumably crediting you and debiting himself.

But to do so would pose significant risk to the attacker. The only way he has to collect on such a debt is to then participate in lifts where he effectively exchanges your debt for other credits he may be collecting. He will leave a clear trail of evidence on every server particpating in the lift. In fact, the most blatent trail will be the record of his identity he leaves on your agent server.

If the agent server does its job of documenting and maintaining an auditable record of all transactions, such an imposter should be able to be prosecuted for fraud in the real world. It shouldn’t be too difficult to prove that you have no valid relationship with him, or that the tally he created using your forged signature was established without any consideration to you. Any credits he collected in lifts using the phony tally, should be traceable right back to him.

The result of such fraud should be to totally discredit the fraudster with the people he needs the most—his immediate trading partners. Once he is known to be unworthy of trust, he will not be able to trade further on the network. He will have to first repair his trading relationships. And that could involve punative penalties if his legitimately obtained tallys include such compliance covenants.

The MyCHIPs server should address these potential fraud issues in several ways: First, any transaction that would be net credit (minus) to your account should not be allowed without an explicit validation from the user.

The private key should not be stored on the agent server. Rather, validation would include real-time, human interaction via your smart phone, for example. You might be required to enter a password or pin to unlock your encrypted private key. Or even better, it might involve a biometric validation, or use of a mobile token you might carry separate from your phone.

Validations initiated by your mobile device could connect to your server on a port, and evan an IP number unknown to the public. In other words, you would not connect to your server at the same address everyone else uses. Only you would know how and where you make that connection. And there is no reason a daemon listening on that port would have to answer to any query unless the proper credentials were provided as part of the initial handshake.

Furthermore, the agent server could validate things like the IP number, and the unique device identification you are connecting from to further validate the connection. Any attempt to authorize a transaction that does not match every aspect of your validation protocol could cause your server to go into a lock-down mode. Net zero and net debit transfers could still carry on, so your ability to participate in lifts would not be impaired. But no net credits could accrue, and no new tallies could be created until the condition is reset with human intervention from your system’s administrator.

Any transaction net crediting your ID should generate a pop-up advice on your device, requiring an approval before proceeding. If the advice goes unanswered, the server should attempt to contact you via a predefined backup method to report the problem. And any attempt to change this advisory protocol should generate further text and email alerts and/or throw the system into lock-down mode.

Recovering from a lost or stolen key will not be painless, but it is possible. In the end, the best answer is to keep private keys safe (like a backup copy in a safe deposit box) and secure (encoded and/or offline). If your private key is compromised, you can recover, but it will be a lot of work and trouble.

Transactions

Before going into more detail about network functionality, let’s go through a few typical transactions that might occur on a fairly regular basis.

Let’s assume you’ve just had a great meal at your favorite restaurant. You like it partly because the nifty MyCHIPs logo in the front window means you can pay with your MyCHIPs-capable phone app.

The waiter comes to your table and presents you with the bill, and you show him the screen of your phone which is displaying a MyCHIPs URL barcode. He pulls out his nifty iPad and scans your barcode, and behind the scenes, things start happening.

First, the credit provider for the restaurant queries your MyCHIPs server to see what your credit looks like. This could involve quite a number of transactions as the software tries to figure out who you are, and why the restaurant should accept your credit. If you are a regular customer, you might already have an established account with the restaurant, and they may be willing to accept your credit on face value. Otherwise, they will be performing some kind of a recursive query with your credit certifier, your employer, your insurers, and auditors, etc. to make a programmatic credit decision. The restaurant’s internal logic makes some formulaic decisions about your fitness as a debtor, and within a few seconds, the waiter smiles at you and asks to see your picture ID.

Satisfied that you are the same person he is seeing on the screen of his iPad, the waiter presses another button, and within a few more seconds, the app on your phone pops up with an authorization prompt. The restaurant has, in essence sent your server an invoice, or a request for payment. It did not require any special authority from you in order to get this far, because no money has yet been spent.

If you were getting this invoice from an unsolicited source, you could easily hit a complaint button at this point, which would do all kinds of nasty things to tarnish the reputation of the MyCHIPs identity spamming you with an unwanted pay request. He and others like him would quickly lose reputation to the point that further unsolicited invoicing requests would not pass your quality bar and so would be rejected without you even knowing about them. But this one is legitimate, so you need to answer it.

It turns out the waiter is also a MyCHIPs enthusiast and he gives you the eye, so you aim your phone at him, he pulls out his phone, and you send him the tip directly over IR link, your personal credit, direct to his. The bill to the restaurant, you authorize without a tip.

Behind the scenes, a brand new piece of money gets minted electronically, and it bears the digital signatures of both you and the restaurant. You agree to ”pay” them within 30 days, and they agree to let you out of the restaurant without you washing any dishes.

So this raises an interesting question: What are you going to use to pay them? After all, this is an article on new money, and you’ve just given them some—yours. So why do you have to do anything further?

Because the value behind money doesn’t stand still. It travels in circles, until eventually redeemed. And we haven’t completed the process until that somehow happens.

Because you have such a stellar credit rating, we can imagine the next step happening just as you are walking out of the restaurant. You have instructed your MyCHIPs server to pay all your bills right away, rather than waiting the allowed 30 days. This helps you get out of restaurants and other places quickly so it is well worth it.

So your server makes a standard followup query to the restaurant’s server and asks it what kinds of CHIPs it has and what kind of CHIPs it wants most. The restaurant also gives you a call-back address which will allow you to indirectly query all its direct suppliers and employees as well as its regular, known customers.

We mentioned you are going to pay the restaurant. And the first rule of MyCHIPs is the issuer of a CHIP must always accept its own credits in full satisfaction of a debt. It’s the only legal tender law you will find in the MyCHIPs construct. So you are going to try to find some of the restaurant’s own issued CHIPs in the network and pay it with those.

Not only will that be fully satisfactory to the restaurant, but it will retire some CHIPs that may have been floating around in the CHIP-o-sphere for a while. That will contract the money supply slightly, and will clean up the restaurant’s books just a bit.

If you can’t find those, we will go to the next best thing and try to find something else on the restaurant’s list of “CHIPs it wants.” Anything it specifies in its “want list” is good enough to settle your account.

Most likely, the restaurant is also interested in acquiring the CHIPs of its suppliers. And the more kinds of CHIPs it accepts, the better its quality rating, so they are probably in the list too.

The restaurant will be purchasing food and other supplies on a regular basis and it knows having those kind of CHIPs will make payment easy and fast. The vendors are also known businesses, so their credit is a relatively safe place to store value. So they are good CHIPs to hold—in other words, a good deal for the restaurant.

The restaurant would also be interested in its employees’ CHIPs if they can be found. Paying an employee with his own CHIPs would also redeem some outstanding money.

But the restaurant may not always have vendor CHIPs available so it may also pay them with its own CHIPs sometimes. And the restaurant will normally be paying its employees with its own CHIPs, so they are likely to have some available. This is why your server will be querying downstream, through the vendor’s supply and labor network, looking for the kind of CHIPs the restaurant wants, but doesn’t yet have enough of.

At the same time, your server may also query upstream in your own network. You are a supplier of labor to your own employer, so he is considered upstream from you. If you find an entity downstream who has CHIPs, satisfactory to the restaurant, you are going to have to give him something in return. You’re not sure what that is yet, but as you query the possible candidates, you will get a list of CHIPs they are looking for as well.

You are looking upstream because that is the stream of CHIPs you have easiest access to, to use for payment. Most obvious among these are the CHIPs of your own employer. You’ve been working there for several months now and you haven’t spent all the credits you have accrued with him.

But you may not find anyone downstream with restaurant CHIPs to sell who wants the CHIPs of your employer. So you may have to keep searching upstream and downstream simultaneously in a recursive, distributed correlation algorithm until you find some available CHIPs upstream that is in demand by someone downstream who has the restaurant CHIPs you are looking for. Another way of saying this is, when you find the same HID both upstream and downstream, you have, in essence found a money circle. It is a pathway, which if you follow far enough, will return right back to you. And the restaurant is the first link in the chain.

Now you are ready to reconcile the bill, which comes nest.

We call this a “credit lift” because of what it looks like on a graph. If you visualize money flowing downhill, or downstream from one entity to the next, you can imagine the restaurant somewhere in the middle. Above it are its customers. Below it are its suppliers and employees.

The money flows downhill, from customer to vendor, from employer to employee, at each step along the way. The value, or product flows in the opposite direction, uphill. Imagine raw materials being mined out of the earth and traveling up through a supply chain to finally become a finished product.

You have found some restaurant CHIPs for sale, held by one of the restaurant’s immediate trading partners. And that partner is looking for CHIPs for sale, held by one of its immediate trading partners. Your algorithm has found a chain of interconnected links, each node of which is interested in collecting some chips of his immediate down-streamer (his supplier). And the end of the chain comes right back to you, through your employer or one of your other trading partners.

Everyone along the chain is willing and able to perform a transaction involving the requested number of CHIPs. Each node only has to worry about the credit worthiness of his immediate trading partners. Each individual node’s logic is: I would willingly give some of my customer’s/employer’s CHIPs back to him, as long as I am guaranteed, at the same time, to receive an equal number of my own CHIPs back from one of my suppliers.

This is where the magic comes in. Intuitively, it seems like we now need some way to assure that everyone around the loop either completes the lift in full, or not at all. This kind of all-or-nothing deal is sometimes called an atomic transaction and is quite common in database design.

However, due to the well known two generals problem, it turns out, it is nearly impossible to do such an atomic transaction reliably over a distributed network. It seems there is always some way a cheater could enter in, agree at first to complete the transaction, and then do something else instead.

So under MyCHIPs, we will take a modified approach. The initiator of the lift, which is you, the restaurant customer in our example, starts a message flowing around the loop. It passes from node to node, collecting a list of digital signatures along the way. We will call this the “phase one commit.”

The general idea is, each person has committed hypothetically to the lift, on the condition that it is certified by you, the lift initiator. If you roll it back, the commitments don’t mean a thing. But if any participant in the lift receives the proper and authorized signature validating the lift, he can attach that signature to the lift.

The affect of doing so means that the credits he was offered in the lift are ratified. In other words, he gets the money he was promised in the lift. Now its his job to pass the validation signature along the line to his next trading partner so he too can get paid.

If everyone around the circle is well behaved and sends the signature along as they should, everyone particpates in the transaction. The effect for them is net-zero, meaning they don’t end up with any more or less CHIPs. But they got rid of some CHIPs they have but don’t need. And the acquired some new CHIPs they wanted but didn’t have enough of.

What if someone is naughty and doesn’t pass the validation key along? At first it seems like they would have snookered the guy next in line. But there are mechanisms to handle this.

First off, the node who is waiting for the signature doesn’t have to wait around all day. He can communicate with other nodes in the lift. And he can do so in two different directions around the loop, only one of which goes through the naughty node. So he is going to get the signature eventually, even if he has to pass an indirect message all the way back to you, the lift initiator to see if the lift was commited by you.

When he gets the signature, the money meant to pass from the naughty node to him is now good. The snookerer hasn’t successfully snookered at all. He just ends up looking like an idiot. And think about to whom.

This is like an employer trying to rip off his employee, or a company trying to rip off a vendor. Yes, it can and will happen. But not for long.

Remember, the only person you can try to snooker is your immediate trading partner—someone you know, and who knows you. This is someone you depend upon in order to carry on credit lifts, the only way you can pay or get paid through the MyCHIPs network. Would-be snookerers are not going to last for long. And their snookering is not really going to work anyway.

So back to your restaurant bill. At the end of a successful lift, you end up with some restaurant credits, which you trade against your personal credit, outstanding with the restaurant. And your bill is now resolved.

All this has happened behind the scenes, while you were enjoying the walk back to your car. That is, assuming everything worked out right.

More on Transactions

There may well be cases where an automated algorithm can’t find satisfactory voluntary trades to resolve all balances. If your server configuration is pretty sophisticated, it may keep trying for 2 or 3 weeks, until your 30 day credit is nearly coming due.

Then you may have a choice to make. Your server might be preconfigured to go out to known money market sites and continue the search for viable pathways to trade credits. But this may have a modest cost, if nodes are only willing to conduct the necessary trade for a fee.

If you absolutely can not find the necessary pathway, you can always convert to dollars, euros, or whatever else the restaurant accepts and resolve the bill that way. The more widespread the MyCHIPs user base, the easier it will become to avoid this last resort.

We should note, your server could also be configured to anticipate your spending patterns. You probably have a handful of grocery stores, restaurants and movie chains you like to frequent from time to time. It would be easy to begin to collect these kinds of CHIPs proactively—even before you need them.

A business may well be willing to give you net 30 terms for your personal credit. But they would prefer to be paid faster. What they really love is when people pay them in advance.

That is the effect of holding a company’s CHIPs. It is like you lending them money or paying for one of their gift certificates or coupons. So they might even be willing to give you a discount if you pay directly using their own CHIPs.

One of the fundamental principles of a CHIP is, all CHIPs should ideally be exchanged in voluntary trades at a 1:1 multiple. The list published by a server of what it has, and what it wants, defines the trades it is willing to do at par, or nominal CHIP value.

But it is also possible to include the notion of what I have, that I could give up, but don’t really want to, and what I don’t really need, but am willing to buy under the right circumstances. This is the definition of a money market node—trades the node is willing to engage in, but only if an additional fee is paid, in the form of a trading ratio.

CHIPs you hope to keep, but would let go of for a price, you list a premium ratio for, say 1.05 times par. CHIPs you will take, but are not as anxious to buy, you list a discount radio, say 0.95 of par. Any node anywhere along a proposed credit lift should be able to communicate with you, by way of a message relayed through your immediate trading partners. It is in your best interest for your server to answer all such buy/sell questions without reservation or bias.

Risk Coverage

We have mentioned the ideas of credit insurance and credit certification. In order to be of the highest value, credit contracts need to be readily enforceable, preferably by the network itself—but also in the outside world.

One approach for allowing a reputable third party to certify credit would be a conditional tally. The idea is that an insured or guaranteed tally carries not only the ID and signature of the issuer and the owner, but also of the guarantor. In the event that an incurred debt is not honored by its issuer, the owner needs to be able to automatically convert the tally, and its contained CHIPs to become the issue of the guarantor.

This is an irrevocable contract of sorts. Once this option is exercised, the guarantor shall have options for redress, but not against the owner—rather against the original issuer who reneged in the first place. Perhaps the guarantor should end up with a pre-signed and authorized tally issued from the original issuer, and payable to the insurer. That way, if the defaulting entity returns to the network at a later time, the bad debt can eventually be collected.

Perhaps a simpler approach is just to interject the third party right from the beginning. For our example, we will call this trusted party MasterCHIPs. And as you will see, it isn’t much different from the notion of credit cards we use today.

The idea is simple. Instead of proving your credit worthiness to all the different vendors you regularly use, you simply prove it to MasterCHIPs.

They know your real world identity, your government ID numbers, your birthday, address and other sensitive information. They know how to collect value from you in the real world. If you owe them money, they will know how to get it.

Then, instead of issuing your own CHIPs to a restaurant, gas station or grocery stores, you are authorized to spend MasterCHIPs at those locations. MasterCHIPs then manages the required lifts to resolve your debts, using the credits you accumulate from your employer.

This would likely be a little more costly for you than establishing your own private credit relationships, or collecting credits in advance from your preferred vendors. But it does provide some additional convenience and anonymity you might find worth paying for.

Mediation

One more advanced topic involves the idea of mediation. Of course, compliance contracts can, and perhaps should include language enabling damaged parties to seek redress in the outside legal system. Clauses which agree in advance to third-party mediation might be attractive to many quality scoring algorithms. But it is also possible to envision resolving certain complaints right within the MyCHIPs community.

This would work by issuing tallies that are also signed by a trusted mediator. The parties would agree in advance that any dispute regarding the issued debt would be resolved by the mediator. Because he is a signatory to the tally itself, he can have the authority to act on behalf of the issuer or any of the assignees, should a dispute be raised.

If either of the parties disputes a particular transaction or chain of transactions, he can file the dispute with the private mediator. A binding decision could be made solely by the mediator. Or in particularly large cases, the mediator could even contract the dispute out to a group of paid jurors, with reputations and experience ratings of their own. In cases where a larger jury is involved, the case could be decided by a majority, or it could even be a pro-rated judgement according to the differing opinions of the jurors. Each of these points could be dealt with in the particular compliance contracts executed at the time of the issuance.

In each case, mediators and jurors would be paid for their time, by one for both of the parties, for example, the loser, as might be defined in the associated contract.

A pre-defined mediator could also be a useful mechanism to deal with lost or stolen keys. If tallys are left with outstanding balances that can not be resolved due to a lost key, the mediator could step in to sign transactions that would close or otherwise resolve the tally. If transactions occur due to fraud, a trusted mediator would have the authority to sign remedial transactions with those party to the involved tally(s).

Personal Strategies

Your server should represent you and your best interests within the credit trading ecosystem. This opens the door for add-on services which can interact with your node to serve your long term financial interests.

One interesting byproduct of carrying on all your financial transactions in a single trading platform is better accounting.

Few people really do, or even understand, accounting very well. Our money is earned and spent in a variety of different ways. And it takes a huge amount of effort to consolidate all those transactions into a single accounting program like Quickbooks, for example.

Furthermore, if we do go to the trouble of entering all that data, many of us don’t really know how to get a benefit out of it. For example, what can we learn by looking at our balance sheet, or our income statement? If we had better feedback coming from an accounting analysis application, could we perhaps modify our behavior in ways that would improve our quality of life?

Today we have phone apps that help us remember to exercise, or tell us how well we are sleeping. What if a phone app could tell us how we are doing at saving for college or for retirement? Of course, with proper accounting, this could be done. But the amount of work to feed in all the data is often prohibitive. And most of us don’t know how to analyze the data anyway.

But if all our financial transactions are available in a single trading platform, it would be very feasible to develop intuitive ways of presenting, and therefore, comprehending our financial fitness. Imagine a graphical representation of your balance sheet, over time that would show you the effect of your behaviors and help you plan more effectively for the future.

An add-on package could tuck away a few CHIPs each week and begin to accumulate them in an interest-bearing, real estate backed issuance. Maybe it would coach you about paying off your home or your car, so you would have accumulated equity you could borrow against later. It could help you apply the discipline necessary to assure that when your working years are over, you will have an accumulation of assets capable of carrying you through your retirement years.

MyCHIPs software should facilitate an API allowing the development of a whole market of add-on products and services to help people take better control of their financial lives.

Topics for Further Discussion

What transactions need to happen when a person with a MyCHIPs ID dies? This may happen with or without a named heir in the outside world. A pre-defined mediator, and compliance clause could be crafted to deal with this situation.
A similar topic involves what happens when an ID disappears from the network and is no longer responsive. Outstanding CHIPs issued by the disappeared party represent a potential loss to anyone holding them. Outstanding CHIPs that are held by the party, but issued by others, still active on the network pose the reverse problem. The issuer gets, in essence an interest free loan which could go on indefinitely—at least until the holder reappears later to redeem the CHIPs.
What transactions need to be supported by servers in order for freelance auditors and other potential types of enforcer agents to effectively do their work? The test case involves a party who successfully issues CHIPs on the network, but refuses to be fully transparent to auditing servers, and refuses to record negative information about itself. This would be easier dealt with in a centralized system where interested parties could go for a more objective opinion of the party’s reputation. In a decentralized system, we must be satisfied with the reputation of any insurers, or be wary because of the lack thereof.
What transactions need to be supported to support the idea of a class action case in the real world? For example, a bad actor issues fraudulent CHIPs and there are a number of other entities who have been harmed. How could a willing enforcer successfully contact all holders of the fraudulent CHIPs, without the cooperation of the issuer, and thereby organize a larger group of claimants to take legal action against the fraud? Again, this is a concept more easily dealt with in a centralized system, but much more difficult in a peer-to-peer network.
Perhaps various providers of account services would voluntarily keep a database of alerts which individual servers could query at their option. This could include fraud complaints as well as advertisements for services such as auditing, certification and class actions. Interested servers might want to periodically compare their own CHIP holdings against any issuances that might appear on an alert site. Any number of alert sites could exist, and they could even mirror each others’ alerts to provide a form of centralization that is voluntary.
There is a need to generalize the money market functionality to work for both CHIPs and traditional currencies. In other words, each node needs to be able to trade its own CHIPs or the CHIPs of its immediate partners for traditional money. Each node needs to be able to publish the exchange rate it is willing to accept for both buy and sell transactions. And there needs to be a portal to Paypal, ACH, or the equivalent to facilitate the actual transfer. This is like a shopping cart that can be checked out automatically without the interaction of the entity, but according to the pricing established by the user.
It would be preferable if, when searching for credit exchanges and lifts, knowledge of the network is distributed. In other words, nodes should only really know specifically about what their nearest neighbors have to buy and sell. Beyond that, they should just know which partner to go through to facilitate more distant trades. The exact knowledge of the complete pathway for a credit lift would be distributed among the participating nodes. This would create additional privacy and security. It would also prevent a single node from mining information about other nodes, such as someone’s net CHIPs worth.

Summary

So, much of the detail of server functionality has been outlined. Many other details are left to be sorted out.

If you have gotten this far, please make contact and give your constructive feedback. All questions on this page first need to be resolved. Then it is time to go on to a more complete protocol specification. Then the coding can begin.

Thanks for your interest in MyCHIPs. We hope you will join the effort.
<— Prev Next —>

Got Choices?

Who's In Charge of You?