Skip to content

Commit

Permalink
Merge pull request #1181 from Concordium/Remove-legacy-wallets-from-C…
Browse files Browse the repository at this point in the history
…oncordium-Protocol-section

Removed references to legacy wallets
  • Loading branch information
TinaKT authored Dec 12, 2024
2 parents 97e3489 + 9d8b9cb commit 0985d49
Show file tree
Hide file tree
Showing 5 changed files with 54 additions and 100 deletions.
4 changes: 2 additions & 2 deletions source/mainnet/docs/protocol/concepts-baker.rst
Original file line number Diff line number Diff line change
Expand Up @@ -78,13 +78,13 @@ Validator account

Each account can use a set of validator keys to register a validator. Whenever a validator produces a valid block that gets included in the chain, a reward is paid to the validator's account (and the staking pool delegators if they have a pool) at :term:`pay day`. The reward is derived from transaction fees paid for transactions included in the block and its predecessors, as well as from newly-minted CCDs.

The account can be viewed in the |cryptox|, the Desktop Wallet, the |mw-gen2|, the |mw-gen1|, or the |bw| depending on where the account was created.
The account can be viewed in the |cryptox|, the Desktop Wallet, or the |bw| depending on where the account was created.

Rewards are added to the staked amount by default. However, you can choose to receive the rewards in the account balance instead of staking them automatically.

.. Note::

It is not possible to have multi-signature validator accounts in |cryptox|, |mw-gen2|, |mw-gen1|, or |bw|. If you need this functionality, you need to run the Desktop Wallet.
It is not possible to have multi-signature validator accounts in |cryptox| or |bw|. If you need this functionality, you need to run the Desktop Wallet.

Staking pool
============
Expand Down
2 changes: 1 addition & 1 deletion source/mainnet/docs/protocol/concepts-delegation.rst
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ When decreasing or removing the stake (whether for delegators or validators), th
Where delegation is available
=============================

You can :ref:`delegate CCDs<add-delegation>` in the Desktop Wallet, |cryptox|, |mw-gen1|, |mw-gen2|, and |bw|. You can also delegate from :ref:`Concordium Client<transactions>`. It is recommended that you use :ref:`CCDScan<ccd-scan>` to research the various validators and pools prior to delegation if you plan to delegate to a specific pool.
You can :ref:`delegate CCDs<add-delegation>` from any of the Concordium wallets or from :ref:`Concordium Client<transactions>`. It is recommended that you use :ref:`CCDScan<ccd-scan>` to research the various validators and pools prior to delegation if you plan to delegate to a specific pool.

Summary
=======
Expand Down
46 changes: 10 additions & 36 deletions source/mainnet/docs/protocol/id-accounts.rst
Original file line number Diff line number Diff line change
Expand Up @@ -13,65 +13,39 @@ Before you can use the Concordium Platform, an :term:`identity provider` must ve
About identities
================

Identities are issued by an :term:`identity provider`. There is a :ref:`registry of selected identity providers and their contact information publicly accessible from the Concordium blockchain<identity-commands>`. Concordium Foundation will maintain the list in the beginning.
Identities are issued by an :term:`identity provider`. There is a :ref:`registry of selected identity providers and their contact information publicly accessible from the Concordium blockchain<identity-commands>`.

.. Note::

It is possible to create a company identity that is not associated with a specific individual but is issued with documents that identify a company.
Company identities are only relevant for a few companies. The way they are created differs from how individual identities are created. For more information, see `Company identity creation <https://developer.concordium.software/en/mainnet/net/guides/company-identities.html#company-identities>`_.

