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.
