coinZdense deep-dive: Intro

Wallet

index

Application RC

---

Intro

---

---

This post is the first of a series of posts that are meant as a deep-dive into the design for the quantum-secure coinZdense hash-based signatures libraries. The coinZdense project aims to create a collection of libraries for (up to) ten different programming languages, that provides the underpinnings for post-quantum transaction signing, specifically for block-chains that either are key-reuse-by design utility chains, or, while they could work just fine not ever reusing a signing key, would benefit from the ability of extensive key-reuse, given that key-reusage is implemented quantum-secure.

In this intro post, I want to discuss mostly when coinZdense is designed to be a good fit for a blockchain project and when it most definitely is not.

In short, if for a blockchain project, the idea of using a signing key hundreds of times ever being good practice from a design point of view is extremely far-fetched, then coinZdense is not a good fit. In general, crypto projects that are coin-only are not a good fit.

A few examples of the type of projects for what coinZdense aims to be a good fit:

• Utility chains that have actual user accounts tied to re-used signing keys (for example, HIVE)
• DEX chains where users and/or trading scripts are first citizens (for example, Atom)
• Infrastructural blockchain components with access control features (for example FlureeDB)

It is important to note that coinZdense is designed as a parameterized signing key library. In order to use coinZdense signatures in a project, you need to really study your use cases well and dimension the parameters for your application with care. There are many trade-offs to consider. Average signing speed, maximum signing time, key generation time, signature size, signing space allocation for delegation, etc, etc. We will look at some of these later in this series.

Now, before we close this introductory post, let's walk through a bit of the base setup. We will do that really quick as the details will follow in separate posts, but this should give you a bit of a feel of things that are coming.

• At the bottom of coinZdense, before we get to any signing, we have a key derivation function provided by libsodium. This function allows us to create many sub-keys from a single high-entropy master key or seed and an index. We have 64 bits of index space that mostely we won't need, but there are other reasons to make sparse use of this index space when implementing delegation and revocation (that we will get into in later posts), so the 64 bit of index space will be something that we'll touch on repeatedly in these posts.
• At the very bottom of hash-based signatures are one-time-signature chains. These double chains of hashing operations on two secret key chunks are used to create a one-time signature for a small number of bits.
• When a transaction is signed, a digest of the transaction is calculated, and it is actually that digest that is to be signed. The length of this digest will be a number of time larger than the number of bits an atomic one-time-signature can sign. So one logical level up, a set of one-time-signature chain-pairs is combined into a larger one-time-signature.
• A single one-time-signature as the name suggests can be used only once. One step up we have the concept of a level-key. A level key is basically a collection of composite one-time signing keys combined in a merkle-tree with a given height. A merkle tree with a height of four, for example, can be used to sign 16 transactions. A height of ten, 1024 transactions. And when all are used, the level-key will be exhausted.
• A collection of level-keys combine to make a signing key. The merkle-tree root of the first level is the public key for the whole signing key. The level key for the first level won't sign any transactions. Instead, it will sign the public key of the level-key one level down. The same for consecutive level keys, except for the deepest level. The deepest level level-key will be used to sign actual transactions.
• Privileges in coinZdense are seen as a tree. The owner-key, to use HIVE terminology, has the entire privileges tree at its disposal. From the owner-key, a new key can be derived by designating the relevant vertices of the graph and signing that designation with the owner-key. Depending on the setup, this can be repeated for the key with attenuated privileges. The design tries to allow decomposition and composition as a tool of attenuation of privileges into a lower privileges delegation key.
• In order to make revocations unique regardless of delegation paths, and as a tool of further attenuation, we allocate index space to delegation keys from the owner-key index space. This might seem like a waste of index space, and it possibly is, but in what it provides to making the administration for revocation manageable appears to make up for that wastefulness.

This was probably quite the info-dump. Don't feel bad if you don't understand half of it yet. You will after everything we just skimmed over gets discussed in later posts. Or maybe you won't. Chances are if you could understand only 50% of what I hurried through here, you will be just fine. But even if you don't get all the details in the end, unless you are deciding on the parameters for your own blockchain project, you'll probably do fine using the API once coinZdense is available for your favourite language.

Wallet

index

Application RC