While identities facilitate compliance with relevant regulations, they also allow users to be represented :term:`on-chain` in a way that protects users’ privacy. That is, transactions on the chain are processed without exposing the identity of the sender or receiver. The identity of an account owner can only be revealed via the process of disclosing an identity. Disclosing an identity can only happen in exceptional circumstances, for example if authorities have detected suspicious activity on the account, and requires action by one or more identity disclosure authorities and the identity provider who issued the account's identity.
While identities facilitate compliance with relevant regulations, they also allow users to be represented :term:`on-chain` in a way that protects users’ privacy. That is, transactions on the chain are processed without exposing the identity of the sender or receiver. The identity of an account owner can only be revealed via the process of :ref:`disclosing an identity <revoke-anomity>`. Disclosing an identity can only happen in exceptional circumstances, for example if authorities have detected suspicious activity on the account, and requires action by one or more identity disclosure authorities and the identity provider who issued the account's identity.

Every account on the chain must be derived from an identity that is verified and signed by an approved identity provider. It is publicly visible which identity provider issued an identity for an account, and who the :term:`identity disclosure authorities<Identity disclosure authority>` are for the account and the identity. In addition to this basic information which enables regulatory compliance, an account owner can choose to publicly reveal other values on their account. These values are called :term:`attributes` and can be, for example, nationality or country of residence. Publicly accessible attributes enable anybody to check the attributes before interacting with an account. Being able to see who issued the identity enables whoever wishes to interact with an account to judge the level of risk in the transaction. If you choose to reveal attributes, you should have a good reason to do so. The general recommendation is not to reveal attributes.
Every account on the chain must be derived from an identity that is verified and signed by an approved identity provider. It is publicly visible which identity provider issued an identity for an account, and who the :term:`identity disclosure authorities<Identity disclosure authority>` are for the account and the identity. Being able to see who issued the identity enables whoever wishes to interact with an account to judge the level of risk in the transaction.

Attributes
----------

Each identity contains a number of cryptographic values and a number of
user-chosen attributes, such as nationality or country of residence. These
attributes are certified by the identity provider. The cryptographic values are
a number of public and private keys, a signature from the identity provider, as
well as a number of secret values the user must use to be able to use the
identity to create accounts.

You are in control of which attributes are revealed to the public. You can choose not to reveal any attributes at all, which is the general recommendation.
An identity contains a number of cryptographic values, i.e. a number of public and private keys, a signature from the identity provider, as
well as a number of secret values required to use the identity for account creation.

Obtain an identity
------------------

You can :ref:`create identities<create-initial-account>` in the |cryptox|, Desktop Wallet, |mw-gen2|, or |bw|. Identity creation is an :term:`off-chain` action.

.. Warning::
It is not possible to exchange identities and accounts between the |mw-gen1| and the Desktop Wallet. If you try to import a file that has been exported from the |mw-gen1| into the Desktop Wallet, the import will fail, and likewise, if you try to import a file exported from the Desktop Wallet into the |mw-gen1|.
You can :ref:`create identities<create-initial-account>` in the |cryptox|, Desktop Wallet, or |bw|. Identity creation is an :term:`off-chain` action.

.. Warning::
Because of the difference in the way private keys are handled between |mw-gen2| / |bw| and the first generation wallets (|mw-gen1| and Desktop Wallet), you cannot exchange identities and accounts between them.

It is possible to exchange accounts and identities between the |cryptox|, |mw-gen2|, and the |bw|. Additionally, |mw-gen1| users can import backup files to |cryptox|.

.. Note::

It is no longer possible for users of |mw-gen1| to create new identities.
Because of difference in the way private keys are handled, you cannot exchange identities and accounts between Desktop Wallet and other wallets.

Identity issuance requires *Identity Verification*, which is the process of verifying the real-life identity of the user. This typically requires taking photographs or scans of identification documents, such as a passport. Identity verification also checks that the user-chosen attributes are valid for the user.
Identity issuance requires *Identity Verification*, which is the process of verifying the real-life identity of the user. This typically requires taking photographs or scans of identification documents, such as a passport.

Upon verification of the user's identification documents and attributes, the Identity provider issues a :term:`user identity certificate`. The User identity certificate contains attributes about the user. It is basically the Identity Provider’s signature over some cryptographic keys of the user and the validated personal attributes.
Upon verification of the user's identification documents, the Identity provider issues a :term:`user identity certificate`. The User identity certificate is basically the Identity Provider’s signature over some cryptographic keys of the user.

