Easy Key - Storing in Transaction History

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
Post Reply
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Easy Key - Storing in Transaction History

Post by KnightMB »

I've created this topic to help think out loud so that any flaws in my logic can be quickly pointed out. :mrgreen:

It has been debated here before, but I think we are all in agreement that Easy Keys are useful, but still dependent on the web server that runs it, which leaves it open to hacks/attacks/etc.

The solution is to just store them in the transaction history, making the web server for Easy Keys no longer needed. On the surface, it sounds easy enough, just store your easy key in the Message field, then public your key will always be tied to the transaction with no way for someone else to fake it since a false transaction using your public key would not be able to unlock the message field, thus no tampering.

So in that respect, easy enough. The tricky part is, how do I figure who owns a certain Easy Key? If two people create a transaction to take ownership of "knightmb" for example, which one is the correct owner? Logically it should seem, the first one to get the name is the owner. So if I create a transaction that locks "knightmb" to my public key first, how does one determine later that I still have that reserve name? The easiest way I can think is to use the same 1 year expiration that the web server uses. Once I have my easy key, it is mine for one year and any transactions after the point that my transaction was created to claim it are thus ignored is invalid. To renew my Easy Key, any time before the 1 years is up, simply send another transaction that confirms I still use the Easy Key at the same Public Key as before. This way it keeps the renew easy and cheap (only cost 1 TK for example). This insures that people can use Easy Keys, keep them for as long as they want to use them, but the Easy Key won't be locked up forever should someone disappear from Timekoin.

My next challenge, no Easy Key exist for "knightmb". But by strange coincidence, two completely different keys submit transactions at the same time to claim it. So now we have 2 transactions, one public key claiming the Easy Key and a completely different public key also claiming the Easy Key. How is it decided who gets it? I figured why not use the same process that elections use, Random selection. The two keys are graded against each other just like the peer election does and the one with the highest score wins as owner. If by even more coincidence, the two keys get the same score somehow, then it is considered a draw and another set of transactions must be submitted to determine the winner of the next transaction cycle. The first one to reach the high score becomes the winner from that point until the 1 year is up.

I think that covers all possible ways for Easy Key to work and break at the same time, so someone please feel free to chime in if you spot a hole in my logic. :mrgreen:
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Easy Key - Storing in Transaction History

Post by warmach »

My concern is what if a server is working with a partial transaction history? How would it prevented from sending TK to an expired easy key? I feel like it needs to be handled by another process, much like the generating peers lists.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Easy Key - Storing in Transaction History

Post by KnightMB »

warmach wrote:My concern is what if a server is working with a partial transaction history? How would it prevented from sending TK to an expired easy key? I feel like it needs to be handled by another process, much like the generating peers lists.
Default failure for partial history can just be key not found for safety reasons. Good point!

Well, scanning the entire transaction history for a years worth of transactions, decrypt them, check message fields, would be CPU & DB overkill to find one key. So I think the 1 TK can spent into a black hole public key, one that would never naturally exist, but that is easy to sort in the database. So for example, you spend 1 TK to public key "EEEEEEEEEEE" and lots more E's. When searching for easy key matches, you simply find the last years worth of transactions to this black hole key and do the lookup this way. This avoids looking through a million transaction records not related to easy key. The oldest transaction match (within the 1 year window) is the one that will be matched up. Anything older/missing/newer basically returns that no key was found. This way, no one is collecting easy key koins into a large account somewhere as any real account balance, basically the 1 TK is spent into oblivion.

Another route is to create a whole new system that just does the easy keys, separate database table, separate process, some type of rules system, etc.
JohnES
Posts: 6
Joined: Tue Feb 18, 2014 1:47 pm

Re: Easy Key - Storing in Transaction History

Post by JohnES »

I think adding it to the transaction history is a good idea, as it can be used as a proof of concept for storing other types of important ownership information in the Timekoin system (i.e. Smart Property).

