# 5 - Blockchain Users

<pre>
  DIP: 0005
  Title: Blockchain Users
  Author(s):  Alexander Block, Cofresi, Andy Freer, Nathan Marley, Anton Suprunchuk, Darren Tapp, Thephez, Udjinm6, Alex Werner, Samuel Westrich
  Special-Thanks: Evan Duffield, Timothy Flynn, Will Wray
  Comments-Summary: No comments yet.
  Status: Withdrawn
  Type: Standard
  Created: 2018-08-15
  License: MIT License
</pre>

## Table of Contents

1. [Abstract](#abstract)
1. [Motivation](#motivation)
1. [Prior Work](#prior-work)
1. [Blockchain User](#blockchain-user)
1. [Specification](#specification)
    1. [Registering a Blockchain User (SubTxRegister)](#registering-a-blockchain-user-subtxregister)
    1. [Topup Blockchain User Credit (SubTxTopup)](#topup-blockchain-user-credit-subtxtopup)
    1. [Reset Blockchain User Key (SubTxResetKey)](#reset-blockchain-user-key-subtxresetkey)
    1. [Close Blockchain User Account (SubTxCloseAccount)](#close-blockchain-user-account-subtxcloseaccount)
    1. [Subscription Transaction Fees](#subscription-transaction-fees)
    1. [Subscription Username](#subscription-username)
    1. [Reject Messages](#reject-messages)
    1. [Validation Rules](#validation-rules)
1. [Copyright](#copyright)

## Abstract

This DIP introduces the “Blockchain User” (BU) to enable more user-friendly transactions and support blockchain-authenticated applications.

**Note**
This DIP has been withdrawn since it is:

1. Not implemented, and
2. Not representative of the current solution to provide similar functionality

## Motivation

In Dash and many other cryptocurrencies, users currently send a payment to an address composed mainly of a cryptographic hash.  This hash is by its random nature very hard to remember for a user and provides no mechanism to send payments without first being provided an address by the recipient.  Most mainstream payment systems provide a simple method of paying a person or business without requiring knowledge of their account details (frequently via a username or email address).  This DIP proposes adding a similar friction-reducing mechanism to Dash while also enabling more advanced user features that are secured by the blockchain.

## Prior Work

* [DIP 0002 - Special Transactions](https://github.com/dashpay/dips/blob/master/dip-0002.md)

## Blockchain User

### Overview

The primary purpose of the Blockchain User is to enable secure services that are linked to a username registered on the blockchain.  Account data stored on the blockchain provides the most security and durability while remaining accessible and verifiable via SPV.  Since the amount of data each account needs to store during its life cycle is minimal, the penalties of adding this data to the blockchain are minimal.  Each Blockchain User funds their username by converting Dash into credits that are used as fees to pay for State Transitions, described in a later DIP.

A Blockchain User is a private key holder that has issued a ‘Register’ Subscription Transaction (SubTxRegister) containing:

 1. An unregistered username - validated as unique at the block height that the transaction is mined and guaranteed to be unique for the lifetime of the subscription.
 2. A public key - derived from the Blockchain User’s private key. This allows user requests (signed with the private key) to be validated.

Blockchain User accounts also maintain a balance of value used to pay fees related to Evolution actions they perform on the network.  The value is created by converting Dash into “credits” at a 1:1 ratio when a Blockchain User is registered and then consumed via DAP State Transitions (modifying the user’s per-DAP data).  Credit balance and consumption of credits will be described more thoroughly in additional DIPs relating to State Transitions.

## Specification

This DIP defines Subscription Transactions - a set of four new DIP-2 special transactions for creating and managing Blockchain Users.

### Registering a Blockchain User (SubTxRegister)

To register a blockchain user, a Register SubTx (SubTxRegister) is submitted to the network.  The SubTxRegister must contain a valid, unregistered username along with a public key.  The username must comply with the criteria described in the [Subscription Username Constraints](#subscription-username) section.  The public key is used for authentication and signing purposes to prove ownership of the username.

In addition to the payload in the special transaction section of the transaction, the SubTxRegister must also include a spend to an OP_RETURN output in order to establish a credit balance for State Transition fees. This output must include the fixed spam-deterrent signup fee (amount to be determined) in addition to the amount being converted to credits. Note: there can only be one OP_RETURN output in a standard transaction.

`OP_RETURN amount = signup fee + amount to convert to credits`

The transaction consists of the following data in the payload area:

| Name | Type | Size | Description |
| - | - | - | - |
| version | uint16_t | 2 | Register transaction version number |
| userNameSize | compactSize uint | 1-9 | Length of the username |
| userName | string | Variable | Username for the account<br> * Cannot be changed by subsequent SubTxs |
| pubKey | BLSPubKey | 48 | Owner’s public key for the account<br> * For authentication only - should not be used to hold funds |
| payloadSig | BLSSig | 96 | Signature of the hash of the preceding fields signed by the blockchain user with the private key for the specified PubKey |

### Topup Blockchain User Credit (SubTxTopup)

A Topup SubTx (SubTxTopup) increases the user’s credit balance by the amount of Dash burned in the transaction.  The Topup SubTx does not need to be signed by the blockchain user, so anyone can topup an account.  The Registration SubTx hash identifies the account receiving the topup.

Similar to the SubTxRegister, the SubTxTopup must spend the amount to be converted to credits using an `OP_RETURN` output.

The transaction consists of the following data in the payload area:

| Name | Type | Size | Description |
| - | - | - | - |
| version | uint16_t | 2 | Topup transaction version number |
| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction |

### Reset Blockchain User Key (SubTxResetKey)

The ResetKey SubTx (SubTxResetKey) allows a blockchain user to change the public key associated with their username.  The transaction must provide the new public key and be signed with the private key corresponding to the current public key (from either the Register SubTx or the most recent ResetKey SubTx if any are present).

#### Key aging

Once a SubTxResetKey is mined, the key that signed the transaction is rendered inactive and begins aging according to the following formula:

* `Age = (Current block) - (Block containing SubTxResetKey)`

The transaction consists of the following data in the payload area:

| Name | Type | Size | Description |
| - | - | - | - |
| version | uint16_t | 2 | Reset key transaction version number |
| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction |
| hashPrevSubTx | uint256 | 32 | Hash of the user’s previous subscription transaction |
| creditFee | int64_t | 8 | Fee (denominated in duffs) to pay for transaction |
| newPubKey | BLSPubKey | 48 |  New public key for a change/reset action |
| payloadSig | BLSSig | 96 | Signature of most recent pubkey prior to this transaction, signing a change/reset action |

### Close Blockchain User Account (SubTxCloseAccount)

The Close SubTx (SubTxCloseAccount) allows a blockchain user to deactivate their username by signing the message with their most recent private key, or in the case of a recently updated public key (via “SubTxResetKey”), a previously used private key.  This latter consideration is to prevent account hijacking attacks. For example, if an attacker obtains a Blockchain User's private key, then changes the public key via ResetKey, the legitimate user can still close the account with their old key.  This can be used to disable the attacker’s ability to access the username and associated data.  To mitigate the risk of account closure due to an old key being compromised, accounts can only be closed using previous keys that are [<= ~90 days old](#key-aging) (51840 blocks).  The private key associated with the currently assigned public key can always be used to Close an account regardless of age.

The transaction consists of the following data in the payload area:

| Name | Type | Size | Description |
| - | - | - | - |
| version | uint16_t | 2 | Close account transaction version number |
| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction |
| hashPrevSubTx | uint256 | 32 | Hash of the user’s previous subscription transaction. This is necessary to ensure proper order of operations is followed (e.g. make sure the proper key has signed the Close message if a ResetKey message is also present) |
| creditFee | int64_t | 8 | Fee (denominated in duffs) to pay for transaction |
| payloadSig | BLSSig | 96 | Signature from either the current key or a previous key<br>Version 1 - Previous keys are constrained to ones <= ~90 days old (51840 blocks)

#### Important notes regarding closed accounts

Version 1 of the Close Account SubTx has the following restrictions:

* Any credits remaining on an closed account are inaccessible
* A closed account may not be re-opened via another version 1 Register SubTx

### Subscription Transaction Fees

Two of the transactions (SubTxRegister and SubTxTopup) must include a classical transaction fee and an `OP_RETURN` output which is used to convert Dash into credits for the relevant account.  The other two transactions (SubTxResetKey and SubTxCloseAccount) perform account management and generally will include a credit fee to cover their processing.  When a miner claims a block reward, credits-based fees are distributed in the same way as input-based transaction fees and converted back to Dash in the coinbase.  From a miner perspective, input-based fees and credits-based fees are equivalent.

| Subscription Transaction | Classical Transaction Fee | Credit Fee | `OP_RETURN` Output |
| - | - | - | - |
| SubTxRegister | Required | - | Required |
| SubTxTopup | Required | - | Required |
| SubTxResetKey | Optional * | Typical | - |
| SubTxCloseAccount | Optional * | Typical | - |

Although most Subscription transactions will pay the full fee via either a classical transaction fee OR a credit fee, there may be cases where it is a combination of the two.  In that case, the total transaction fee is calculated by adding them:
`Total fee = classical transaction fee + credit fee`

* Note: A classical transaction fee could be included for any Subscription Transaction, but typically will not be present unless a user’s credit balance is too low to cover the full transaction cost.

### Subscription Username

#### Constraints

The username field of the Register SubTx must meet the following criteria:

* Minimum length: 3 characters
* Maximum length: 24 characters
* Acceptable characters: `A-Z` (case insensitive); `0-9`
  * Note: Usernames are validated as all lowercase characters regardless of the case in the SubTxRegister
* Unique across the Dash blockchain and current mempool
* Immutable - the username of a Blockchain User cannot be changed

The choice of allowable characters has been intentionally constrained to this subset of ASCII in the initial version.  This minimized character set is to ensure future-compatible usernames.  Future versions may relax the constraints to allow more characters, but characters in this initial set will always be valid.

### Reject Messages

Reject messages provide feedback when an invalid transaction is sent.  The table
below provides details on the reject messages in the Dash Core implementation:

| Message Type | Message | Description |
| - | - | - |
| REJECT_INVALID | bad-subtx-payload | Bad payload |
| REJECT_INVALID | bad-subtx-version | Non-current version number provided |
| REJECT_INVALID | bad-subtx-fee | Fee exceeds minimum or maximum accepted value |
| REJECT_INVALID | bad-subtx-sig | Bad signature |
| REJECT_INVALID | bad-subtx-dupusername | Duplicate username - this username already present on the blockchain or in the mempool |
| REJECT_INVALID | bad-subtx-lowtopup | Topup amount too low |
| REJECT_INVALID | bad-subtx-accountclosed | Referenced account has been closed |
| REJECT_INVALID | bad-subtx-ancestor | The `hashPrevSubTx` field does not reference the most recent SubTx |
| REJECT_INSUFFICIENTFEE | bad-subtx-nocredits | Credit balance too low to pay fee |
| REJECT_TS_INVALID | bad-subtx-nouser | Provided user not found |

### Validation Rules

#### SubTxRegister

A version 1 SubTxRegister is **_invalid_** if _any_ of these conditions are true:

* Username does not conform to the username constraints
* A SubTxRegister for this username is already present in the blockchain
* A SubTxRegister transaction is received that conflicts with one already in the mempool
  * Note: A valid block containing a SubTxRegister overrides any conflicting mempool SubTxRegister
* An `OP_RETURN` output is not present
* There are no `OP_RETURN` outputs receiving a value > 0

**Note**: Any block is considered invalid if it contains more than one SubTxRegister for the same username.

#### SubTxTopup

A version 1 SubTxTopup is **_invalid_** if _any_ of these conditions are true:

* The provided SubTxRegister hash does not reference an open account
* An `OP_RETURN` output is not present
* There are no `OP_RETURN` outputs receiving a value > 0

#### SubTxResetKey

A version 1 SubTxResetKey is **_invalid_** if _any_ of these conditions are true:

* The provided SubTxRegister hash does not reference an open account
* The provided previous SubTx hash is invalid (e.g. not associated with last SubTx hash of the user in the RegTxHash field, incorrect hash format, etc.)
* The combined credit fee and transaction fee provided are less than the minimum allowable network fee
* The new public key is invalid
* The signature is invalid

#### SubTxCloseAccount

A version 1 SubTxCloseAccount is **_invalid_** if _any_ of these conditions are true:

* The provided SubTxRegister hash does not reference an open account
* The provided previous SubTx hash is invalid (e.g. not associated with last SubTx hash of the user in the RegTxHash field, incorrect hash format, etc.)
* The combined credit fee and transaction fee provided are less than the minimum allowable network fee
* The signature is invalid
* The signing key is a previously used one (i.e. not the current key) [more than ~90 days old](#key-aging) (`576 blocks/day * 90 days = 51840 blocks`)

## Copyright

Copyright (c) 2018 Dash Core Group, Inc. [Licensed under the MIT License](https://opensource.org/licenses/MIT)