[RAW]: Combine JUMBLR, subatomic, ARRR and VRSC liquidity chains into a KMD VRSC mixer

jl777c Today at 15:38 --- @grewalsatinder @SHossain @mrlynch here is a spec for how to combine JUMBLR, subatomic, ARRR and VRSC liquidity chains into a KMD/VRSC mixer. the GUI i reference i imagine to be shurli

JUMBLR rebooted

JUMBLR created privacy by having globally synchronized t2z and z2t transactions of fixed sizes, these transactions were single party using the zaddr space as a way to shield the t2z source of the z2t destination.

optional privacy onchain defeated the privacy level

...

PIRATE has the ultimate privacy

VRSC defi liquidity chains allows to do conversions in a single party transaction, it also allows having excess liquidity to reduce slippage of an in and out conversion and unconversion.

subatomic allows swapping taddr for ARRR in a practical way

let us assume we have a VRSC-KMD-vARRR-JUMBLR liquidity chain with plenty of excess liquidity for all the coins

A) obtain it using normal transparent means with VRSC or KMD

B) have a jumblr button in the GUI that will specify time period and: 
  1) do a vrsc conversion of all the VRSC-KMD-vARRR-JUMBLR to vARRR 
  2) subatomic withdraw all vARRR to ARRR (can be all at once or using the standard sizes 10.0002/100.0002/1000.0002)
  3) ARRR z->z to a fresh never used zaddr
  4) every 10 ARRR blocks do a randomly delayed fixed size 10.0001 or 100.0001 or 1000.0001 subatomic ARRR 
     to vARRR conversion, with a variety of reilable vARRR bobs.

C) convert 10/100/1000 vARRR to KMD or VRSC at anytime using liquidity chain. the size must be matched to the prior conversion size, eg. if a 100.00001 vARRR was converted, then convert exactly 100 vARRR to KMD or VRSC. Also, the destination address should be limited to a fixed size, can be different than the 10/100/1000 but it shouldnt be too big. this way the end result is N destination addresses, all with the same amount. one destination would have some fractional amount, which makes it a bit contaminated, so best to recycle such funds through the entire process again

the random delay every 10 blocks is calibrated to process all the ARRR in the wallet over the time period, it is a bit tricky but the details can be worked out by estimating the average size that will be converted, and then use that to get the total number of conversions. without any delays, it will take number of conversions times 10 minutes. so if the specified time is 35% more that the estimated time, then each 10 blocks there should be a 35% chance of not doing anything. maybe we have a N/M vs M/N effect and the 35% needs to be adjusted, the idea is to stretch out the total time it takes to do the fixed sized conversions by randomly not doing the scheduled transfer.

to make things more non-deterministic, the size selection should be randomized so that there is an almost equal chance to do a 10 or 100 or 1000 sized conversion. the difference should only be due to there being no 1000 conversion possible with balances less than 1000 (and same for less than 100).

that means that the average size will be a bit less than 370 ARRR converted. lets estimate it with 333.
so calculate the number of periods by dividing total zfunds in the jumblr address by 333. total time is that times 10 minutes. now we can estimate the percentage chance we need to randomly skip a conversion.

all of this random delay will eliminate timing attack, using the fixed sizes will make all these jumblr conversions look very similar, especially since they are externally synchronized to every 10 PIRATE blocks. I think it is not a problem to recalculate the estimate every 10 blocks. that allows more funds to be added at anytime.

the more this is used, the more in the liquidity chain for JUMBLR, so its value will increase based on usage, no need for JUMBLR fees (the other thing that reduced usage a lot)

jl777c Today at 15:53 --- there are three main parts to the solution

1. the liquidity chain which is a onetime creation but the inventory would need to be continually rebalanced. however, with the built in profit motive, once it gets rolling, it should be self-maintaining. @SHossain is taking lead on this
2. GUI to make it easy to use, which i assume will be shurli so that is @grewalsatinder
3. reliable and trustworthy subatomic bobs to do the ARRR <-> vARRR conversion. the more that we have the better overall privacy, so hopefully we can get half a dozen such nodes

once all this is put together, users would just need to specify how much and over what time period and over that time period KMD (or VRSC) is jumblred into a new set of addresses. timing analysis and knapsack analysis is prevented, and there will be very little slippage using the verus liquidity chain. from a practical point the slippage and not knowing what exchange rate you would get was one of the biggest issues. also the design eliminates any fees needed for JUMBLR, but it still gains in value as usage of this grows this will be the first to combine defi liquidity conversion and privacy

jl777c Today at 16:33 --- the things that are at the border of transparent and zaddr are the vARRR <-> ARRR subatomic swaps, so that is what needs to be jumblred all the rest other than the ARRR z2z are transparent, so nothing special needs to be done to them. however the end result should be fixed sized addresses of KMD, say 1000 or 10000 denomination. so the end result are a bunch of fresh KMD addresses, all with the same amounts. anything that is fractional is pushed through the system again to end up with the smaller denomination end result this prevents correlation of the final destination. along the way timing analysis is prevented by all nodes synchronizing to every 10 ARRR blocks, but sometimes randomly deciding to do nothing. the longer time period you set, the more private it is as the effective anon set (total number of fixed sized destinations) is bigger the longer the timeframe is. we hope that the big whales would be doing this process over many months

jl777c Today at 17:09 --- the important thing to make sure is to prevent timing attack and knapsack attacks. those are very powerful ways to deanonymize. since we are staring with taddr and ending with taddr, both timing and knapsack analysis is possible, even though it went through the PIRATE anon set. the pirate anon set makes it so that if you avoid the timing and knapsack attacks, then it becomes very private by not charging anything more than txfees, it becomes practical to iterate the process, so for fractional amounts at a bigger size, it can just be processed again with a smaller target size for the fraction. also, the fixed sized funds in the destination address can also be iterated, which means we can have continually looping funds, that are happening in addition to onetime processed, but no way to differentiate. to make this work, we will need hundreds or thousands of active jumblr happening at the same time. once we can establish that, then people that start, stop, wait for a while, resume, stop, wait, resume, ... their effective anon set becomes very large. of course the price risk of keeping it in ARRR increases, but if ARRR price is increasing, then this is not a bad thing the design is a bit of overkill, but that is insurance against some assumption being violated. that being said, it wont matter if the vARRR and even the vARRR conversion to ARRR is done in bulk unique size. since there are taddr aspects to that anyway, not much is gained by making those fixed sizes.

grewalsatinder Today at 17:18 --- vARRR = Verus ARRR (PIRATE issued on Verus), right?

let us assume we have a VRSC-KMD-vARRR-JUMBLR liquidity chain with plenty of excess liquidity for all the coins

and JUMBLR is the JUMBLR assetchain, which will be included in the process of subatomic swaps?

jl777c Today at 17:20 --- vARRR is a 1:1 coin with PIRATE that is created as a VRSC chain

grewalsatinder Today at 17:20 --- So far we have tested VRSC and zVRSC swaps with PIRATE (ARRR) and zPIRATE (zARRR). have we tested vARRR or something?

jl777c Today at 17:20 --- JUMBLR is just part of the liquidity chain, not involved at all in the subatomic swaps once vARRR is issued, it will be like a normal assetchain the assumption is that normal rpc calls can be used to convert from the liquidity chain (VRSC-KMD-vARRR-JUMBLR) you will need to make special multichain conversion call, but that is just a rpc call to that chain. shossain will get the details on what exact commands to make JUMBLR being part of the multichain liquidity pool will have the effect of JUMBLR price increasing as the amount of other coins in the liquidity pool increase. since JUMBLR coin is not part of the process, it will always be lagging the other coins in the liquidity pool. which means its price will be pushed up as other coins have their liquidity increased

grewalsatinder Today at 17:23 --- I haven't tested VRSC chains yet. so these VRSC chains are similar to komodod -ac_name=SOMECHAIN? and the subatomic swap will treat it like an assetchain?

jl777c Today at 17:24 --- the vARRR chain will be a manual gateway chain so people send ARRR and get vARRR in return. vARRR will be an ordinary chain, with some specific set of parameters that shossain will make

