So that 50% attack results in someone taking all the land? No thanks.
It is a poor idea to use blockchain for government registries. If you want transparency, simply publish signed daily updates and that's enough. Just use simple DB with backups, and optionally, a printer printing changes on a paper.
Merkel tree audit log of the data, the poor man's Blockchain, works fine and good enough. Now you have a db and you can claim to use a blockchain for pr reasons.
It doesn't matter, it's a dumb idea anyway because there is a central authority managing the land registry and there is no need for anyone else to be involved.
Also, SQL database is much more convenient to use, it has query language and indices unlike a blockchain.
You can put an index on your blockchain DB, what are you talking? Every node can manage it as it pleases (within the limits of the consensus algorithm).
Yes, if you have a centralized model you don't need it. Just saying that this incident is the exact risk a blockchain is meant to mitigate through redundancy. You can say you don't care about this risk, but it doesn't change the truth of the statement.
Yeah, the overwhelming majority of the benefit of blockchain here is just gotten by making the data public and signed.
Now you may argue "that is a blockchain, not every blockchain is associated with a shitcoin" but to be frank that ship has sailed, if you wanted to defend that you'd have had to do a lot more work over the past decade.
Which could easily be solved by just making data publicly accessible. Actually I see no reason why you shouldn't be able to download land registry say every month. Same actually goes for any stock ownership in companies over certain threshold.
That is what I'm saying. And you may be right, but the security guarantees are math and math is patient. If people decide to ignore it today, it'll still be true any time they decide to take another look.
>Now you may argue "that is a blockchain, not every blockchain is associated with a shitcoin" but to be frank that ship has sailed, if you wanted to defend that you'd have had to do a lot more work over the past decade.
What do you mean by "More Work" here?
There were plenty of tests and pilots of systems like that described. Dual goals of reducing the cost of transferring property and publicly attesting all current ownership. Real lawyers and real lawmakers developed proposals to integrate these sort of services with current public land registries.
The issue as far as I see it isnt the "work" its the "antiwork". If you want to learn about land sale nft pilots you literally have to put -metaverse into the google search to weed out the metaverse nonsense. Theres just too much noise around blockchain for even the best signal to penetrate. The stupid monkey nft guys really fucked the whole space. Probably take another decade to dig out all the toxic waste from blockchains reputation.
> It is a poor idea to use blockchain for government registries. If you want transparency, simply publish signed daily updates and that's enough.
A blockchain is essentially that, just with the daily update that's being signed also including the signature and hash of the previous day.
Blockchain as a technology is actually useful here. It does not mean automatically that blocks have to be mined by third parties, although pseudocurrencies have gone that route for decentralization reasons.
Blockchain is unnecessary complicated, for example, it has mining, rewards for those who add new records, even VM and scripts and all of these are not needed for a government registry. I do not need scripts within a land registry.
> Blockchain is unnecessary complicated, for example, it has mining
depends on configuration, you can make any traditional web service replicated (replication is one and only thing that protects data in decentralized ledger, same as DNA is stored in every cell) using something like CometBFT on top. Mining/PoS or VM - all optional.
Clearly, you would scope the features and choose implementation options so that it makes sense for the use case. Mining (ie PoW and/or Nakamoto consensus) is clearly inferior to any deterministic consensus here. A cryptocurrency isn't necessary and would be a distraction. But at least some limited programmability could make sense (eg for escrow).
A blockchain solves the problem of consensus under Byzantine faults. Payments are an incidental use case, and not even a good one because managing payments including avoiding double spending can be achieved with a weaker primitive than consensus.
No. Blockchain is made for managing transactions between untrusted parties. In case with a land, there is an authority managing the registry, so a standard relational DB (with optional digital signatures) is the bets option. Why someone wants to use a tool, not good for a specific purpose, for that exact purpose?
I would be less comfortable with my land registry tied to a blockchain, as soon as I lose it (who is much more likely to) it's impossible to get my land back.
What's wrong with paper records backup up a digital record and audit trail. This all seems like a solution for a non-problem to me.
A blockchain isn't stopping you from doing any of those things, if anything it's facilitating different backup models by different parties. A paper record is so much more susceptible to various kinds of risks, adversarial and otherwise. I recommend to look past the hype or hate at the technology. A blockchain is the logical extreme of where you end up when you think about how to sync backups, and you recognize that it comes with certain mathematical limitations on how much disruption you can handle.
> A blockchain is the logical extreme of where you end up when you think about how to sync backups
It's not. Blockchains are only eventually consistent among nodes. They're designed for synced backups among adversarial peers.
There's no reason for a government agency to use one internally. There are better ways to sync backups when the people with access to make updates are also authorized to do so.
Internally, you don't need it, agreed. But that is centralization risk exemplified in this incident. Which isn't necessary. Every notary could be a node. It would be a lot more resilient, and it would look a lot like a blockchain (not necessarily with a crypto currency though) if you do it properly.
You can have decentralization without blockchain. A defining feature of blockchain is that each node depends on the precise ordering of prior nodes which is a huge liability if you have network disruptions, etc, in a bureaucracy.
A git repo with cryptographically signed commits solves all the same problems without the headache.
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.
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.
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.
> 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.
You can't do any real money/real estate transactions without canonical order (chain of events). that's why git analogy is not applicable here. You'd need "main" branch to be canonically finalized for each and every participant.
What? Sure you can. All you need is confidence in the current owner. You don't need the whole history. Can you imagine the poor store clerk trying to say "sorry sir I can't accept that $20 bill unless you can name every prior owner in order".
Not sure if you're being deliberately obtuse here but this isn't an issue with the cadence of real estate transactions. Real estate ledgers do not need to support HFT.
If every notary is a node, you need some mechanism to ensure they perform only legitimate transactions and constantly monitor them. It is easier to just have a central authority.
So that 50% attack results in someone taking all the land? No thanks.
It is a poor idea to use blockchain for government registries. If you want transparency, simply publish signed daily updates and that's enough. Just use simple DB with backups, and optionally, a printer printing changes on a paper.
Merkel tree audit log of the data, the poor man's Blockchain, works fine and good enough. Now you have a db and you can claim to use a blockchain for pr reasons.
2/3 attack. Read up on BFT.
It doesn't matter, it's a dumb idea anyway because there is a central authority managing the land registry and there is no need for anyone else to be involved.
Also, SQL database is much more convenient to use, it has query language and indices unlike a blockchain.
You can put an index on your blockchain DB, what are you talking? Every node can manage it as it pleases (within the limits of the consensus algorithm).
Yes, if you have a centralized model you don't need it. Just saying that this incident is the exact risk a blockchain is meant to mitigate through redundancy. You can say you don't care about this risk, but it doesn't change the truth of the statement.
Yeah, the overwhelming majority of the benefit of blockchain here is just gotten by making the data public and signed.
Now you may argue "that is a blockchain, not every blockchain is associated with a shitcoin" but to be frank that ship has sailed, if you wanted to defend that you'd have had to do a lot more work over the past decade.
Which could easily be solved by just making data publicly accessible. Actually I see no reason why you shouldn't be able to download land registry say every month. Same actually goes for any stock ownership in companies over certain threshold.
That is what I'm saying. And you may be right, but the security guarantees are math and math is patient. If people decide to ignore it today, it'll still be true any time they decide to take another look.
>Now you may argue "that is a blockchain, not every blockchain is associated with a shitcoin" but to be frank that ship has sailed, if you wanted to defend that you'd have had to do a lot more work over the past decade.
What do you mean by "More Work" here?
There were plenty of tests and pilots of systems like that described. Dual goals of reducing the cost of transferring property and publicly attesting all current ownership. Real lawyers and real lawmakers developed proposals to integrate these sort of services with current public land registries.
The issue as far as I see it isnt the "work" its the "antiwork". If you want to learn about land sale nft pilots you literally have to put -metaverse into the google search to weed out the metaverse nonsense. Theres just too much noise around blockchain for even the best signal to penetrate. The stupid monkey nft guys really fucked the whole space. Probably take another decade to dig out all the toxic waste from blockchains reputation.
> It is a poor idea to use blockchain for government registries. If you want transparency, simply publish signed daily updates and that's enough.
A blockchain is essentially that, just with the daily update that's being signed also including the signature and hash of the previous day.
Blockchain as a technology is actually useful here. It does not mean automatically that blocks have to be mined by third parties, although pseudocurrencies have gone that route for decentralization reasons.
Blockchain is unnecessary complicated, for example, it has mining, rewards for those who add new records, even VM and scripts and all of these are not needed for a government registry. I do not need scripts within a land registry.
> Blockchain is unnecessary complicated, for example, it has mining
depends on configuration, you can make any traditional web service replicated (replication is one and only thing that protects data in decentralized ledger, same as DNA is stored in every cell) using something like CometBFT on top. Mining/PoS or VM - all optional.
Clearly, you would scope the features and choose implementation options so that it makes sense for the use case. Mining (ie PoW and/or Nakamoto consensus) is clearly inferior to any deterministic consensus here. A cryptocurrency isn't necessary and would be a distraction. But at least some limited programmability could make sense (eg for escrow).
If they deleted the blockchain db from the nodes, this is still lost.
Blockchain doesn't have anything esp. to do with data loss. It solves exactly one problem which is distributed double spending in accounting ledgers.
A blockchain solves the problem of consensus under Byzantine faults. Payments are an incidental use case, and not even a good one because managing payments including avoiding double spending can be achieved with a weaker primitive than consensus.
[dead]
I suppose the idea could be that you have several different institutions holding the same data, which they know is valid because of the Blockchain.
No. Blockchain is made for managing transactions between untrusted parties. In case with a land, there is an authority managing the registry, so a standard relational DB (with optional digital signatures) is the bets option. Why someone wants to use a tool, not good for a specific purpose, for that exact purpose?
"X is made for Y" is inside-the-box thinking
I would be less comfortable with my land registry tied to a blockchain, as soon as I lose it (who is much more likely to) it's impossible to get my land back.
What's wrong with paper records backup up a digital record and audit trail. This all seems like a solution for a non-problem to me.
A blockchain isn't stopping you from doing any of those things, if anything it's facilitating different backup models by different parties. A paper record is so much more susceptible to various kinds of risks, adversarial and otherwise. I recommend to look past the hype or hate at the technology. A blockchain is the logical extreme of where you end up when you think about how to sync backups, and you recognize that it comes with certain mathematical limitations on how much disruption you can handle.
> A blockchain is the logical extreme of where you end up when you think about how to sync backups
It's not. Blockchains are only eventually consistent among nodes. They're designed for synced backups among adversarial peers.
There's no reason for a government agency to use one internally. There are better ways to sync backups when the people with access to make updates are also authorized to do so.
Internally, you don't need it, agreed. But that is centralization risk exemplified in this incident. Which isn't necessary. Every notary could be a node. It would be a lot more resilient, and it would look a lot like a blockchain (not necessarily with a crypto currency though) if you do it properly.
You can have decentralization without blockchain. A defining feature of blockchain is that each node depends on the precise ordering of prior nodes which is a huge liability if you have network disruptions, etc, in a bureaucracy.
A git repo with cryptographically signed commits solves all the same problems without the headache.
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.
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.
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.
> 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.
You can't do any real money/real estate transactions without canonical order (chain of events). that's why git analogy is not applicable here. You'd need "main" branch to be canonically finalized for each and every participant.
What? Sure you can. All you need is confidence in the current owner. You don't need the whole history. Can you imagine the poor store clerk trying to say "sorry sir I can't accept that $20 bill unless you can name every prior owner in order".
Not sure if you're being deliberately obtuse here but this isn't an issue with the cadence of real estate transactions. Real estate ledgers do not need to support HFT.
If every notary is a node, you need some mechanism to ensure they perform only legitimate transactions and constantly monitor them. It is easier to just have a central authority.
You need that anyway. It's not technology that's stopping notaries from falsifying transactions in the current system.