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)
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.
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.
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.
- 1 Namecoin Specification
- 1.1 WORKING DRAFT
- 1.2 Abstract
- 1.3 Status of this Memo
- 1.4 Copyright Notice
- 1.5 Requirements Language
- 1.6 Introduction
- 1.7 Terminology
- 1.8 Overview
- 1.9 Resources
- 1.10 Identifiers
- 1.11 Namespaces
- 1.12 Namecoin IRI
- 1.13 Client API
- 1.14 Fees
- 1.15 Addresses
- 1.16 Transaction
- 1.17 Blockchain
- 1.18 Network Protocol
- 1.19 Nodes
- 1.20 Miners
- 1.21 File Structures
- 1.22 Security Considerations
- 1.23 References
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.
/d/namecoin /a/namecoin/test /id/أفضل
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.
|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|
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.
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.
Base58 encoded namecoin address.
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.
A label for that address (e.g. name of receiver).
It MUST NOT be longer than 50 Unicode code points.
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.
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|
|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:
- Choose a prefix for respective address and network
- Calculate a hash:
RIPEMD-160(SHA-256(ECDSA public key))
- Calculate a checksum:
SHA-256(SHA-256(prefix + hash))
- Result address:
prefix + hash + first 4 bytes of checksum
+ (plus) sign denotes a binary concatenation.
Applications MAY Base58 encode address for display purposes or MAY use other encoding.