I’m trying to model the world of centralized, decentralized, and an in-between place that I think (among other solutions), Git as a store and GitHub (as a platform, but imperfectly) fit as a solution.

I have a diagram of that model, that shows Bitcoin and a property ownership database are on a centralized/decentralized spectrum:

Bitcoin

Full decentralized. You don’t need anyone’s permission to buy or sell Bitcoin (even though your nation-state may try to legislate it). You also don’t need anyone’s permission to mount something like an exchange, though you’ll need to gain the trust of a community to get them to use it. There’s nothing physical at all for Bitcoin - it’s all electronic and tradeable at a variable exchange rate for regular currencies. It’s also losable, and stealable. Also, law enforcement may not show too much interest in helping you recover small amounts of Bitcoin that have been stolen from you unless that theft involved threats or violence.

Land Registry

(residential property ownership)

Thee are an average of 2,100 title changes per working day in the US nationally. It is run at a state level with a feed to federal government agencies (probably). I wrote before on property ownership databases in Step Aside Blockchains, Hashgraphs Are Giving Plain Merkle Trees A Turbo Boost.

I show four decentralized vs centralized alternatives for this (the house icons with 1-4 in them, above).

1. Database-backed - as it is today.

• There’s one per US state at least.
• States can update the records correctly based on sales, and a workflow that involved multiple legal entities.
• States can set fees for title changes, and change those up or down as they see fit.
• Storage for the title ownership and workflow/transactions is most likely a relational schema.
• States can seize property using the legal system. In non rule-of-law jurisdictions, a seizure can happen silently.
• Seizure situations can be addressed even after the event towards “recovery”
• Similarly, the system is subject to fraud, with there being a high interest from law enforcement it prosecution and a return of assets.
• People can inquire about records through a number of means, which may have fees associated for retrieval.

2. Partially decentralized.

As #1, but transactions towards title changes are now on a distributed ledger (and out of the relational schema), with participating parties appending steps in a workflow towards a conclusion of the title change themselves. States should charge lower fees for title changes, as less of the workflow-driven changes are done by their offices.

This is the closest that residential property ownership can get in respect of blockchain/DLT nirvana.

What is unique about this proposition is that people inquiring on a title for a property could ask the alleged owner for a right to see the record decrypted. The owner because of their private key and knowledge of the requester’s public key could satisfy that directly. The requester could be a Realtor, and the situation could be the alleged owner putting the house on the market.

What if the owner loses their private key? No matter, the state has a way of making a new one, but the owner is going to have to turn up at a state office, pay a fee, show some ID, and wait for bureaucracy to do its business. Meaning, in the end, the centralized authority can update the distributed ledger (based on what they themselves have stored in a classic database), and controls to a great degree what other updates can happen to the system.

Importantly, in theft situations (someone too your private key and sold your house while you were on vacation), the state and law enforcement are going to participate to get your house back. The physical asset (the house) the non-owners would be removed fairly quickly and the house returned to you. The ledger gets corrected too, so say it is yours again. This might be true, even if you wrote your private key on a wall inside your house. See A thief can’t pass good title on stolen goods: If you buy a stolen item, it is not yours, it is still the original owner’s[Hacker News] for more info on stolen goods and ownership. Bitcoin is mentioned, but the law only aids return of assets when it can.

3. Centralized with witnesses

As the basic #1 situation, but with a deliberate feed to witnessing entities. The feed could be structured (REST etc) or informal (like automated email). The feed could be restricted to pre-agreed collaborators, or open for all to register for. The feed could be free or might come with subscription costs. The feed is potentially corruptible, sadly.

It seems comical that I may suggest email as part of a solution, but there is historical precedent. Gold Bullion trading about 15 years ago was performed via email in an ‘Over The Counter’ (OTC) way. For example: “I sell you 330 ounces of gold at $829.4 an ounce, right” .. “yup confirm, $829.4/oz an ounce for 330oz is what I’m buying”. Of course, if you’d moved a decimal position inadvertently you might be in a position to want to falsify your email record so as to not lose your shirt. The system used the CC feature of email and a single Swiss company that agreed to be a witness to these conversations as a way of making sure the he-said-she-said situation did not happen. I wonder to what extent that possibility removed the possibility of the attempt to rewrite the record.

Back to property sales - it is the potential for corruption that’s been removed. Extrajudicial seizures of property can’t happen so easily now. Or at least, the original owner has a mechanism to independently prove that their property was seized.

4. A Git-backed centralized allowing subscribers

Git is a perfect* history retaining Merkle tree, of course.

Like #3, but using Git for ‘subscription’ concept.

Unlike #1, this system could be the canonical database too. It is easy to launch too - a minimal viable product could be launched using GitHub as the entire backend platform and embracing pull-requests as the mechanism to manage change. Realtors could minimally have python scripts. If only Github has custom editors.

The Merkle tree aspect is important as delivers a tamper-proof feature for the system for free. Well, provided the content is plain text and not PDF.

University degree certificates

Students graduate in batches. The entirely of a university’s yearly graduations could be stored in a single text file. Sure, but that would not be that accessible, and fraught with update congestion at a certain time of year. This would be better as one YAML file per graduate and stored Git (on GitHub), assuming all you want to do is have an authoritative account of your academic achievement, and be able to direct prospective employers to it. Maybe you’d like to obscure your name for some level of privacy.

File: 445EE92D2430B3BA0770F9DC16AB31FFBFF61A3FADFC00B49E6F5D581F276D04.yaml located at https://graduates.utexas.edu/1983/05/21/ could contain:

First semester: Fall 1980 	
Last semester: Fall 1987
MASTER OF ARTS (MA)
Major: ASTRONOMY

445EE92D2430B3BA0770F9DC16AB31FFBFF61A3FADFC00B49E6F5D581F276D04 is the string “Neil deGrasse Tyson 1958-10-05 sdflsp” run through SHA256, by the way. The ‘sdflsp’ is just a random string fixed for NDT’s entry at the time it was created. Graduates would have to take a note of their full string and pass the URL with it to prospective employers. The prospective employer would repeat the SHA256 transform to prove it is actually the candidate. Universities would most likely cooperate with legal name changes in the years after graduation. The first version could just be Git on GitHub with no other sophistication. The next level up could be with a modest app that combines a SHA256 decode (but without bookmarkable URLs). UT already has a web-app by the way: utdirect.utexas.edu/registrar/degv.WBX.

I’m not sure why the blockchain versions of this idea exist. They are an order more complex is terms of solutions. There are big names behind them like MIT, and many thousands of lines of code written to deliver them www.blockcerts.org/ is the online site for the technology being build at github.com/blockchain-certificates/.

Reminder: decentralization to the max

• a system, that once started, isn’t stoppable by any centralized entity, and only fails because of unfixable bugs or it simply stops being used
• a system that allows enrollment for people/orgs without permission from any centralized entity
• a system that allows alternate software to be developed for it over time

And with respect to a distributed ledger:

• a ledger that may well allow anonymity for participants, and a bunch of obscuring as to the purpose of the transactions on it
• a ledger where theft is possible and law enforcement may not be able to help you even if you could get them interested (which is not a given)
• a ledger where regulations may not apply (pump and dump; insider trading, etc)

* Git is imperfect, actually

First of all, you need to turn force-push off for the repo/branch. You need to do this to be able to use it long term and have the merkle tree hashes communicable/useful.

Then you need to enforce (or police) a signed commits situation to make sure someone passing themselves off as a Person A is indeed Person A.

Timestamps in Git are blurry thing. By looking at three commits #1, #2 and #3 and their hashes written up in a neat Merkle-tree, I will be able to say with certainty that #1 came before #2 which came before #3. I might not be able to say when they happened. If commit #2 references “JDK shot and killed in Dallas”, I can be sure that it happened after 12:30pm on November 22, 1963. I can’t be sure that its predecessor happened much before that moment as its declared timestamp says. With Merkle trees though, I can be sure that there is only one shot about blurring the temporal record, as witnesses to the repo (those who clone and infrequently ‘pull’) are able to call ‘foul’ when the changed Merkle tree says tampering has happened. And because Git’s retained history, witnesses might even be able to add a lot of detail as to what precisely happened that was bad.

Lastly, you need to be sure that you’re not encountering one of a couple of Git upper limits:

1. Git repo history can only get so big. 1GB according to some Git dev-team thinking ten years ago, even though there are field reports of repos going as big as 40GB today.

2. Git can only accept changes at a certain rate - like 1 every 15 seconds. This is because of a bottleneck around “push pull” when multiple participants are trying to do a ‘push’ at the same time.

Subversion and Perforce can go much higher for those two upper limits, but neither is a Merkle tree which has plenty of verification benefits, whereas Git has that out of the box (yay).

And Git could still be centralized.

Continuing the ‘imperfection’ thought a little: One repo could well be ‘king’. Say Gold bullion trades are captured with a Git repo that is cloneable by trading participants and orgs/countries wanting to keep tabs on it all. The exchange has a moment before the commits are written to the ledger/repo and pushed to change them. Sure, either of the counter-parties could call foul and it’d be caught quite quickly, but there is still a place for manipulation - it is just that it is a one-shot, which is less bad I guess.