Jump to: navigation, search

Namecoin Specification

Revision as of 12:35, 30 January 2016 by Biolizard89 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Warning: I found this page because a new contributor asked about it. As far as I can tell it was written by someone who is not a developer and who has a repeated history of misrepresenting his crappy work as affiliated with Namecoin. I will be going through official channels to delete this page in the near future, but in the meantime assume that everything here is false, because you won't be far off. Cheers. --Biolizard89 (talk) 12:35, 30 January 2016 (UTC)

Namecoin Developers

April 2014

Namecoin Specification


This is a WORKING DRAFT it's not completed and it's not official in any way. It's not yet reviewed nor approved by Namecoin community.


Namecoin is an open source decentralized database system and peer-to-peer electronic cash system based on Bitcoin.

Status of this Memo

This document specifies the current status of Namecoin. That includes protocols and data structures used by Namecoin. This document applies to all applications which intend to interact with Namecoin and it's protocol. It also contains full specification required to implement a Namecoin Node or Miner.

Copyright Notice

This document is licensed under Creative Commons Attribution-ShareAlike (CC BY-SA). Which means it can be freely copied and redistributed unlimitedly in any medium or format.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Namecoin is used to register names and store associated values in the blockchain, a shared database distributed by peer-to-peer in a secure way. These names later can be used to query the database and retrieve associated data.


  • Peer-to-peer - a peer-to-peer (P2P) network is a type of decentralized and distributed network architecture in which individual nodes in the network (called "peers") act as both suppliers and consumers of resources.
  • Address - a public key, used to receive payment.
  • Resource - data which is distributed.
  • Identifier - a unambiguous path to Resource.
  • Namespace - a grouping of Resources, it describes the way Resources are interpreted.
  • Transaction - a signed message which describes the way inputs and outputs are spent and which Resources are being registered or set.
  • Block - a record in the Blockchain that contains Transactions.
  • Blockchain - a public list of Blocks.
  • Miner - a software in part of Namecoin which by solving proof of work creates Blocks and includes verified transactions in it.
  • Node - a software in part of Namecoin which relays transactions and blocks to peers.
  • Peer - a Node or Miner or other client which listens on Namecoin network.


  • Every Resource in Namecoin MUST be located in a Namespace. And a single resource MUST NOT be in multiple namespaces.
  • Namespaces itself MUST NOT be registrable and MUST NOT be usable.
  • Every namespace SHOULD have it's own purpose and usage.
  • Different namespaces for same purpose SHOULD NOT exist.
  • Resources MUST be stored in a Block and thus Blockchain. Resource MUST be only included in a Block if Transaction which contains it are valid.
  • Miners MUST verify whether Transactions are valid and MUST NOT include invalid transactions in blocks.
  • Peers MUST relay transactions and blocks to other peers and MUST NOT relay invalid transactions or blocks.


A Resource is a set of data. It's interpretation fully depends on a Namespace in which it is. Implementations which doesn't recognize namespace in which this resource are located in MUST not alter or process it in any way. Applications MUST threat this data as binary blob. How to interpret data in this resource are described in section of respective namespace. Multiple resources with same data can exist only if they have different identifiers and thus they MUST be considered different.


An Identifier is a ipath from Internationalized Resource Identifiers (IRI) as per RFC 3987. It uniquely and unambiguously identifies a Resource. A single Resource MUST have only one identifier and different resources MUST NOT have same identifiers. ipath is encoded as per RFC, ie., identifiers are case-sensitive and MUST be normalized using NFC (see UAX15) first before testing for equality, but Identifiers MUST be stored unchanged. All implementations MUST conform to RFC 3987 and Unicode Standard when using Identifiers. The first isegment_nz of a identifier MUST be a namespace and depending on namespace it MAY further limit how the following isegment are encoded or what code points are allowed. There are no limit for maximal length of an Identifier, but implementations MUST have space for atleast 1000 Unicode code points for ipath, which (depending on encoding) might be more than 1000 bytes.

Identifier examples:



A namespace MUST be case insensitive isegment_nz from IRI and it describes how data in a Resource is interpreted and processed. Namespaces MUST NOT be longer than 50 Unicode code points.

