DevLog 11 - Catallax Trust White Paper and Release Schedule

I’ve spent the last three weeks working on the Web App for our Project MCD.  I have the functionality there and am now onto the design.  I’ve tried to simplify things along the way so that I can get things to release.

Now that all the functionality is in place I’m happy to announce the release schedule!

Project MCD is actually a project called the Catallax Trust.  The Catallax Trust is a fiat trust that will let you lock up crypto and have it paid out over time based on the price of crypto assets on the date of payout.

For example:  Put 100 ETH into a contract and have it pay out $1,000 a month for 3 years.  If the price of ETH goes up less ETH will come out each month.  If it goes down you will get more ETH, but your trust may run out of money before the 3 years is up.

These trusts are good for employment contracts, giving to charities, keeping your self-disciplined and HODLing during the fork to Metropolis and the inevitable volatility that will follow.

I’m releasing the whitepaper today, code soon, test net after that and hoping to be live by the time we get to DevCon 3.

Schedule:

October 2nd:  White Paper 

October 9th:  Contract Code Release

October 16th:  TestNet Release

October 23rd: Live

Please head over to this thread on our Reddit to pick the white paper apart and ask questions.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

You can discuss this article and more at our reddit page r/Catallax.

DevLog 10 - HarveyCoin - Decentralized Disaster Relief

***Read Past the intro to hear about a set of Etherum contracts that let you donate your existing ETH today to people that need help and get it all back in the future as the disaster is mitigated.***

Catchup:

