Onboarding content updates 12.2021

[ta-lind]

Follow-up to: #246; #247; #248; #261

Preview + svgs: https://www.figma.com/file/dEqHmYVc2uawBfdOkmKyUi/UX-Onboarding-Storyboards?node-id=714%3A401
decred - onboarding content - 1221.zip

I'm consolidating the recent work on the onboarding content to this issue for coordination. Initially we aimed to create simple and short animated slides for each of these since motion goes a much longer way on helping to communicate these concepts.

However the motion part isn't delivered (at least no during this proposal period I guess). Since we've got some quite decent concepts worked out along side most of the visual assets, we've shifted the work into just solving this content with static images for the time being. These did require some workarounds to make better sense of, so myself and Jani are still wrapping up the last items.

Regarding implementation @bgptr I think the https://react-spring.io/hooks/use-transition#toggle-between-components you suggested should work quite well.

1. I've marked the slides which would contain several images looping in the artboards as "slide1-1" "slide1-2" etc. I'm not sure how well looping more than 2-3 imgs would work, as that's the case for some of the ticket lifecycle ones, so will try to shorten them to 3 imgs where possible or break into several slides.
2. The image dimensions are 580x400(2x) px - this probably differs from the placeholder img from the past UI specs which had a square ratio.
3. Planning to still create thumbnail images which are square for each one.
4. Ticket lifecycle + consensus voting will be added next.

Regarding the copy I would appreciate any help on validating and writing – @jzbz @xaur
I've added the recent versions to Figma. This is mostly with draft or existing copy, as well some with just references on what they would be about. Ideally the copy can contain links to docs or relevant source for further reading as well.

[xaur]

@linnutee Is there a plaintext version of the copy I could review?

[ta-lind]

@xaur - copied over the current state of things from Figma.

# LN

s1 
## Backup data is needed in addition to seed key
Understand that backup data is needed in addition to your wallet seed to recover all LN funds

s2
## LN is a 2nd layer network on top of the DCR blockchain, designed to facilitate micropayments more efficiently. 
While the on-chain transactions require an average of 5 minutes for block confirmation, Lightning transactions are routed near-instantaneously. Lightning Network is made up of individual payment channels created by various Decred users. These form a network of lightning nodes that can route transactions among themselves.


s3
## Its preferred to keep wallet online most of the time
LN has been implemented assuming that wallets (nodes) are online most of the time. 

Episodic wallets, meaning ones that remain online for very small amounts of time, may see degraded ability to send and receive payments.


s4
## Episodic wallets should use watchtower service for safety
Understand that a malicious counter-party may steal funds from episodic wallets unless they use a watchtower service.


s5
## Sending and Reciving amounts are limited to what is available in your published channels
A channel is opened by locking up an amount of DCR into an on-chain ‘funding transaction’. This automatically creates a 2 of 2 multi-sig wallet on the Decred network, with each user receiving one of the keys (usually requires up to 6 confirmations (blocks) to be available.).

Off-chain LN transactions can be made with confidence of on-blockchain enforceability, when a channel is closed it’s balance will then be recorded to the Decred blockchain.


s6
## Minimize risk by using a seperate wallet for LN
The wallet account used for LN operations remains unlocked while the LN wallet is running. Funds from that account are at risk from anyone with remote or physical access to your computer. It is recommended to use a seperate account (or better yet, a separate wallet) with small amount of funds to minimize the risk.



# Decred Intro

s1
## Why was Decred created?
Decred was created to address a crisis of governance (link) in Bitcoin. Decred has built a hybrid Proof-of-Work/Proof-of-Stake system, which puts Decred currency holders in charge of its governance to ensure order and faireness in decision-making and dispute resolving processes.


s2
## Governance systems empower its community 
Decred's consensus system that uses hybrid PoW/PoS, where PoS can override PoW, is an answer to Bitcoin's problem where PoW miners hold a monopoly on consensus enforcement via their exclusive write access to the ledger.



# Consensus Code ——— Probs makes sense to merge with “Decred Intro”

s1
## Focus on Consensus Code
While many cryptocurrency projects view consensus code as a means to an end or something delicate with which you must take great care, Decred takes the view that this code is the real engine that drives all cryptocurrencies.

