Blockchain: RFC

[Zenaan Harkness]

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.