Another month has gone by since the last Catallax DevLog update and it has been a busy month.  Work on project MCD continues and I’m still hoping to hit October 1st unless I get derailed by the project I’ll be discussing today.  The most interesting news is that we participated in the dAppathon put on by BCG DV and Dvolution in LA. We launched a prototype for a service called Lannister (http://lannister.tech) that lets you collateralize any existing or future ownable ethereum service.  I’ll publish a dev log on this in the future but we have more important things to talk about today. 

Now for today’s news and request for help: 

I’m from Houston and I haven’t been home for 2 ½  weeks.  I’ve seen pictures and I’ve heard stories. We’re headed back home now to a dry house with our shoulders filled with survivor’s guilt.  I’m a computer programmer.  I’m not a jump in a boat and pull people out of houses kind of guy.  I know people like that and I’m amazed at their service. What can I do?  How can I help?

I’ve started something and I need your help.  One of Catallax’s core concepts is the idea that decaying money can be used to rapidly rebuild a crumbled economy.  This was tried in Austria in the 1930s and was so successful that it threatened the central bank’s authority to issue currency and was shut down. See the Worgl experiment.  Ethereum lets us try it again very easily.

We have very big plan on how to implement this in a global way that fundamentally realigns incentives in the economy.  We are working on it, but we need help now.  Houston is hurting and Irma is hurling toward Florida and about to create another disaster area.

So here is what I have so far.  I call it HarveyCoin.  Open to better names.

HarveyCoin

HarveyCoin allows you to donate ETH to people who need it today and get it back over the course of the future in a guaranteed way. It is a glorified HODL strategy that helps people get their homes back while you maintain your position in ETH that you plan on cashing in far in the future.

There are four use cases: 

  1. Donate.  Donate your ETH today by creating a HarveyWallet and minting new HarveyCoin.  There is a 1:1 relationship between HarveyCoin and ETH.  Your ETH will be given out to people in need over the next 5 years and will decay back to you over that time.  So if you donate 5 ETH today you’ll be able to reclaim 1 ETH in a year, 1 ETH the year after that, etc.

  2. Become a Service Provider.  Create a HarveyWallet and begin accepting HarveyCoin for your services today.  The ETH you make by selling your services will decay at a stiff ~20% rate, but per day this is fairly low if you work with your fellow vendors and employees to get them onto the system as well and can turn over your HarveyCoin quickly.

  3. Get help.  Apply to the custodian to get disaster relief funds in the form of HarveyCoin in your HarveyWallet.  You’ll be free to spend the HarveyCoin with any approved vendors or other citizen that has a HarveyWallet.

  4. Exchange ETH for HarveyCoin.  Exchange cash or ETH to get more HarveyCoin.  This lets people who are dead ends in the ecosystem get value out the system for their HarveyCoin.  If the system is successful this should maintain as close of a 1:1 relationship between HarveyCoin and ETH as possible.  This gives us a good barometer of the system's success.

If you have ETH today that you plan on holding for a long time your only downside is liquidity. HarveyCoin helps you resist fear, uncertainty, and doubt while building the utility case for Ethereum. 

There is no profit built in for the custodian in the initial contracts.  The custodian can issue itself some HarveyCoin for administrative purposes, but I’m hoping this can be kept to a bare minimum and will keep the custodian true to making sure that HarveyCoin is as valuable as possible as it is the only funds that the custodian will be able to get access to.

You can find the command center for this project on r/Catallax here.  Please hop over and find a way to help.

Things we need:

  1. The initial contracts need to be vetted and can be found here.  I’m hoping to build some truffle tests in the near future as real life allows.  I wrote these quickly and they need some serious TLC before going live.
  2. Wallets for iOS and Android that make it dead simple to trade HarveyCoin.  I know react-native has some issues with implementing web3, but maybe there is a cordova/phonegap solution that can be put together quickly.
  3. Suggestions for the governance structure.  Right now the custodian just has an owner, but we can easily set that to a multisig wallet or some other governance structure.  All suggestions welcome here. I don't have the talent, training, or bandwidth to run a significant disaster recovery effort all by myself.
  4. A web app that directs the 4 use cases to relevant web apps that can capture info needed to approve wallets.
  5. Someone to write the exchange contracts.

I’ll quickly go through the basics of the contract:

HarveyCustodian

Members:

uint drain - holds decayed funds available to be claimed by minters

address treasury - the treasury wallet that minted funds go into for dispersal.  Also a HarveyWallet and subject to decay.

uint totalMinted - the total donated

uint totalDrained - the total reclaimed

address owner - owner of the custodian

mapping(address => bool) validWallets - allows the custodian to authorize HarveyWallets to participate in the system.

address[] wallets - a list of wallets that have participated with the system for iteration.

Functions:

setOwner - sets the owner of the custodian

setTreasury - sets the treasury wallet

mint - forwards funds to the treasury

unMint - allows minters to claim funds out of the drain

sendDecay - deposits decay with the custodian

setValidWallet - sets the validity of the wallet

calcVested - calcs the % vested over a 5 year period of a donation

availableToRedeem - calcs the amount available to be withdrawn given a minted amount, redeemed amount, and startTime

HarveyWallet

Members:

mapping(address => bool) owner - holds the owner status of the wallet.  Allows for multiple owners

address custodian - the custodian overseeing the wallet

uint lastCatchup - records the last time the wallet paid the decay fee

uint mintStart - records the time the wallet minted(you can only mint once)

uint minted - amount minted

uint redeemed - amount redeemed already

Functions:

setOwner - sets the address and validity of an owner

pay - pays an amount to another valid HarveyWallet.

calcCatchup - calculates how much this wallet owes in decay fees.

catchup - pays the decay fee to the custodian.

mint - donates ETH to the treasury that can be claimed back as time moves forward.

unMint - claims back ETH from the drain

Please hop over to r/Catallax to discuss more. 

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

You can discuss this article and more at our reddit page r/Catallax.

 

Dev Log 9 - New OpCodes and Schedule Update

It has been about a month since the last update and the reason is that I’ve been coding like crazy.

I’ve discovered some cool stuff coming in metropolis that will make Project Sigmund a much better and more useful project.  The opCodes are returndatasize and returndatacopy.  I’m going to have to start learning some assembly for this so if you have some good suggestions on where to gets started with assembly, let me know.  I want to do something like this:

bytes results;

bool testresult = aContract.call(sig, _1);

if(result == false) throw;

assembly {

// retrieve the size of the code, this needs assembly

let size := returndatasize()

returndatacopy(results,0, size)

}

return results;

As a result of this discovery, I’m moving Project Sigmund Back to after Metropolis comes out.  I’ve been very busy with Project MCD.  As of today, I have the contracts feature complete and there is just a bit of refactoring to come.  Then, on to the web app.  I’m don’t think I’m going to hit my original August 15th deadline, and I now would like to have it mostly ready to go by August 24th when I’m heading out to LA to participate in the Dappathon. If you are going to be there, please let me know.  I'd love to sync up and I'm still looking for a team to participate with.

The coding on these contracts is giving more perspective and I’m pretty sure that Project BMP is a no go because they just take too long to build and I really like the direction I’m going for a full featured Catallaxian set of contracts in Project Wall-e so I may just jump into those after MCD goes live.

I’ve also got a good bit of legal advice on Project CANb.  As you know the SEC ruled on the DAO and that is really steering me away from a token based project.  We’ll see if there is a good solution or not, but i’m still hoping to get the basic white paper ready to shop around at DevCon. I may have to leave the idea on the cutting room floor, but hope remains.

Here is the updated schedule

  • Project Sigmund - August 15th, 2017(delayed to after Metropolis)

  • Project MCD - October 1st, 2017(Expected August 24th)

  • Project BMP - November 1st, 2017 (DevCon3) (In jepordy of being cancled)

  • Project CANb - April 1st, 2018(Facing legal hurdles)

  • Project WALL-e - August 1st, 2018(May get moved up)

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

You can discuss this article and more at our reddit page r/Catallax.

Dev Log 8 - Project Timeline

Today is a short update.  The last week and a half have been pretty full of 3-hour feeding cycles trying to get my new son up from 6lbs. to 7lbs.  We hit 7 this morning.  Great Success.  As a result, this week has been light on the coding side of things as the day job has been getting almost all available cycles.

The coding that I have been doing has been scoping out the framework for our first "real-world product."  Since it is all theoretical so far I'm not quite ready to show any of it off.  What I have done is put together a very aggressive timeline of the Catallax project.  I'll offer it here without many details.  Feel free to hold my feet to the fire.  I'm sure we'll see some slippage, but if I don't set some hard goals I'll just stay in the learning phase forever.

  • Project Sigmund - August 15th, 2017
  • Project MCD - October 1st, 2017
  • Project BMP - November 1st, 2017 (DevCon3)
  • Project CANb - April 1st, 2018
  • Project WALL-e - August 1st, 2018

This is a pretty aggressive schedule and has me building 3 production level dApps by DevCon.  I kind of doubt the 3rd one will be ready, but I hope that the first two will be.  Sigmund and MCD do not have any kind of ICO component.  I'm hoping that they will be solid, real-world products that can provide some revenue for the remaining development.

Project BMP is a really exciting experiment in Catallaxian economics and I hope I can have some of it ready for DevCon.

CANb and WALL-e are big, epic projects that require a lot of jumping through regulation hoops and infrastructure creation.  I've given them a little more runway.

Next week I hope to have some lessons learned from my develpment on Sigmund.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

You can discuss this article and more at our reddit page r/Catallax.

Loans and New Type of Capital

This is the fifth part in a five part series of posts that lay out the basics of what we are trying to build with Catallax.  The series will follow the following schedule and I’ll update the list with links as the articles go live:
 
Demurrage, Catch Up, and Pref Dividends
Passthroughs, Legacy, and Folding the Blockchain
Privacy, Accounts, and Transparency 
Voluntary Organization and Citizen Override
Loans and a new kind of Capitalist (today)
 
One way to offload the responsibility of paying a decay fee is to loan your cash to someone else so that they pay the fee instead.  Loans under the Catallax system have some important properties that are important to discuss and that make apparent the power of this new economic system.
 
When a loan is made in the Catallax system it is done via a particular kind of loan smart contract.  This contract has the unique ability to remove prefs from circulation when a borrower pays cash back to a lender.  This is important because we don’t want symbiotic small circles forming in our economic ecosystems.
 
Lenders will lend a borrower cash and in return get prefs in that borrower's account.  They hold onto these prefs (as well as the loan amount) until payments start coming back the other way.  When a borrower pays back some of the loan the prefs will be removed from the lender’s ledger.  During the length of the loan the lender will benefit not only from the interest charged but from the pref payments coming from the borrower.  If the borrower is using the the cash for building a business it may become prudent for the lender to forgive the loan balance to maintain a pref balance with the borrower.
 
This turns lenders into a new kind pseudo banker/venture capitalist.  We believe that a large number of balances will be forgiven and that this will form a new, more personal, relationship between bankers and borrowers.  Bankers now can find a long term benefit by helping their clients become more profitable and driving revenue to their accounts.
 
Another effect this should have is driving interest rates to very low levels.  When people are wanting to loan out cash instead of having it decay the amount of capital available should increase and form a very competitive market for rates.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

You can discuss this article and more at our reddit page r/Catallax.

Storage Contracts, Mappings, and ETL - Dev Log 8

Weekly Updates:

  1. Did I mention I was a father again? Not a whole lot of coding this week as I’m trapped in the whirlpool of 3 hour feeding cycles.  Never fear though we do explore something of value today.
  2. My book Immortality is up to #123 in the Kindle Store > Kindle eBooks > Nonfiction > Politics & Social Sciences > Philosophy > Metaphysics category on the kindle store.  Watch out world.
  3. I purchased my various tickets to DevCon3.  Look out Mexico, Here I come!

The Code

Today’s post isn’t very long but I think it will help answer some questions for others who have been confused by the storage system in Ethereum.

There are a number of good pieces of info out there that talk about how you should handle storage for more complicated contracts.  The basic idea is that you create a storage contract to hold all of your data so that if your master contract needs to be replaced you can just deploy a new contract and point the storage to a new place.  Here are a few articles on how some of this works:

https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88
https://ethereum.stackexchange.com/questions/13167/are-there-well-solved-and-simple-storage-patterns-for-solidity
https://ethereum.stackexchange.com/questions/15930/pushing-pulling-data-from-data-storage-contract
http://solidity.readthedocs.io/en/develop/miscellaneous.html

The colony article is really interesting and they end up setting a place for all different kinds of data.  As it is difficult to predict what kinds of data you are going to have I thought it would be interesting to think about how to make this more generic.  This gets especially difficult when you start doing mappings of mappings.   This is going to be important for our decaying tokens as we are going to need to keep track of transaction inputs in a mapping(address => mapping(address => amount)) such that we can get data you like prefs[reciver][payer]

My little example looks at allocating ERC20 allowances and how to store those:

contract MapTest {

    mapping(address => mapping(address => uint256)) public approvals;
    mapping(bytes32 => uint256) public approvalsKeccak256;
    mapping(bytes32 => uint256) public genericStore;

    function MapTest(){

    }

    function AddAllowanceMap(address sender, address recipient, uint256 amount){
        approvals[sender][recipient] = amount;
    }

    function AddAllowanceKeccak256(address sender, address recipient, uint256 amount){
        approvalsKeccak256[keccak256(sender,recipient)] = amount;
    }

    function AddAllowanceGeneric(address sender, address recipient,uint256 amount){
        genericStore[keccak256('allowance', sender, recipient)] = amount;
    }

}

If you load this up into Remix and run each function with "0x1","0x3",100 you will see that the gas cost is just about the same for each instance.

This is pretty powerful as we can now keep all of our mappings in one place.  This violates all kinds of separations of concerns and may be a bad idea, but it will make the code in our stage contract much cleaner.  So if we are going to violate the separation of concerns, let's go all the way and build a generic storage contract that can be ETLed if we need to copy data.

Here is the basic generic storage contract.

contract StorageTest {

    //keep track of if we have seen this key before or not
    mapping(bytes32 => bool) public genericStoreExists;

    //a place to put our data
    mapping(bytes32 => bytes32) public genericStore;

    //a place to keep track of our keys.  Out of order...but still, we
    //have them
    bytes32[] public genericIterator;

    //keep track of the number of keys we are storing
    uint256 public genericCount;

    function StorageTest(){

    }


    //store our data
    // We assume that your variable name has been convered to 
    // bytes32.  You can do this via a keccak or converting string to bytes
    // We assume you have keccaked your variable path
    // We assume that all values are cast to bytes32
    function PutValue(bytes32 _dataGroup, bytes32 _kecKey, bytes32 _value){

        bytes32 key = keccak256(_dataGroup, _kecKey);
        return PutValueRaw(key, _value);
    }

    function PutValueRaw(bytes32 key, bytes32 _value){

        genericStore[key] = _value;
        if(genericStoreExists[key] == false){
            genericStoreExists[key] = true;
            genericIterator.push(key);
            genericCount = genericCount + 1;
        }
    }


    //get the raw bytes
    function getBytes(bytes32 _dataGroup, bytes32 _kecKey) constant returns(bytes32){
        bytes32 key = keccak256(_dataGroup, _kecKey);
        return genericStore[key];
    }

    //get integers
    function getInt(bytes32 _dataGroup, bytes32 _kecKey) constant returns(uint256){
        bytes32 key = keccak256(_dataGroup, _kecKey);
        return uint256(genericStore[key]);
    }

    //get addresses
    function getAddress(bytes32 _dataGroup, bytes32 _kecKey) constant returns(address){
        bytes32 key = keccak256(_dataGroup, _kecKey);
        return address(genericStore[key]);
    }

    //get bools
    function getBool(bytes32 _dataGroup, bytes32 _kecKey) constant returns(bool){
        bytes32 key = keccak256(_dataGroup, _kecKey);
        bytes32 value = genericStore[key];
        if(value == 0x0){
            return false;
        }
        else{
            return true;
        }

    }

    //not sure about arrays
    //not sure about enums
}

There is more work to do here, but the basics are here.  Try putting in some data by creating a contract in remix and then submitting PutValue with “0x0000000000000000000000000000000000000000000000000000000000000001","0x0000000000000000000000000000000000000000000000000000000000000001",”"0x0000000000000000000000000000000000000000000000000000000000000014".  

 

Once that is complete, call getInt with “0x0000000000000000000000000000000000000000000000000000000000000001","0x0000000000000000000000000000000000000000000000000000000000000001" and you should get out 20.  It works!

 

We can also ETL(Extract, Transform, Load) this contract.  Here I’ve built a small data copy contract that will move data from this storage to another storage contract of the same type:

contract StorageCopy {

    StorageTest public Source;
    StorageTest public Target;
    uint256 public CurrentItem;


    function StorageCopy(address _source, address _target){
        Source = StorageTest(_source);
        Target = StorageTest(_target);
    }

    function DoCopy() returns (uint256){
        uint256 SourceCount = Source.genericCount();
        for(uint256 i = CurrentItem; i < SourceCount; i++){
            Target.PutValueRaw(Source.genericIterator(i), 
                Source.genericStore(Source.genericIterator(i)));

            //keep track of where we are in the process
            CurrentItem = i;
            //todo:  scheme to check remaining gas and bail if gas gets too low
            //next call will start with Current item

        }
    }

}

Create two StorageTest contracts in Remix.  Call PutValue on the first contract with "0x1","0x1","0x0000000000000000000000000000000000000000000000000000000000000001" and "0x2","0x2","0x0000000000000000000000000000000000000000000000000000000000000002".  Now create a StorageCopy contract and pass in the addresses of your two created cotracts like this:  "0x0971b5d216af52c411c9016bbc63665b4e6f2542","0xde6a66562c299052b1cfd24abc1dc639d429e1d6" where the addresses are what Remix generated for you.  Call the DoCopy Function and the data should copy over.

You should now be able to call getInt with "0x2","0x2" on the second StorageTest contract and get out the 2 value you put in for that dataGroup / mapping address pair.  It works!

 

There is a lot left undone here.  You’d want to secure the data contract.  You also are going to have to deal with gas limits as the comments in the comments say.  There are some data types that I’m not sure how to handle yet.  Arrays could be particularly difficult.  You might be able to save a ton of gas by writing some native assembly in here as well.  All in all, though, this is a decent footprint for a basic storage contract.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

Get to know Catallax: Selective Citizenship and Citizen Override

This is the fourth part in a five part series of posts that lay out the basics of what we are trying to build with Catallax.  The series will follow the following schedule and I’ll update the list with links as the articles go live:

  1. Demurrage, Catch Up, and Pref Dividends
  2. Passthroughs, Legacy, and Folding the Blockchain
  3. Privacy, Accounts, and Transparency  
  4. Selective Citizenship and Citizen Override (today)
  5. Loans and a new kind of Capitalist

The Catallax system requires some ‘central’ authority to exist to set decay rates and pull the levers of the economy to keep the economic piston pumping.  A huge benefit of cryptocurrencies is the ability to do away with centralization.  In the same way that we took a long / short position on privacy, we will also take a long / short position on centralization.
 
In our opinion, the world is not ready to overthrow the nation state. There may be a day in the distant future where we can reach this kind of reality but we believe that there needs to be a bridge between now and then.  In order to neutralize too much authority, we propose a scenario of Selective Citizenship and the Citizen Override.
 
Selective Citizenship allows for citizen accounts to elect to pay a tax out of their pref flows that go to an institution that they want to be a part of.  These institutions can be State level institutions or something smaller like a local utility district or school system.  We contend that one of the killer apps of ethereum and other cryptocurrencies is taxation.  Once municipalities realize that by issuing their own form of crypto they can make taxation automagical you will begin to see a lot more municipalities issuing crypto.  Catallax seeks to speed this revolution by adding a taxation layer into our system.
 
We are also short authority and believe that citizens should maintain control over the ruling authority.  Therefore we put forward the idea of the citizen override.  The citizen override provides the opportunity for citizens to give an authority the right of easy taxation, but give the citizens an easy way to turn off the faucet and override the ability of the account to operate.
 
An example of how this would work on the largest scale would be the US nationalizing a Catallax currency and enforcing that all citizens elect the USA tax.  This tax mechanism replaces the IRS.  In return citizens now have a method to turn off the faucet by voting.  If Congress reaches a 23% approval rating like they have now, the citizens that pay the tax can turn off the government's access to pay representatives their salaries.
 
In a more realistic scenario, the first Catallax system will start in a state of benevolent dictatorship, evolve an authoritative court system, establish a legislative council that will turn into an elected body and then eventually pass to a form of constitutional organization where citizens have significantly more control over their governments than they currently do.
 
Our civic institutions have taken a serious hit in the last few decades as capitalistic organizations have found profit avenues that have made us less dependent on those civic organizations.  The Selective Citizenship system seeks to restore that civic infrastructure by giving grassroots organizations a dead simple way to generate revenue.  Because the money that is taxed is money that is already flowing away from citizens it is much easier to convince someone to elect the tax. They are going to be losing the money anyway, so why not have it go to a group seeking to improve the local street infrastructure or establish new green spaces?
 
This governance may be one of the last parts of the system to come online, but it is one of the most important pieces and any of our supporters should demand that these items stay central to the conversation of Catallax and its future.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

Testing With Time - Dev Log 7

Weekly Update

  1. I’m a Dad again(for the fourth time).  Weston James was born on Tuesday evening June the 20th.  Mom and baby are healthy.  Big Bro, Big Sis, and Big Sis 2 are super excited, and Dad is really proud.
  2. I guess I’m a professional solidity developer as someone paid me actual money(well ETH) for the contract we are discussing today.  Not a lot, but enough be significant.
  3. Work continues on the whitepaper for the first service offering that Catallax will be trying to launch.  Lawyers, accountants, legalese, etc., etc.

Today we are going to do some testing with time.  The is going to be very important once we start testing our demurrage code.  In our decaying token we used passing block numbers to calculate our decay periods.  In the example today we are going to use the actual time system in Ethereum.  This system isn’t an exact science since we are somewhat dependent on the Miners to give a truthful timestamp on each block.  You would not use this system if you were doing calculations on short time scales because a miner could attempt to cheat your contract.  Our example today uses month long periods so we should be fine using time.
 
The contract we are going to develop is called a DisciplineWallet.  Do you have lambo money from buying into the ethereum crowdsale two years ago?  Afraid you’re going to get spooked and sell?  Use the DisciplineWallet and restrict access to your ETH on a monthly basis.
 
When we first started talking about this contract the client wanted the payout to be consistent in USD.  We went back and forth and finally decided that we needed to do it in ETH because there isn’t really a good USD to ETH Oracle that is reliable over long periods of time.  If you know of one, please let me know and I’ll try to update this contract to do USD instead.
 
Our contract will do the following:

  • Be initialized with a term in months and an amount of ETH to pay out each month
  • Take Deposits in ETH
  • Expose a Withdraw function that can be called once a month to send the specified amount of ETH to the owner of the contract
  • Let us change the owner of the contract
  • Withdraw all the remaining ETH to a specified address once the term has run its course
  • Give us a safety function to move coins out of the contact if we accidentally send ERC20 tokens to the contract
  • Use the fallback function as a deposit function
  • Tell us when the next withdrawal is available

Once we write up our contract we are going to want to test it.  To do this we are going to need a blockchain environment that will let us make time go by quickly. Fortunately, the testrpc that is packaged with the truffle dev environment lets us do this with the following call:

web3.currentProvider.sendAsync({
       jsonrpc: "2.0",
       method: "evm_increaseTime",
       params: [86400 * 34],
       id: new Date().getTime()
     }


In the above example, we are moving the clock forward 34 days(86400 seconds in a day).  Our tests will do withdrawals and then move the clock forward and do withdrawals again.
 
Our contract will need to pass the following tests:
 
    ✓ should Deploy a wallet with owner (91ms)
    ✓ should be off when it starts and has no ether (69ms)
    ✓ should have a function Period that returns the length of a month (102ms)
    ✓ should have a function NextWithdraw that returns the first withdraw time (94ms)
    ✓ should turn on when sent ether (775ms)
    ✓ should fail if constructor sent ether
    ✓ should allow withdraw after 1 month and ether goes to owner (750ms)
    ✓ should fail on instant withdraw (255ms)
    ✓ should not allow more than term number of withdraws (955ms)
    ✓ should not allow withdraw if some time has passed, but not enough (382ms)
    ✓ should allow withdraw all after term is over (3389ms)
    ✓ should fail if withdrawAll is called before term is over (388ms)
    ✓ should reject payment if payout term is expired (2778ms)
    ✓ should deposit using deposit function (245ms)
    ✓ should allow for transfer of owner (1529ms)
    ✓ should reduce payout if payout would drain account before the end of the term (679ms)

The code and truffle set up can be found on GitHub here. 
Here is our contact.

pragma solidity ^0.4.11;

contract DisciplineWallet {

  /**
  * @dev term is the number of months that a wallet will pay out
  */
  uint16 public term;


  /**
  * @dev currentTerm tracks the number of withdraws that have occured
  */
  uint16 public currentTerm;

  /**
  * @dev contractStart stores the timestamp(number of seconds since 1/1/1970) that the contract was created
  */
  uint public contractStart;

  /**
  * @dev payout is the number of wei(smallest unit of ETH) to pay out
  */
  uint public payout;


  /**
  * @dev bActive is tracks if the wallet is open for business or not
  */
  bool public bActive;
  address public owner;

  /**
   * @dev Throws if called by any account other than the owner.
   */
  modifier onlyOwner() {
    if (msg.sender != owner) {
      throw;
    }
    _;
  }

  /**
   * @dev constructor
   * @param termLength number of months that the contract will be active
   * @param weiOutputPerPeriod of wei to pay out
   */
  function DisciplineWallet(uint16 termLength, uint weiOutputPerPeriod) {

    if(termLength < 1) throw; //term cant be 0
    if(weiOutputPerPeriod < 1) throw; //we cant pay out 0

    //the owner will start as the address creating the contract
    owner = msg.sender;

    //set the term
    term = termLength;

    //record the time of the start contract
    contractStart = now;

    //start with the current term as 1
    currentTerm = 1;

    //set the payout per period
    payout = weiOutputPerPeriod;
  }


  /**
   * @dev calculates the length of a month
   */
  function Period() constant returns (uint32 lengthOfMonth){
    //put this in a constant function so that we don't have to use storage
    //execution takes 302 gas which means calculation is more efficent in any contract under 66 months.
    //not sure about deployment costs
    //the period is about 30.66 days so that leap year is taken into account every 4 years.
    return (1 years / 12) + (1 days / 4);
  }

  /**
   * @dev tells us what date we can call the withdraw function
   */
  function NextWithdraw() constant returns(uint secondsAfter1970){
    return contractStart + (Period() * currentTerm);
  }

  /**
   * @dev the fallback function will make a deposit
   */
  function () payable{
    Deposit();
  }

  /**
   * @dev Put ETH into the contract, also called by the fallback function
   */
  function Deposit() payable {
    //don't accept ether if the term is over
    if(currentTerm > term) throw;
    if(bActive == false){
      //first time we get ether, turn on the contract
      bActive = true;
    }
  }

  /**
   * @dev Withdraw will send the payout to the owner if enough time has passed
   */
  function Withdraw() onlyOwner returns(bool ok){
    if(currentTerm <= term && now > NextWithdraw()){

      //payout may not be more than balance / term or the account has been underfunded
      //if it is then use the lower calculatio
      if(payout < (this.balance / (term - currentTerm + 1))){
        owner.transfer(payout);
      }
      else{
        owner.transfer(this.balance / term);
      }

      currentTerm = currentTerm + 1;

      if (currentTerm > term){
        bActive = false;
      }

      return true;
    } else{
      throw;
    }

  }


  /**
   * @dev once all terms have expired you can move any remaining ETH to another account
   * @param targetAddress The address to transfer remaining ETH to.
   */
  function WithdrawAll(address targetAddress) onlyOwner returns(bool ok){
    if (targetAddress == 0x0) throw; //dont accidentally burn ether
    if(currentTerm > term && this.balance > 0){
      targetAddress.transfer(this.balance);
      bActive = false;
      return true;
    } else {
      throw;
    }

  }

  /**
   * @dev Allows the current owner to transfer control of the contract to a newOwner.
   * @param newOwner The address to transfer ownership to.
   */
  function transferOwnership(address newOwner) onlyOwner {
    if (newOwner != address(0)) {
      owner = newOwner;
    }
  }

  /**
   * @dev Allows the owner to send tokens elsewhere that were accidentally sent to this account
   * @param Token The address of the ERC20 token
   * @param _to The address the tokens should end up at
   * @param _value The amount of tokens
   */
  function safetyTransferToken(address Token, address _to, uint _value) onlyOwner returns (bool ok){
    bytes4 sig = bytes4(sha3("transfer(address,uint256)"));
    return Token.call(sig, _to, _value);
  }

}


The tests are in CoffeeScript and can easily be compiled to js. The core test concept here is the passage of time.
 
In the "it should allow withdraw after 1 month and ether goes to owner" test we simulate the passing of 34 days via our testrpc evm_increaseTime function mentioned earlier.

Our test code needs to do this multiple time over a set amount of time.  I use a variant of the following function:

withdrawFunction = ()->
  return q.Promise (resolve, reject)->
    web3.currentProvider.sendAsync
      jsonrpc: "2.0",
      method: "evm_increaseTime",
      params: [86400 * 34],  # 86400 seconds in a day
      id: new Date().getTime()
    , (err)->
      i.Withdraw(from: accounts[0])
      .then (result)->
        resolve result
      .catch (err)->
        reject err

We can call it in a loop like this:

async.eachSeries [1..13], (item, done)->
        #console.log item
        withdrawFunction()
        .then (result)->
          i.currentTerm.call(from: accounts[0])
        .then (result)->
          #console.log result
          done()
        .catch (err)->
          #console.log err
          done(err)
    .then (result)->
      assert(false, "shouldnt be here")
    .catch (error)->
      if error.toString().indexOf("invalid op") > -1
        #console.log("We were expecting a Solidity throw (aka an invalid op), we got one. Test succeeded.")
        assert.equal error.toString().indexOf("invalid op") > -1, true, 'didnt find invalid op throw'
      else
        assert(false, error.toString())
  done()

In the above case we call withdraw 13 times and expect it to fail on the 13th try.
 
We now have a great way to test the passage of time when testing our solidity contracts.  Since Catallax will likely do monthly this avenue of calculation may work.  We could manipulate our Decay Token to use timestamps instead of block numbers.  On the other hand, using block numbers allows us more control if we need to do some emergency decay as a monetary lever.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality(Purchasing a hard or kindle copy helps support this project.

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

Privacy, Accounts, and Transparency

This is the third part in a five part series of posts that lay out the basics of what we are trying to build with Catallax.  The series will follow the following schedule and I’ll update the list with links as the articles go live:

  1. Demurrage, Catch Up, and Pref Dividends
  2. Passthroughs, Legacy, and Folding the Blockchain
  3. Privacy, Accounts, and Transparency  (today)
  4. Selective Citizenship and Citizen Override
  5. Loans and a new kind of Capitalist

 Privacy is a very important issue.  It is also an issue that is very hard to predict.  It is possible that in the future we will have a very hard time maintaining privacy for anyone when computers and data are involved.  This has caused me to think about a few questions in regards to Catallax and how to move forward with privacy in mind.

 
How can we be long privacy in the places we want it?
How can we be short privacy in the places we don’t want it?
How can we reduce the need for privacy by increasing the value of transparency?
 
Let’s first talk about the elephant in the room.  Catallax in its rawest form lacks any kind of privacy.  It tracks who you spend money with, who spends money with you, and publishes that info on a public blockchain. Yikes.  This is a privacy nightmare.
 
So let’s unpack this and see how it isn’t that bad.
 
The first step we take is by making transparency really valuable.  The scenarios given in part 1 show how by making your transactions open you can reap varying levels of financial reward for the sacrifice in privacy.
 
A scenario that I regularly compare this to is the ownership of stock.  Chances are that if you own stocks you don’t own them anonymously. You want your name(or at least your account number) next to those certificates so that they well send you dividends when they pay out.
 
Catallax’s first step in addressing these issues is by making it more valuable give up some privacy than to keep it.
 
With that in mind, there are still situations where you do NOT want to forfeit your privacy.  For example, there may be a medicine you need for an undisclosed medical condition and you don’t want the public to know you are buying it.  For those situations, we propose a system of privacy pools.  The privacy pools will allow you to send cash into a vague account and have it anonymously end up in the account you want it to go to.  This is a technical challenge but I think is achievable by using zkSnarks. This is a core feature coming to a future version of ethereum.  These pools will still operate in a catallaxy way where cash will flow from receivers into the pools and out to payers via a pass through, but the payments will be less associated with the payer’s ability to spend money wisely.
 
We further address privacy by splitting accounts into contexts, each of which has a specific privacy profile:
 
Citizen Accounts:  real people can send and receive private payment
 
Legal Entity Accounts: businesses with limited liability must sacrifice some privacy for the right to limited liability.  They can receive private payments, but cannot send them.
 
Government and Institutional Accounts:  These accounts can collect taxation from the system and as a consequence must be completely transparent.  They cannot make or receive private payments.
 
These accounts and their subtypes are discussed more in the Form Language section of my book Immortality (buying a physical or kindle copy helps support this project).
 
This privacy signature is currently a proposal and I’m very interested in speaking with experts on the gaps I’ve left.  I think that the current proposal address privacy where it is important and adds significant anti-corruption infrastructure where it is needed for a free and open society to develop.

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality (Purchase of a physical or kindle copy helps support this project).

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.

Next: Selective Citizenship and Citizen Override
 

Happy Birthday, Catallax!

Note: The Dev Log will return next week and we’ll be looking at testing time in truffle + testrpc. I’m on vacation this week. Enjoy this brief history post in its stead.

This week is the three year anniversary of the concept behind Catallax.  Every year my family and I take a retreat into the east Texas woods to relax and rejuvenate. This place is great and there is a ton of child care so that parents can reconnect and have some time to step away from the children.
 
Three years ago I had a really great confluence of influencers. We had just found out that our third child was on the way and I was deep in the weeds with Piketty, Fukuyama, and wrestling them through the lenses of Alexander.
 
I had been thinking for a long time about how money fell short of all that I thought it could be. I distinctly remember drawing a dollar with arrows over it going both directions in the early 2000s. I was introduced to Kevin Phillips’ History of the American Rich and I banged my head against the problem a good bit, but never came up with much.
 
In 2009 I discovered Gesell and his natural money concept. That discovery really clicked a few things into place and there was something about the 0% interest assumptions that I knew was going to be important. I wrote a piece of fan fiction about one of the big cell phone makers launching a natural money to fix the economic crisis. It never really went anywhere.
 
It wasn't until June of 2014 that Bitcoin and the Blockchain came into the picture and clicked all the pieces into place.
 
Lessig's mayday PAC was flailing and the prospect of never being able to fix money in politics led to a deeper question of how can we fix money.  Piketty showing the data of capital concentration magnified many of the principles that I'd been ruminating on since I'd read Phillips a decade and a half earlier. On a morning walk, a number of ideas were elevated into RAM out of the cold storage of my brain. Bitcoin's idea of a public ledger of all transactions was a key piece in the puzzle. Before seeing and understanding that this was a tech that could actually live in the world Catallax would not have been possible.
 
It wasn't until later that year that I got into the meat of the Bitcoin tech and realized that all the pieces I needed were already there, but the summer of 2014 caused me to start writing the pattern language found in my book Immortality. 
 
I tried to soft launch in 2015 with a talk at the Texas Bitcoin Conference and flying to NYC to demo at the Singularity Institute's Exponential Finance.  The feedback was ok, but not what I wanted. In that same season, a colleague brought a business opportunity to me that was too good to pass up. We bought a company in an unrelated field and we've been fighting the good fight trying to apply new technologies to the world of organ donation for the last two years.  It has been a fun ride and we are starting to see enough light at the end of the tunnel that I can start to hand some of my responsibilities over to new employees. 
 
I haven't been completely idle. As I've been crisscrossing the country installing software at organ centers I've been piecing together the book Immortality that lays out why I think we need this new kind of money. "Why?" Was the biggest question I received when I had tried to launch previously.  Somewhere around early 2016 Robert Pirsig helped me answer that question in his amazing book Lila.  I hope that if you have the “Why?” question and that the intersection of moral philosophy and economics piques your interest that will check out Immortality and that it will answers that question.
 
During the last two years, ethereum has really matured and now seems to be the platform that I needed all along. Now we are here in the summer of 2017 and people are paying me to write solidity contracts. The pieces of the puzzle for how Catallax can be a real thing now are starting to fall in place and the last few hurdles of regulatory compliance are being arranged.  Please follow us on twitter, medium, rss, Facebook, or Reddit and come along for the ride.
 
Let's fix money.
 

Happy Birthday, Catallax!

If this is interesting to you and you'd like to see where we are going with Catallax, please pick up my book Immortality.

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0

If you would like more code articles like this please consider becoming a patron on patreon.