Re:Why we rolled our own consensus algorithm
by dlubarov on Thursday November 15, 2018 @08:02PM
(#18465220)
I think it's worth distinguishing a few cases here:
1. Reimplementing an existing cryptographic primitive, such as SHA-256.
2. Inventing a new cryptographic primitive, with a reduction to existing cryptographic assumptions, and implementing it. A recent example is SPHINCS-256, which was proven secure in the random oracle model.
3. Postulating a new cryptographic hardness assumption, inventing a new cryptographic primitive based on it, and implementing it. Recent examples are IOTA's Curl hash function and StarkWare's Jarvis cipher.
#1 is risky, but at least the risk can be mitigated by having qualified peers review the implementation. #2 is riskier, but still, it can be mitigated by having qualified peers review the proof. #3 seems far more dangerous, since it involves conjecture.
What the Tupelo team is doing is like #2 -- risky, yes, but not comparable to #3.
1. Reimplementing an existing cryptographic primitive, such as SHA-256.
2. Inventing a new cryptographic primitive, with a reduction to existing cryptographic assumptions, and implementing it. A recent example is SPHINCS-256, which was proven secure in the random oracle model.
3. Postulating a new cryptographic hardness assumption, inventing a new cryptographic primitive based on it, and implementing it. Recent examples are IOTA's Curl hash function and StarkWare's Jarvis cipher.
#1 is risky, but at least the risk can be mitigated by having qualified peers review the implementation. #2 is riskier, but still, it can be mitigated by having qualified peers review the proof. #3 seems far more dangerous, since it involves conjecture.
What the Tupelo team is doing is like #2 -- risky, yes, but not comparable to #3.