The coinZdense project continues to crawl forward slowly but steadily. I've settled on a format for the coinZdense RC files now, the files that basically configure coinZdense for a specific application or blockchain. the format is a simple JSON format describing the basic parameters and both the horizontal and vertical signing-key structure.
Let's start with a real simple one:
{
"appname": "DEMO-01",
"hashlen": 32,
"otsbits": 13,
"keyspace": {
"heights": [9, 9, 8, 8]
}
}
In this configuration, we don't use any horizontal key hierarchies, just the regular horizontal stack of signing keys. A stack of four level keys to be precise, making up a signing key that can sign a total of two to the power thirtyfour transactions. About 17 billion signatures.
I added a usefull linter script to the Python coinZdense repo, named coinzdense-lint.py, let's look what this linter tells us when we run it on our RC file:
ERROR: keyspace definition in coinZdense RC file should be a list of objects
NOTICE: There are errors in the file format, not testing keyspace dimentions!
NOTICICE: error count : 1
Seems like we made a mistake. While we don't have any horizontal hierarchy in our keys, keyspace still needs to be an array of objects, not just a single object. Let's try again.
{
"appname": "DEMO-01",
"hashlen": 32,
"otsbits": 13,
"keyspace": [
{
"heights": [9, 9, 8, 8]
}
]
}
Now for the linter results:
NOTICE: 40 out of 64 bit needed to support keyspace for deepest 4 single-priv key-levels
INFO: Key-derivation entropy usage: 40 out of 64 bit needed to support keyspace
NOTICICE: error count : 0
Everything seems alright now, but there is some info that might be useful. There are 24 bits left for our key-derivation setup, so if we wanted to, we could play around a bit with our keyspace and use up those bits.
While with 17 billion signatures to exaust, we probably won't need to use those bits, lets see what happens if we grow our setup a bit.
{
"appname": "DEMO-01",
"hashlen": 32,
"otsbits": 13,
"keyspace": [
{
"heights": [9, 9, 9, 9, 8, 8, 8, 8]
}
]
}
If this works, we can sign 295 quintillion transactions with our 8 level signing key, but will it work?
NOTICE: 38 out of 64 bit needed to support keyspace for deepest 4 single-priv key-levels
NOTICE: 47 out of 64 bit needed to support keyspace for deepest 5 single-priv key-levels
NOTICE: 56 out of 64 bit needed to support keyspace for deepest 6 single-priv key-levels
ERROR: Key-derivation entropy would be exausted 65 out of 64 bit needed to support keyspace for deepest 7 single-priv key-levels
ERROR: Key-derivation entropy would be exausted 74 out of 64 bit needed to support keyspace for deepest 8 single-priv key-levels
ERROR: Key-derivation entropy would be exausted 74 out of 64 bit needed to support keyspace for deepest 1 priviledge levels
ERROR: Key-derivation entropy would be exausted 74 out of 64 bit needed to support keyspace
NOTICICE: error count : 1
Oops, seems we overshot. We could have basically predicted this, right? Let's tune things a bit until we get that 64 bits:
{
"appname": "DEMO-01",
"hashlen": 32,
"otsbits": 13,
"keyspace": [
{
"heights": [9, 9, 8, 8, 8, 8, 8]
}
]
}
NOTICE: 38 out of 64 bit needed to support keyspace for deepest 4 single-priv key-levels
NOTICE: 46 out of 64 bit needed to support keyspace for deepest 5 single-priv key-levels
NOTICE: 55 out of 64 bit needed to support keyspace for deepest 6 single-priv key-levels
NOTICE: 64 out of 64 bit needed to support keyspace for deepest 7 single-priv key-levels
INFO: Key-derivation entropy usage: 64 out of 64 bit needed to support keyspace
NOTICICE: error count : 0
Well, that looks good, we have a signing key that could sign 288 quadrillion transactions. Now while this is a useful exercise, it is unlikely having a key that could sign this many transactions is at all useful. We don't need our keyspace to be able to exhaust our key derivation as entropy source, unless there is a chance it could actually end up needing to exhaust it.
Let's look what happens if we make our keyspace a bit in line with the horizontal hierarchies we would need to emulate something like HIVE:
{
"appname": "HIVISH-DEMO",
"hashlen": 24,
"otsbits": 11,
"keyspace": [
{
"heights" : [9, 9],
"reserve": 8
},
{
"heights" : [9, 9, 8],
"reserve": 16
},
{
"heights": [9, 9, 8, 8]
}
],
"hierarchy": {
"ACTIVE": {
"POSTING": {}
}
}
}
Here is one crafted to use up all 64 bits of KDF entropy generation space.
- Our unnamed OWNER key can sign up to 262 thousand transactions, 256 of those reserved for replacing an ACTIVE key with.
- Our ACTIVE key can sign up to 67 million transactions, 65 thousand of those reserved for replacing the POSTING key with a new one.
- Our POSTING key can sign up to 17 billion transactions, and when these run out, our ACTIVE key can always make us a new posting key.
This is just a random example of what would be possible, there are likely smarter ways to use up the 64 bits at our disposal, and chances are we don't need to actually use 64 bits at all if these are the levels we want to be worjing with.
But we don't need to stop at just the levels we have here, lets stick with HIVE as an example and see what happens if instead of filing up three key levels with our 64 bit of KDF space, we add a few extra levels.
{
"appname": "HIVISH-DEMO-2",
"hashlen": 24,
"otsbits": 11,
"keyspace": [
{
"heights" : [9, 9],
"reserve": 8
},
{
"heights" : [9, 9, 8],
"reserve": 8
},
{
"heights": [9, 8, 8, 8],
"reserve": 8
},
{
"heights": [8, 8],
"reserve": 9
},
{
"heights": [8, 8],
"reserve": 9
},
{
"heights": [8, 8]
}
],
"hierarchy": {
"ACTIVE": {
"POSTING": {
"vote": {},
"comment": {},
"delete_comment": {},
"custom_json": {
"actifit": {},
"cbm": {
"cbm__pub__drink_beer": {},
"cbm__craft__start": {}
},
"dlux": {
"dlux_dex_hive_sell": {},
"dlux_ft_bid": {}
},
"exode": {
"exode_newgame": {},
"exode_join_squadron": {},
"exode_leave_squadron": {}
},
"pm": {
"pm_create_bid": {},
"pm_cancel_bid": {}
},
"sm": {
"sm_find_match": {},
"sm_start_match": {},
"sm_cancel_match": {}
}
},
"comment_options": {},
"claim_reward_balance": {}
},
"transfer": {},
"transfer_to_vesting": {},
"withdraw_vesting": {},
"limit_order_create": {},
"limit_order_cancel": {},
"convert": {},
"create_claimed_account": {},
"claim_account": {},
"account_update": {},
"account_witness_vote": {},
"account_witness_proxy": {},
"custom": {},
"request_account_recovery": {},
"escrow_transfer": {},
"escrow_dispute": {},
"escrow_release": {},
"escrow_approve": {},
"transfer_to_savings": {},
"transfer_from_savings": {},
"cancel_transfer_from_savings": {},
"delegate_vesting_shares": {}
},
"recover_account": {},
"change_recovery_account": {},
"decline_voting_rights": {},
"set_reset_account": {}
}
}
NOTICE: 39 out of 64 bit needed to support keyspace for deepest 4 single-priv key-levels
INFO: Key-derivation entropy usage: 64 out of 64 bit needed to support keyspace
NOTICICE: error count : 0
Now things start to look a bit complex. Let's walk through them:
- Our OWNER key can sign 262 thousand transactions, 256 reserved for replacing the active key with a new one, or creating an OWNER operation level key , for example "change_recovery_account".
- Our ACTIVE key can sign 67 million transactions, 256 reserved for replacing the POSTING key or creating an ACTIVE operation level key, for example "transfer_to_savings".
- Our "change_recovery_account" can sign 67 million change_recovery_account transactions.
- Our POSTING key can sign 85 billion transactions, 256 reserved for creating operating level keys, for example a "vote" key or a "custom_json" key.
- Our "transfer_to_savings" key can sign 85 billion transfer_to_savings transactions
- Our "custom_json" key can sign 65 thousand custom_json transactions, 512 reserved for creating DApp level keys like a "dlux" key or an "exode" key.
- Our DApp level key can sign 65 thousand DApp specific custom_json transactions, 512 reserved for creating DApp operation level keys, for example "exode_join_squadron"
- Our DApp operation level key can sign 65,000 specific custom_json transactions. For example our exode_join_squadron can only sign custom_json exode_join_squadron transactions.
Again, this is just an example of the way coinZdense RC files can be configured, these are in no way meant to represent valid coinZdense configurations for if/when coinZdense ever gets integrated into the HIVE ecosystem. I hope though the linting tool provided can in the future become usefull for finding the proper dimentions for different blockchains choosing to addopt coinZdense post-quantum signatures.
tippingjar and discord
Again, if you think I'm doing good work with this slow-moving unfunded project, consider upvoting my posts, paying a visit to my tippingjar page or joining me on discord.
