- Master branch currently contains 2.1.0.0 [beta 1 - testnet only] *
Cloak uses the Enigma system in order to faclilate private/secure transactionns.
How does this work?
CloakShield - Node to node communications
On startup, each Cloak wallet generates a [NID_secp256k1] keypair (Cloaking Encryption Key / CEK) to enable them to derive ad-hoc secrets using ECDH with their private key and the recipient's public key. This communication forms the basis on all node-to-node communications relating to Enigma. See 'src/enigma/cloakshield.h/.cpp' for more information on this. This ECDH based encrypted communication is also utilized for onion-routed data, which is handled by CloakShield. CloakShield is a nice name for this collective functionality relating to encrypted node communications.
When onion routing is enabled, the client will attempt to construct a valid onion route for the data using the list of Enigma peers that it is aware of. The node may not have a direct connection to the Enigma peers, but that is not necessary as CloakData (data packed for routing with CloakShield) packets are relayed peer-to-peer. An onion route will typically consist of 3 distinct routes to the destination node, with 3 node hops per route. Multiple routes are used to cope with situations where a routing node drops offline.
Nodes periodically send out an Enigma Announcement (src/enigma/enigmaann.h) to peers to advertise their services for onion routing. Other nodes on the network store the announcements (until they expire or are replaced with an update) and use them to construct the onion routes.
NOTE: The annoucement code could be improved to reduce traffic on the network. At present, re-announcements are sent periodically. It would be prudent to extend this and only send small signed "I'm still alive!" messages (at least as long as the underlying associated encryption key data remains the same).
IMPROVEMENT: The annoucement system is a potential DoS target as there is currently very little computational cost to generating an Enigma Announcement. To mitigate this, a proof-of-work should be generated for the annoucement and transmitted with it. Peers can then quickly and cheaply verify the proof and dicard any bad data.
Enigma - Transaction Process
When a node sends funds via Enigma to an stealth address, the following happens:
- Sender generates inputs to cover amount sent, enigma reward (sent * (.2-1)%) and network fee (unknown at present, so ample reserved).
- Sender generates a CloakingRequest object (containing unique stealth nonce for this request).
- Sender generates 2 or 3 one-time stealth payment addresses using the recipients stealth address and splits the sent amount randomly between the addresses.
- Sender onion routes CloakRequest to network. The request contains the 'send amount' so that Cloakers know how much to reserve.
- Cloaker picks up CloakRequest and decides to participate.
- Cloaker supplies X inputs to sender and a stealth address and stealth hash (for their change).
- Cloaker sends CloakingAcceptResponse to Sender. This contains stealth address, stealth nonce and TX inputs.
- Sender waits until enough Cloakers have accepted.
- Sender creates Enigma transaction using own inputs and Cloaker inputs. Inputs are shuffled.
- Sender creates TX ouputs for all Cloakers. The outputs randomly split their change and return it to them. This also allocates the cloaking reward to Cloakers.
- Sender creates their own change returns for the Enigma TX. These are one-time stealth payment addresses.
- The Sender calculates the network TX fee and subtracts this from their own change return.
- The Sender sends the Enigma TX to the Cloakers for signing.
- Cloakers check the TX to ensure their inputs are present and correct and that there are one-time payment addresses linked to one of thier stealth addresses with payment that exceeds the input amount.
- Cloakers sign or reject the TX and send signatures to Sender.
- Sender collates the signatures and transmits the finalized, signed TX to the network.
- Nodes scan incoming transactions for stealth payments and Enigma payments and detect any payments or change. Keypairs and addresses are generated for any matching payments and generated keys/addresses are saved to the local wallet.
How are stealth and Enigma transactions detected/received?
All incoming transactions are scanned. Stealth transactions are scanned for first (using the default ephemeral pubkey contained in a random OP_RETURN TX output). After this, Enigma transactions are then scanned for. Enigma transactions also use the standard ephemeral pubkey, but payments use an additional step involving a further derived key. Enigma outputs are generated using a hash of the ephemeral pubkey, a private stealth address hash and the output index.
When scanning for Enigma transactions, the zero-index payment addresses are generated for each owned stealth address [HASH(ephemeral_pubkey, hash_stealth_secret, 0)]. If a match is found for the zero-index of a stealth address, additional addresses are generated for the remaining indexes [num_tx_outputs] and these are scanned against to detect payments. See FindEnigmaTransactions in wallet.cpp for more info.
A similar scanning method is employed by Cloakers prior to signing an Enigma TX to ensure they are getting reimbursed correctly. See GetEnigmaOutputsAmounts in wallet.cpp for more info.
New Codebase
The Cloak3 project contains a fork of the recent Litecoin codebase. This comes with segwit, soft-forks are all the latest Bitcoin goodies. Work was started on porting Cloak to this codebase, but stopped due to lack of resources. The wallet does indeed boot now, but header syncing needs more additional work. Older Cloak clients do not differentiate between PoS and PoW blocks when issuing headers, so this will need to be addressed before work can continue. A potential solution would be to avoid header-sync when connected to an older Cloak node as the problem will lessen as clients update over time.
Compiling the new codebase is an absolute dream in comparison to the old/existing codebase. For this reason alone it may be worth switching to the new codebase prior to the public sourcecode release.
Potential Improvements
- Include an encrypted payment ID in the OP_RETURN stealth output for Enigma transactions. This allows the receiver to use the payment ID as the address name for the newly generated/detected one-time address. This would also help stores and exchanges track Enigma payments more easily.
- Include a proof-of-work for Enigma Announcements and Cloak Requests. These are 2 potential DoS targets and adding a PoW function would migigate this.
Security, Peer Review and Audit
The Enigma code has had little to no peer review to date. This makes it critical that the code is reviewed carefully before public release. DoS attacks may hamper users, but stolen funds are the most important area to cover when checking the code.
- Is it possible to trick a Cloaker into signing a transaction that does not pay them correctly?
- Is it possible for a Cloaker to hijack the transaction during sending to trick the sender prior to the Sender finalizing the transaction?
CloakCoin (CLOAK) Release
CloakCoin is a cool new crypto currency that will feature a uniquely implemented anonymization feature that uses exchanges on the back end and a decoupled transaction flow architecture.
This wallet supports the staking=0 option in the CloakCoin.conf file to disable the stake miner thread for pool and exchange operators.
Current dependencies:
qt 5.5.1
openssl v1.0.2g
boost v1.57.0
Curl v7.40.0
leveldb (Bitcoin Fork) v1.2
berkeley DB v4.8.30
libpng v1.6.16
libEvent v2.0.21
miniupnpc v1.9.20140911
protobuf v2.6.1
qrencode v3.4.4