jl777c Today at 17:25 --- i will jump start the vARRR chain by manually issuing X amount, in exchange for having a matched amount of ARRR reserved to cover it the I will swap this vARRR for ARRR from the vARRR subatomic bob operators so the vARRR is a 1:1 claim for the ARRR that i will have in reserve other than the initial manual creation of vARRR, the rest will be done via subatomic swaps. for the vARRR <-> ARRR, and then the shurli GUI manages the process for each user

why: using ARRR privacy to create private amounts of a transparent currency the entire "what" is more a "how" statement, not sure why to simplify it what/why: using ARRR privacy to make an automated KMD mixer the KMD in fixed sized destination amounts wont be as private as ARRR, but it will be a lot more private than existing KMD and the KMD being a lot more liquid than ARRR gives value to the ARRR side too this also creates a lot more liquidity for ARRR to more understand what this is about, you need to understand https://medium.com/veruscoin/verus-testnet-release-marks-new-advancements-in-crypto-2701bf3e7c3

grewalsatinder Today at 17:35 --- just confirming, this whole process of Jumblr is possible using existing subatomic code compiles from subatomic.c file, right? Anything need updating in it?

jl777c Today at 17:35 --- subatomic swaps between vARRR and ARRR should work with existing codebase, needs to be verified to be 100% sure, but i dont see why any changes are needed the GUI will need to make some liquidity chain calls, basically sending funds into it and taking funds out of it

grewalsatinder Today at 17:36 --- excellent! yes, vARRR is the missing verified point I'm concerned. Looking forward to the test results for that from @SHossain

jl777c Today at 17:37 --- it is just a standalone chain, so should just work like any other standalone chain ARRR has the best privacy and verus has the best blockchain enforced liquidity (better than uniswap), JUMBLR solves the timing/knapsack attacks, subatomic allows ARRR to be swapped for a transparent coin this puts all four of those things together in an easy to use one click GUI you should be able to say "jumblr X amount of KMD over N days" and then the GUI would use the various components to achieve this. if it is stopped, that is actually good from a randomization/delay standpoint. it will just resume when it is started again the output would be "special" KMD addresses that have no history, with all of them having the identical amounts in them

grewalsatinder Today at 17:40 --- I will read that referenced VRSC medium article. if there is anything else that you think will help with better understanding with VRSC and this whole concept, please provide the link. will be grateful for such reference help material. :slight_smile:

jl777c Today at 17:42 --- if you are familiar with uniswap, you can think of it as doing something similar, but without the gas fee and front running issue

jl777c Today at 17:42 --- instead of trading against an orderbook of orders, you trade with a blockchain liquidity pool

grewalsatinder Today at 17:43 --- I have to read on uniswaps. to be honest I haven't explored uniswap etc at all.

jl777c Today at 17:43 --- so the price depends on the balance of the coins locked in the liquidity pool lets say there are 100 KMD and 1000 ARRR locked. then the conversion price would be 0.1KMD per ARRR there are lots of details in the actual price setting, as it changes as people add/remove coins from the liquidity pool however, if some whale puts in a LOT of KMD and ARRR at a fixed ratio, then the price will always be close to that ratio as long as the total net trades of any coin is small compared to the total locked in the liquidity pool that will virtually eliminate price slippage over the time the jumblr is doing its thing essentially you swap against the blockchain and not another trader the issue with past designs of KMD -> ARRR -> -> KMD was that the conversion price would have to be done via atomic swaps, which required active bobs and an atomic swap process. the verus liquidity chain condenses that part to a single transfer that you can do from a single node of course, this process can be used with any other coin that is supported by the liquidity chain, but with txfees being such a big issue, using KMD will cost contain the gas/txfee issue and nowadays KMD is trading 10 million+ USD, every day. so this becomes feasible @grewalsatinder the destination addresses should be in a separate or at least segregated wallet so the user wont accidentally contaminate it with funds from other addresses. i think a good way is to just add some prefix/suffix to the main passphrase and use that to generate a set of destination addresses that way, to access the funds, you need to log into a single such address and that means you can only spend funds in that address. that isolates the spending of the jumblr funds so for N destination address, the GUI can calculate the address for "jumblr 0" +

"jumblr 1" + .... oh, another clarification. the jumblr process should just work with all the zaddr funds in the jumblr zaddr. that way, people can just add ARRR directly to that address and bypass the converting KMD via the liquidity chain step. this will further enhance the jumblr anon set as now we dont even know that the output addresses are funded by KMD -> liquidity chain -> vARRR -> ARRR it could have just been ARRR from whatever other source this feature wont take any additional effort in the GUI, as you just use the total in the zaddr, and dont care where the ARRR came from so using the backend half, it becomes a way to convert ARRR into fixed size KMD addresses without any other linkage if you draw out a diagram, it should become clearer for you

grewalsatinder Today at 18:03 --- @jl777c will vARRR be only pegged to just ARRR ?

jl777c Today at 18:05 --- vARRR is a proxy token for ARRR as far as the jumblr process is concerned, it is equivalent in value to ARRR

grewalsatinder Today at 18:14 ---

1. The point of needing reliable Bobs in subatomic swaps, is there any chance that Bobs could be of any issue in this whole architecture to track, analyse or de-anonymise the Jumblr transactions and funds for any crypto currencies jumblred through them?
2. the vARRR Proxy token is centrally issued by you? or is that a decentralised process? For me personally I have great trust in you so it isn't much of an issue if you centrally issue vARRR proxy token on VRSC chain, because I can have trust on you for having the same amount of 1:1 (vARRR:ARRR). But for others, you think this could be a concerning point? Or may be I'm missing something because I yet to read and understand VRSC tech updates.

jl777c Today at 18:16 --- 2. it will need to be centrally issued as ARRR is totally private, no way to do it any other way. it is basically like a CEX when you make a deposit. however if everybody treats vARRR as ARRR equivalent during the jumblr process, then that is what matters. eg. as long as the vARRR liquidity in the liquidity chain matches the ARRR value, it actually doesnt matter if the vARRR is not having 1:1 backing. of course it will. one point is that only the jumblr period is at risk, so if you do a short term jumblr, then the risk for default is minimized if you use the same zaddr and ip address for all the subatomic swaps, then an evil bob could indeed monitor things deduce a fair amount. that is why we need as many bobs as practical and to randomize which ones are used, and i guess having multiple zaddr will be a very good thing if the GUI can handle N different jumblr zaddr, that will allow a design resistant to evil bob if GUI can have multiple subatomic pubkeys that it randomly selects to a random bob, things get even harder. however, as long as there is no link between the source zaddr and dest zaddr, the bobs can only be guessing. but definitely will need to have at least two subatomic pubkeys, one for each direction. that will break the link that bobs can see. also using different ip address for each direction, would then remove ip address correlation from bob

grewalsatinder Today at 8:34 PM --- As per current design, the GUI only is helping defining the pubkey, t address, and z address for the DEXP2P chain, and executing the DEXP2P API and subatomic commands to to subatomic swaps. From this latest description, I think it's not possible to just change the pubkey and other details for DEXP2P on the fly without shutting down the DEXP2P chain first and then restarting it with the new set again, and then proceeding with the further swaps.

SHossain Today at 8:34 PM ---

So far we have tested VRSC and zVRSC swaps with PIRATE (ARRR) and zPIRATE (zARRR). have we tested vARRR or something?

@grewalsatinder i'm in a process of testing and creating vARRR.

grewalsatinder Today at 8:35 PM --- So, taking the example of managing just 2 set of (pubkey, taddr, zaddr) is a nice example to make a code for to see how this can be managed

SHossain Today at 8:35 PM --- and there is no zPIRATE as it's already z chain :slight_smile:

jl777c Today at 8:35 PM --- @grewalsatinder jumblr process will take days, weeks, months. so maybe it just needs to alternate pubkeys on startup for dexp2p

grewalsatinder Today at 8:35 PM --- regarding the IP address, I think preferrably using i2p would be better, but I'm afraid it's too slow that the chances are subatomic swaps may fail. and Tor is just a shiny IP anon tech provider, but now can't be consider a true anon tech.

jl777c Today at 8:37 PM --- if someone is using proxy, then can just change servers when running different instances of jumblr remember the process is over days, weeks, months

grewalsatinder Today at 8:37 PM ---

and there is no zPIRATE as it's already z chain :slight_smile:

@SHossain yes, I think I got carried away in conversation. you are correct 😄

jl777c Today at 8:38 PM --- the more hardcore users will go to many different high volume hot spots i think we can just let the user manage the shurli ip address based on their connections ip address

SHossain Today at 8:38 PM --- can we assume since users will use JUMBLR for privacy, they are also familiar with VPN and will also use VPN?

grewalsatinder Today at 8:38 PM --- hmm... okay, so in that case the IP can be proxy, a VPN, or even Tor I guess, it should be fine.

jl777c Today at 8:38 PM --- it doesnt make sense to internalize the ip address

SHossain Today at 8:39 PM --- VPN wouldn't be that slow

grewalsatinder Today at 8:39 PM --- like for 1 session, of suppose 1 day, just using same IP and then notifying next time you used what IP last time and giving warning about it can be shown in the GUI

jl777c Today at 8:39 PM --- yes, the user should be warned not to use the same ip address for the various jumblr steps

grewalsatinder Today at 8:39 PM --- can handle that part

SHossain Today at 8:39 PM --- some VPN providers are really fast and doesn't slow down internet

jl777c Today at 8:39 PM --- yes, detect and warn before doing any new jumblr things. that lets the user switch vpn location and resume

SHossain Today at 8:40 PM --- mullvad and nordvpn are good providers as i heard

jl777c Today at 8:40 PM --- also using a vpn ip address that a lot of people use is quite advantageous everyone that uses that vpn ip address would appear to be from the same ip address dont use tor

SHossain Today at 8:40 PM --- yep

jl777c Today at 8:41 PM --- by detecting and warning, it will make it the user responsibility to fix the ip linkage and rotating through N different dexp2p pubkeys, one per startup seems to randomize the pubkey linkage or maybe just make a new random pubkey with each time you start shurli. why to use the same dexp2p pubkey more than once? a session based pubkey should be sufficient

SHossain Today at 8:43 PM --- having same pubkey for bob make sense in a way as they have to be verified by that pubkey. this is not required for alice

jl777c Today at 8:43 PM --- so now, across sessions, a bob wont be able to make any correlations. correct, alice can use session based pubkeys. different one each session

grewalsatinder Today at 8:43 PM ---

so for N destination address, the GUI can calculate the address for 
"jumblr 0" + <main passphrase>
"jumblr 1" + <main passphrase>
....

I was also thinking of handling the multiple Jumblr z address generated from a seed word. as you explained, I can make a randomised N number and use that for a new session of DEXP2P settings set (pubkey, taddr, zaddr). example: jumblr 234398 +

and next startup use a different one. And save this 234398 number in an encrypted file which is encrypted using the

, which can be checked later to find which seed was used to make the swaps last time, and also to remember which passphrase has the funds in them.

jl777c Today at 8:44 PM --- yes, something like that that allows only the alice node to reconstruct just imagine that bob is storing all data and make sure that regardless of that, he wont be able to figure out much of anything

SHossain Today at 8:46 PM --- paranoid users can use 2 VPN to make a tunnel through a tunnel and also can combine tor with these if they like. in this way, it is better than using only tor or using only single VPN provider 😅

jl777c Today at 8:47 PM --- i think close to the majority of tor traffic is about trying to deanonymize its users. best to just not use tor

SHossain Today at 8:47 PM --- yes, true.

jl777c Today at 8:51 PM --- one change to reduce reliance on the centrally issued nature of vARRR is to do the vARRR -> ARRR conversion incrementally in smallish sizes, maybe the max 1000.0002 ARRR size. this is then done iteratively, interleaved with the other direction. that way, only a small percentage of funds is in vARRR form at any given time, though the time limitation reduces the jumblr anon set, so that is the downside of this. i guess it can be something the user decides, more privacy by converting to ARRR all at once. less risk relying on vARRR if the -> ARRR side is done incrementally