The last few days at HiveFest were both great and terrible for me. HiveFest itself was amazing, but at the same time the last day of HiveFest overlapped with an event in my personal life that currently has me at the point of breaking down.

I gave a talk on the first day of HiveFest about my CoinZdense project. The main content of this post will be about that talk. I'll share my slides, get into some things a bit deeper, and get into some of my personal shit too. I'll do that first, so people reading this will understand why I was a bit off balanced during my talk, and why I left the closing dinner early yesterday.

Some personal shit

As I've told some of you on HiveFest, I'm currently going through the last phase of my mariage. I'm married and my wife and I have four kids that I love with whole my heart. In the last few years we have become like brother and sister, then, later we both ended up doing things, outside, that married people aren't supposed to do. Six months ago, I met the most amazing woman from Latin America online living a two hour drive from me, also in an expired relationship, and a few months back we started secretly meeting. I fell in love deeper than I ever did in my life and we started to both think about a future together, away from here. We weren't ready to take the step because of our continuing ties, finances, and the concequences for my kids. Then my wife found out through my phone and although we were already going through the process of ending our marriage, it impacted things for me and my girlfriend. The fall-out of this discovery led to major tensions between me and my girlfriend, and this weekend, during HiveFest, these tensions came to what appears to be an explosive end. After my talk, multiple people asked me if I was nervous for the talk. I wasn't, I was off balance because of the stuff going on in my life. I wasn't expecting it, but I felt a lot of support from multiple people on HiveFest to who I talked about my mariage ending and about the things I was going through with my girlfriend. Especialy @lasseehlers telling me about the shit he went through, and talking to @priyanarc, knowing what she had to go through and is still going through gave me some perspective. Then yesterday my girlfriend had sent me a few DMs. She writes in Spanish and my Spanish is not that good and Google Translate doesn't always capture the nuances. I knew it wasn't good, I knew it was bad. Then at the closing dinner I was talking to @awildovasquez who happens to be from the same country originally as my girlfriend, and I showed him the last messages I got. He told me just how bad the content was. At that point I started breaking down, emotionally. I tried to get a grip of my emotions, but after a short time I just lost it and had to leave early. I'm a mess right now, but I will be alright. The closing dinner was in a place called "De Hoop". Hoop is the dutch word for Hope, so maybe that is a sign that there is still a tiny bit of hope for me and my girlfriend, but right now I'm bracing for impact, expecting her to make the breakup explicit any moment. God, I love this woman.

CoinZdense

Enough of my personal shit on to my slides. The talk is at 4h32 mark in the day-one stream.

The talk is about my CoinZdense project. A project that attempts to create post-quantum transaction signing and least-authority subkey-management for Web 3.0 ecosystems.

This slide is meant for the HIVE crowd specifically to show where they might know me from.

• I wrote and published my novel Ragnarok Conspiracy on the chain.
• I wrote and used to run a script that reported on the STEEM flag-wars.
• I was the author of the asyncsteem Python 2 library.
• On #creativecoin I was responsible for the SilentBob curation initiative curating #fiction and #poetry.

For those outside of the HIVE community, let me add the following things you might know me from:

• For the least-authority folks: I'm the author of the proof of concept least authority file-system MinorFs, and related the pyrumpeltree implementation of the RumpelTree algoritm that I designed.
• For the non-HIVE blockchain folks: I wrote most of the the Python library aioflureedb for communicating with the FlureeDB blockchain-based graph database, and related, the Fluree-schema-scenario-tool for schema and smart-function unit testing with FlureeDB.

So where did my project start. The history of CoinZdense start off with my novel Ragnarok Conspiracy. Ragnarok Conspiracy is quite possibly the first Web-3.0-first published book. In 2017 I started posting draft-chapters of my book as I was writing it. When I was done, I used competitions to crowd-source the editing for my book with the community. Later I used some of the money I earned from posting my chapters to contract the talented @marylucy to create a dozen amazing illustrations for my book. An illustrator that I found through running a competition again. I think this process really showed me the power of both Web 3.0 and the community.

What is also important about this book, is that it starts out with a quantum bolckchain heist that takes place in the year 2027. The physics used to pull of this quantum blockchain heist are out-there scifi that later link to weird stuff like portal technology, but the quantum-blockchain-heist part of the story is very much a real threath that could one day come to pass. In the book the world ecconomy collapses after the succesfull heist, and a global war, the Copyright-Wars start.