Due to the delicate nature of this code in a cryptocurrency project, exceptional measures must be undertaken to ensure that it behaves as planned under all possible scenarios.



# Hybrid PoW/PoS

s1
## 1 CPU, 1 Vote – Proof-of-Work

Proof-of-Work (PoW) solved the double spending problem, being a primer for cryptocurrencies. From its protocol consensus perspective, the lack of formal decision-making procedures has a history of controversies and chain splits. PoW miners hold a monopoly on consensus enforcement via their exclusive write access to the ledger.

s2
## 1 Coin, 1 Vote – Proof-Of Stake

Proof-of-Stake (PoS) developed a better alignment of interests, and computational efficiencies, though resulted in different shortcomings, most notably the “nothing-at-stake problem” and inherent risks of resulting in feudalism. 


s3
## Hybrid PoW/PoS - best of both worlds

Decred employs a combination of PoW and PoS to yield the best of both systems, mitigate their weaknesses. Whether an new rules upgrade, emergency, conflict, bug fix or new technology, Decred facilitates formal agreement, helping to avoid contentious hard forks and maintain a unified community during the process.




# Staking and Tickets

s1
## Tickets are created by time-locking coins

Decred holders can participate in the Staking (Proof-of-Stake) process by time-locking their coins (amounting to the ticket value) in exchange of tickets. 


s2
## Tickets have multiple functions — Missing copy

These tickets are used to vote on miners’ Proof-of-Work in order to validate changes to the Decred blockchain and on the governance proposals within the Politeia system.

Opt-in governance via time-locking coins.

Applies to:
creating new blocks
consensus changes
project management


s3
## Rewards

Staking your funds also generates semi-passive returns with relatively low risk, as each voted ticket receives part of the block reward (link).




# Core Functions of Staking ——— no copy, refer to draft sketches

s1
## New block creation
As you might understand already, staking and the tickets have three core functions. Firstly cover block creation -> ensuring good miner behaviour.

Stakeholders maintain direct power over the miners, ensuring good behaviour through aligned incentives. Anyone can be a stakeholder,  including miners.


s2
## Consensus Changes
New consensus rules ... forming agreement  from both miners as well stakers  

cover number of successful and smooth consensus change votes since 2017?



s3 - 4
## Treasury and Project Management ——— needs copy, refer to slide splitting, this could ideally be around covering both approval and denying votes

Decred community of stakeholders votes to fund contractors to complete projects ... e.g. dev, marketing, design,

Politeia proposals, CMS
Bad actors side




# Ticket Lifecycle ——— incomplete copy, synth. off current ticket lifecycle copy

s1 
## Proof-of-Stake, Block Rewards

A basic introduction to Decred’s PoS rewards

Simple pictorial representation of the rewards accured hrough PoS.


s2
## Ticket goes through different states in their lifecycle

A basic introduction to Decred’s PoS.

Abstract grid of the key ticket states to be explored in the section. 

Frames the subject matter of onboarding piece.


s3 
##  Immature tickets
A basic runthrough of Immature ticket states.

A representation that shows the ticket surrounded by a vessel, volume that isolates the ticket from surrounding elements

This signifies that that tickets cannot be interacted with during the 21 hours of immaturity and are isolated from the actions of both holder and network.


s4 
## Live Tickets
A runthrough of live ticket states and the mempool

- Lottery
- Calendar average 28 day to vote
 - Maximum period 142 days
- Ticket transitions from immature to live


s5
## Voted Tickets
Upon succesfully voting, turn immature again for  256 blocks (~20 hrs) and

Then unlocks funds + block reward

“On average, 50% of tickets will be called to vote within 28 days.”

A run through of ticket expiration.

Stakey now resembles the form of an expired cheese with holes clearly visible as well as odour and files.


s6
## When Something Went Wrong
Combine expire + miss and getting revoked revoked

The average ticket age 28 days when called. Tickets are staked (locked up) for up to 142 days, at which point, a ticket expires if it has not been called, and the funds are returned to the wallet.
The ticket price is always refunded, no matter if your ticket votes, misses, or expires.




