5 ms·

Many financial transactions take place between parties who don't necessarily trust that the other side isn't fudging their numbers in order to get a better deal

by v64 9y ago

Many financial transactions take place between parties who don't necessarily trust that the other side isn't fudging their numbers in order to get a better deal for themselves or to conceal information. Auditing firms exist to pour through the financial books of both sides to say, with our due diligence, we've confirmed that the financial statements both parties are claiming are supported by evidence. This is a time consuming process that involves dozens to hundreds of staff, depending on the size of the transaction. If all of the transactions of a company existed on a blockchain system, this would greatly simplify the auditing process. In order to have access to this system, your financial institution or business would run a node on the network, spreading out the overall cost of using the system. Because of cryptographic assurances, you can guarantee that past data hasn't been manipulated. Using smart contracts, you can also guarantee that every transaction follows certain conditions, making it impossible to do trickery like backdating documents. Security additions (like zkSNARKs today) would enable concealing specific aspects of transactions while allowing third parties to verify their validity. Long term, you could theoretically have an entire exchange that runs on a blockchain, with asset transfers mediated via smart contracts. The clearinghouses that exist to verify the assets of those who buy and sell, and complete the paperwork to document such transfers, could be largely automated. All of this can be achieved today with third parties, but you pay a lot for that trust. Once the technology has matured to a point where it's deployed widely and these types of transactions can be automated, I expect the associated costs of that trust to be reduced.

pishpash 9y ago
Abstractly, I do not see how, economically, devolving trust can reduce cost. You pay for trust either to a third party as now or you pay it to the network verifiers. Somewhere there is a cost. Now, keeping all records digitally and openly accessible, and having automated processes to replace human processes, that can certainly reduce cost, but it's a business process change and orthogonal to the blockchain.
DenisM 9y ago
I know you're no partial to this line of reasoning, but please humor me... Could we achieve the same end by creating a big Git repository under control of the SEC? Anyone can make a clone, SEC will approve pull requests as needed. Or would you argue that this effectively becomes a blockchain as soon as we use start using hashes? I think it's useful to have a paper-trail of hashed blocks/files, gives you a simple mental model to reason about immutability. I just don't quite understand the need for the decentralized commit protocol. For any legitimate (legal) purpose one could rely on a large central entity yielding much higher speed and lower expense/complexity.
- v64 9y ago
  I don't think you can underestimate how important immutability and trustlessness are in cases like these. Don't get me wrong, your setup would be an improvement over many manually curated processes (and in my own business, I use ledger-cli.org with the files under version control), but the lack of the two aforementioned attributes makes it a technological change that doesn't change the underlying politics. In the end, you're just moving the third party elsewhere, and you'd still need staff to verify that people are committing their finances regularly and aren't trying to sneak in retroactive changes in large commits. If someone ever decides to try to get away with rewriting their git history and arguing that the SEC accepted an erroneous pull request that contains the wrong history, that would need to be audited/litigated out to resolve whose tree was correct (just because the SEC owns the master repo doesn't necessarily mean that their custodians of it haven't rewritten history themselves). Also, the fact that the "authority" repo is centralized means you may have issues if for some reason it's inaccessible (these issues arise in reality when GitHub goes down).

by v64 9y ago

pishpash 9y ago

Abstractly, I do not see how, economically, devolving trust can reduce cost. You pay for trust either to a third party as now or you pay it to the network verifiers. Somewhere there is a cost. Now, keeping all records digitally and openly accessible, and having automated processes to replace human processes, that can certainly reduce cost, but it's a business process change and orthogonal to the blockchain.

DenisM 9y ago

I know you're no partial to this line of reasoning, but please humor me... Could we achieve the same end by creating a big Git repository under control of the SEC? Anyone can make a clone, SEC will approve pull requests as needed. Or would you argue that this effectively becomes a blockchain as soon as we use start using hashes? I think it's useful to have a paper-trail of hashed blocks/files, gives you a simple mental model to reason about immutability. I just don't quite understand the need for the decentralized commit protocol. For any legitimate (legal) purpose one could rely on a large central entity yielding much higher speed and lower expense/complexity.

v64 9y ago
I don't think you can underestimate how important immutability and trustlessness are in cases like these. Don't get me wrong, your setup would be an improvement over many manually curated processes (and in my own business, I use ledger-cli.org with the files under version control), but the lack of the two aforementioned attributes makes it a technological change that doesn't change the underlying politics. In the end, you're just moving the third party elsewhere, and you'd still need staff to verify that people are committing their finances regularly and aren't trying to sneak in retroactive changes in large commits. If someone ever decides to try to get away with rewriting their git history and arguing that the SEC accepted an erroneous pull request that contains the wrong history, that would need to be audited/litigated out to resolve whose tree was correct (just because the SEC owns the master repo doesn't necessarily mean that their custodians of it haven't rewritten history themselves). Also, the fact that the "authority" repo is centralized means you may have issues if for some reason it's inaccessible (these issues arise in reality when GitHub goes down).