An interesting project to watch involving LN is “CHIPS,” which is being worked on by the team that created Komodo
You may be interested in delegated detection, a feature that isn’t going to be in Sapling but is nonetheless quite interesting.
This is great. Let me send you what I have as soon as I get home tonight.
Even if there are rough edges, there’s an opportunity to turn this into a self-hosted solution for individuals, where a mobile wallet connects to the privately run service (at home, on a VPS etc) to generate proofs.
I haven’t thought about this for transparent transactions. As far as shielded transactions go:
- You can’t have a child transaction in the same block as a parent transaction, because the child’s anchor needs to include the parent’s note commitments, and that only happens after blocks are mined.
- Within a transaction, you can have multiple proofs chained together (later anchors derived from earlier commitments). However, the proofs themselves don’t depend on the validity of other proofs in the transaction (the anchor is sufficient via the Merkle path), and thus can be validated completely independently. But this would only give you a speed-up linear in the number of cores.
A more promising verification speed-up is probabilistic batch verification, where you could run a single slower validation for all proofs in a block, which would speed up overall block validation for blocks with many shielded Sprout transactions. We have an implementation of this (#2106), but it needs further development and testing before we would consider merging it, and we would likely run it in addition to regular verification.
Since you mentioned btcd, what do you think of building a Zcash node on top of btcsuite? Is it interesting/worthwhile/too difficult?
Another question, have you looked at atomicswap project? Would it be possible to add Zcash support and bridge Zcash with currently supported networks? And how does it compare with zbxcat?
The AMA is technically over now. Thanks everyone for the questions and to the engineers for answering! ![]()
I’ll start with the main drawback: when used for the Sprout circuit, you reveal your spending keys to the proving service. This is obviously not an issue if you are sending from a t-address (since the spending keys are just dummy values), and thus could be used to do mobile payments to z-addresses, but it severely limits the use-cases for sending from a z-address. There are still use-cases though! The most obvious one to me is exchanges - when they want to make a shielded payment, they could spin up a temporary powerful node, use it for payment offloading, and then shut it down. In that situation, it doesn’t matter that the spending keys are sent to the proving service, because both the client and proving service are controlled by the same entity.
In Sapling, you will be able to do payment offloading without revealing your spending keys. As @nathan-at-least referred to, hardware wallets are the most likely user of this.
Re: btcsuite, we haven’t written any Zcash libraries in Go, although @str4d and I took a stab at implementing some of the primitives. It’s definitely interesting and worthwhile, we started that due to interest from Open Bazaar, but haven’t had time to finish.
Looks possible to add Zcash to atomicswap, it’s for exchange between Decred and other currencies? Functionality looks similar. zbxcat is currently just a standalone cli tool. Would be nice if someone wanted to add Zcash to atomicswap utility ![]()
When you do that, doesn’t that mean the people that are supposed to be sending money to you have to perform a rather computationally expensive operation? Wouldn’t it be better / more polite to provide them each with a different t_addr and then do your own t-to-z transaction?
Wouldn’t it be better / more polite to provide them each with a different t_addr and then do your own t-to-z transaction?
Sure, it’s probably practically better today to not require people to use 1.7GB of RAM for 60 seconds or more to send you money (sapling soon™). But, if the hypothetical electrum zcash port I was asking about doesn’t support z-addrs, then you still couldn’t do that second t-to-z part without access to a full wallet. As such, I feel like a zcash wallet without z-addr support doesn’t really feel like a zcash wallet at all.
I’m going to close this thread. Feel free to expand discussion from topics discussed here into new threads!