# Identity (Pi/CMS) ——— no copy, refer to draft sketches

s1 
## Back-up your ID
General ID functionality
will become more important than the login+password pair
Take good care of it or game over


s2 
## Identity and Proposals
In Politeia, proposals, comments, comment votes, and now also updates, are signed with identity's key. These messages can have high impact on decision making and spending, so these signatures might become more important.

———

s2 
## Identity and CMS
In CMS, identity is already used to sign invoices and comments, and possibly DCCs and DCC votes (not sure, need to check). In the future, I hope it will be also used to sign proposal owner's approval of billing against the proposal (and without such approval billing will not be allowed).


s3
## Submit invoices in time




# Consensus Voting ——— no copy, refer to draft sketches

s1
## Overview
A basic introduction to on-chain consensus.

Depiction of a firm handshake signifying consensus being established between 2 parties.

This signifies the importance of establishing consensus at the heart of Decred’s network design and proposition. 


s2 
## Rules
A basic introduction to network consensus rules.

Rondel signs a ban on a selection of activities that are detrimental to Decred’s network.

This signifies that the network is governed by laws, depicted in a way that is relatable in a real world context.


s3 
## Infrastructure
A basic runthrough of network infrastructure

Graphic match between a blueprint and a final vision/design.

This signifies Decred’s consensus voting’s ability to upgrade the network to enable the adoption of new technologies such as Lightning Network and more recently decentralized treasury. 


s4
## Upgrade
A runthrough of the network upgrade process.

A relatable dashboard-like interface that demonstrates the relationship between PoS and PoW upgrade processes on a Dashboard-like interface. Example: https://voting.decred.org/ 

This reaffirms the point made in slide 1 where there is a direct relationship between parties who arbitrate one another. 


s5
## Time Frame
A runthrough of the timeframe of the prior process.

An interpretation of the passing of days on a calendar/chart. This may change based on the Rolling window and the threshold provided by PoS.

The clearly presented that there is a due process for enacting a network upgrade. 


s6
## Ticket Lifecycle (Voted)
A section further clarifying how the PoS voting component works.
This is communicated through an endless set of traffic lights/ abstract depiction.

This signifies the Yes/No/Abstain voting structure of PoS in a tangible way.


s7
## Approval
A section further clarifying Decred’s Hard Fork resistance.

A visual representation of this showing a binary/boolean outcome/flow resulting from the activation of new network consensus rules. 

This further reiterates the initial emphasis on establishing consensus.

[bgptr]

@jzbz @xaur FYI: I've opened a draft PR with the new tutorials: decred/decrediton#3669
You could try it or even the text could be reviewed there if it's more convenient for you guys.

[ta-lind]

@bgptr added all thumbnails https://www.figma.com/file/dEqHmYVc2uawBfdOkmKyUi/decred---onboarding-slides
svgs: decred - onboarding slides - thumbs.zip

[bgptr]

@linnutee thank you. The thumbnails look great. I've updated my decrediton PR with them.
I could not find the Identity (Pi/CMS)'s thumbnail. Is it left out
accidentally?

[ta-lind]

I'll add those as well. Wasn't sure if the last two would go to Decrediton, it won't hurt to have them there also I recon.

[jzbz]

I made some edits in #3728 for the parts that are already included in the release.
Other misc edits are below. We'll probably want to whittle the the text down further as well.

Going to take some of this and work it into #3729 to start, will update that issue with a comment when completed.

# LN

s1 
## Backup data is needed in addition to wallet seed.

Understand that backup data is needed in addition to your wallet seed to recover all Lightning Network funds

s2
## Lightning Network is a layer 2 network on top of the Decred blockchain, designed to facilitate micropayments more efficiently. 

While on-chain transactions require an average of 5 minutes for confirmation, Lightning transactions are routed near-instantaneously. The Lightning Network is made up of individual payment channels created by various Decred users. These form a network of nodes which can route transactions among themselves.


s3
## It's preferred to keep your wallet online most of the time.

Lightning Network has been implemented assuming that wallets (nodes) are online most of the time.

Episodic wallets, meaning ones that remain online for very short amounts of time, may see degraded ability to send and receive payments.


s4
## Episodic wallets should use a watchtower service for safety.

Understand that a malicious counterparty may steal funds from episodic wallets unless they use a watchtower service.


s5
## Sending and receiving amounts are limited to what is available in your published channels.

A channel is opened by locking up an amount of DCR into an on-chain ‘funding transaction’. This automatically creates a 2 of 2 multisig wallet on the Decred network, with each user receiving one of the keys (usually requiring up to 6 confirmations (blocks) to be available.).

Off-chain Lightning Network transactions can be made with the confidence of on-chain enforceability, when a channel is closed its balance will then be recorded to the Decred blockchain.


s6
## Minimize risk by using a separate wallet for Lightning.

The wallet account used for Lightning Network operations remains unlocked while Lightning is being used. Funds from that account are at risk from anyone with remote or physical access to your computer. It is recommended to use a separate account (or better yet, a separate wallet) with a small amount of funds to minimize the risk.



# Decred Intro

s1
## Why was Decred created?

Decred was created to address a crisis of governance (link) in Bitcoin. Decred has built a hybrid Proof-of-Work/Proof-of-Stake system, which puts Decred currency holders in charge of its governance to ensure order and fairness in decision-making and dispute resolving processes.



s2
## Governance systems empower its community 

Decred's consensus system uses hybrid PoW/PoS, where PoS can override PoW, which is an answer to Bitcoin's problem of PoW miners holding a monopoly on consensus enforcement via their exclusive write access to the ledger.



# Consensus Code ——— Probs makes sense to merge with “Decred Intro”

s1
## Focus on Consensus Code

While many cryptocurrency projects view consensus code as a means to an end, or something delicate with which you must take great care, Decred takes the view that this code is the real engine that drives all cryptocurrencies.

Due to the delicate nature of this code in a cryptocurrency project, exceptional measures must be undertaken to ensure that it behaves as planned under all possible scenarios.



# Hybrid PoW/PoS

s1
## 1 CPU, 1 Vote – Proof-of-Work

Proof-of-Work (PoW) solved the double-spending problem, being a primer for cryptocurrencies. From its protocol consensus perspective, the lack of formal decision-making procedures has a history of controversies and chain splits. PoW miners hold a monopoly on consensus enforcement via their exclusive write access to the ledger.

s2
## 1 Coin, 1 Vote – Proof-of-Stake

Proof-of-Stake (PoS) developed a better alignment of interests, and computational efficiencies, though resulted in different shortcomings, most notably the “nothing-at-stake problem” and inherent risk of resulting in feudalism. 


s3
## Hybrid PoW/PoS - Best of both worlds

Decred employs a combination of PoW and PoS to yield the best of both systems, and mitigate their weaknesses. Whether a new rules upgrade, emergency, conflict, bug fix, or new technology, Decred facilitates formal agreement, helping to avoid contentious hard forks and maintaining a unified community during the process.




# Staking and Tickets

s1
## Tickets are created by time-locking coins

Decred holders can participate in the Staking (Proof-of-Stake) process by time-locking their coins (amounting to the ticket value) in exchange for tickets. 


s2
## Tickets have multiple functions — Missing copy

These tickets are used to vote on miners’ Proof-of-Work in order to validate changes to the Decred blockchain and on the governance proposals within the Politeia system.

Opt-in governance via time-locking coins. applies to:
creating new blocks
consensus changes
project management


s3
## Rewards

Staking your funds also generates semi-passive returns with relatively low risk, as each voted ticket receives part of the block reward (link).




# Core Functions of Staking ——— no copy, refer to draft sketches

s1
## New block creation

As you might understand already, staking and the tickets have three core functions. Firstly cover block creation -> ensuring good miner behavior.

Stakeholders maintain direct power over the miners, ensuring good behavior through aligned incentives. Anyone can be a stakeholder,  including miners.


s2
## Consensus Changes

New consensus rules ... forming agreement  from both miners as well as stakers.

cover number of successful and smooth consensus change votes since 2017?



s3 - 4
## Treasury and Project Management ——— needs copy, refer to slide

splitting, this could ideally be around covering both approval and denying votes

