In this blog post about the coinZdense project I want to do the opposite of what we did for the deep-dive post series, I want to make this post all about context, top-down, and about the different concepts that come together in the coinZdense project.
The coinZdense project is a project currently in its late design and mid prototyping stage. The project aims to:
Provide a multi-language least-authority hash-based-signing and sub-key management layer for the post-quantum version of Web 3.0
Chances are that reading the above sentence, you, the reader, have absolutely no clue what I mean when I write "a multi-language least-authority hash-based-signing and sub-key management layer for the post-quantum version of web3",and that's OK, because explaining that is exactly what this post is about.
We are going to be disecting the sentence above, looking at:
- Web 3.0, the mergere of the world wide web and blockchain technology.
- Multi-language: Why the project needs to (eventualy) support multiple programming languages
- Post-quantum: Why the clock is ticking for many ECDSA based utility chains because of quantum computing.
- Hash-based signing: The foundational tech used by the project to achieve quantum resistance.
- Least-authority subkey management: Using sub-keys in a least authority way
Web 3.0
The term Web 3.0 currently means different things to different people. To some it is about AI. To others it’s all about the semantic web and about connecting knowledge. To others it’s about freedom from big-social. And then there is the group of people who firmly believe Web 3.0 is a hype or a scam, or who believe it is a place for extremists and crypto cowboys. We are not going to go into the political side of Web 3.0 here, just the technological side.
From the perspective of the coinZdense project, Web 3.0 is basically about the underlying technology for Web 3.0: Blockchain, access control and transactions.
In short, Web 3.0 is any technology where the sum of the web and the blockchain is bigger than the parts. Think about projects like the blockchain based blogging and distributed application platform HIVE (where I’m posting this right now). A platform where users can earn money from upvotes on their content, but also playing games. Think also of projects like FlureeDB, an open source blockchain based semantic web graph database.
Some Web 3.0 technology stacks, like HIVE, are bound to their own crypto currency, but some, like FlureeDB aren’t. This is really important to realise. For many the term blockchain and crypto currencies are synonymous. With Web 3.0 this isn’t necessarily true.
It is important to realise that coinZdense is a project is designed and dimensioned with utility blockchains or Web 3.0 in mind. CoinZdense is meant to be a post-quantum crypto wallet solution for Web 3.0 blockchains. Coin-only blockchains have different needs and requirements, and there already exists a crypto currency that quite adequately solved the problem for coin-only chains, and that is QRL, the Quantum Resistant Ledger. CoinZdense doesn’t attempt to compete with QRL in any way. It tries to be to utility chains what QRL is to coin-only chains. In fact, CoinZdense will, for several reasons, be poorly suited for coin-only
chains. The main difference between these two blockchain types lies in the need for and/or the convenience of the re-use of signing keys.
Transactions, keys and signatures
At the core of blockchain technology lies the concept of digital signatures. There is a digital key tied to a digital address, that can be used to create digital signatures that map to the same address. These signing keys are used to sign transactions. For a coin-only blockchain, the a transaction will commonly be the transfer of funds from one address to one or more other addresses. A blockchain is like a huge ledger. There is info on the ledger telling that address A holds funds from one or more previous transactions. Now when the owner of address A wants to transfer these funds, she will create a transaction and sign it. The transaction basically tells the blockchain something like:
"I, the owner of address A hereby transfer funds B to address C, signed by A"
This transaction may leave funds in address A, but with a little care, it is possible to clean out address A in a transaction.
"I, the owner of address A1 hereby transfer funds B to address C and transfer the remaining funds in A1 to address A2, signed A1"
As we will later see, there are reasons for not wanting to re-use signing keys, so this is a common pattern used in coin-only blockchains. Avoiding key-reuse in coin-only chains is neither inconvenient nor undesirable, this can be different though for utility or Web 3.0 blockchains depending on the utility functions provided.
Often, in Web 3.0, an address is more like a user identity or an account. It it at best inconvenient and at worst impossible to avoid key-reusage in a utility blockchain. The coinZdense project aims specifically at blockchains that use or could benefit from the ability to safely reuse signing keys not once or twice but thousands or even millions of times.
Multi language
When I say multi-language, I'm not talking about English, French and Spanish, instead I'm talking about programming languages like Python and JavaScript. When we look at current ECDSA based Web 3.0 eco systems, we see a wide variety of programming languages, sometimes even within a single Web 3.0 ecosystem. It is impossible to cover the whole spectrum for all Web 3.0 projects, but I aim to at least make a solid start with this project by leveraging the availability of (a subset of) the libsodium cryptography library in many languages. The project is starting out with a Python prototype that is currently under development. C++ will be the second languages that will be targeted by the project.
Other languages on the roadmap are JavaScript, Monte, Rust, Clojure and ClojureScript. A roadmap that might get extended with Go Elixir and/or TypeScript in the future. Note that currently CoinZdense is currently an unfunded one-man project, so it will be quite some time before the language roadmap will be complete.
Post-quantum
Now we get to the point of why key-reuse in blockchain technology is, or rather at some point in the next decade will become problematic: Quantum computers.
Blockchain technology, for the most part, today uses elliptic curve cryptography for signatures. The Elliptic Curve Digital Signature Algorithm (ECDSA). Today, ECDSA is perfectly safe. You can reuse ECDSA signing keys as much as you like without fear that something bad will happen NOW if you do so. But there is a problem on the horizon, quantum computing. Once quantum computers grow sufficiently big in terms of net error free quantum bits, it will become possible and practically viable to harvest signing keys from blockchain signatures.
There is a nice and convenient feature of ECDSA signatures that allows an ECDSA public key to be derived from an ECDSA signature, and using a special quantum computing algorithm, a quantum computer with a net size of roughly 1500 error free quantum bits should be able to turn this public key into a private key, giving the attacker a perfect copy of your signing key.
In that, ECDSA as a signing algorithm isn't ready for large quantum computers when they arrive. We need other signing algorithms that are post-quantum ready. The problem is there but smaller for coin-only blockchains that don't by default reuse signing keys (an explanation of resident vulnerability falls outside of the scope of this post, but is the reason why something like $QRL is still very much needed in the coin-only blockchain space), but for utility or Web 3.0 chains, the problem is quite big, not now in 2022, but when these quantum computers arrive, some years from now.
Hash-based signing
One thing I didn't know about when writing my novel was hash-based signatures. Here is another coincidence. I have a background in computer forensics and spent many years designing and building least authority systems. In both these, I've spent much time designing systems that use secure hashing as underlying primitives. The Quantum Resistant Ledger (QRL) uses hash-based signatures in order to provide it's quantum resistance. As far as we currently know, there are no quantum computer based attack algorithms against hash based signatures. The coinZdense project uses hash-based signing that in most ways is similar to the techniques used by QRL. The total signing architecture is quite different though.
One important attribute of hash-based signing, compared to elliptic curve based signing is that a hash-based signing key gets used up, it is a resource that gets exhausted. Well, you could say the same is tru for ECDSA in the light of quantum computers, that it gets exhausted on a single use, but that isn't usually how people think about signing keys.
Multi-level signing keys
Because CoinZdense targets Web 3.0 or utility blockchains, the assumption that a signing key, could need to be re-used maybe millions of times or even more. There are technical reasons that make scaling to this level of key-reuse require coinZdense signing keys to be multi-level keys and for signatures to often contain multiple signatures.
For example, we could have a level zero hash-based signing key that can be used to sign 512 level one signing keys. Each of these 512 level one keys could be used to sign 256 level two keys, and each of the in total 130,072 level two keys could be used to sign 512 transactions, allowing the combined multi-level key the ability to sign up to 67,108,864 transactions.
The very first transaction to be signed will result in a combination of three signatures as the transaction will need to be signed, but the level one key and the level two keys as well. The next transaction though, should require only one signature, that of the transaction, as the latest level one and latest level two keys will already be known.
After the 512th transaction, the level two key will be exhausted and a new level two key will need to be (or have been) created and needs to be signed before usage. After 130,072 signatures, the level one key too will get exhausted and we'll need a new signed level one key.
Subkeys & authority
We are living in an age where security is becoming more and more the default. The idea of a single all powerful key for all posible operations is becoming to be considered poor design. As an example, the HIVE (formerly STEEM) blockchain has a reduced authority key called the POSTING key that gets used for every day usage but not for most of the financial operations. It is reasonably safe to use a posting key on a computer you don't fully trust.
While for HIVE there is always only one posting key, coinZdense is designed to support a more hierarchical approach For example, in coinZdense you could have one OWNER key, three ACTIVE keys and six POSTING keys, two posting keys per ACTIVE key. The OWNER key could revoke one ACTIVE key and thereby revoke two POSTING keys.
Later in this post we will see that it is actually more flexible than that, but in general that is the gist of it.
Least-authority
We discussed the concept of sub-keys and authorizations a bit when we discussed the OWNER/ACTIVE/POSTING keys used by HIVE and how they could map to coinZdense sub-keys, but coinZdense aims to provide something as close as possible to Least Authority in its management of sub-keys. As the author of the open source least-authority projects MinorFS and pyrumpeltree, I'm a big fan of the decomposable DAG, composable DAG approach to authority. The idea of that operations are like leafs on a tree. Related operations combine on small branches, then larger branches, then a tree. You can compose a new small tree by decomposition, picking one or multiple branches or even individual leafs.
Least authority subkey management
Key-space as a resource
One detail that makes the CoinZdense different from other signing key crypto, is that for coinZdense, key derivation is a first citizen, and the unique index used in key derivation is considered an exaustable resource and a resource that is handled with least-authority resource management.
This to the point that revocation of sub-keys isn't done by revoking the sub-key, instead the chunk of key-derivation key-space used by the sub-key is revoked. This allows for more fine grained revocation.
Revisiting the project goals
As stated before, the project aims to:
Provide a multi-language least-authority hash-based-signing and sub-key management layer for the post-quantum version of Web 3.0
Hopefully after reading this blog post, this line now makes more sense than it did at the beginning of this post.
CoinZdense, the project name
Now for the name, coinZdense. The name is a pun on coin and coincidence because the start of the project and some of the technological choices for the project come to be because of a set of coincidences. Let's look at some context.
Ragnarok Conspiracy
This project started out because of a set of coincidences. I write fiction. My first publications where the novelettes Orussian Quarantine and Atheist Afterlife (also published as Ethereal Pixy-Rings Of Mercy). My first novel-sized publication, Ragnarok Conspiracy was first published on the Web 3.0 blogging platform STEEM.
As part of the research for this novel, I looked into quantum computing and the risk it poses to public key cryptography. In the story, a brilliant dutch scientist, Wietse Dijkstra, in the 1990s invents a technology, quantum trinities, a form of quantum entanglement between three quantum entities, for reducing the error rate for quantum computing to almost zero. When Wietse presents his theories to potential corporate investors, Wietse gets kidnaped, his death gets staged and he ends up being held prisoner for many decades, forced to develop quantum computers for industrial espionage.
This is all back story for the novel. The prologue of the story starts in 2027, when a young dating-site scammer, Dakila de la Vega, from the philippines discovers data on a laptop he was asked to repair. The laptop of one of Wietse's guards, a laptop that Wietse tried to use to expose his capturers, to expose large scale quantum computer based industrial espionage. What however happens in the story is that Dakila uses the data on the laptop to commit a large scale quantum blockchain heist. A blockchain heist that ends up doing what Wietse intended, exposing PUPR to the world, but also a blockchain heist that ends up destroying the monetary system and causing a global war between the now very powerful PUPR and much of the rest of the world.
The STEEM blockchain heist
Time for the next coincidence. My book, first published on the STEEM blockchain talked about a quantum blockchain heist. Then the unthinkable happened, STEEM was hit by an actual blockchain heist. Not a quantum blockchain heist, but a leveraged-stake consensus blockchain heist. Maybe you know the story, maybe you don't, but STEEM started out as a kinda shady blockchain project with ninja-mined stake owned by a private company, Steemit Inc, often affectionately referred to as Stinc. Despite this history, STEEM became a great community ecosystem with an amazing community and Steemit Inc supported the growth of the STEEM community in many different ways with its ninja mined stake. Then at one time there was a buy-out. The TRON guys bought Steemit Inc and with it the ninja-mined stake. The community though, at least a big part of the community wouldn't have it, considered the buy-out by TRON to be a hostile takeover, and started discussing a community fork.
A lot happened in between, but the whole debacle ended with a fund displacing fork that basically moved funds from a few of the bigger community fork proponents to a TRON account. A blockchain heist. It was a leveraged stake heist, the TRON guys convinced the exchange guys to use their customers' stake to support the malicious fork. There would have been no consensus, no blockchain heist, without the role these exchanges played in voting for the malicious fund displacing fork.
While not actually that relevant for the project, the coincidence of this blockchain heist happening on STEEM did contribute to the growing set of coincidences that made me start this project and that made me eventually name it coinZdense.
My background
Next to the coincidences surounding a blockchain heist in my fiction and then later on the Web 3.0 platform where I first published this fiction, the match between the specific technology of hash based signatures and my own background was also a big coincidence. In the past I've worked on two least authority projects MinorFS and pyrumpeltree. The later making use of a secure-hashes based algoritm designed specificaly for attenuation and decomposition of tree-oriented authority structures.
I have also worked for many years in computer forensics, among other things designing and building computer forensic frameworks that make heavy use of secure hashing. A proof of concept framework MattockFs implemented the concept of oportunistic hashing, and was later extended with a merkle-tree and blockchain based integrity guards for the framework provenance log.
While looking into the Quantum Resistant Ledger ($QRL), I found there was quite a lot overlap between quantum computing resistant hash-based signatures, and the work I did in the past on pyrumpeltree and MattockFS.
Funding & scaling
In Ragnarok Conspiracy 2027 is the year that a large scale quantum blockchain heist happens.
While it will probably be more then half a decade and possibly more than a decade before quantum computers will be powerfull enough to pose a threath to ECDSA, I still hope to finish the CoinZdense project for most of the listed programming languages well in time before things become truly urgent. The problem though is that the project right now is an unfunded one-man project. I am currently looking at ways that will allow me to allocate more time to the project (paying myself for work I do on the project), possibly do things like contract a web designer for the (curently rather crappy) project website, and maybe hire developers for currently lower priority programming languages like Go, Elixir and Typescript.
When the project started getting shape, I first tried for funding through the HIVE Decentralized Hive Fund proposal system. That failed as I reached barely more than 10% of the required support level. I'm still looking for a viable alternative, either for funding during development or a construct that would give me a decent chance of yield income after development.
Support for the project in any form is highly appreciated. I've now put the following tipping and support options in place:
So far none of these has yielded any funding for the project yet. If this type of funding fails to yield any income, I am contemplating asking blockchain projects that end up using the coinZdense libraries for a voluntary contribution payable in the (new) crypto in question.
Maybe also an hybrid option where part of the contribution would be done as an airdrop for owners of the hive-engine COINZDENSE project-support token as to incentify people buying these project support token right now.
My problem though: With my limited time right now for actually working on the project, I really don't want to spent much of the limmited time I have on marketing effords for any of these options.
If anyone reading this has ideas of how I could get some funding for this project that would me allow to scale up my hours and maybe contract other developers and a web designer for the project site, please say so in the comments, or contact me