Comments on scoping doc

[AArnott]

From the scoping doc, a couple questions:

It reduces supply of ZEC by locking up staked ZEC

The doc doesn't talk at all about _un_locking ZEC. What is that process? Are there set timeframes the user must consent to in advance, or can the ZEC be unlocked at any time?

reduces required confirmations to a nice small number like 10.

Maybe out of scope for a scoping doc, but I'm curious what challenges exist to shrink this number even further. Re-orgs in excess of 10 blocks should be rare, so maybe that makes finality easier to achieve. But I wonder if we could get to finality within 2-3 blocks eventually.

Unsophisticated users (who understand little about crypto and do not use specialized tools) delegate ZEC and get rewards from their mobile wallet.

That sounds awesome. I'll be interested in learning what mobile wallet devs need to do, and what UX we'll need to add, to support this.

[zookoatshieldedlabs]

The doc doesn't talk at all about _un_locking ZEC. What is that process? Are there set timeframes the user must consent to in advance, or can the ZEC be unlocked at any time?

Yes, it's a good question, but I don't think it needs to be part of the scoping doc. I suppose we'll learn more about the options and trade-offs of that as we experiment with our prototypes. However, the stated motivation of locking up ZEC is still valid, even if users can unlock ZEC at any time, because staking generates demand for ZEC.

[arya2]

Why Hybrid Proof-of-Work/Proof-of-Stake?

• It reduces supply of ZEC by locking up staked ZEC and increases demand for ZEC by giving people something else to do with it. Both reducing supply and increasing demand put upward pressure on the price of ZEC. This is good because the price of ZEC is the fuel for the mission and attracts users.

This point makes sense for PoS, but doesn't explain the motivation for a hybrid PoW/PoS, I would actually interpret it as a motivation for pure PoS. A "Why Proof-of-Stake" subheading might be effective here, as well as some mention of the motivation for hybrid PoW/PoS over pure PoS.

It reduces supply of ZEC by locking up staked ZEC

I'm not sure that it necessarily does, those coins would be less liquid which could help lower the velocity of the supply (depending on how long staked ZEC would be locked before it can be unstaked), but I'd be skeptical of that having a substantial impact on the supply/demand balance relative to the impact of reducing energy costs required to maintain the chain (that are currently effectively paid for by all ZEC holders), and offering a way of at least partially avoiding dilution/inflation when ZEC is issued via block subsidies.

I think if we want to keep this point, we should make it conditional on the duration that staked ZEC would have to remain locked, and should mention it after noting that it partially compensates ZEC holders for inflation (if we agree that that'll probably have a bigger impact).

something else to do with it.

I would be more specific here and say that it gives ZEC holders a way to partially avoid inflation as new ZEC is issued via block subsidies.

• It adds finality, which protects users from being robbed (with hybrid protection), reduces deposit times at CEXes and other services, and enables bridges.

I would say it enables finality, or I would change the header to be more specifically about Crosslink or Trailing Finality.

• It lays the foundation for future improvements, such as cross-chain interop and scalability.

If I understand correctly, it's the finality that enables cross-chain interop, so I would mention that in the point above (though I think it's already covered by "enables bridges")

UX goals

....

• Other services that require finality, such as cross-chain bridges, are willing to rely on Zcash’s finality.

This point doesn't seem like it would directly affect the UX on its own, I think it's enough to mention that finality would enable bridges in the motivation section, though it seems very useful so I would elaborate on why that's useful in the motivation section.

• Unsophisticated users (who understand little about crypto and do not use specialized tools) delegate ZEC and get rewards from their mobile wallet.

I think it would be better to say that it makes contributing to mining/appending blocks onto the chain and receiving block rewards easier and more accessible for everyone (since it would make it easier for even the most technically proficient users, and technical proficiency isn't currently the only barrier there).

Requirements

• Zcash transactions come with a kind of finality which protects the users as much as possible against all possible attacks, and is sufficient for services such as cross-chain bridges and centralized exchanges.

Zcash transactions come with a kind of finality

I think we could call this strong or deterministic finality?

which protects the users as much as possible against all possible attacks

This seems too broad, I would think it makes some kinds of attacks a little easier, could we say that it offers greater protection rather than the maximum possible degree of protection?

Trade-offs

Goals which we currently believe are not safely achievable in this first deployment without losing some of the above goals and requirements:

• Improving Zcash's bandwidth (number of transactions per time) or latency (time for a transaction).
• Deploying cross-chain interoperation such as the Inter-Blockchain Communication protocol (IBC) or Cross-Chain Interoperability Protocol (CCIP).

Specifying what the trade-offs are here could be useful, I expect that pursuing these goals would be at the expense of deploying some version of Crosslink as soon as possible.

• Improving Zcash's bandwidth

"Throughput" might be the more conventional term here.