Hi guys,
The bitcoin ecosystem is well established. As Zcash is a fork of Bitcoin, can we expect projects like https://bitcore.io/ to easily integrate and work?
I’m launching a product that uses Bitcore to interact with the Bitcoin network, and I wondered if we could use it for Zcash.
Thanks,
Richard
I plan on looking into this over the next few months because I personally like bitcore
Please keep me informed about what we Zcash engineers can do to help with this. What we’ve done so far is to base Zcashd on Bitcoind and to make the RPC-API to Zcashd be a superset of the RPC-API to Bitcoind. If I understand correctly (which is questionable) Bitcoin doesn’t use the RPC-API at all, so someone would need to write node.js bindings directly for Zcashd, right?
One thing that we could potentially do to help with that effort would be to set up continuous integration, so that if changes to Bitcore or changes to Zcashd broke that integration, we would find out soon and we would know exactly which patch caused it to go from working to failing.
bitcore-node binds to libbitcoind via these files.
Is there a way to run zcashd as bitcoind or is there something different and important added (from a high-level perspective) to zcashd.
Of course I’d compile zcashd as a library for that… (in this case libzcashd)
/don’t have exact idea about Zcash’s RPC-API or Bitcon’s API… talking just about .h exports from that library which is the way I think bitcore-node operates with libbitcoind
Zcash’s binaries such as zcashd and zcash-cli behave identically to Bitcoin currently, with only added functionality. The protocol itself has some changes as well, but is mostly reverse compatible.
So basically if I create a libzcashd instead of zcashd and switch it with libbitcoind in the bitcore-node’s library then it should work the same?
Wouldn’t it need some changes? E.g. in generation of addresses for livenet / testnet… Different structure of data in transactions? (Dunno)
The question is - “Is there a fair chance that it will work as a drop-in replacement?”
A fair chance, yes. There’s little reason to remove functions from the libbitcoind/libzcash API, and I’m not aware of cases where we have done that, although I can’t guarantee that we won’t. If you try it and it doesn’t work, please file a ticket.
(Note that Zcash Core is compiled with a C++11 compiler, which might affect ABI compatibility, as opposed to the API.)
Looking at that code, I can’t immediately see anything that wouldn’t work if it is recompiled/relinked. Note that it uses CBlock and CTransaction directly which will have changed size and layout.
Mhm, those changed sizes will probably cause some issues…
ABI shouldn’t be a problem I’ll just have to use same compiler for that. The problem isn’t C++11 itselt but standard libraries (AFAIK)… Will share results once I’ll attempt to put it together.
Will Zcash support multisig? It’s a feature we’re using, and if we implemented Zcash it would be essential…
First, big picture:
We haven’t ever considered any kind of compatability or stability at the library interface layer (rather than RPC interface), and I don’t think we can promise that. However, this is one of the many things we’d love to have but simply don’t have resources for. In other words, we would be helpful with any community effort, but can’t do this ourselves.
Second, about bitcore specifically:
Hi, I’m unfamiliar with bitcore (and also with npm packaging), so I explored around bitcore and bitcore-lib a bit, and I don’t see how it links to libbitcoin. Furthermore, even if the library bindings were updates, it appears like there would need to be changes to the js to match our changes to consensus rules. We need solid documentation for those changes to consensus from Bitcoin anyway, so this would be a perfect opportunity for bitcore-zcash development to review/refine our consensus documentation.
Just a quick glance at the README which specifies there’s a full node implementation, and then seeing block fields re-ified in JS, such as in blockheader.js suggests, to me, that a fair amount of the bitcoin protocol is implemented in JS rather than abstracted away by libbitcoin. (I could be reading this wrong, I only spent ~5 minutes.)
Whether or not zcash support requires libbitcoin/libzcash wrapper updates or JS updates, either approach would be very valuable for the Zcash ecosystem. A pure JS protocol implementation would be especially valuable by dint of being a separate protocol implementation.
So, if anyone works on this, please let us know and we’ll be as helpful as we can afford!
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.
Yes, I would recommend that if you fork or submit patches to bitcore, it would be better to treat these types as opaque and being liable to change, i.e. assume that we don’t make any guarantee of ABI stability for their size or layout. Referring to them by pointers would be less likely to break.
Do you know if anything progressed with this - is Zcash likely to support Bitcore.io anytime soon? The comments above suggest it should be straightforward
is there any npm like bitcore-lib / bitcore-explorer same for zcash