Skip to content

Instantly share code, notes, and snippets.

Last active Jun 23, 2017
What would you like to do?
Decentralized Mutual Credit Clearing on the Blockchain
It's a marriage of the ideas proposed by Thomas H. Greco. in the book 'The end of Money and the Future of Civilization' to the ideas proposed by Satoshi Nakamoto with the Bitcoin protocol.
Decentralized Mutual Credit Clearing on the Blockchain from the bottom up.
Briefly, this is how I envision it working.
Issuance of Smart Contracts
Farmer Joe issues 10000 joe coins out of an address on the base blockchain and gives it to anyone that works for him. Say, 10 Joe coins/hr for some amount of produce. (This part could be encoded as a message in the base blockchain).
- Amount of issuance
- Brief description of issuance (as long as within limit of the size of transaction on base blockchain
- Expiration Date (can be computed by determining block number and block rate and find the expiration target block of the base blockchain)
People start working for him and the coin goes into circulation.
Farm Burger a few miles down also issues 5000 fb coins out of an address on the base blockchain and gives it to anyone that works for them. Say, 20 fb coins/hr for some items on the menu.
The wallet allows them to find each other based on various criteria (location is my favorite, but why limit it to that). And a CFD to be created based on various criteria and the various wallet implementations of the base blockchains can decide on how much features or simplicity they want to provide.
In other words, Megan who worked for farmer Joe can now spend her coins with farmer joe (till the expiration date) or with Farm Burger (till that contract's expiration date).
The longer the expiration dates the more the token behaves like an asset, the shorter the expiration dates the more the token behaves like a currency. It could of course always be a hybrid too where the expiration from original issuance is for a very long time while for various CFDs that a particular issuing address might have created is for shorter times.
- Search for Nearest x units of location
- Search based on some other specific parameter (could be many). All wallets could allow their own implementations and 'features' for searching
- Send Request (for creating a CFD - contract for difference). Again individual wallets could allow for their own kinds of implementations of what a CFD means to them.
- Accept Request
When this happens. The hash of the cfd contract is actually stored in the main Bitcoin blockchain. But the base blockchain within it contains the merkle root of the wallet addresses that can now accept each others coins.
This would allow for easy discovery of where all can the coins in my wallet be used.
One important point to consider here is if the original issuance is done using the
-transaction ID in which case no more coins will be issued.
-address ID in which case more coins can be issued and this can very easily be tracked (but perhaps future coin issuance could be restricted to some voting requirements based on the existing CFDs that address ID already has out there).
- Decline Request.
Notifications. yada yada. Perhaps some sort of revision workflow for CFD or stop.
Some other important points to note:
Farm Burger could be creating his own CFDs with others or Farm Burger and Farmer Joe could together create further CFDs using their existing CFD. Say, a neighboring housing complex issued its own Foxy Coins which are redeemable for rent by them and this housing complex gets into a CFD with the existing CFD of Farm Burger and Farmer Joe rather than getting into individual agreements between them. Or the housing complex could get into separate agreements with each other.
Now imagine thousands of such contracts. When you work for a particular place and get it's coins you could use them in 1000s of places.
Decentralized credit from the bottom up instead of centralized debt from the top down.
Every existing blockchain out there that has the capability of smart contracts could implement this on their own blockchain and just keep the hash of the transaction (of CFD) on the Bitcoin blockchain.
The Bitcoin protocol allows for a 40 byte OPRETURN value.
That 40 byte value could be represented as such:
That is:
The first 32 bytes are the hash of the transaction from the base blockchain.
The next 2 are bytes of the identifier of the base blockchain (could represent 2^16 permutations).
The next 4 is some sort of a time identifier till which the transaction is valid. (Can cover up to approx 140 years)
The last two would indicate that this transaction is a specific kind of transaction for mutual credit clearing. The name is handful and I just like to call it 'Ananda'. It has two possible values:
':)' - The issuance is based on Transaction ID
';)' - The issuance is based on Address ID
The 'base blockchain' could refer to some other alt blockchain (say FlorinCoin, BitShares, NXT) that has the capability to implement such smart contracts or perhaps the federated Open Transaction Server or even on top of one of the meta layers on top of Bitcoin (Mastercoin, CounterParty, ColoredCoin) as long as the OPRETURN value is not being used by any of those already.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment