Grant Application: BTCPayServer Zcash Module Project Review

[machinesunmachine]

Hi @artkor , thanks for your questions. I know that this project is personally important to you! I’ve seen that you’ve contributed code to the BTCPayServer Zcash plugin in the past:

Upgrade BTCPayServer Zcash Plugin for 2.1

This is the very first draft of the document. I will add screenshots later. If you notice any errors or have any additions, please let me know.

So I’m sure you care just as much as we do about making sure that the plugin functions as well as possible.

My team was paid by Zcash in 2023 to do a review of the BTCPayServer Zcash module. Here’s the results of our analysis then, in the form of nine bullet points:

@machinesunmachine

• There’s no ZCash section in the wallets area in BTCPay. All other currencies have them as a way to review your wallet / incoming payments / match up invoices / etc. The current implementation shows the ZCash address for purchase.
• ZCash viewing key is essentially hard-coded into the docker compose file, instead of having a settings page in the admin area like all the other currencies.
• There does not appear to be support for multiple ZCash wallets, like with other currencies.
• No support for multiple stores (multiple stores must share the same wallet, as the ZCash plugin hard codes the wallet address into the container).
• There’s no setup process for ZCash wallets, like there is with other currencies (when creating a new store, other currencies ask you for wallet info and enable/disable currency support depending on how you provide it).
• The method documented by Hanh is either incomplete or out of date, and requires using Hanh’s custom containers and will not work (at least without modification) with non ZCash currencies. The method documented below includes replacement info / code that works with the most recent version of BTCPay and is compatible with other currencies.
• The processes below are the result of a lot of trial and error due to poor / missing / outright incorrect documentation on both the parts of BTCPay and the ZCash plugin. There is zero chance a user without significant IT/dev experience will be able to get things working without new docs / changes to the code.
• We were unable to find any functioning wallet that supports testnet, and so had to run a full zcashd node in order to get some testnet coins to run transactions through.
• Running a testnet node does not appear to work. There’s no official documentation for it, and although we did find a docker container by Hanh that is named as if it supports it, that container crashes immediately on startup. Since Hanh doesn’t mention it anywhere, we’re assuming it’s something else.

[link to original analysis]

It does seem that work has been done to correct these issues since then. @1337bytes reports:

This, and the other mentioned issues (other than the lack of multi-wallet/store support) have since been resolved.

[link to 1337bytes’s quote here]

We are proposing to be paid the exact same amount of money (adjusted for inflation) to perform the exact same review again, in order to confirm that the 2023 problems have been addressed.

@artkor

In particular, could you please clarify whether this work is intended to be a formal code audit, or whether it is not an audit at all but rather an advisory or architectural review focused on general feedback and recommendations?

I am uncertain as to why there is confusion regarding whether we are proposing an audit or a review.

The word ‘audit’ appears 0 times in our proposal:

The word ‘review’ appears 14 times:

@artkor

Additionally, could you explain how the proposed evaluation would account for constraints at the Zcash protocol level (and, more generally, any blockchain), including cases where certain features such as refunds are not natively supported/provided? How would this align with the architectural characteristics of BTCPayServer? For example, the use of view keys for merchant wallets does not introduce double-spend risks and does not pose a threat to either merchant or payer funds.

More broadly, while we understand how traditional banking payment processing works, those systems rely on trusted third parties. Blockchain-based systems intentionally impose constraints precisely because there are no intermediaries. During our discussion, I found it difficult to explain how we would act on recommendations such as implementing payment refunds, given that some of these constraints cannot be addressed at the application level.

I think there might be confusion here. See above for the nine bullet points we identified as problematic in our 2023 analysis of the Zcash module, which we propose to review again to confirm that everything (except for multi-wallet and multi-store support) has been corrected.

I know that the committee was supposed to take this proposal to a vote this morning, and has probably already voted now. It’s unfortunate that you did not post these questions any time earlier in the 11 days since your last comment, so that we could have had time to respond before the vote.