Implementing Z-Addr in Bisq DEX (Zcash future plans)

3rd Party Applications
#1

Hi,

I can’t help but notice that although having all these privacy features are great, it defeats the purpose if the main way people are getting ZCash is through centralized exchanges that obligatorily have KYC.

Looking around for Decentralized Exchanges that are open source and Peer-to-Peer, I haven’t found any that transact ZCash Z-Addr.

The closest is Bisq, which transacts t-Addr but still doesn’t support z-Addr. Interestingly Bisq works with Monero (XMR) which are private by default. They use the private transaction key provided by the XMR sender to confirm the transaction. (More info https://bisq.wiki/Trading_Monero#Auto-confirming_trades )

So the question is, using this or similar methods, would it be possible to securely and reliably transact Z-Addr through DEX like Bisq?

and, Are you guys collaborating with any DEX to make fully shielded trades happen?

thanks,

#2

One thought is that if you’re coming in from bitcoin or ethereum you’re probably leaking enough privacy data in that moment that the move to a zcash t address, and then a quick move to shielded, doesn’t increase your exposure to privacy leaks.

It’s confusing but I’m pretty sure this is true, if that helps make Bisq more useful to you right now!

If you’re coming from another privacy coin like monero, the question is then how much the DEX leaks. The situation is probably the same!

This isn’t to say that z address support isn’t desirable! It totally is. But just in case this perspective is helpful I wanted to share it!

2 Likes
#3

And, by the way, the Bisq developers are welcome to apply for Zcash Open Major Grants.

3 Likes
#4

I think this would be a good use-case for payment disclosures, where the sender of a transaction can disclose a specific output to a third party (without revealing anything about the rest of the transaction, or the sender’s own funds or other transactions). I’ve been meaning for a while to write up a ZIP for Sapling payment disclosures; this is a good motivator!

4 Likes
Leap frogging zaddr
#5

I see that perspective. Now from a usability standpoint, the less steps and less expenses (transaction fees) spent the easier it will be for Z-Addr adoption.

Best option) Trader sends from a Z-Addr and I receive at a Z-Addr. Job done.

Second option) Trader sends from a t-Addr and I receive at a T-Addr, then I’d have to pay transaction fees to send portions of the total amount over time to Z-Addr. Since, sending the full amount all at once to a Z-Addr compromises the total balance that the Z-Addr has, so its bad practice from what I read somewhere in the Zcash site. Most people might not want to put in the extra work to do this.

From my understanding the DEX only shares data is needed to conduct the transaction and only with the trading partner.

"As for the trading process, your payment information is stored locally on your machine, and only your trading partner (and your mediator or arbitrator, in case of a dispute) can ever see it. All data exchanged between users is encrypted and signed.

To transmit data from one user to another, Bisq uses a P2P network built on top of Tor, which provides a high degree of anonymity. " ( link to full source https://bisq.network/faq/#how-privacy-protected )

#7

Decided I’ll write this up today :grinning_face_with_smiling_eyes:

5 Likes
#8

Is this true? It could be, but I’m not sure if it is!

Also transaction fees are very low for the time being, so fees alone aren’t that much of a problem.

@str4d so you’d disclose details of the payment to the DEX?

1 Like
#9

I haven’t actually looked at how Bisq etc. work, but for their auto-confirming use-case, it’s probably a requirement that something can confirm that a transaction went to the correct address with the correct amount. A payment disclosure would enable disclosing the minimum information required for that: a single output’s recipient address, value, and memo field.

It would of course be preferable to enable completely private exchanges of funds; this is something that UDAs / wrapped assets in Zcash could enable. But for an existing DEX where details are inherently transparent, I think using payment disclosure would most closely match what gets disclosed to what needs to be disclosed.

2 Likes
#10

Having used Bisq quite a bit in recent years, and having looked into it in some depth, I’ll add some perspective here.

Bisq is pretty good from a privacy perspective pretty much everything is handled via onion services, and while you have on-chain transactions to worry about privacy-wise, adding z-addresses would do quite a bit to address seller/buyer privacy (especially in the successful-contract case)

As I understand it, unless something has changed in recent weeks/months most of the actual confirmation of non-Bitcoin transactions in Bisq is done manually by the peers. Verified confirmation only occurs during the dispute portion of the protocol where arbitrator need to make a determination as to whether a transaction actually took place.

