I've almost arived at the point in the aiohivebot project where I need to look into supporting transactions.
Transactions, being signed, are the space where my aiohivebot and coinZdense project start overlapping. For those reading this who don't know about coinZdense, its my slow moving project aiming to provide hash-based signing and least authority subkey management to Web-3.0 and utility blockchains.
While not strictly needed for aiohivebot, I'm not going to implement transactions in aiohivebot without also embracing the oportunity to experiment with hash based signatures in a real life setting, and the custom , custom_binary and custom_json seem to provide this possibility. I want to start off with using custom_json for transparancy and debugability purposes, and later look into moving to custom_binary possibly combined with custom if that ends up making sense.
hash based signatures ?
Hash based signatures are big compared to ECDSA. Signing keys take long to create compared to ECDSA. Hash based signatures get used up as you use them. So why would anyone want to use hash based signatures? Well, quantum computing. Right now quantum computing isn't powerfull enough to be any threath for a blockchain like HIVE, or rather for the public keys and signatures that are on the blockchain. At some point in the future though, as the number of error free logical general purpose qbits in quantum computer rises beyond a certain treshold thjings are going to change rather abrubtly and dramatically. Ones a generic quantum computer reaches this treshold, it should be able to extract a copy of the private ECDSA signing key given only its public key. On HIVE all public keys are truly public and they are queryable through the API. In chains where they aren't, as a property of the signature encoding conventions used, blockchain pubkeys are generally extractable from signatures. For non Web-3.0 non-utility chains, public keys usualy don't need to actually be public, and their disclosure in a single transaction can usualy be set up in such a way that these keys are functionally use and throw away.For Web 3.0 chains though, and a big part of utility chains, key-reuse is essential and quantum computing will some day become a big problem. Hash based signatures come at a price, but we need them. Not today, but at some date in the future and we need to start preparing for that date.
What I am proposing in this post is part of that preparation.
get_transaction_hex times two
In order to sign a transaction, the get_transaction_hex API call provides a hex string of the data that needs to actually be signed. The problem is that if we use custom_json and friends within one transaction, the hash-based signature of the transaction contained in the custom_json won't be known yet. We don't want to polute the chain with spurious transactions if we can avoid it, so what we should do is work with a virtual transaction that will never get published.
Eventually we will need to post a broadcast_transaction containing a signed transaction with multiple operations. Given that aiohivebot is driven by block processing, all broadcast operations triggered in a single block can be delayed untill the end of the block processing, potentially combining many operations in one transaction.
What we plan to do is take these operations and act as if we are about to send out a transaction, but instead of creating the transaction, we use the hex version of the transaction data to create an extra operation, a custom_json (for now), a custom_json that holds a hash-based signature.
We append this hash based signature custom_json operation to the transaction and we do another get_transaction_hex call with this operation added. And it is this second transaction that we will actually broadcast after ecdsa signing it with the regular HIVE signing key.
integrating HIVE CoinZdense Disaster Recovery tools functionality
A while back I wrote a little hash-based signature quantum disaster recovery tool for HIVE as a simple side project for coinZdense. The project uses the lower level one-time signing key primatives to create a hash based disastery recovery key, that it then publishes to the HIVE chain as part of the users json_metadata using the account_update broadcast opp. The idea is that if HIVE users ever get struck by a quantum-computing based attack against their private keys, and this happens before HIVE has moved to post-quantum signing, the pressence and age of these hash-based one time signing keys could allow the rightfull owner of the account to recover their account by one-time publishing a new hash-based signing key.
I plan to integrate and extend this functionality from this tool into aiohivebot.
Build in L2 validation
Because this implementation would be aiming at new L2s using it, aiohivebot will get the option to L2-validate the hash based signatures as the signed operations get streamed to the
middleware. I am planning to add a validate argument to operations, both at L2 and at L1, that is callable as a way to abstract the hash-based signature validation.
Volatility of ops
While the base idea is to allow for all transactions to have a hash-based signature custom_json included, something is to be said for (at least at first) limit this to less volitile operations. For example vote operations are relatively volatile. Vote operations seem much more volatile than fund transfer or even posts. The idea is that we allow for the setting where only transactions that (also) contain less volatile operations will get a hash based signature added to it by aiohivebot.
This is not an end goal
This idea isn't an end solution for preventing quantum-computing disaster for HIVE, its about creating a playground for testing and working with the technology before trying to move to an ecosystem where this technology could blend into L1.
Input is welcome (and desired)
It will probably be a few weeks before I start working on this. I would really appreciate feedback on the ideas presented in this post:
- Making an experimental L2 hash-based signing implementation that uses custom_json
- In the future move to custom and/or custom_binary instead
- Using user json_metadata for publishing L2 signing keys
- Defining vote and possible other operations as volatile, meaning they won't get hash based signatures on their own unless explicitly requested through the API.
- Making L2 hash-based signature validation a callable argument on all (L2 and L2) operation callbacks and transaction callbacks.
If you are either a dev, a witness, or part of the core dev team for the chain, I would really like to hear your perspective on these ideas. It is important to note that compared to ECDSA signatures, depending on dimensioning parameters, hash based signatures aren't exactly small.
I hope that the ideas I'm presenting here are a decent way for me to experiment with L2 hash-based signatures, but if its not, I really need to know before commencing.
While its just meant as a playground for the technology, I do feel that creating a library that will introduce extra custom_json load on the chain for any L2, middleware or bot that uses it is something that needs the support of the HIVE community and witnesses, and next to this dev input should be very welcome too. So please share your thoughts with me. Share your concerns if you have any, and share your suggestions if you believe you know of ways to improve on the outline I've sketched in this post.