5 - Blockchain Users#

  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

Table of Contents#

  1. Abstract

  2. Motivation

  3. Prior Work

  4. Blockchain User

  5. Specification

    1. Registering a Blockchain User (SubTxRegister)

    2. Topup Blockchain User Credit (SubTxTopup)

    3. Reset Blockchain User Key (SubTxResetKey)

    4. Close Blockchain User Account (SubTxCloseAccount)

    5. Subscription Transaction Fees

    6. Subscription Username

    7. Reject Messages

    8. Validation Rules

  6. 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#

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 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
* Cannot be changed by subsequent SubTxs

pubKey

BLSPubKey

48

Owner’s public key for the account
* 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 (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
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 (576 blocks/day * 90 days = 51840 blocks)