To that end, I believe that stand alone payment disclosures would satisfy the criteria necessary for Bisq to be able to include shielded zcash as an option. (see Bisq Monero trading wiki: https://bisq.wiki/Trading_Monero for details on how the process works for Monero).

(To that end, as a ZOMG committee member, I’ll throw out that I would be very interested to see proposals contributing to this flow - both from Bisq, and in getting payment disclosures implemented in wallets etc.)

5 Likes
#11

Hi all,
happy to see that discussion and interest.
I am not very familiar with ZCash features how to proof the transfer from/to z addresses. For Monero there is the tx key and with that it is possible to verify the transfer, which is required in case of a dispute so that the mediator can check if the transfer was made or not. The auto-confirm feature we just added a few months ago is only for that XMR feature, so the release of the BTC from the XMR receiver is done automatically and the user do not need to click manually “payment received”. This speeds up trades. Such a feature would not be required initially, in fact its probably not even wanted as it would require trusted Bisq contributors to run such infrastructure nodes and that comes with costs and need to be justified by the trade volume (which is in XMR justified but most other altcoins have much lower trade volume).

As many OS projects we are short on dev resources, so if any dev from here want to work on that it would go faster for sure. Otherwise best is to make a very clear description what is needed as a Bisq proposal at https://github.com/bisq-network/proposals/issues and then hopefully some dev pick it up and implements it. In the best case if there is a tool to verify the z tx, it could be implemented quite easily.
But some complications might arise from how it should be supported to mix z and t txs? Some users might not care so mixing it would work, but others (most?) would care, so we would have basically 2 diff. coins, but that partitions the market… so all those considerations should be in the proposal…

3 Likes
Bittrex delisting zec, monero and dash. any ideas?
#12

From your description I believe viewing keys & selective payment disclosure for shielded transactions could make this best case a reality.

but confirmation from others on here is needed

3 Likes
#13

Regarding privacy on Bisq:

One side is always BTC, so we inherit all the on-chain privacy issues of Bitcoin.

One can get full privacy with enough care and avoiding mixing fiat trades with altcoin trades. Most fiat payment methods leak real life ID to the trade peer (e.g. required full name for a bank transfer), so you have to be aware that you are not anonymous to at least that person. So if one trades both fiat and altcoins in the same app there are several areas where one leaks over the identity potentially leaked at the fiat side to the altcoin side. Beside the on-chain privacy issue on Bitcoin (which can be avoided if every trade is isolated and a CoinJoin made in between) there are a few other issues as the onion address stays the same and the signature and encryption key as well. Those keys form then a kind of global identity and can link offers and trades. There are plans to fix that but creating for each offer and trade a new onion address will have it resource limitations, so there is no perfect solution known yet for that.

So how to get full privacy?

  • Use a dedicated Bisq app for each trade
  • Fund the wallet from CoinJoined funds
  • Once trade is completed send BTC funds to a CJ again
  • For next trade use a fresh data directory so no keys/onions are leaking from first trade/offer to next
  • Know how to avoid privacy loss on the altcoin side

One can run multiple Bisq apps with custom app names, all is isolated in a dedicated data directory.

I assume for most users such a setup comes with too much inconvenience, time delay and miner fee costs. So if privacy is already weakened on the BTC blockchain side, all the rest has to be seen in relation to that. Also as the Fiat on/off ramp is core use case and mission of Bisq and privacy is inherently weakened by the involvement of banks or payment processors all the rest has to be seen under that context as well. There are some more private payment forms like Face to Face but that has very low volume.

To trade only altcoins (which do not have traces from KYC exchanges) and not doing a fresh setup for each trade might leak that one entity has done those trades but as long that cluster is not connected to a real life entity it has less relevance.

Beside all that, Bisq is not audited in depth from security/privacy researchers (though we got some medium light audits) so there might be some technical issue beside the known ones and the conceptual ones (fiat/bank transfer).

2 Likes
#14

Thank you for doing this, @str4d!

Sapling Payment Disclosures would also enable Amoveo’s DEX:

Perhaps ECC could prioritise implementation? :slight_smile:

1 Like