Whoops, I missed this before writing my reply about bitcore-lib’s js implementation. My point still stands about library interface compatibility: we didn’t make this a goal, so maintaining this wrapper will require a fork from bitcore-node (*) and may need to be updates with each of our pre-launch test releases. Meanwhile, we’d love to have this codebase working with the zcash network, so even though we can’t commit full-time dev support, we would make an effort to be helpful.
After the wrapper itself is updated, we’ve also changed some consensus rules in ways which may violate invariants within bitcore-node’s js code. One example is that a zcash CTransaction may have 0 inputs and 0 outputs, if it contains at least one PourDescription. In that case, funds are moving confidentially using the zeroknowledge proof system, and there are no standard “transparent” txin/txout elements.
Next, in order to ensure the node is enforcing full consensus, it would need to be aware of new fields and how to validate them, which includes validating the zeroknowledge proofs. The simplest way to make this work, I would guess is for us to export the right abstraction in libzcash for validating proofs.
Finally, if bitcore implementations need to send confidential transactions, they would also need to generate proofs, and again, the cleanest approach would be to add the right API to libzcash.
If it is useful to use a bitcore-based tool which can’t fully validate the zeroknowledge stuff and cannot do confidential transfers, those last two steps aren’t necessary. This might make sense for block explorers or tools doings “transparent” Bitcoin-script-only transactions, both with SPV-like security.
(*) I would advocate a fork of bitcore that can support either bitcoin or zcash. We also haven’t anticipated linking both libraries into the same binary, so that may require some more collaborative effort on the build/linking front. For example, we haven’t changed the library name or namespaces, AFAIK, so that would be the first step.