.. image:: ./images/identity-creation.png
:alt: graphic drawing showing how the user interacts with the identity provider

.. Note::

If using |cryptox|, |bw|, or |mw-gen2| with Digitial Trust Solutions (DTS) as your identity provider, and you have a mitID (Denmark) or Suomi.fi e-identification (Finland), you can use that to complete the identity verification process.

About accounts
==============

For information about accounts, see :ref:`Accounts<managing_accounts>`.

.. Note::
If using |cryptox| or |bw| with Digitial Trust Solutions (DTS) as your identity provider, and you have a mitID (Denmark) or Suomi.fi e-identification (Finland), you can use that to complete the identity verification process.

It is no longer possible for users of |mw-gen1| to create new accounts.

.. _revoke-anomity:

Expand Down
42 changes: 12 additions & 30 deletions source/mainnet/docs/protocol/manage-accounts.rst
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@
Accounts
========

Accounts and :term:`identities<identity>` are strongly linked on the Concordium Platform. To be able to hold, send, or receive :term:`CCD` or become a :term:`validator` on the Concordium blockchain, you need an account and an identity. This is regardless of whether you are using the |cryptox|, Desktop Wallet, or Concordium Client for your transactions.
Accounts and :term:`identities<identity>` are strongly linked on the Concordium Platform. To be able to hold, send, or receive :term:`CCD` or become a :term:`validator` on the Concordium blockchain, you need an account and an identity. This is regardless of whether you are using the one of the Concordium wallets or Concordium Client for your transactions.

You must have a verified identity and a user identity certificate issued by an authorized :term:`identity provider` to create accounts on the Concordium Platform. For more information about identities, see :ref:`Identities<reference-id-accounts>`.

Expand All @@ -30,7 +30,7 @@ The off-chain part of the account contains:
the account on the chain)

Concordium provides several ways of interacting with the on-chain account.
Off-chain parts of accounts can be transferred between different devices but not between |mw-gen1| and Desktop Wallet, or |mw-gen2| and Desktop Wallet. The same account can be used from multiple devices at the same time.
The same account can be used from multiple devices at the same time, and off-chain parts of accounts can be transferred between different devices, however not between Desktop Wallet and other wallet types.

Accounts on the chain are identified via an account address, which is a 32-byte
sequence. The address is usually displayed in Base58Check encoding with version
Expand All @@ -46,12 +46,12 @@ Initial account

.. Note::

Initial accounts are not created by the identity provider when using |mw-gen2| or |bw|. You create all accounts yourself.
Initial accounts are not created by the identity provider when using |cryptox| or |bw|. You create all accounts yourself.

The user gets an :term:`initial account` at the same time as an :ref:`identity<reference-id-accounts>` has been issued by an :term:`identity provider`. As the initial account is submitted to the chain by the identity provider, the identity provider knows the owner of the initial account. For this reason, you may not want to use the initial account and create a regular account instead. There can only be one initial account for one identity.

The user additionally :ref:`creates account keys<export-import>` for an initial account, which the user stores privately. The identity provider then verifies that the attributes in the user identity information
are valid for the user and stores them locally in an identity object that is specific to the user. Identity objects are only held by identity providers. The identity provider then opens an
The user additionally :ref:`creates account keys<export-import>` for an initial account, which the user stores privately. The identity provider then verifies the validity of the user identity information
and stores it locally in an identity object that is specific to the user. Identity objects are only held by identity providers. The identity provider then opens an
account, the initial account, on behalf of the user. At the end of the identity verification process, the user receives a user identity certificate that can be used for creating
additional accounts and the user gets access to the initial account on the Concordium Platform. These certificates are valid for a given period. You can obtain a new certificate
by creating a new identity and going through the identity verification process again with an identity provider.
Expand All @@ -65,12 +65,9 @@ Account creation
Once you have an identity and a user identity certificate from an identity provider, you can use it to create more accounts on the Concordium Platform. This is typically done using an :ref:`app or wallet<tools>` that guides users through the account creation process. The creation of an account is an :term:`on-chain` action that requires sending a transaction to a node that participates in the Concordium network.

.. Note::
|mw-gen2| and |mw-gen1| do not submit the transaction directly to a node, but via a proxy. |mw-gen2| and |mw-gen1| do not need to be connected to a node.
|cryptoX| does not submit the transaction directly to a node, but via a proxy. |cryptox| does not need to be connected to a node.

The input to the transaction is a *credential*, which contains a number of :term:`cryptographic proofs<cryptographic proof>`, as well as a selection of :term:`attributes` the user wishes to reveal publicly. The proofs establish that the attributes the user revealed publicly are the ones approved by the identity provider. The proofs reveal no other information. In particular, the identity provider itself cannot determine the owner of the account. Note that revealing attributes publicly is completely optional. The benefit gained from revealing attributes is that other users may decide whether to trust the account based on the publicly available information.

An example is that you might need to reveal your nationality sometimes. So you might have one account with no attributes revealed, and another account that reveals your nationality. When required, you can use the account with the nationality revealed while keeping
all other activities undisclosed.
The input to the transaction is a *credential*, which contains a number of :term:`cryptographic proofs<cryptographic proof>`. The proofs reveal no information about the owner of the account. In particular, the identity provider itself cannot determine the owner of the account.

.. image:: ../protocol/images/account-creation.png
:alt: graphic drawing showing how user creates accounts
Expand All @@ -80,31 +77,16 @@ all other activities undisclosed.

Any time you create a new account when using |mw-gen1| or Desktop Wallet, you should make a :ref:`backup<export-import>`. Backups protect your account keys, ensuring that you do not lose access to your CCDs.

Attributes
----------

Each identity contains a number of cryptographic values and a number of
user-chosen attributes, such as nationality or country of residence. These
attributes are certified by the identity provider. The cryptographic values are
Each identity contains a number of cryptographic values. The cryptographic values are
a number of public and private keys, a signature from the identity provider, as
well as a number of secret values the user must use to be able to use the
identity to create accounts.

You are in control of which attributes are revealed to the public. You can choose not to reveal any attributes, which is the general recommendation.

Benefits of revealing attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Every account on the chain must be derived from an identity that is verified and
signed by an approved identity provider. It is publicly visible which identity
provider issued an identity for an account and who the identity disclosure authority are
for the account and the identity. In addition to this basic information which
enables regulatory compliance, an account owner can choose to publicly reveal
other values on their account, such as their nationality or country of
residence. Since this information is publicly accessible, anybody can check it
before interacting with an account. Moreover, being able to see who issued the
identity enables whoever wishes to interact with an account to judge the level
of risk in the transaction.
for the account and the identity. This means that anybody can check it
before interacting with an account to judge the level of risk in the transaction.


Account concepts
Expand Down Expand Up @@ -155,7 +137,7 @@ validate transactions.

You can :ref:`look up the sequence number<account-seqno>` from an up to date node using Concordium Client.

The |mw-gen2| and |mw-gen1| keeps track of the sequence number and assigns the correct one when sending transactions.
The |cryptox| keeps track of the sequence number and assigns the correct one when sending transactions.
``concordium-client`` tracks the sequence number automatically, but it can
also be set manually.

Expand Down Expand Up @@ -190,6 +172,6 @@ Command-line tool
The Concordium distribution ships with a command-line tool named
:ref:`concordium-client<concordium-client>`. It is designed as a low-level interface to the
Concordium blockchain. It cannot be used to create identities, but it can
:ref:`import accounts<concordium-client-import-accounts-keys>` exported from the mobile wallet. Once an account has been
:ref:`import accounts<concordium-client-import-accounts-keys>` exported from the |cryptox|. Once an account has been
imported, the tool can be used to do CCD transfers from the account, as well as
send all other :ref:`transaction<transactions>` types supported by the Concordium blockchain.
Loading

0 comments on commit 0985d49

Please sign in to comment.