Then, after publishing my book on HIVE and later on conventional channels, a huge coincidence happened. A real blockchain heist was committed. Not quantum blockchain heist, but a leveraged-stake consensus attack involving Sunjuchen / Justin Sun and exchanges.

Untill recently, I was confused about the details, but then during the opening drinks at HiveFest I spoke to @therealwolf, and he explained it to me: The leveraged-stake consensus attack was committed by Justin Sun, fooling exchanges into using customer stake to vote in witnesses that in turn voted in a hard-fork that robbed multiple STEEM account holders of their stake.

This real blockchain heist on the same chain where I had published my book about a blockchain heist really got me thinking, and it incepted many aspects of the CoinZdense project, including some of the target ecosystems I am currently aiming to target.

So lets look into the thread of a "quantum"-blockchain heist. What is the problem with Quantum Computing? The main problem arises from the re-use of ECDSA keys. It is important to know that usually with ECDSA a signature will have a recovery bit that allows the public key to be derived from the signature. So if you have a signature you have the public key.

Now comes the quantum computer bit: If you have a public key, AND you have a really big quantum computer, much bigger than currently exists, then it is possible to derive the signing key from either the public key or a single signature in polynomial time. In other words, the conversion may not be instant or even fast, it will become a fiable attack.

It is important to realize the problem is different for a coin-only blockchain than it is for a Web 3.0 blockchain. For a coin-only blockchain, much of the problem is delayed by years because it usually isn't really necesary to reuse a signing key. The idea is that whenever you spent an unspent-output, you spent it completely and never use that signing key again. You simply transfer the change from the USO to your own brand new address. Sometimes it is some extra effort and discipline, but it is possible. There also is already a solution for coin-only chains that The Quantum Resistent Ledger (QRL) has shown us. Basically single-level hash-based signatures.

For Web 3.0 chains the problem isn't quite as easily fixed. Web 3.0 chains like HIVE rely on extensive key-reuse. Not a few thousand times like you could do with a QRL wallet, but mny many times. You can't have your account get exausted because you voted a few thousand times or did a few thousand custom_json's. That's where CoinZdense hopes to come in.

So when will Quantum computing become a problem? Aparently that is a really difficult problem that experts don't quite agree upon. It might 5 years from now, it might be 20. We know though it will be a problem first for Web 3.0 chains and for sitting-duck USO's.

The main problem that QRL actually solves won't come till later, when the polynomial time needed to transform a signature into a signing key fits well enough into the latency of the network that a key could be reconstructed and a competing transaction (with crazy fees) could be succesfully created within the lag of the network. The time between the first and the latter is also pretty much unguessable, but not that relevant for CoinZdense or Web 3.0.

Below we are going to look into the layering of the CoinZdense project, but before we can, let's have a look at the layers for a Web 3.0 platform. In this case, predictably: HIVE.

At layer zero we have the crypto primitives like ECDSA for signing and different hashing algoritms. Above that we have the layer-1 blockchain. Then above that we have the DApps at layer two and above.

CoinZdense will be positioned at layer zero and layer one, and for a smallish bit at layer 2.

At layer zero we have the base algoritms for hash-based signatures, basically the things that are simular to QRL are mostly at layer zero. At layer one we have the chained hash-based signatures that we need to be able to support many millions of signatures using the same key.

Then whe have what I refer to as layer one and a half. The Web 3.0 Entropy layer or Wen3 layer. I'll get back on that one below.

We start off by looking at layer zero, basic hash-based signing. I didn't have time to get into this deeper during my talk, but I'll quickly go over the pictures in the slide.

At the top right we see a simple setup for a 3 bit one time signing setup. In reality 5, 6 or 7 bit would likely be more common, but for an image 3 bit is more illustrative. The index-space allocation is our link to the Wen3 layer. A key derivation function implemented by libsodium is used to extract two one-time-usage secrets, one up and one down (and for a hashing salt, but thats out of scope of this post). The secret is hashed two to the power of N times where N is the number of bits the OTS is for, so for this exzmple eight times. We'll revisit this image when we discuss signing, but let's walk through the public key creation first. The results of the eight hashing operation will be one pub-up and one pub-down hash.

Then we get to the top right picture. In this example we want to sign 16 bit hash values. Again this is not a realistic value. the values were chosen to make the immages easy on the eye. As we have 16 bits that we sign 3 bits at a time, we need fix pairs of pubs. We take the concattenation of these six pubs and hash it ones more with our level key salt as a salt. The result is one One-Time-Signature pubkey.

Now we move on to the image at the bottom right. Let say we have key that should be able to sign up to 16 transactions. We create 16 OTS pubkeys and put them in a list. For every two in the list we concattenate the pubkeys and take the hash of that. So after one time we have 8 hashes, than 4 than 2, and finaly only one hash. That hash is our public key, the merkle tree root. The intermediate hashes are nodes in the merkle tree, nodes we'll use in the signature.

So now for the actual signing and validation. Back to the top-left image. In the image the the binary value '011' is going to be signed. Again we use the two secrets. Secret-up is hashed 4 (3+1) times, secete-down is hashed 5 (8-3) times. The results give us an up and a down for 3 bits of some hash. The bottom left image shows us how it fits in into the actual signing. The 16 bit hash is chopped up into chunks of 3 bits and each chunk is signed with its own up and down. Now when the signature needs to be validated, the two chains are completed to find the pub-up and the pub-down.

Now we get back to the merkle tree. Let's say validating we get OTS-pubkey6, how do we get to the full pubkey? What we do is that we include OTS-Pubkey7 and the merkle tree nodes mn010, mn00 and mn0 into the signature. So now if the validator completes all the OTS chains, hashes them together and recreates the pubkey from the merkle tree nodes included in the signature, the resulting merkle tree root should be equal to the pubkey.

This setup is pretty simular to the extended merkle signature scheme (XMSS) used in QRL, except that CoinZdense uses a double chain where XMSS uses a CRC check as protection against index-reuse attacks. I'm an engineer, I don't trust CRC, even if it's use has been peer-reviewed. So in CoinZdense we accept some extra overhead to be 100% sure of the robustness of the resulting solution.

On to layer one. As you may understand from the last silde, creating OTS chains takes up CPU resources and thus time. If we want to create a signing key that can sign a billion transactions, we need to calculate billions of OTS chains for our merkle tree first. This would be crazy for many reasons. We can't wait that long, and the resources used just to keep the merkle tree in memory would be out of proportions. And if we ever need to restore the key from its master key, it would again take up crazy time.

So instead of making a key that can sign a bittion transactions, we make for example four keys, to statt off with. Each can sign only a thousand things. The level zero key is going to be our irreplacable key bound to our public key on the chain. This key is used only to sign level 1 keys. A level 1 key is used to sign level 2 keys, a level 2 key to sign level 3 keys, and a level 3 keys is used to sign transactions.

Now after 1024 transactions the level 3 key is exausted and a new level-3 key is created. After 1048576 transactions both the level 2 key and level 3 key are exausted and need replacing.

On to the Web 3.0 Entropy layer or Wen3 layer. A layer whose name isn't just a good fit for the Web 3.0 Entropy layer, I chose the name because Wen3 sounds like the name of the love of my life. My (for now, or maybe only still in my own mind, see my personal shit paragrph at the start of this post) girlfriend. I won't type out her name, but chances are you can guess.

One of three parts of the Wen3 layer is all about entropy as a resource. As you have seen in the layer zero part, we use a key derivation function to turn the master key into level salts (one per level key) and up and down secrets for each N bits of each one-time siging key. For CoinZdense we define that all sub keys (like Active and Posting keys in HIVE) live in the same index-space for entropy derived using these key derivations. Each bit of entropy is created from the same master key and a different 64 bit index, and we must never reuse an index. We treat antropy as a resource, not unlike how memory is treates in a computer.

The Wen3 layer manages this resource in multiple ways. One of these ways is that it manages level-key pre-calculation. In the last slide we saw how huge merkle trees were impractical, and that we need to chop up our solution using a layered or chained design. This is a whole lot better, but there is still something that needs addressing. Signing the 1025th transaction will take up about 2000 times as much time as signing the 1024th transaction. The 1048577th transaction almost 4000 times. This could easily still create a user experience that is unacceptable. Level keys need to be created before they are actually needed in order to. Triggering this creation and managing the threaths or processes to accomplish this from the library is a task for the Wen3 layer too.

We touched on this a bit already. Keys in CoinZdense are statefull. That state needs to reside somewere, either on the chain, or on the client. Both have advantages and disadvantages, and CoinZdense cant make the choice one for every chain in existance, the choice should be defined by the individual chains. If it is on the client, then one OWNER key might be used to create multiple ACTIVE keys and each OWNER key could be used to create multiple POSTING keys. The idea would be that a key lives on only one machine, together with it's state, and doesn't need to sync with other machines using the chain in order to sync.

From a least authority view the idea of having multiple keys at a given attenuation level is a good idea. You can revoke a single machine by revoking that key. In CoinZdense you don't actually revoke keys, by the way, you revoke the entropy-space the key lives in. This could be done with low or high granulatity allowing for different fine-grained revocation patterns.

An other least-authority concept CoinZdense aims to allow for is layer-2 attenuation. Say someone makes an application or a bot that needs to do custom_json posts for a specific layer 2 application and that application needs to run without the user. It would make sense if we could grant that application only the right to make custom_json operations specific to that application or DApp. You could for example derive a Splinterlands key from your posting key, or even finer grained, derive a key that could only do cancel operations on splinterlands.

This setup is what makes Wen3 a layer 1.5 ting. It is mostly layer 1, but the least authority access controll extends into layer two. It is important to note that it will be up to the core devs to figure out if and how they want to expose the Wen3 least-authority access controll attributes to layer 2 DApps.

The CoinZdense project isn't really a small project, especialy not for one person. I would like to support the full ecosystem of multiple interesting blockchains and blockchain technology stacks, but that is going to be practically impossible. In this diagram you see a preliminary matrix of languages and chains or technologies I hope I can support. The ecosystems might be incomplete, as for the last three I merely skimmed the github repos.

Lets go through the chains and/or blockchain technologies first, to get a picture of why I want to support these ecosystems to the best of my ability.

Hive is probably obvious. It's where the project started. It's an amazing Web3 platform with a broad ecosystem and a real and active community. Unfortunately the ecosystem is a bit too broad for comfort, so there are a few languages I won't be able to support, but with the growing use of Hive Keychain, and maybe HiveAuth (See the talk by @arcange on the day-2 stream), it is possible this will become less of a problem for some of the red languages.

Second is FlureeDB. FlureeDB is an amazing technology that allows you to have high-integrity graph databases that run on top of your private blockchain. I've done a lot of work on the Python part of the FlureeDB ecosystem, but the prime languages are Clojure and ClojureScript.

The third one is Agoric. I wish I had spent more time at learning about this project, but my main atraction for this project doesn't so much stem from the blockchain itself, but from its links with the Monte language. Like the SES (Secure EcmaScript) on the list, it is an object capability language.

The final two chains in the matrix are Rune and Atom. Given the role exchanges played in the Steem blockchain heist, but also given the ecconomic vulnerability of centralized exchanges in case of a quantum computing attack against major coins like BitCoin, I believe decentralized exchanges are going to be important in case of such an event. When the shit hits the fan, we will need distributed exchanges badly, and if they are blockchain based, we need those decentralized exchanges to be quantum resistent.

So much for the columns, on to the rows, the languages.

I'm currently working on proof of concept code for the Wen3 layer in Python, and I've completed layer zero and layer one code for C++ and Python. The yellow languages in the picture. I'll be working on these languages for a while further till there is a reference implementation in both languages.

After that, the green languages, JavaScript, Clojure, ClojureScript, Monte and Rust are languages I definetely need to work, either alone or with your help.

The red languages are languages I won't be wotking on myself. My skills in these languages are either non existant or verry low, or in the case of Ruby, I just pasionately hate the language.

The orange languages, TypeScript and Go are languages I might end up working on if I get the time and/or the funding.

So why is the project called CoinZdense? CoinZdense is a pun on coincidence. It was a huge coincidence that the very Web 3.0 blockchain that I wrote a book on that starts out with a quantum blockchain got hit by an actual blockchain heist. It was also a coincidence that the technology needed to protect a Web 3.0 platform, secure hashing based algoritms and least authority discipline perfectly alligned with my background in computer forensics and capability based and least-authority security.

So why spell it CoinZdense? The 'Z' for two reasons, one that we are aiming for authoriZation Based Access Controll (ZBAC) with our subkey management, and because we are using petnames from Zookoo's triangle.

As for coin, that makes sense because it's about crypto.

