hypercatallaxy

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
 

A week with Ethereum

The past week has been a fun one as I’ve started trying to actually write some ethereum code and figure out if the eco-system is ready for me to try to build on top of yet.  My very high-level priorities are currently:

  1. Figure out if I can build a decaying currency as prescribed by hypercatallaxy on ethereum.

  2. Figure out how to integrate this system with existing payment networks in a way that gives the Catallax card an unfair advantage over other kinds of payment networks.

  3. Figure out how to build the governance model as described in my book “Immortality” on the ethereum blockchain.

  4. Figure out how to transition from a “benevolent dictator” model to the created governance model in a trustless way that makes sense for system stability.

This week was all about #1.  I don’t have any code to post yet, but I did make some significant discoveries that I think will be productive:

Ethereum transactions are expensive.  

They are not as expensive as bitcoin transactions, but still expensive enough that building out all the infrastructure in blockchain storage is just not really an option at this point.  Writing a piece of data (address-> unit) looks like it can cost about $0.008. This is not that bad unless you are catching up and trying to send a couple dollars of demurrage to the 10,000 accounts that in your pref table.  Then all of a sudden you are updating 10,000 address -> uint pairs and this is going to cost you $80 to distribute $2 in decay.  This obviously won’t work right now.  Moore’s law says this probably won’t work for 12 years if gas costs track computing power.

Storing Data Off Chain

The solution looks like it may be storing data off chain.  Your pref map and even your balance may end up needing to be off chain in some trustless data structure.  TrueBit looks like the leader in the clubhouse here.  Because of the way hypercatallaxy works we should be able to structure code in such a way that current balances are deterministic given a set of transaction operators.  TrueBit lets any number of solvers run our code for us and update the blockchain.  If they try to lie, verifiers can force them to prove their calculations and take a large reward if they catch a cheater.  There are a bunch of things to work through here, but my current thoughts are that the Ethereum based part of the problem may end up just being a linked list of structs that track:

transactionType: uint (these will be coded in solidity based code so EVMs can run the transactions)

transactionHash: byte32 (this is a signature proving that the msg.sender created the transaction)

transactionLocation: byte32 (this is an ipfs hash pointing to a location where the json of the transaction detail can be publicly retrieved and verified with the has

I’ve just started thinking through this so there may be some more variable needed, but this kind of structure should get recording transaction down to a few cents and that is way more manageable.

If you have any insight or sample projects that have done this kind of structure where most of the data is kept off chain, let me know where to look.  Source code is a super bonus.

Next Steps:

I think I’m going to be learning a lot about Merkle Trees and roots and how those can be recorded once and then used as verification.


I’m also meeting with a card processing company that may have some insight on how I can set up goal #2. If nothing else I’ll have some expectation of the costs involved and be able to do some of the math necessary to figure out if the 0 transaction fee is going to be feasible or not.

Donations always accepted at:

BTC: 1AAfkhg1NEQwGmwW36dwDZjSAvNLtKECas

ETH and Tokens: 0x148311c647ec8a584d896c04f6492b5d9cb3a9b0