Ok so that was a long answer, but I hope it will clear things up. The idea is that you as a service provider cannot cheat your customer. Beside establishing transparency through open sourcing code, publishing the sig chains, hashes etc allows customers to even use the service if they do not trust it. The big picture is that companies like Keybase put a lot of effort into building crypto software that reduces the amount of trust you have to put into the creators/service owners to a minimum. (*) Of course, Bitcoin is not perfect as well, but the probability or attacks that achieve large-scale history rewriting are tiny (see 51% attack). The Bitcoin Blockchain however is (almost*) unchangeable. You cannot achieve this by posting to a web page only since it can change any time. The Keybase people call this "Be Honest or Get Caught". For you as a Keybase user, this means the following: If, at any point in time, the head hash available through the Keybase service and the one hashes into the Bitcoin Blockchain at that time diverge, you now something is fishy. The important part here is that in contrast to a sig chain that you as a service owner publish yourself, you cannot rewrite history. Now people started to exploit this by committing data, such as hashes, to the Blockchain in order to securely and irrevocably timestamp their data. This gives us a public, sealed log of events that is secured by a large, global community. But why now also push to the Bitcoin chain? Essentially, Bitcoin users/clients are continuously checking and verifying the Bitcoin chain to be an append-only log, a public, timestamped ledger. Ok so what I explained above already holds without Bitcoin. About committing to the Bitcoin Blockchain. If you are interested in more details, Keybase explains some more details of their approach here. So for a service that continuously publishes the chain and hence the head signature, you only need to remember this one and as soon as the chain changes (probably new elements were appended), you just need to verify everything from the head you already had and after that, remember the new one. If at ANY point in the chain something is changed, all elements following would need to be recreated and the top element('s hash). > Z, then you can verify no element of the whole chain ever changed by remembering only the current head of the chain. To make this more clear, if you have a long chain, such as:Ī-> B ->. Hence, people can detect this, because the head is now B' instead of B. Now the nice thing is that this will render the existing proof of B (the signature) wrong, since the signed content changed. If you would really want X to be part of the chain, you would need to create a new B' that incorporates the hash of X instead the one of A. However, the forked chain now looks something like this: If you now want to later add a proof X that "happened" between A and B, you can embed the hash of A to make it a successor. Where A is the first proof and B is a proof that incorporates the hash of A. Why is such a chain a good thing?Īppend-only data structures have some nice properties: The sequence is fixed and this is easy to prove and verify. The idea is that by incorporating the previous proof, you not only sign the current statement but reassure your knowledge of the previous one, as well. I see there are great comments already, but let me condense them and add the missing pieces: Why hashing the previous proof into the current proof?Īs already indicated by ISMSDEV, keybase is essentially building an append-only data structure, an immutable log.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |