jl777cToday at 1:04 AM @ITM any luck in deanonymizing PIRATE?
ITMToday at 1:06 AM I was able to chain the z-tx1 to z-txn - 1. no amounts 😦 so I can tell if z-tx2 came from z-tx1, and z-tx1 depends on miner block n All I got was: Let say z-address transaction 1 you received 100 ARRR now z-address transaction 2 you received another 50 ARRR Now you spend it. z-address transaction 3. Now I doing reverse proof. Don't submit tx1 and tx3 fails the proofing. Don't submit tx2 and tx3 fails the proofing. So Now I can say for sure say tx3 depends on tx1 and tx2 but I will not know tx3 amount and who tx3 belongs to So I am now building meta data(A lot of meta data) so using digital price, graviex and tradeogre. So far I got to know who transfered from Tradeogre to digitalprice, digitalprice to Tradeogre , but graviex people are not withdrawing as much 😦 so my transaction are still unspent as long as the transaction are unspent, the privacy is intact. @jl777c sometimes Tx are multiple spends, which is harder to trace. So my theory is that sending multiple z-address that are not the same is harder to reverse or understand So far PIRATE winning 😛 , Hush is easy to decode. When I get time, I want to setup a mini project to do meta leaking. So Let say you your wallet is syncing still(you spend z-address tx1 10 ARRR earlier) Now when the user attempts to spend some coins(Balance is 90), the daemon is stupid and will attempt to use tx1 again. Now I have 2 distinct proofs. Silent Dragon now handles it perfect (Thanks to Duke). Most nodes will reject the transactions, my node will say hmm double spend and 2 different hash(transaction id's) so now I got 2 different proofs to work with that attempts to create distinct results and valid. Like X + Y = 3, now no one will now what X and what's Y. Now comes the second proof. 2X + Y = 4. Now I can set the huge equation to be equal and solve for sapling params. Leaking huge amount of information about the address and other transaction related to that proof. Well its a theory I am working towards. So if a small leak like that, I can then finally determine the address and the amounts :slight_smile: but it does not break or deanonymize PIRATE, only foolish people that leak meta data or attempts a double spend by mistake. the equation of sn-snarks are huges and completely maths. So I am getting there and understanding the maths. Learning curve.
jl777cToday at 1:27 AM @ca333 ITM made the first way to extract information out of ztransactions, even z->z ! even making a dependency graph seems to be a breakthrough and any optional zaddr chain will very quickly have amounts and dependency graph deanonymized
ITMToday at 1:28 AM its related to notes that duke pointed out. which help greatly. @jl777c I am working towards presentation of nodes in 3d. Learning Data virtualization using python. Fun things.
jl777cToday at 1:31 AM for atomic swaps with zaddr, we will need to allow z->t (p2sh atomic swap) and t -> z, so the amounts of that final -> z will be known. it seems from that half public address a z -> z to another address is needed. but is that even enough. what will be needed to break all linkage if we start with the atomic swap t -> z
ITMToday at 1:33 AM Cannot wait, more data to play with. So t-Address to z-address, one will only know the transaction(Actually note proof but easier to refer it to transaction id) z-address to z-address using reverse proofing
jl777cToday at 1:35 AM i think if we have the following, it will be hard to get much useful info: zt is the destination t -> z address, z0, z1, z2, ... are other zaddr so if funds in zt -> z0 during intervals and z0 -> z1 or z2 in intervals and then z1 and z2 send back to z0 in intervals, this looping back i think will confuse your tracking, especially if the amounts being sent from z0/z1/z2 are randomly selected
ITMToday at 1:35 AM z-address to t-address will then leak everything yes, it will mess it up so more transactions goes through, the harder it gets since reverse proofing will require more combinations and swapping of tx to generate a invalid vs valid proof.
jl777cToday at 1:37 AM so funds would need to be sent to zt, and only atomic swap from zt. then post process the zt funds to z0/z1/z2 with loops
ITMToday at 1:37 AM so by doing it random will mess up my tracking completely
jl777cToday at 1:38 AM @mrlynch some super important privacy implications basically JUMBLR logic applied to the zt funds will be needed
ITMToday at 1:38 AM since if transaction goes to 10million, it will take years to reverse and lot of computation resources will not be feasible at all
jl777cToday at 1:39 AM yes, so if we have z0, z1, .. z99 and at each step it sends a random amount to a random address this will create loops and the random amounts will rapidly make any estimate of the value in a proof very fuzzy and before atomic swapping z0/z99 -> zt not sure if that is enough, i guess having a new zt per atomic swap would be best, but not sure that is practical
ITMToday at 1:42 AM end of the day, its all about computation resource cost 8! vs 20! is huge
jl777cToday at 1:43 AM yes, and if a user node is creating a new zaddr per swap, very soon their node will bog down. i think just treating zt as a taddr and then jumbling it up afterward with z0/z99 will make it cost prohibitive.
ITMToday at 1:46 AM currently people are using and spending there z-address slowly, so the steps are easy and about max 9! at the moment. Like 400 000 hush proofs. Which on a couple gpu its quick. Using random will just move it to 10! so more proof to reverse
jl777cToday at 1:47 AM but we do need to make a distinction between atomic swap derived zaddr and pure zaddr without such contamination with 100 addresses that are randomly sending random amounts to random addresses, isnt it approaching 100! ?
ITMToday at 1:47 AM no, so 100 random sending per block, if all comes from distinct previous address and just 1, it will be the same only by increasing the outputs causes issues
jl777cToday at 1:49 AM z_sendmany of 100 with random amounts to each
ITMToday at 1:50 AM so let say you send to 10, I will not know anything until all 10 outputs are spend which is hard because one user will hodl so I can not proof the 10 dependency
jl777cToday at 1:51 AM so if there is one output to a hodl address that is never spent, it seems to make it more difficult
ITMToday at 1:51 AM now I have 4 people never spend, which one is it link to, we will never know until one of the 4 spends it yes
jl777cToday at 1:52 AM so people doing atomic swaps will need a hodl address where some funds are sent to with each transaction maybe that is much simpler to implement and has a bigger deterrent effect
ITMToday at 1:52 AM since the note has no proofing, so all the others I attempt to associate will return invalid proof
jl777cToday at 1:53 AM can just be 0.0001 sent to a hodl address with each transaction
ITMToday at 1:53 AM :shush:
jl777cToday at 1:53 AM when will you publish something about your fantastic zcash deanonymizer? i assume mimblewimble is childs play to deanon, since all the tx are in plaintext before it is mined
ITMToday at 1:55 AM Soon, I trying to get a small setup and paper. Just to show the first 100k blocks(or 6 months data) So people can actually improve upon the research and maybe even come up with better solutions. I only get weekends to work on it it can be invalid or incorrect, but it something
jl777cToday at 1:58 AM having actual percentages of each chain deanoymized would be very interesting, i assume DASH is not having any actual privacy
ITMToday at 1:58 AM XMR has 0 privacy lol
jl777cToday at 1:58 AM DM me a PIRATE address, I will send you a donation oh, if XMR has 0% privacy, i guess PIRATE is the only hope for any actual privacy
ITMToday at 2:00 AM XMR you use elimination, there increase it to 12+ I think now. But the problem is I can inject on transaction, I will know my inputs and outputs. So the entire block can be easily reverse if my outputs > the rest in the current block, its simple task it was publish and spoken many times but XMR then decided to do something like bulletproofs to reduce xmr size which actually made it easier for elimination
passcombo.com 🏴☠🍋Today at 2:10 AM would be nice to see article showing how much effort/money/infrastructure is needed to deanonimize popular privacy protocols with examples and link to block explorers, so that nobody can say "not proven" + some resume for avg users so that they understand the implications of this
jl777cToday at 2:11 AM i think the implication is that only PIRATE has a chance of remaining private
ca333Today at 2:48 AM �ITM made the first way to extract information out of ztransactions, even z->z !� excellent - i wasn't aware of his findings. Depending on the of extractable info we could probably utilize it to visualize the data for the less techincal crowd - i am sure many parties would find value in this. It would also be a great presentation on why PIRATE provides real privacy as opposed to hybrid implementations.