[c7b]

Agreed that you don't need total ordering and hence consensus for pure asset transfers. But if you want to make any changes at all, like updating the list of nodes, you do. So in practice, you do need it. Every other proposal will fall short in a critical and avoidable way. Amending your git proposal with the necessary parts will turn it into a blockchain.

[margalabargala]

Disagree. We're talking real estate here. The time between transactions is months to years, not seconds to minutes. A git history will work fine. If there are racing transactions against the same piece of real estate, that's probably fraud, not something that should be automatically resolved.

[c7b]

git as-is is completely unfit for purpose and a huge security risk for this use case, because it uses MD5, which is no longer collision-resistant.

If your proposal is 'something like git, with a few modifications to make it suitable for this use case', then that's exactly what I'm proposing. What you will need, once you've considered all requirements to the best extent feasible, will be a blockchain. Eg you do need the ability to make protocol updates, no matter the time scale of transactions.

[margalabargala]

> git as-is is completely unfit for purpose and a huge security risk for this use case, because it uses MD5, which is no longer collision-resistant.

Firstly, git does not use MD5. It uses SHA1.

Secondly, since 2017 git has shipped with an implementation of SHA1 (sha1dc) that detects the collision attack you describe, which for this use case renders it a non-issue.

Thirdly, git supports `git init --object-format=sha256` which removes the whole issue for anyone who cares to do so.

I think git as-is solves the problem nicely. The only additional value blockchain provides is the ability for someone to point at it and say "look! A use for blockchain exists!" which isn't worth the downsides it'll bring.