Oh good point. I’m not sure if just Sapling-with-payment-offloading would be sufficient, without this additional “current balances in blocks” feature…
1 Like
Actually, I had planned on building this - A z-cash service that indexes everything electrum style + the remote proving service. This will allow a web-based client to use z-addresses easily by offloading everything to the service.
I might have to rethink it a bit based on what I’ve learned today, but I think this is still a promising idea.
5 Likes
can you explain what Electrum does basically? It’s not just trusting some server with the balances?
2 Likes
I read some of the Sapling documents today and it mentioned Proof of Stake.
… Care to elaborate on that?
1 Like
So this latest blog post is really exciting! Zcash for Everyone - Electric Coin Company
In the beyond Sapling section it says:
Possibilities include scalability improvements to allow practically unlimited numbers of transactions
Is this referring to BOLT or are there other proposals out there?
4 Likes
Sapling addresses will contain a cryptographic mechanism for this which is discussed here. We haven’t figured out the exact UX yet, though, so I can’t guarantee when or how you will be able to interact with this feature.
3 Likes
There is no plan to encorporate PoS in Sapling. That is something we are thinking of for the further future. First we want to see how well it does in other cryptocurrencies, e.g. Ethereum and Cardano
3 Likes
Yes i am aware it wont be in sapling, but i didnt realize you had thought at all about a change like that.
Any chance you will talk more on it?
2 Likes
The Electrum server is a caching service that indexes UTXOs by public addresses, so it can answer API calls like “getBalance(any_bitcoin_address)” and “getUTXOset(any_bitcoin_address)” without rescaning the entire blockchain.
It is used by the Electrum Client to show the UI. The actual transactions on the client use the regular SPV stuff and get the SPV-level security.
4 Likes
I think it’s hard to quantify how much harder. The two main reasons it’s hard are performance issues of shielded payments, and the fact that transparent addresses are almost identical to bitcoin, so if you have experience with that adding Zcash t-addrs is easier.
2 Likes
It’s very speculative at the moment, and like I said, we need to see first if PoS works well in practice. Of course it would be awesome to avoid the heavy energy consumption of PoW.
3 Likes
Performance improvements are important. Have you guys considered disallowing txs with parents in the same mined block so you can do parallel shared-nothing tx validation, or is this not compatible with the way z-addresses are implemented?
2 Likes
This is pretty cool. Thanks for sharing!
1 Like
There are lots of possibilities! Not sure if any of them can really achieve “practically unlimited”. 
Evaluating which one offers the best balance of consistent-low-latency, finality, capacity, practicality, reliability, assurance, simplicity, decentralization, etc. is the next step.
Possibilities include using new ZKP techniques such as zk-STARKS to compress large numbers of transactions (e.g. 1M transactions) into a single proof (e.g. a 1-MB string), and then recursively compress a million such proofs into a 1-MB string, and then have global network consensus on that. This would yield a capacity of up to a trillion transactions per consensus-period. But there are a whole lot of questions about whether it would be possible at all or whether it would come with other trade-offs that are unacceptable.
Other possibilities include Bitcoin-NG or SPECTRE, some new invention that I haven’t understood yet (like Algorand), or “copy whatever Casper/PoS/sharding protocol Ethereum has launched, as long as it works”.
8 Likes
In order to achieve this for shielded addresses (for which balances and other details are encrypted) you would need to forfeit a viewing key to the remote server, making it getBalance(viewing_key). In a UTXO-based model the server must perform some kind of “scanning” over the blockchain using this viewing key.
The authority to modify (i.e. increment) the balance of an address is given to anyone who has that address, as they are authorized to make payments to it. I don’t immediately see how you can avoid the scanning without breaking some privacy guarantee. (Maybe some kind of homomorphic encryption idea would help here.)
4 Likes
We have studied something similar: an online/offline split-node setup for making shielded transactions (#2542). My goal for this is to be able to have an offline node (or a Qubes VM with no networking) contain the keys, and generate transactions interactively using the online node (moving data in between via USB drives or clipboard buffers). I was only imagining this to be for specific spending operations, but you could probably extend this more generally to the entire node…
3 Likes
P.S. Oh yeah, and like you originally asked, Lightning Network / BOLT is also a good possibility. The Lightning Network folks have just performed their 1.0 spec and multiple implementation interop tests, so that’s very encouraging. On the other hand, I haven’t seen any evidence of UX testing yet, like whether users will find the workflow and economics of Lightning Network off-putting. Fortunately, others are likely to run those experiments for us within the next few months so we can learn from them. Lightning Network and BOLT are nicely decoupled from the underlying consensus protocol, so in principle the Zcash dev team — or someone else — can implement and deploy Lightning Network atop Zcash even while simultaneously upgrading the Zcash network/consensus protocol.
5 Likes
Regarding BIP-44-like derivation, we have a draft design for this (not yet written up) which would enable derivation of multiple z-keys (across different circuits) from a single master key, rooted in the same seed as regular BIP-32 HD wallets. I would be interested to see what you have come up with, to see if our design fits your use cases, and where the interesting differences are! 
4 Likes
Hey this was super fun! Thanks for all the great questions, and I’m excited to see what happens next, such as with Alexey’s Cosmos hub. Happy holidays everybody! 
ⓩ
8 Likes
Hmm, that’s a good point. I hadn’t thought of this.
So, for this model to work the user has to hand their viewing_key to the service. Not ideal.
I wonder if there’s a way the service can stream all shielded transactions to the user and the user can then check them against their viewing key. Probably too much data/processing.
I wonder if the user can send the service multiple viewkeys to hide theirs? But the server will be able to figure out the users key because all the matched transactions will correspond to only one key. I wonder if the client can generate “decoy” viewkeys.
I need to think about this. Thanks for your help
1 Like