As the barterDEX test team is gathering info on a lot of new coins, there was a lull in bugs found. Instead of just waiting around doing nothing, I decided to put JUMBLR inside komodod. That way there are less moving parts and only native komodod is needed for JUMBLR. The JUMBLR core will be compatible with the previously described passphrase based address management for the GUI to implement.
However if you can run two command line commands, you can start using JUMBLR. I have 10 nodes setup to be doing JUMBLR so that is the equivalent of a mixin level of 10, before anybody else joins. As more and more people start JUMBLR, the mixin level continues to increase, to 100 and above is what I would like to see.
For now, the code is still quite new and if you are using JUMBLR you must take care to make sure your wallet is properly backed up as z transactions only exist inside your wallet and if you lose the wallet, you will lose the zfunds, even if you have your passphrase.
#### README
komodod now has jumblr_deposit and jumblr_secret RPC calls.
Jumblr works like described previously where all the nodes with jumblr active synchronize their tx activity during the same block to maximize the mixing effect. However, unlike all other mixers/tumblers, you never give up control of your coins to anybody else. JUMBLR uses a one to many allocation of funds, ie. one deposit address and many secret addresses. You can always run multiple komodod daemons to get multiple active deposit addresses.
JUMBLR implements t -> z, z -> z and z -> t transactions to maximize privacy of the destination t (transparent) address. So while it is transparent, its first activity is funds coming from an untracable z address.
Which of the three stages is done is randomly selected at each turn. Also when there are more than one possible transaction at the selected stage, a random one is selected. This randomization prevents analyzing incoming z ->t transactions by its size to correlate it to the originating address.
jumblr_deposit
designates the deposit address as the jumblr deposit address for that session. You can select an address that already has funds in it and it will immediately start jumblr process. If there are no funds, it will wait until you send funds to it.
There are three sizes of a jumblr transaction: 10 KMD, 100 KMD and 1000 KMD. There is also a fixed interval of blocks where all jumblr nodes are active. Currently it is set to be 10, but this is subject to change. Only during every 10*10 blocks are the largest 1000 KMD transactions processed, so this concentrates all the large transactions every N*N blocks.
jumblr_secret notifies JUMBLR where to send the final z -> t transactions. In order to allow larger accounts to obtain privacy, up to 777 secret addresses are supported. Whenever a z -> t stage is activated, a random secret address from the list of the then active secret addresses is selected.
Practical Advice:
Obtaining privacy used to be very difficult. JUMBLR makes it as simple as issuing two command line calls. Higher level layers can be added to help manage the addresses, ie. linking them at the passphrase level. Such things are left to each implementation.
Once obtained, it is very easy to lose all the privacy. With a single errant transaction that combines some previously used address and the secretaddress, well, the secretaddress is no longer so private.
The advice is to setup a totally separate node!
This might seem a bit drastic, but if you want to maintain privacy, it is best to make it look like all the transactions are coming from a different node. The easiest way for most people to do this is to actually have a different node.
It can be a dedicated laptop (recommended) or a VPS (for not so big amounts) with a totally fresh komodod wallet. Generate an address on this wallet and use that as the jumblr_secret address on your main node. As the JUMBLR operates funds will teleport into your secret node's address. If you are careful and never use the same IP address for both your nodes, you will be able to maintain very good privacy.
Of course, dont be sending emails that link the two accounts together! Dont use secret address funds for home delivery purchases!! Etc. There are many ways to lose the privacy, just think about what linkages can be dont at the IP and blockchain level and that should be a useful preparation.
What if you have 100,000 KMD and you dont want others to know you are such a whale?
Instead of generating 1 secret address, generate 100 and make a script file with:
./komodo-cli jumblr_secret
./komodo-cli jumblr_secret
...
./komodo-cli jumblr_secret
And make sure to delete all traces of this when the JUMBLR is finished. You will end up with 100 addresses that have an average of 1000 KMD each. So as long as you are careful and dont do a 10,000 KMD transaction (that will link 10 of your secret addresses together), you can appear as 100 different people each with 1000 KMD.
####
I used the following to generate a jumblr script to run:
cd ~/komodo/src; echo "./komodo-cli jumblr_deposit `./komodo-cli getnewaddress`" > jumblr; echo "./komodo-cli jumblr_secret `./komodo-cli getnewaddress`" >>jumblr; chmod +x jumblr; cat jumblr
it should create a file called jumblr which just has a call to jumblr_deposit and another to jumblr_secret. Send funds to the jumblr_deposit and it will be jumbled into the secret address. When you run it, it should return:
{
"result": 0
}
{
"result": "success",
"num": 0
}
currently only the dev branch has the jumblr API in it, but as it proves itself stable it will be propagated to beta and then the master branch. This is not a consensus affecting change. make sure to do a:
git checkout dev
git pull
That way you can make sure to get the version with jumblr API active
http://kmd.explorer.supernet.org/address/RGhxXpXSSBTBm9EvNsXnTQczthMCxHX91t is the address where the fees are collected.
