4 ms·

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 has

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.

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.