| Sub-key Registration | Wallet |
Sub-key revocation
So let's get that disconnect out of the way first. Let's look at it from a HIVE key-levels perspective. Imagine your laptop breaks. The keyboard stops working, so you bring it to the repair shop and they say they can repair it but it will cost you €400,-. It's a 3 year old laptop that you doubt would still be worth even €500 after the repair. The shop however offers you to take the broken laptop off your hands for €300. You do the maths and take the offer. You didn't use the laptop for storing valuable stuff, you made a backup to your NAS twice a week, so everything is irie. Then, when you get home, you realize you actually did have your HIVE posting key on there. You are 99% sure you didn't have your active key on there, buy that 1% just keeps you worried. So what do you do? You set out to replace your active key with a new one.
As we discussed in the previous post in this series, coinZdense, other than HIVE at presence, would allow you to have register and use a second active key level key, and provides the ways to register the second key through first usage. In this case though, we not only need a new one, we also really need to revoke the first one.
The way we usually think about this is that we are revoking the actual active key, and by revoking the active key, that we are revoking the posting key.
While this is conceptually correct in this case, technically it's a bit different. With coinZdense we don't actually revoke keys, we revoke chunks of allocated index-space instead.
Lets say in our example our posting key was created allocating alocB and its parent active key was created allocating aloc2, then revoking both keys will be done by revoking the aloc2 space.
So far things are still effectively the same, but we could come to the conclusion that maybe, just maybe, we may need to revoke both aloc1 chunks as well. In that case, we could simply revoke the whole heap-alike chunk of our index-space and simply revoke all previously issued keys in one sweeping operation.
The opposite would be possible too. We could figure that we have the posting key on too many devices to revoke the old posting key right now, but we want to stop the active key from doing any new operations.
In that case we can do something that really messes with the conventional way of thinking about revocation, we simply revoke everything but the heap-space of the active key, leaving the posting key untouched but still revoking the index-space that the active key would need to successfully transact.
So what does this revocation design setup mean, really?
- The blockchain needs to keep track of a single revocation table for the owner key only, designating a list of revoked index-space chunks (offset/size).
- Revoke operations take a list of one or more chunks and are signed by an appropriate key with a key-space that fully contains the revoked chunks.
- All transactions, sub-key registrations, and also index-space revocations are validated checking if the index-space used in the operation isn't revoked.
That's it. There isn't more to revocation, and thus this is a short post today. Because it's a conceptual disconnect though, I thought it would be good to not cramp this part in with the previous post, give your brain the room to connect the dots.
In the next and last post in this series, I'll be discussing the coinZdense wallet. While important to complete the deep-dive, the wallet is a bit on it's own, conceptually, so right now after posting this post here, I'm starting soliciting feedback from the crypto and POLA community and some of the relevant blockchain communities. I'll make changes to these posts based on the feedback I receive, hoping there are just details that need fixing. Any input from this point on is highly appreciated, but please give feedback after having read all the post thus far. They are pieces of the puzzle meant to fit together.
My questions for feedback:
- Are there any security cock-ups or security concerns I've overlooked?
- Are there any, not too hard to implement, POLA improvements possible to the design?
- Are there any usability improvements that I could do?
- Are there any fundamental incompatibilities with the proposed implementation and (potential) target chains, including HIVE?
- Are there any missing features that could help coinZdense fit better with important blockchain projects?
| Sub-key Registration | Wallet |
|
|
|