RT @cathieyun: I worked with @hdevalence and @oleganza to implement a programmable constraint system for Bulletproofs, which you can use to build zero knowledge proofs over arbitrary statements! Check out our post:
Upcoming: R1CS improvements, and more work on Cloak!
I haven't had my coffee yet but I think these means that we now have zero knowledge proofs and private transactions on Stellar.
If so then this is awesome news as we have been encountering some scenarios where this type of functionality is preferred for certain use cases in the mainstream world especially when federation is enabled.
No, there are no ZKPs or private transactions on Stellar. Cloak is in early stage of research and development, and even R1CS API in Bulletproofs is not production-ready. Moreover, Cloak by itself is just a protocol of moving values, it does not cover authorization/contracts and a ton of operational issues, one of them is a ZK version of coinjoin (we'd have to build the whole new multi-party protocol for cooperatively building a single transaction).
Thanks for the clarification. We will continue working on our own iterations at the moment and hope that a network wide solution evolves in time as federation has immense adoption potential once we solve the privacy trade-offs.
To give you an example, my federation wallet address for [TON.Money](https://TON.Money) is being configured as tondmc\*[ton.money](https://ton.money)
This is uber convenient because as the saying goes, it makes *sending money as easy as sending email.* The problem however is that it is now trivial to work out my balance and to trace every transaction I have made from the wallet and if the recipients also use federated addresses then it gets even worse.
For example I am sending multiple payments every week to orders\*tequila.express then you are naturally going to become concerned about my well being while in fact I am just a generous type of person that loves giving "*spiritual*" gifts.
Therefore the ability for me to be able to provably send or receive cloaked transactions whilst using federation is important in order for us to be able to increase the use of our currency & wallet app in the related real world applications that we are building using without leaking private information.
At a second layer, I may not want to display the balance of my account at tondmc\*[ton.money](https://ton.money) but for reasons of pre-authorisation I may need to show that I have sufficient funds in the account. My suspicion is that this newly released code will provide a shortcut to creating privately linked accounts which hold balances (think of the main account as a current/checking account and the side pocket accounts as savings accounts).
Now we can build an application which requests a pre-authorisation for X amount, which the main account can confirm it controls (and can block) using zero-knowledge-proofs and those transactions can subsequently be constructed and settled privately as explained above.
Not sure if that makes any sense, will go have another cup.
The point is to find a way to have (privately) linked accounts with balances, which balances can be proven and spent but which are not shown as part of the main balance of the very public federated account address.
For example, I don't want to show a balance greater than 10,000 TON or 10,000 XLM at any time to reduce my kidnap risk.
Any txn that takes my balance above those limits automatically gets split amongst sub-accounts used Cloaked txns so that nobody can see the true balance underlying dmc\*[ton.money](https://ton.money) which only look looks like it has 10,000 of each asset.
When I want to spend a balance, we can include an option to spend from the federated account or as cloaked transaction(s) from the cloaked savings account(s).
Our app will be used in the real world for real transactions in the not too distant future so the sooner we address the privacy issues the better and these newly announced open source tools seem like a better way to handle these problems at a network level rather than than via a home-rolled proprietary solution.