Track Blossom #42
Assignees
Labels
Comments
ghost
added
the
|
Moved to Projects |
|
Final https://z.cash/blog/final-blossom-goals/ Technical Debt identified https://github.com/zcash/zcash/labels/good%20first%20issue |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Zcash plan to have Blossom activate approximately around October 28th, 2019 (one year after Sapling activation).
We need to understand the impact, technical and business risks of adopting or choosing not to adopt.
Here’s the current set of feature goals Zero will be looking into for Blossom.
Transaction Confirmation Usability and Security Improvements
Github: zcash #3674
What is it? Improve usability and security of fees and confirmations while accounting for growing transaction volume, demand spikes, and transaction-based DOS scenarios.
Who does this affect? Transaction senders and receivers.
Why is this a goal? We cannot prevent demand shocks or growth approaching scalability limits, but we can and should help users understand what is happening and help them protect themselves.
Light Client Protocol Dovetailing
Github: zcash #3675
What is it? Alter the base consensus protocol to reinforce light client support.
Who does this affect? (Future potential) Zcash light client end users.
Why is this a goal? We anticipate more light client users than full node users in the future (all other things being equal), so any streamlining of this use case in the base consensus protocol is potentially valuable.
Retire Sprout Addresses
Github: zcash #3677
What is it? Turn off all support for Sprout addresses and funds stored at those addresses except the ability to transfer funds out of those addresses.
Who does this affect? Sprout users.
Why is this a goal? This removes technical debt and simplifies the ecosystem moving forward. Additionally it prompts usage of the Sprout→Sapling turnstile
Rollback Protection and Hardening
Github: zcash #3678
What is it? Add protections against rollbacks larger than some predetermined length.
Who does this affect? All transactors, especially multi-user service providers.
Why is this a goal? All users would reject a large enough rollback. Some users would reject a smaller rollback. By codifying a well-known standard for the maximum acceptable rollback depth, we reduce economic uncertainty across the ecosystem. Other consensus features as well as external products and services can begin relying on this design decision. (Nuance: this does not answer the question of what people should or will do in the event of such a rollback. It simply ensures that no one will naively or accidentally proceed in a business-as-usual manner in this event thus protecting them from harm.)
Custodian Reinforcement
Github: zcash #3679
What is it? This includes a variety of potential features that can potentially protect typical end-users as well as specialized custodians. This may include recipient address verification, “vault functionality”, “I Got Burgled Button”, transaction cancellation, or transfer rate limiting functionality.
Who does this affect? All users.
Who does this affect? All users.
Why is this a goal? A substantial weakness of cryptocurrencies is how difficult self-custody is for wide user bases. By introducing protocol features that can help users protect themselves against theft or loss and/or enable custodian providers to reduce their operational risk, we aim to make Zcash safer for a larger user base.
The text was updated successfully, but these errors were encountered: