Skip to content

Instantly share code, notes, and snippets.

@leto

leto/deanon.md Secret

Created September 18, 2019 10:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save leto/b03b152be119331f21ebe6fff340f573 to your computer and use it in GitHub Desktop.
Save leto/b03b152be119331f21ebe6fff340f573 to your computer and use it in GitHub Desktop.
de-anon stuff

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment