Decentralized, Centralized, or Somewhere In-Between?

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

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

Bitcoin

Bitcoin is fully decentralized. You don’t need anyone’s permission to buy or sell Bitcoin — even though your nation-state may be trying 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. 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

Also known as the residential property ownership, the land registry holds 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. To learn more, I wrote before on property ownership databases in Step Aside Blockchains, Hashgraphs Are Giving Plain Merkle Trees A Turbo Boost.

I show four decentralized versus 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 an event towards “recovery.”
• Similarly, the system is subject to fraud, with there being a high interest from law enforcement in 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

In contrast to the previous section, 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 to 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 their 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 the 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 of what other updates can happen to the system.

Importantly, in theft situations (someone took 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. As far as the physical asset (the house), the non-owners would be removed fairly quickly, and the house would be returned to you. The ledger gets corrected too. 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

Centralized with witnesses are similar to the first section on being database-backed, but there is 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. The feed could be free or might come with subscription costs. Sadly, the feed is potentially corruptible.

It seems comical that I may suggest email as part of a solution, but there is historical precedent. About 15 years ago, Gold Bullion trading 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?” You, then, 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 that you do 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

Like section three, this section is similar, but we will be using Git for the "subscription" concept.

Unlike section one, this system could be the canonical database, too. It is easy to launch — a minimal viable product could be launched using GitHub as the entire backend platform and embracing pull-requests as a mechanism to manage change. Realtors could minimally have Python scripts — if only GitHub had custom editors.

The Merkle tree aspect is important because it delivers a tamper-proof feature to the system for free. However, this is provided that the content is in plain text and not a PDF.

University Degrees Certificates

Students graduate in batches. The entirety of a university’s yearly graduations could be stored in a single text file. But, that would not be very 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. 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 — utdirect.utexas.edu/registrar/degv.WBX.

I’m not sure why the blockchain versions of this idea exist. They are in an order of more complex terms of solutions. There are big names behind them, like MIT, and 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 will either fail because of unfixable bugs or it will simply stop being used
• A system that allows enrollment for people/organizations 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 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 — Seriously

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 and 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 a 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 “JFK shot and killed in Dallas,” I can be sure that it happened after 12:30 pm 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, however, 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 of 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. 1 GB, according to some Git dev-team thinking ten years ago, even though there are field reports of repos, can go as big as 40 GB today.
2. Git can only accept changes at a certain rate — like one 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 about 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 organizations/countries want to keep tabs on it all. The exchange has a moment before their commitments are written on 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 not as bad — I guess.