On to the roadmap. I'm currently working on completing and integrating the Wen3 design. After that I'll be making a few more itterations for the proof of concept in Python.

The first real milestone will be a stable-API interoperable implementation of the POC code in C++17 and Python3 that can act as a reference implemention for the other languages.

After that, we can branch out to the other languages.

Helping out?

This project is currenly a one-man project and also an 'unfunded' project.

If you care for this project and want to help making it a success, there are currently three ways you can help out. You can help me out by helping fund my time (and potentially the time of other people contributing to the project). If you are on HIVE, the best way to support the project is by buying COINZDENSE support tokens on hive-engine. If you aren't on HIVE and want to donate other crypto or even fiat currency, there is a donations page supporting both crypto and paypal donations.

A second way to contribute is the project website. It's just static content, but the site looks like it was made in 1995.

A third way to help is advocacy. I'm not very diplomaticly inclined. In later stages of the project the project could really use an advocate to make the target (and other web3) projects aware of the project and help allign our specs with the specific or shared needs of the different chains, but also outside.

Finaly, in stage four and five, after the reference implementations are there, additional devs might help speed things up while porting to the different languages.

tokenomics / donation spending

It is probably not needed because the tokens aren't an investment, they are project support tokens, but for openness, I'm listing how I plan to allocate any money comming in either from COINZDENSE tokens or direct donations for the project. Most of the below is only relevant if the project gets some really big donations, what right now I don't expect could happen.

• There are a total of 60.000 COINZDENSE tokens
  • 80 were airdropped to early supporters of the project
  • The rest are managed by @croupierbot (that's also me)
    • 40,000 are in a sell-order at a price of 3 HIVE
    • 10,000 are in a sell-order at a price of 2 HIVE
    • What remains is in a sell order at a price of 1 HIVE
    • Any token not in the possesion of @croupierbot has a buy-back order at a price of 0.1 HIVE
    • These orders will remain like this till they get filled or the project ends
• @pibara's hours spent on the project before the date of HiveFest 2022 are (brutally) capped to 50 as not to discourage potential contributors regarding making contributions.
• At the beginning of each month, donations are first converted to HBD under the controll of @croupierbot.
  • Conversion may be delayed to the next month if the specific accumulated crypto has a value that is too much trouble to imediately convert, or may be administratively converted by @pibara.
• Direct expenses will be subtracted first
• 25% of incomming fund comming in untill the reference implementation is complete, will be set aside for stage 4
• Another 25% of incomming funds are set aside for the next month.
• If there are sufficient remaining funds, contributors (including me) will be paid up to 80 HBD per hour of work at the start of each month. If there aren't sufficient funds, the available funds are distributed according to hours contributed upto that month (an hour is an hour), taking into account earlier pay-outs and taking into account that at least 75% of spent funds go to development (and not advocates or web)
• Any available funds that would exceed the 80 HBD per hour of work mark is set aside for next month.
• Stage-4 will extend into stage-5 ONLY if remaining funds are likely to suffice fo complete an extra language.
• When the project ends:
  • The remaining funds will be distributed according to hours contributed upto that month (an hour is an hour), taking into account earlier pay-outs and taking into account that at least 75% of spent funds go to development (and not advocates or web), and never exceeding the total of 200 HBD per hour of contributed work.
  • Any not sold COINZDENSE project support token are distributed amongst contributors according to hours contributed.
  • If after the capped distribution of remaining funds, something remains, these will get re-distributed to owners of the COINZDENSE project support token according to the amount of tokens they own.
• Funds allocation will be published in a monthly HIVE post.

Don't think many people donating will care about the above, but for those that do, it's out there now, just in case the funding goes better than it now seems to be going. It's also there for potential contributors. I'm not paying anyone out of my pocket, so if you help out, these rules above will determine the funds that will flow your way if or when tokens get sold or other

I'm @pibara both on Hive and on github, please reach out to me if you want to contribute to this project, now or in the future. Buy some COINZDENSE project support token, donate crypto or fiat, help me out by bringing the project website to something that looks like it wasn't made in 1995, help out advocating the project, and after the reference implementation is complete, help porting it to some of the remaining languages.

And if you can't help me in any of these ways, just keep me in your thoughts regarding the personal shit I started my post with. Appart from funding, a web dude/duddet and advocating, I really just need you guys to send your good fibes my way.