While I am overall supportive of adding Zcash support to 3rd-party payment processors, especially open source ones, the proposal lacks the depth and plans for integrating with BTCPay Server. I would like to discuss the following issues with the proposal:
In the technical approach, “It is shielded. A block explorer cannot see the merchant’s transactions” should not be a problem as the viewing keys can be generated to verify incoming z2z payment and then forwarded to merchant’s destination address or held on the viewing key address it self. And memos are for Z-address only, not T-address. T-addrs payments can be verified via a block explorer.
For the block scanner, maybe you can leverage the Zcash Block Explorer which is being funded currently. And leverage ZIP-321 for Payment Request URIs ZIP 321: Payment Request URIs
The complexity could be limited to T-address setup and Z-address viewing key setup, which the new pools should share.
BTCPay Server does not officially support “altcoins” and can remove “altcoin” implementation if it is not maintained. Is it possible to test the waters by connecting with BTCPay Server devs and checking their interest in onboarding a Zcash implementation?
Note: BTCPay developers do not implement alternative coins on request. Adding a new coin explicitly depends on the community and developers of those coins. Furthermore, BTCPay developers do not spend excessive time testing nor maintaining the altcoins. If you’re submitting a PR for a new coin, make sure that your image works. If the altcoin integration is not actively maintained it will be removed from BTCPay.
Downsides of the project need to be expanded to the level of ongoing support post implementation, have you evaluated how was the experience of Ethereum & Monero integrations?
This proposal is heavily tied to BTCPay Server, what is the backup if it is not integrated? What are the alternatives? Can the deliverable be run as a standalone ZcashPay Server instead?
It would be better to see precise estimation for a task of this size, as for gauging interest, the forum is the best to discuss it.
I’m referencing the BtcPay architecture which uses its own block explorer to bridge between the fullnode and the payment server. I know that you can use the ivk to decode incoming transactions but in the context of the existing explorer, it is not available.
The block scanner itself is not a concern. We have libraries that make this trivial to implement. The issue is that it has to fit with the existing chain. This explorer is the bridge with the payment server. It must have the same API and it must be able to run along with the other block explorer.
I’m not sure what you mean by that. If you are talking about only supporting t-addresses for refunds, that could be considered. Also I don’t see why the new pools would have the same z-addr setup but maybe they do. Sprout and sapling don’t have the same address format.
Their position is well known. In short “They welcome new coins but don’t expect them to do the work for you”.
As a platform, it is understandable that they want to check the quality of the code they associate with. This is true for any framework to be honest.
Even if the Monero or Ethereum teams have decided to drop their support for btcpay server it doesn’t mean the same will happen to zcash. In this respect, I don’t see where
the downside is. In any case, as the integration is open sourced, there is an opportunity for another team to take over.
In the past, Anypay has taken a grant to add zcash but dropped it after a year. Now the community doesn’t get anything because the code isn’t available.
Before committing to this project, we’ll do a thorough analysis of the work required. If it is not cost effective, I will cancel (and refund). Though we won’t commit before having a good level of confidence. For example, at this point, I think that t-addr support should be doable at the minimum. This will allow people to pay in zcash privately as long as they use a z-addr themselves (z2t tx). Not as good as z2z or t2z but at least the customer privacy is protected.
To be clear, we will not attempt to build zcashpay server from scratch.
the cost will be greatly superior to what this proposal is about. Btcpay got a grant of 150k usd from Kraken - and more from other sponsors.
this cost is adequate considering the amount of work put into it. Accepting payment is one thing, doing all the accounting, regulation and auditing work is another. All this work is already done by btcpay, we shouldn’t redo it.
even if the above was met, I’m not sure businesses would want to deploy additional software and infrastructure just to support zcash.
Instead, if we say that they can have zcash payments (in addition to bitcoin) by flipping a switch, this is much better value proposition in my opinion.
Clearly, it is a lot of work. This is not the first time that a payment gateway has been suggested but it is still not available. I’m going to guess that the project difficulty is one factor.
I have done a certain level of research to gauge the feasibility of the integration: It’s hard and it’s made harder because we don’t have full control of the platform. But again, that’s true for any project. We can’t fork btcpay and plug it in because we need to have recognition from the btcpay foundation too. Otherwise merchants will not pick us up.
At this point, I’d like to know how much interest there is in proceeding further from the community and from ZOMG. If there is a lot, then we will start engaging the other team.
I think this is an important consideration in relation to UX. Enabling current (and future) users of BTCPay Server to simply accept ZEC with just a toggle would be the perfect Trojan horse for Zcash acceptance as a payment network.
It is also acceptable that the first iteration would only enable sending to a transparent address. However, if ZEC is indeed popular among BTCPay Server users then we can try to integrate shielded address. Ideally we want a fully shielded ZECPay Server in the future with ZUSD payment rails (if ECC decides to develop UDAs that is).
Hi @hanh, sorry for the delay in getting back to you. Contrary to what you may be thinking, the ZOMG actually likes this idea a fair bit. We cross-checked with some folks from the ECC and they are also keen on the idea, which is good news since they spend a lot of time thinking about getting ZEC out there in people’s hands/transactions.
However, as you point out, there are questions around the feasibility of this succeeding as designed, given the inherent limitations of the pieces you have to play wth.
Do you think this kind of breakdown for the project makes sense?
Milestone 1 - documentation of how the integration is going to work and the task graph that gets to a working product.
Milestone 2 - documented interfaces with stub implementations, etc.
Milestone 3 - successful integration into BTCPay Server.
At any stage above, we are both free to decide (mutually) that it may not be worthwhile carrying it out to the very end.