5 ms·

Would you provide a realistic real world use case for either or blockchain in general beyond bitcoin?

by qaq 8y ago

lmpostor 8y ago
Data Storage Marketplace to answer your question on use case outside of bitcoin. Of course that relies on several assumptions that remain to be seen, first that the user-experience will be acceptable comparative to centralized solutions, 2nd that the cost will be cheaper. But again that is really the answer for any/most use-cases of blockchain, which is really just a socialized way through inflation (production of new tokens) for confirming data to be true (in this case that data is stored in a reliable/accessible manner). So as long as the application itself can meet that standard, there exists financial opportunity.
candiodari 8y ago
Providing trustworthy transaction logs that can be shared between multiple organizations that don't trust each other, which is of course the central part of the problem we call "banking". To be more detailed. Currently a lot of banks constantly create third-party companies whose only function is to get transactions from bank A, and transactions from bank B, and just record them, providing the logs when either the banks or the government/court requests them. Or when the banks want them. In some cases this is done by central banks, but central banks also do this amongst themselves. There's 2 problems here: 1) those companies are not always trustworthy 2) the jurisdictions those companies operate under are not always trustworthy (in the central bank cooperation use cases) smaller issues: those companies are usually expensive, and staffed by idiots. So cryptographically provably unchangeable logs (which is what blockchains are, at their core) certainly have their function within the banking system. Lots and lots of these are needed. Plus they're already used for that purpose.
- qaq 8y ago
  Banking sector is pretty bad example for many reasons, people implementing hyped up tech pure for the purposes of implementing hyped up tech. Top 3-4 banks will have enough compute to subvert it so trustworthy is not really applicable.
  - candiodari 8y ago
    Look I get that you "can" subvert bitcoin because of the "proof of work" system. This is a problem specific to bitcoin, and it is not a property of blockchains.
    - qaq 8y ago
      if you are not using proof of work what are you using for the consensus?
- TheEzEzz 8y ago
  Do you have any literature on this specific application and why it's challenging? In my head (super simplified) I would just have both institutions sign the hash of the transaction appended to the hash of the head of the transaction log, then you append hat to each copy of the log and move on to the next transaction. Both orgs then have the full log and can verify that every entry in the log was signed off by both them and the other org. You can compare hashes between orgs every N minutes to verify integrity. I'm curious what piece of the puzzle I'm missing.
  - candiodari 8y ago
    Well the problem with that approach is how you do it when the 2 institutions are far apart and have to process a lot of transactions (not that they don't manage to fuck it up when we're talking 10 transactions per day, but that's fixable in different ways). Also this does not satisfy the government/3rd party audit issue (which is important in court cases: can an independent expert verify the log in a way that nobody can subvert ?). In your proposal they can still sabotage this cooperatively, aside from the (potential) impracticality of doing that. So what you do is this: 1) log message comes in 2) generate (public, private) key pair 3) sign log message using private key 4) sign PREVIOUS public key using private key 5) erase previous private key 6) store log message, public key and both signatures 7) goto 1 (usually some metadata, such as amounts on accounts, gets included on a regular basis. Usually there's only a very small number of actual accounts since these are exchanges between huge banks. There aren't that many huge banks, especially not in a specific exchange, in fact, mostly only 2. Even in large systems, 10000 is the biggest I've seen) No need for connection to other party, and by on a regular basis sending one of these public keys to both parties, the integrity of the entire log is 100% guaranteed. You can also "prove" what the time was by encoding functions that are well known afterwards and widely available, but not known ahead of time (like variations in pulsar frequencies, or sunspot images. This principle is called a "natural oracle" and does not require trust. But if you can post a sunspot image of day X, that proves the message was not made before X). Suppose you hack this system (whether actually hack it, or simply have the root credentials on hard): you cannot change past log messages without tripping the alarm (meaning both participants can verify with 100% certainty that you messed with them). You can only change log messages from that point forward (and at that point, why not just replace shit at step 1 of the process). Note: yes, you can delete the logs entirely (but again, this trips the alarm), and yes, you can stop the log and change future messages.
- cjhopman 8y ago
  Right, but there's no need for an inefficient complicated consensus protocol in that use case. If the term "blockchain" still applies, then it becomes nearly meaningless.

