3 ms·

You say land use, but your explanation of the need is economic -- that use case is already conceded. It's bad on other grounds. You haven't explained why a lan

You say land use, but your explanation of the need is economic -- that use case is already conceded. It's bad on other grounds. You haven't explained why a land registry is appropriately modelled by a peer-2-peer adversarial database system. There is an authority here: the state. Land is /registered/ with the state. If there are multiple parties with a claim to land, that dispute requires a non-technical consensus model called 'the law' and its resolution is not final. The state retains the privilege, as it must, to revise its decisions. Trying to replace courts with blockchains is a dumb idea, so silly that its proposal immediately signals a profound ignorance of the problem domain. Which is: People.

mike_hearn 4y ago
You're mis-understanding the use case. It's been some years but my recollection of the explanation is something like this. The process of buying/selling houses and land involves many organizations. There is the land registry, the bank, lawyers, conveyancers and possibly others I've forgotten about. To actually complete a sale requires coordination of all of these. Today this is done with lots of human-readable documents bouncing around, maybe in digital form if you're lucky, wet ink signatures, lots of people who are just sort of trusted because they're pillars of society and so on. There's lots that can go wrong even in the absence of a dispute over who actually owns the land currently, it's very slow and it's very hard to digitize. Land registry exposing some documented HTTP endpoints doesn't fix anything because it doesn't solve any of the coordination or security or privacy problems.
- mjburgess 4y ago
  Yes, but for the same reason blockchain doesn't Those are problems coordinating people --- not nodes holding duplicate and adversarial copies of datasets The whole blockchain sales pitch is lie or fallacy of ambiguity. Ie., the 'consensus' of a blockchain isn't social and indeed makes social consensus much harder since it aims for immutability and so on
  - mike_hearn 4y ago
    The consensus is largely social, because for a transaction to commit it must be (digitally) signed by the correct counterparties, and people holding duplicated and adversarial copies is a real problem that does cause disruption to business on a daily basis. If two organizations have two documents that claim to be the same thing but differ, how do you decide who wins? Ideally you never get into that situation but it can easily happen in many ways. Still, I'm not trying to sell this stuff to you. If you don't believe these problems or the use cases exist, fine; the world is full of people who deal with them and would indeed like solutions.
    - mjburgess 4y ago
      If you think carefully about how consensus between people is resolved, you'll realise an immutable append-only ledger makes that process harder, not easier. Digital signatures can be added to any piece of data: add a column to a database. It's a catastrophe to make a private key a requirement of adding to a ledger, since in practice, people lose/steal/etc. them.
      - mike_hearn 4y ago
        Yes, you can add digital signatures to any kind of data. Basic REST doesn't do this however, so already we're beyond what it does. Now think it through some more: with what certificate is that signature associated? You need some sort of PKI that's built to a level that can replace wet ink signatures in all business transactions. What bytes are signed? You need some agreement on serialization because you can't actually sign a database column unless it's just a byte array. Now how do you get that signature to people? It has to stay associated with the data as it moves around, which it won't do it if it's just sitting in a database column, so you need some protocol to ensure it gets to the right place at the right time. But transactions are ultimately performed between people, or legal identities, not IP addresses, so you need a way to map those. Domain names aren't it because they don't represent e.g. sub-departments, subsidiaries, individual employees, so you need a naming service that reflects organizational structures in a less ad-hoc way. Finally, what happens if two users click "Submit" near simultaneously on two conflicting edits? You need some way to resolve the conflict, but recall, these are peer institutions. There isn't one that's the authority and one that's not. That's the whole problem we're trying to solve. So you need some sort of consensus algorithm that can resolve transactions that conflict, which reflects the peer to peer nature of the underlying business relationships. By the time you've built all of that + lots more, you've got an enterprise blockchain platform. Does it actually contain blocks? Well, the one I designed didn't actually, and sometimes we didn't even call it a blockchain at all. But that's the terminology the business world settled on for this type of system.

mike_hearn 4y ago

You're mis-understanding the use case. It's been some years but my recollection of the explanation is something like this. The process of buying/selling houses and land involves many organizations. There is the land registry, the bank, lawyers, conveyancers and possibly others I've forgotten about. To actually complete a sale requires coordination of all of these. Today this is done with lots of human-readable documents bouncing around, maybe in digital form if you're lucky, wet ink signatures, lots of people who are just sort of trusted because they're pillars of society and so on. There's lots that can go wrong even in the absence of a dispute over who actually owns the land currently, it's very slow and it's very hard to digitize. Land registry exposing some documented HTTP endpoints doesn't fix anything because it doesn't solve any of the coordination or security or privacy problems.

mjburgess 4y ago
Yes, but for the same reason blockchain doesn't Those are problems coordinating people --- not nodes holding duplicate and adversarial copies of datasets The whole blockchain sales pitch is lie or fallacy of ambiguity. Ie., the 'consensus' of a blockchain isn't social and indeed makes social consensus much harder since it aims for immutability and so on
- mike_hearn 4y ago
  The consensus is largely social, because for a transaction to commit it must be (digitally) signed by the correct counterparties, and people holding duplicated and adversarial copies is a real problem that does cause disruption to business on a daily basis. If two organizations have two documents that claim to be the same thing but differ, how do you decide who wins? Ideally you never get into that situation but it can easily happen in many ways. Still, I'm not trying to sell this stuff to you. If you don't believe these problems or the use cases exist, fine; the world is full of people who deal with them and would indeed like solutions.
  - mjburgess 4y ago
    If you think carefully about how consensus between people is resolved, you'll realise an immutable append-only ledger makes that process harder, not easier. Digital signatures can be added to any piece of data: add a column to a database. It's a catastrophe to make a private key a requirement of adding to a ledger, since in practice, people lose/steal/etc. them.
    - mike_hearn 4y ago
      Yes, you can add digital signatures to any kind of data. Basic REST doesn't do this however, so already we're beyond what it does. Now think it through some more: with what certificate is that signature associated? You need some sort of PKI that's built to a level that can replace wet ink signatures in all business transactions. What bytes are signed? You need some agreement on serialization because you can't actually sign a database column unless it's just a byte array. Now how do you get that signature to people? It has to stay associated with the data as it moves around, which it won't do it if it's just sitting in a database column, so you need some protocol to ensure it gets to the right place at the right time. But transactions are ultimately performed between people, or legal identities, not IP addresses, so you need a way to map those. Domain names aren't it because they don't represent e.g. sub-departments, subsidiaries, individual employees, so you need a naming service that reflects organizational structures in a less ad-hoc way. Finally, what happens if two users click "Submit" near simultaneously on two conflicting edits? You need some way to resolve the conflict, but recall, these are peer institutions. There isn't one that's the authority and one that's not. That's the whole problem we're trying to solve. So you need some sort of consensus algorithm that can resolve transactions that conflict, which reflects the peer to peer nature of the underlying business relationships. By the time you've built all of that + lots more, you've got an enterprise blockchain platform. Does it actually contain blocks? Well, the one I designed didn't actually, and sometimes we didn't even call it a blockchain at all. But that's the terminology the business world settled on for this type of system.