Decred community of stakeholders votes to fund contractors to complete projects ... e.g. dev, marketing, design,

Politeia proposals, CMS
Bad actors side




# Ticket Lifecycle ——— incomplete copy, synth. off current ticket lifecycle copy

s1 
## Proof-of-Stake, Block Rewards

A basic introduction to Decred’s PoS rewards

Simple pictorial representation of the rewards accrued through PoS.


s2
## Tickets go through different stages in their lifecycle

A basic introduction to Decred’s PoS.

Abstract grid of the key ticket states to be explored in the section. 

Frames the subject matter of onboarding piece.


s3 
##  Immature tickets

A basic run-through of Immature ticket states.

A representation that shows the ticket surrounded by a vessel, volume that isolates the ticket from surrounding elements

This signifies that tickets cannot be interacted with during the 21 hours of immaturity and are isolated from the actions of both holder and network.


s4 
## Live Tickets

A run-through of live ticket states and the mempool

- Lottery
- Calendar average 28 day to vote
 - Maximum period 142 days
- Ticket transitions from immature to live


s5
## Voted Tickets

Upon successfully voting, turn immature again for 256 blocks (~20 hrs) and

Then unlocks funds + block reward

“On average, 50% of tickets will be called to vote within 28 days.”

A run-through of ticket expiration.

Stakey now resembles the form of an expired cheese with holes clearly visible as well as odor and files.


s6
## When Something Went Wrong

Combine expire + miss and getting revoked revoked

The average ticket age 28 days when called. Tickets are staked (locked up) for up to 142 days, at which point, a ticket expires if it has not been called, and the funds are returned to the wallet.
The ticket price is always refunded, no matter if your ticket votes, misses, or expires.




# Identity (Pi/CMS) ——— no copy, refer to draft sketches

s1 
## Back-up your ID

General ID functionality
Will become more important than the login+password pair.
Take good care of it or game over.


s2 
## Identity and Proposals

In Politeia, proposals, comments, comment votes, and now also updates, are signed with identity's key. These messages can have a high impact on decision making and spending, so these signatures might become more important.

———

s2 
## Identity and CMS

In CMS, identity is already used to sign invoices and comments, and possibly DCCs and DCC votes (not sure, need to check). In the future, I hope it will be also used to sign the proposal owner's approval of billing against the proposal (and without such approval billing will not be allowed).


s3
## Submit invoices in time

# Consensus Voting ——— no copy, refer to draft sketches

s1
## Overview

A basic introduction to on-chain consensus.

Depiction of a firm handshake signifying consensus being established between 2 parties.

This signifies the importance of establishing consensus at the heart of Decred’s network design and proposition. 


s2 
## Rules

A basic introduction to network consensus rules.

Rondel signs a ban on a selection of activities that are detrimental to Decred’s network.

This signifies that the network is governed by laws, depicted in a way that is relatable in a real-world context.


s3 
## Infrastructure

A basic run-through of network infrastructure

Graphic match between a blueprint and a final vision/design.

This signifies Decred’s consensus voting’s ability to upgrade the network to enable the adoption of new technologies such as Lightning Network and more recently decentralized treasury. 


s4
## Upgrade

A run-through of the network upgrade process.

A relatable dashboard-like interface that demonstrates the relationship between PoS and PoW upgrade processes on a Dashboard-like interface. Example: https://voting.decred.org/ 

This reaffirms the point made in slide 1 where there is a direct relationship between parties who arbitrate one another. 


s5
## Time Frame

A run-through of the timeframe of the prior process.

An interpretation of the passing of days on a calendar/chart. This may change based on the Rolling window and the threshold provided by PoS.

The clearly presented that there is a due process for enacting a network upgrade. 


s6
## Ticket Lifecycle (Voted)

A section further clarifying how the PoS voting component works.
This is communicated through an endless set of traffic lights/abstract depictions.

This signifies the Yes/No/Abstain voting structure of PoS in a tangible way.


s7
## Approval

A section further clarifying Decred’s Hard Fork resistance.

A visual representation of this showing a binary/boolean outcome/flow resulting from the activation of new network consensus rules. 

This further reiterates the initial emphasis on establishing consensus.