Full Namecoin implementations MUST implemented all namespaces from this document. A lighter Namecoin clients MAY implemented only some namespaces, but then they MUST NOT work as Miner or Node.

Namespace Specification Description Used version
a Application Application specific data. 1.0
d Domain Name Specification Domain name system, used for .bit top level domain. 3.0
ds Secure Domain Name Secure Domain name system, used for .bit top level domain. 1.0
id Identity Public online identity. 2.0
is Secure Identity Secure online identity. 1.0
p Product Product information. 1.0

Namecoin IRI

Namecoin IRI and scheme MUST follow RFC 3987

Namecoin clients MUST NOT act on IRIs without getting the user's authorization. They SHOULD require the user to manually approve each action individually, though in some cases they MAY allow the user to automatically make this decision.

Graphical namecoin clients SHOULD register themselves as the handler for the "namecoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.



Scheme commands

Clients MUST support all commands mentioned below and SHOULD NOT execute action if IRI contains unrecognized parameters. But clients MAY provide an option for user to force execution anyway with notice that unrecognized parameters will be ignored.




Description: Send specified amount of Namecoins to specified address.


  • Address

Base58 encoded namecoin address.

  • Amount

Amount of namecoins to send. MUST be in satoshis, smallest possible namecoin unit. Amount MUST NOT contain any commas (,) or periods (.)

Namecoin clients SHOULD display the amount in user preferable format. That is, it SHOULD be displayed according to user locale.

  • Label

A label for that address (e.g. name of receiver).

It MUST NOT be longer than 50 Unicode code points.

  • Message

A message that describes the transaction to the user.

It MUST NOT be longer than 1024 Unicode code points.




Description: Initiate Payment Protocol.

payment-iri - IRI to merchant web address for starting payment.

Namecoin wallets MUST support fetching Payment Requests via HTTP and HTTPS protocols and they MAY support additional protocols.




Description: Sign specified message.

Message MUST NOT be longer than 1024 Unicode code points.




Description: Verify given message.

Message MUST NOT be longer than 1024 Unicode code points.

Client API

For full specification see Client API




Type Mainnet Prefix Testnet Prefix Usage
PUBKEY_ADDRESS 0x34 0x6f Address used to receive Namecoins
SCRIPT_ADDRESS 0x0d 0xc4 p2sh 6xxx and 2xxx addresses
SECRET_KEY 0xe4 0xef WIF format
EXT_PUBLIC_KEY 0xd7dd6370 0x043587cf npub and tpub
EXT_SECRET_KEY 0xd7dc6e31 0x04358394 nprv and tprv

To calculate an Address, applications MUST use the following algorithm:

  1. Choose a prefix for respective address and network
  2. Calculate a hash: RIPEMD-160(SHA-256(ECDSA public key))
  3. Calculate a checksum: SHA-256(SHA-256(prefix + hash))
  4. Result address: prefix + hash + first 4 bytes of checksum

Note: The + (plus) sign denotes a binary concatenation.

Applications MAY Base58 encode address for display purposes or MAY use other encoding.





Network Protocol






File Structures


Security Considerations

Unicode characters are used and thus UTR36 and UTS39 applies.



[Bitcoin] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" (PDF)
[CC BY-SA] Attribution-ShareAlike 4.0 International (HTML)
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997 (TXT, HTML, PDF, XML)
[RFC3987] M. Duerst, M. Suignard, "Internationalized Resource Identifiers (IRIs)", January 2005 (TXT, HTML, PDF, XML)
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", January 2005 (TXT, HTML, PDF, XML)
[ProtocolBuffers] "Protocol Buffers" (HTML)
[Unicode] "The Unicode Standard" (HTML)
[UAX15] "Unicode Normalization Forms" (HTML)
[UAX31] "Unicode Identifier and Pattern Syntax" (HTML)
[UTS6] "Standard Compression Scheme for Unicode" (HTML)
[UTR36] "Unicode Security Considerations" (HTML)
[UTS39] "Unicode Security Mechanisms" (HTML)
[RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", November 2003 (TXT, HTML, PDF, XML)