Part of an undertaking this big is securing funding and political/social support. Being a bit "trendy" helps with those.

This is the most plausible rationale for doing it with blockchains (see also: many other blockchains)

The whole system appears to rely on a trusted group certifying the [probable] authenticity of an individual's records and Rohingya refugee status, in which case you might as well let them host it on a well-backed up regular database...

It's possible, even easy, to insert fake attestations that biometric B corresponds to identity I. But an append-only log has the advantage over other databases that a simple older-record-wins heuristic is likely to prefer genuine identity records.

A regular database has no way to make it infeasible to insert fake old records. Sure, you can publish checkpoints. But that doesn't work so well when you're up against a government that wants to erase your entire ethnicity.

Isn't the sufficiently determined government with the ability to compromise an organization's computers almost as much of a threat to carry out 51% attacks on its private blockchain as to successfully target distributed copies of database checkpoints?

(In practice, I think the Myanmar government's strategy would simply be to disregard the database rather than to attack it anyway, on the basis the local prejudice against the Rohingya isn't based around their numbers or individual identities but the claim that they are actually Bangladeshi illegal immigrants lying about Myanmar ancestry and land)

Yes, it is a threat. That's why I'm not sure why they're not just using Ethereum. Well, I think I know why -- "let's use Ethereum!" isn't a fundable startup idea. But it's too bad, because I have a feeling Myanmar doesn't have even enough compute power to double-spend a single CryptoKitty.

And yeah, a government would certainly try to ignore facts it didn't like.

Who signs the identity certificates? And who are "they" who maintain the repository? And who decides which commits are legitimate?

Git is a distributed database only if every copy eventually syncs to tip, and only if everyone can agree what "tip" is. Each of those conditions is hard to meet if the problem statement assumes that malicious actors have write access to the repo and can arbitrarily assert which fork is master.

You have exactly the same problem with "blockchain". Whatever solution you propose for this new blockchain can equally be applied to write a git merge driver for this new git repository.

If your solution is "proof of work", then you have the additional problem that there is a large group of people with significant computational power who can take over your new blockchain for the appropriate fee.

When someone proposes a solution that involves throwing money at a problem, you should be jumping for joy, not asking what happens when someone then throws money at the problem. Such a solution is the economic equivalent of proving that an NP problem is actually a P problem.

Blockchain as implemented in Bitcoin takes a thorny sociopolitical problem (how to store monetary value) and turns it into an economic problem (how to calculate SHA-256 moving the smallest number of electrons).

As applied to the Rohingya situation, it switches out the political power of whoever is currently dominant and replaces it with monetary power (proof of work). It commoditizes political power. I don't know about you, but I'd take an economic problem of being the group with the most money (== computing power) over an intricate, shifting political problem any day of the week.

> As applied to the Rohingya situation, it switches out the political power of whoever is currently dominant and replaces it with monetary power (proof of work).

My assertion is that using a blockchain, as opposed to existing proven technologies, adds nothing of value.

You keep restating the opposite claim, but you have yet to explain how a blockchain adds any value over not using one.

You can facilitate git rewrites, but it's not computationally expensive (or expensive in any sense) to do that. So it's easy to erase history and start over. A proof-of-work approach (or proof-of-whatever, as long as the incentives are aligned) imposes a cost to rewriting history. And if you believe that there's some relationship between economic power and truth/goodness (debatable, but it's a tenet of most of Western societies), then creating a cost, even a wasteful one, is a good thing.

If existing proven technologies have a way of making rewrites hard (not reputationally hard but economically hard), then I'd appreciate the education. I'm not aware of such a power.

> A proof-of-work approach (or proof-of-whatever, as long as the incentives are aligned) imposes a cost to rewriting history.

That's not exclusive to blockchains. Blockchains impose a cost to rewriting history because peers follow a set of rules that make it so. You can impose a similar set of rules in any alternative solution, blockchain or not. Simply do not accept non-fast-forward branch updates. Validate all proposed updates against your standard rules, and if validated, use your custom merge driver to implement any required merging rules.

I have yet to see an description of a threat model here which explains how such a blockchain's decentralized consensus system solves this particular real world problem.

OK, now I think I see your point.

Either you're agreeing that you could stick proof of work into a more conventional database (not sure if that's what you mean by "You can impose a similar set of rules in any alternative solution, blockchain or not"), or you don't think the self-validating nature of a proof-of-work blockchain is interesting.

The alternative solution you describe in your first paragraph still has the flaw that a nation-state could delete all known copies of the real national database, publish a new one, and say "Here's the national git log. Oceania has always been at war with Eastasia." Someone finds a backup copy of the original and publishes it. Now, determining which one is right is basically a question of whoever shouts louder. There's nothing inherently better or worse about the fake log compared to the real one, since both follow the rules; it's a question of who you believe.

In a blockchain solution, on the other hand, the nation-state would have to say "here's the real blockchain," but either the amount of work required to produce the fake one was more than the work required to produce the real one (in which case congratulations, they win), or else it's self-disproving. Nobody has to argue whether the real one's real, because the real one by definition has the most work put into it. Unless I'm misunderstanding you, your example alternative solution doesn't have that important feature.

Myanmar obliterated all traces of the Rohingya, razing their villages, rebuilding entirely different structures on those locations, and then claiming that the Rohingya burned down their own homes and voluntarily left the country (listen to https://www.nytimes.com/2018/08/14/podcasts/the-daily/myanma... for more). It's completely within the threat model of this situation that a nation-state might want to rewrite its identity database and deny that it ever happened.

Sorry if I'm still somehow talking past you.

> Now, determining which one is right is basically a question of whoever shouts louder... It's completely within the threat model of this situation that a nation-state might want to rewrite its identity database and deny that it ever happened.

This was a solved problem before Bitcoin: https://en.wikipedia.org/wiki/Trusted_timestamping

Now that Bitcoin exists, you don't need to trust a third party for trusted timestamping any more; you can insert hashes into an existing (stronger) blockchain instead.

I accept this is technically "blockchain" in that case, but I wouldn't really call it "blockchain technology" or "turning to blockchain" and there's no need to reinvent a new blockchain with all the risks that entail.

Take my git repository and add a rule that to be considered valid by a client an authority must have inserted the commit hash (or a child commit hash) into the Bitcoin blockchain. If an alternate branch appears, the earliest appearance wins. You get the property you're looking for, but you don't need to invent a whole new system to do it. Bitcoin (or any blockchain) isn't required; any trusted timestamp service will do instead. If you don't want to use a third party, then sure, use Bitcoin, but no need to invent anything new.

I argue that this is far better than "turning to blockchain". All the components are well understood. There is no risk in this model.

>When someone proposes a solution that involves throwing money at a problem, you should be jumping for joy

I'm sure that people who are starving to death are grateful to know that a bunch of rich techbros are dumping money into an exercise in patting themselves on the back rather than spending it on anything actually useful.

Your last paragraph is just hilariously naive.