How would you ensure Easy Keys are "owned" by a particular individual? Would you just prevent a key from being re-registered if it was still valid (i.e. one year)? What if you wanted to re-assign an Easy Key to another public key (private key gets compromised, etc)?
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Easy Key - Storing in Transaction History

Post by KnightMB »

JohnES wrote:I think adding it to the transaction history is a good idea, as it can be used as a proof of concept for storing other types of important ownership information in the Timekoin system (i.e. Smart Property).

How would you ensure Easy Keys are "owned" by a particular individual? Would you just prevent a key from being re-registered if it was still valid (i.e. one year)? What if you wanted to re-assign an Easy Key to another public key (private key gets compromised, etc)?
Good questions, I had not thought about that.

The public key that creates the transaction is the only one that can unlock the transaction, so proving your key owns the "older" transaction claiming a key is easy enough to verify. I should draw this out, it will make more sense (to me also :D ) to see it spread out visually.

Good question, what if someone wants to get rid of the key associated? It would require still being able to produce a transaction that basically states "expire my key instantly" from the original public key, then take ownership of the easy key name with a new transaction from the new key that should own it. It won't help if your private/public key get stolen and you do not have it, but if a copy (private/public key) was stolen instead, at least you could "expire" the easy key used and assigned a new one to a freshly generated key pair.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Easy Key - Storing in Transaction History

Post by KnightMB »

Chart to go with my thoughts.

Also, since Warmach mentioned it about partial history, why not make it so that the keys only work with 100% transaction history. So if you just created a new server and it is only 2% of the way finished on syncing up the transaction history, easy keys won't work until it is complete (so it can do proper history and time length compares on transactions claiming easy keys).
Attachments
easy_key_db_chart.png
JohnES
Posts: 6
Joined: Tue Feb 18, 2014 1:47 pm

Re: Easy Key - Storing in Transaction History

Post by JohnES »

It looks good. The 100% transaction history requirement is very reasonable. I think a "transfer ownership" transaction type may need to be added. Let's say there are four transaction types:

Register Easy Key - Creates a new Easy Key, takes ownership of a released Easy Key, expires in one year
Renew Easy Key - Extend the expiration for another year
Release Easy Key - Abandons an Easy Key, and anyone can claim it
Transfer Easy Key - Assign ownership of an Easy Key I own to a new address, extending the expiration for another year

I could be wrong, but if I understand correctly, the following could occur if the transfer scenario is not taken into account:

In order to transfer an Easy Key to a different public key, a valid user would have to Release and Register in the same transaction block to effectively transfer the key. An attacker that wants to "steal" an Easy Key could watch for a pending Release transaction and insert a Register transaction. If the attacker's Register transaction just happens to sort before the valid user's Register transaction, then the attacker would end up getting the key. Having the Transfer type would make the operation atomic, which would prevent the attack from occurring.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Easy Key - Storing in Transaction History

Post by KnightMB »

JohnES wrote:Transfer Easy Key - Assign ownership of an Easy Key I own to a new address, extending the expiration for another year

I could be wrong, but if I understand correctly, the following could occur if the transfer scenario is not taken into account:

In order to transfer an Easy Key to a different public key, a valid user would have to Release and Register in the same transaction block to effectively transfer the key. An attacker that wants to "steal" an Easy Key could watch for a pending Release transaction and insert a Register transaction. If the attacker's Register transaction just happens to sort before the valid user's Register transaction, then the attacker would end up getting the key. Having the Transfer type would make the operation atomic, which would prevent the attack from occurring.
You are right, had not thought about that scenario, very good point!

I will have to think that one out. I think it might be easy enough to have a transaction that assigns the easy key to another public key without the need to expire first, then re-register a new key to it. Something along the lines of a hash that can be used to verify that Key A has assigned Easy Key "knightmb" to Key B and to prove it, here is a hash of Key B coming directly from the original owner Key A. The hash is just Key B, so any server can take the Key B, hash it, check against what Key A is claiming. If the two match, then owernship has been assigned from Key A to Key B and the one year ownership takes place from that point now. Make sense in my head, will have to flowchart it out a little. :mrgreen:
Post Reply