CloakCoin is a cryptocurrency designed to facilitate trustless and anonymous, decentralized transfers with PoSA (Proof-of-Stake-Anonymous transfers), and secure, anonymous and decentralized marketplace trading with OneMarket.
Cloak is a dual PoW/PoS (Proof of Work, Proof of Stake) coin, which is now in the Proof-of-Stake (interest bearing) stage. (now only PoS)
PoSA3 is CloakCoin’s trustless, anonymous payment system, that forms the basis of future development and provides the underlying transaction system for the decentralized Cloak ‘OneMarket’ marketplace.
Privacy today is perhaps more important than ever. The thundering pace of technological advancement has rapidly broadened our horizons and connected the world like never before. Thanks to Bitcoin’s introduction in 2009, cryptocurrency is steadily moving into the mainstream and we can now transfer digital currency securely across the globe in an instant, using the power of the blockchain.
As cryptocurrency adoption becomes more widespread, increased regulation is inevitable. It remains to be seen what form this regulation will take, but many are concerned it may be overly draconian and designed to stifle some of the more libertarian aspects of cryptocurrency.
Due to Bitcoin’s quest for ubiquity, anonymity for users has never been a priority for the core Bitcoin developers. This has led to the emergence of a number of privacy-centric,alternative cryptocurrencies, designed with anonymity in mind.
There are many different methodologies and approaches to solving the problem of anonymous transactions, and in this document we present a full overview of CloakCoin's PoSA 3 system.
PoSA3 is at heart a decentralized, off-blockchain mixing service which allows users on the CloakCoin network to transmit Cloak anonymously to each other. It has been designed to ensure the mixing process is both trustless and anonymous.
This ensures a user's Cloak coins are kept safe during transfer and that the sender and receiver cannot be tied or associated. Cloak coins are never transferred to an intermediate party during Cloaking, so coins remain safe.
We have also worked hard to ensure the PoSA design rewards users who assist in Cloaking transfers and will continue to improve the process and further incentivize active participants. Anyone with Cloak coins can participate in Cloaking operations, which allows them to leave their wallet running in Staking/Cloaking mode to allow it to passively assist in Cloaking and earn significant rewards.
PoSA3 is the third iteration of Cloak’s trustless and anonymous payment system. PoSA transactions are ‘cloaked’ by other users, who receive a reward for their assistance. The other users provide inputs and outputs to the PoSA transaction making it impossible to determine the true source and destination of the cloak transfer.
All PoSA messages on the network are hashed and encrypted for the recipient using CloakShield to ensure data security and integrity.
2.1. The PoSA Process (for PoSA enabled nodes)
PoSA Announcements
PoSA nodes communicate over the Cloak network and a node will keep track of other active PoSA nodes. PoSA Announcement Broadcasts alert other PoSA nodes of our public session key and current PoSA cloaking balance.
PoSA Cloaking Requests
When a user wishes to send a Cloaked PoSA transaction, they elect a series of PoSA nodes (with a high enough PoSA balance) and request their assistance in cloaking. A PoSA node can choose to assist in cloaking and send an acceptance response to the requester to indicate this.
If a PoSA node declines to participate in cloaking or does not respond in a timely manner, an alternate PoSA node is elected and contacted. DDoS (distributed denial of service) protection will blacklist any misbehaving nodes for the remainder of the session.
A node is deemed to be misbehaving if it repeatedly refuses to sign a PoSA transaction or refuses to relay PoSA messages. PoSA cloaking nodes use an Elliptic Curve Diffie Hellman key exchange (ECDH) to derive a shared secret with the PoSA initiating node, which is used to generate a shared secret key for symmetric RSA-256 data encryption between a cloaking node and the sender node.
PoSA Cloaking Acceptance
When a PoSA node accepts a 'cloaking' request, it provides a list of transaction inputs and outputs to be used for the PoSA transaction. Input amounts provided by a cloaking node must be greater or equal to the PoSA send amount (plus any fees). Outputs are carefully selected so that they match the true output of the PoSA transaction as closely as possible.
If the PoSA output address has not previously been used, a new change address is generated by the 'Cloaker'. If the PoSA output address has previously received funds, an existing address with similar activity is chosen by the 'Cloaker' to return their input funds and receive the PoSA 'cloaking' reward.
The 'Cloaked' PoSA Transaction
The PoSA Sender constructs a 'cloaked' transaction using the inputs and outputs provided by the PoSA Cloaker nodes. The PoSA Sender then adds their own inputs and outputs to the transaction,before shuffling all transaction inputs and outputs to facilitate 'cloaking'.
The 'cloaked' transaction is then encrypted and sent (using CloakShield) to each participating Cloaker.
Cloaker nodes check the transaction to ensure the inputs and outputs they supplied are present in the'cloaked' transactionand that one or more of their outputs has also been rewarded with sufficient fees.
If the transaction checks are passed, the transaction is signed (SIGHASH_ALL+SIGHASH_ANYONECANPAY), encrypted and relayed back to the PoSA Sender. Once all PoSA Cloakers have signed the transaction, the PoSA Sender confirms the signed transaction is valid and signs it. The 'Cloaked' transaction is then ready for submission to the Cloak network.
2.2.1. Tracking PoSA Cloaking Nodes
PoSA enabled nodes on the Cloak network broadcast announcements to other nodes. These PoSA announcements contain the public ec-key ID of the node and the currently available balance for PoSA cloaking operations.
Nodes maintain a list of other active PoSA nodes on the network so that they can communicate for cloaking purposes. Nodes IDs are generated on a session-by-session basis; restarting the client will refresh the current ID.
Each wallet creates a public/secret (secp256k1) key pair for the session at start-up.
The wallet announces its public key and Cloaking balance for the session periodically to other nodes on the Cloak network.
Nodes keep track of other active PoSA Cloaking nodes and can communicate with them directly or indirectly (via CloakShield Onion Routing).
2.2.2. Initiating a PoSA Transaction
Alice wishes to send 10 Cloak to Catherine using 1 mixer:
Alice broadcasts a PoSA request to the network, containing her public PoSA session key and the amount of cloak she wishes to send. Her request is securely routed through a series of PoSA nodes to mask the originator.
Bob has ‘Cloaking Mode’ enabled and creates a secure CloakShield encryption channel for secure communication with Alice. Bob then constructs a PoSA response packet and sends it securely to Alice. The response contains a list of Bob’s inputs and outputs that Alice will use to ‘Cloak’ her transaction.
Alice decrypts and processes Bob’s PoSA response and creates a PoSA transaction using her own inputs and outputs mixed with Bob’s inputs and outputs. This is encrypted and sent to Bob for signing.
Bob decrypts the PoSA transaction and performs a number of integrity checks on the transaction to ensure the inputs and outputs he supplied have been used correctly and that he has been rewarded sufficiently. If the PoSA transaction passes the tests, Bob signs it,
encrypts it and transmits it to Alice.
Alice performs further checks on the signed transaction before signing it herself. The transaction is then submitting it to the network (securely routed through PoSA nodes) for inclusion in a block.
When the transaction is finalized, Catherine will receive the funds from Alice and Bob will receive a ‘Cloaking’ reward for assisting in the PoSA transaction.
Due to Bob’s inputs and outputs mirroring Alice’s, it is not possible to ascertain the true sender and recipient of the PoSA transaction
CloakShield provides secure communications between nodes on the Cloak network using symmetric RSA encryption backed by an Elliptic Curve Diffie Hellman key exchange (ECDH).
This allows nodes to exchange data securely, providing protection from snoopers (man in the middle) and imposters (sybil attack). CloakShield is designed to secure both PoSA and OneMarket, and will ensure your data stays as private as possible.
CloakShield allows the encrypted sending of data to one or more recipients.When sending to a single recipient, the payload is RSA encrypted using the ECDH shared secret.When sending to multiple recipients, the payload is encrypted using a one-time key and the key is then encrypted for each recipient using the ECDH/RSA method.
Generating a shared encryption key
In order for Alice and Bob to communicate securely, they must agree on a shared encryption key.
CloakShield uses ECDH to accomplish this:
• Alice has PoSA private key dA and PoSA public key QA=dAG (where G is the generator for the elliptic-curve). Bob has PoSA private key dB and PoSA public key QB=dBG.
• Alice has Bob's PoSA public key dB from the PoSA announcements he sends to the network to announce his availability for cloaking assistance. She uses her private key dA and Bob's public key QB to calculate shared secret dAQB=dAdBG (ECDH_compute_key in OpenSSL).
• Alice then creates a SHA256 hash of the secret and passes the hash to the OpenSSL EVP_BytesToKey method in order to derive an encryption key and IV, which will be used to encrypt data for Bob (using symmetric RSA encryption).
• Alice is now able to create CloakShield secured messages for Bob.
When Bob receives a Cloak Shielded message from Alice, he reads Alice's public key from the message header and generates the same shared secret key as Alice, as per the steps above (with his secret key, instead of Alice's). The Cloak wallet maintains a list of active CloakShield keys and will check the list for an existing CloakShield key before generating one.
CloakShield Data
CloakShield allows any Cloak data objects to be serialized and transmitted securely to one or more recipients. A CloakShield data packet-header contains the sender's PoSA public key and the public keys hashes of the recipients.
CloakShield headers contain a verification hash which is generated using the sender's public key and the raw unencrypted data. This hash is verified during decryption of CloakShield data to ensure that the recipient info in the header matches the encryption key, and that the data has not been altered.
CloakShield Onion Routing
Onion routing is a technique (used by TOR) for anonymous communication over a computer network. In an onion network, messages are encapsulated in layers of encryption, analogous to layers of an onion.
The encrypted data is transmitted through a series of network nodes called onion routers, each of which "peels" away a single
layer, uncovering the data's next destination. When the final layer is decrypted, the message arrives at its destination.
The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes.
Onion Routing Analogy
The addition of 'onion routing' functionality to the PoSA network (using CloakShield) allows nodes to communicate indirectly to circumvent traffic analysis.
This hampers attempts at determining which nodes are communicating with each other or which nodes submitting transactions to the CloakCoin network. When a PoSA node wishes to communicate with another PoSA node it selects a number of other PoSA nodes to act as relays for the communication.
Each encrypted layer can only be decrypted by the intended relay [for which the specific layer was encrypted]. After decrypting a layer, the relay passes the data to the next relay node.
This routing continues it until the data reaches its intended recipient and all layers have been decrypted in turn by the selected relay nodes. Due to the self-contained nature of the PoSA network, exit nodes are not required and CloakShield ensures there is no risk of a relay node reading or altering the encrypted data
Step 1 - Request Cloaking: PoSA Request from Sender and Response from Cloaker
Step 2 - PoSA TX Signing: PoSA Sign Request from Sender and PoSA Sign Response from Cloaker
Step 3 - Sender Signs PoSA TX, relays TX to Cloakers and submits TX to CloakCoin network
