On Thu, Feb 06, 2020 at 08:55:20PM +0000, other.arkitech wrote:
Dear friends,
Request For Criticism about what I've written:
Current blockchains are all genesis-block based, which means they are ever-growing structures. Aside of being under the effects of an elastic-gum force that complicates their scalability in size, there exist problems scaling on addresses or scaling on bandwith. What touches to cryptography comes straight when dealing of ever-growing structures. Such a buried pile of layers of information requires consideration because it contains cryptography of past times. There are two problems with that. 1.- can expire secrets. 2.- The runtime software must be equiped with all cypher-suites used in the past, including those too old to rely on who were already cracked, broken.
A challenge is the to design a platform that does not depend on cypher-suites that were needed in the past. Once a new encryption technology deprecates another, the platform must be able to replace the cypher-suite and forget about the previous one.
After the Git (ongoing) fiasco around the SHA hash transition, for anyone who missed the memo a base requirement to any sane solution is a protocol version number at the very beginning of your comms. If that version number increases, future versions can decide what to do, regardless of $TODAYS assumptions being right or wrong. But (as with Git), when even a version # does not exist, you have the mess of deep protocol diving to determine some arcane corner case which implies the old vs some new, version, or perhaps a massive global flag day to simply drop the old (i.e. current) protocol altogether. In other words, don't build in such pain - begin all communications with a version number. <don't take it personally but> You are not smart enough to know all the future proto/crypto/etc-o changes that might be required, should your software - or even just your protocol - prove to become popular one day.