As you may know if you have been following my posts, I am currently working on a project that aims to be the first step in bringing hash-based-signatures to the HIVE eco-system. The proposal is to create a first working version of two low-level and two higher level libraries, together implementing hash-based signatures in both C++ and Python.

The first step, a few weeks ago, was the creation of a proto-type version of the low-level library for Python, pyspqsigs ( The name stands for Python Simple Post-Quantum Signatures ). With this, we demonstrated how a simple single level hash based signature setup can be made using BLAKE2b hashing primitives.

In the second, ongoing, step, I started porting the proof of concept to the new and incomplete single-file header-only C++ library spq-sigs. While working on this port, I ended up using the amazing crypto library libsodium, and came to the conclusion that this library should not only be the basis for the C++ implementation, but also for the Python implementation, and in the future if we go beyond the original proposal, also for JavaScript.

Below is the updated envisioned high-level setup for the two high level and the two low level libraries.

In C++, the spq-sigs library implements signing key generation and message signatures. The spq-sigs is being built as a template library, so that dimensioning the signing key and signature code becomes a compile-time thing. Note that the low-level library implements only single-level hash-based signatures, and does not implement safe storage of signing keys. Those functionalities are left for the (hopefully) future higher level library pqhivepp. The name stands for Post-Quantum HIVE Cplusspluss) If I get to writing pqhivepp (and its Python equivalent), this library shall implement multi-level hash-based signatures, dimensioned specifically for typical and outlier usage with the HIVE blockchain. Further, this library will implement safe password protected and securely encrypted storage of stateful hash bases signing keys in a wallet. That is, as we will discuss later, if my dhf-proposal ends up gathering enough support in coming weeks.

As for progress on the spq-sigs library. So far I've ported (with some minor changes that will require back-port efforts to Python), the key generation and signing parts of the python proof of concept to C++, and I've done so using libsodium. Some work has been done on code cleanup, but work remains on things like const-correctness. The code is currently still single-threaded, and work on signature validation isn't finished.

Once the C++ port is working, multi-threaded, const-correct, and tested, I'll be going back to Python and re-implement the Python proof of concept implementation using PyNaCl, a Python wrapper for libsodium as basis. This should make the python stack look somethin like this:

The dhf-proposal. What if it gathers sufficient support, what if it doesn't?

The dhf-proposal has now been active for 10 days. Before that, there was a full month where the proposal could have gathered support, so in effect, there have now been 40 days of an approvable proposal. I made the proposal because I have bills to pay, and allocating sufficient time to work on a project like this and complete it in a reasonable time when other revenue generating activities pull on my, has proven difficult. Because my proposal is for a 3-month project, and has so far only gathered 11% of the required support, I came to the conclusion recently that I need to define two paths for this project.

• A happy path, where the proposal accumulates the needed support before this month is over.
• The not-so-hapy path where it doesn't.

The happy path

Three weeks over till this month is over. The proposal is at 11% right now, but the right people voting could change that, so I'm not losing hope. What is the plan if the happy path happens?

1: Spent time gathering and interpreting key-usage stats.

The first thing needed to make the higher level libraries possible will be a data gathering step. What types of keys are used with what frequency by that types of users. Generate probability density histograms for key usage. What is typical key usage for a specific type of key? What do the outliers look like? Without that data, picking the right parameters would become conservative guess work leading to inefficient use of the technology. So the first happy-path step would be gathering data on key usage.

2: Determine the appropriate dimensions and parameters for hash-based signatures for HIVE.

Once we have a few weeks, or possibly, if needed a few months worth of data and extracted key-usage histograms, we can start picking parameters for hash based signatures. It is quite possible and even likely that different key types have different usage patterns and thus require different parameters. But it is also possible that they will be close enough in stats to justify the simplicity of a single set of parameters. In this step we try to figure that out and choose our parameter sets.

3: Finish spq-sigs and implement the chosen (multi-level) dimensions and parameters in pqhivepp

Once we have the proper parameters for HIVE, we can make a start at implementing them in a first version of the higher level libraries. We'll start of with C++ and see how things work out.

4: Port to Python

Once multi-level keys and signatures of the right dimensions prove themselves in C++, the next step is the Python port.

5: Implement wallets

Finally, last step of this project under the happy path will be the implementation of password protected encrypted wallets. There may be some quality control after that, but functionally, this should be the completion of the project.

The not-so-happy path

So what if the proposal doesn't get the required support?

1: Delete the proposal

Well, for one, it would be silly to keep waiting beyond the point where completion within the remaining time would become unachievable. So I'm setting myself a hard deadline for proposal acceptance. If the proposal doesn't gather enough support before the 1st of June, I'm deleting the proposal.

2: Look for alternative funding

While I'll delete the proposal under the not so happy path, I won't be giving up on the project, at least not completely. The plan is to look for alternative funding. A lot of other blockchains have the same problem with not being post-quantum ready, so maybe there are other places for me to find funding for continued substantial work on this project.

3: Complete spq-sigs and pyspqsigs

Doesn't matter if I find alternate funding for me to complete the low-level libraries. Sufficient work has been done already on the lower level code for me to complete these two lower level libraries within a reasonable span of time. Only, without any funding, that will most likely be the end of it for me.

The somewhat more happy not-so-happy path

Now assume the not-so happy path ends with me finding alternative funding. What could be the next steps then?

4: Implement a JavaScript port of spq-sigs

An important target missing from my dhf-proposal is JavaScript. I'm not a JavaScript developer. I have worked with JavaScript but most certainly, I'm not an expert. The two libraries libsodium-wrappers and sodium-native though look pretty promising for making work on a port to JavaScript doable, even with my limited JavaScript skills and knowledge.

5: Moving wallets and multi-level signatures/signing-keys down.

Here is where things get interesting. While pqhivepp and pypqhive are meant to be hard-coded for HIVE usage, if I find funding outside of HIVE for my project, I still won't want to completely abandon HIVE. So instead, the implementation of multi-level signatures and secure wallets will move down to spq-sigs and pyspqsigs. If HIVE would still want to use the alt-funded libraries, that should then be possible. Someone will then however need to figure out the most appropriate parameters and dimensions, and that someone won't be me.

Help make the happy path happen.

I hope this post shows I'm not giving up on this project, no matter what, but it might very well become a much smaller low-level-only project without funding. So please, anyone who hasn't approved of my dhf-proposal proposal yet, please do so now, there are only three weeks left before I'm scaling the project down and start exploring (non-HIVE) alternatives for funding work on the higher level library functionality.