BitKey™ is going to be an secondary channel for transactions. The idea behind it is that an anoymous transaction
won't be an transaction which is traceable through the blockchain. Example: you want to transfer 100 ROOT from A to B.
Client A will automatically transfer the coins to an public address and then send it's encrypted private key with the
100 ROOTs to client B. Finally client B will have received the coins from client A without making an real transaction.
Users will be "identified" through a public key and a boradcasted RootCash-index with all clients/keys.
won't be an transaction which is traceable through the blockchain. Example: you want to transfer 100 ROOT from A to B.
Client A will automatically transfer the coins to an public address and then send it's encrypted private key with the
100 ROOTs to client B. Finally client B will have received the coins from client A without making an real transaction.
Users will be "identified" through a public key and a boradcasted RootCash-index with all clients/keys.
There's one thing I don't understand: Who chooses to which public address the coins are sent? How can you assure (or can you even assure) that client B is the only one who has the private key of this address. Because if not, client B would have to transfer the coins to a new address to make sure they really "belong to him" and therefore transaction fees would be charged two times. Please correct me if I'm wrong.
please read the whitepaper as it explains the tx-mechanism which is used here more detailed.
(there are NO tx-fees used for BitKey-transactions)
to your question regarding the public key redundandce:
keep in mind that the BitKey-IDs of each client are representations of an secp256r ECDSA keypairs public key.
so there is no need to worry about somebody to generate the same priv-key. (with actual resource-limit not possible)