Would you provide a realistic real world use case for either or blockchain in general beyond bitcoin?

by qaq 8y ago

Would you provide a realistic real world use case for either or blockchain in general beyond bitcoin?

Data Storage Marketplace to answer your question on use case outside of bitcoin. Of course that relies on several assumptions that remain to be seen, first that the user-experience will be acceptable comparative to centralized solutions, 2nd that the cost will be cheaper. But again that is really the answer for any/most use-cases of blockchain, which is really just a socialized way through inflation (production of new tokens) for confirming data to be true (in this case that data is stored in a reliable/accessible manner). So as long as the application itself can meet that standard, there exists financial opportunity.

candiodari 8y ago

Providing trustworthy transaction logs that can be shared between multiple organizations that don't trust each other, which is of course the central part of the problem we call "banking". To be more detailed. Currently a lot of banks constantly create third-party companies whose only function is to get transactions from bank A, and transactions from bank B, and just record them, providing the logs when either the banks or the government/court requests them. Or when the banks want them. In some cases this is done by central banks, but central banks also do this amongst themselves. There's 2 problems here: 1) those companies are not always trustworthy 2) the jurisdictions those companies operate under are not always trustworthy (in the central bank cooperation use cases) smaller issues: those companies are usually expensive, and staffed by idiots. So cryptographically provably unchangeable logs (which is what blockchains are, at their core) certainly have their function within the banking system. Lots and lots of these are needed. Plus they're already used for that purpose.

qaq 8y ago
Banking sector is pretty bad example for many reasons, people implementing hyped up tech pure for the purposes of implementing hyped up tech. Top 3-4 banks will have enough compute to subvert it so trustworthy is not really applicable.
- candiodari 8y ago
  Look I get that you "can" subvert bitcoin because of the "proof of work" system. This is a problem specific to bitcoin, and it is not a property of blockchains.
  - qaq 8y ago
    if you are not using proof of work what are you using for the consensus?
TheEzEzz 8y ago
Do you have any literature on this specific application and why it's challenging? In my head (super simplified) I would just have both institutions sign the hash of the transaction appended to the hash of the head of the transaction log, then you append hat to each copy of the log and move on to the next transaction. Both orgs then have the full log and can verify that every entry in the log was signed off by both them and the other org. You can compare hashes between orgs every N minutes to verify integrity. I'm curious what piece of the puzzle I'm missing.
- candiodari 8y ago
  Well the problem with that approach is how you do it when the 2 institutions are far apart and have to process a lot of transactions (not that they don't manage to fuck it up when we're talking 10 transactions per day, but that's fixable in different ways). Also this does not satisfy the government/3rd party audit issue (which is important in court cases: can an independent expert verify the log in a way that nobody can subvert ?). In your proposal they can still sabotage this cooperatively, aside from the (potential) impracticality of doing that. So what you do is this: 1) log message comes in 2) generate (public, private) key pair 3) sign log message using private key 4) sign PREVIOUS public key using private key 5) erase previous private key 6) store log message, public key and both signatures 7) goto 1 (usually some metadata, such as amounts on accounts, gets included on a regular basis. Usually there's only a very small number of actual accounts since these are exchanges between huge banks. There aren't that many huge banks, especially not in a specific exchange, in fact, mostly only 2. Even in large systems, 10000 is the biggest I've seen) No need for connection to other party, and by on a regular basis sending one of these public keys to both parties, the integrity of the entire log is 100% guaranteed. You can also "prove" what the time was by encoding functions that are well known afterwards and widely available, but not known ahead of time (like variations in pulsar frequencies, or sunspot images. This principle is called a "natural oracle" and does not require trust. But if you can post a sunspot image of day X, that proves the message was not made before X). Suppose you hack this system (whether actually hack it, or simply have the root credentials on hard): you cannot change past log messages without tripping the alarm (meaning both participants can verify with 100% certainty that you messed with them). You can only change log messages from that point forward (and at that point, why not just replace shit at step 1 of the process). Note: yes, you can delete the logs entirely (but again, this trips the alarm), and yes, you can stop the log and change future messages.
cjhopman 8y ago
Right, but there's no need for an inefficient complicated consensus protocol in that use case. If the term "blockchain" still applies, then it becomes nearly meaningless.