​​​​​​​​​​​Non-Fungible Tokens

So-called Non-Fungible Tokens (NFTs) have become popular in the last time. When you have two 1 dollar coins in your pocket, it doesn’t matter whether you pay for your coffee with one coin or the other. The coins only represent a value and are interchangeable against each other or fungible. Non-fungible tokens, however, are representing one specific asset and are thus unique. Mostly, these tokens represent digital art, with the binary data of the particular file stored as the value of the NFT record. For larger objects, even if they are not of a digital nature, all identifying information can be stored as an NFT to prove owner- and authorship. For digital files, a hash of the file can be taken as the value, with MD5 being the most common hash algorithm used to verify digital files. Other algorithms such as SHA-1 are popular as well. With the first confirmation on the blockchain, your NFT gets an immutable timestamp, so you can prove that you were the first one who published the file in question.

​It has to be taken in consideration that the records on the Namecoin blockchain will expire after 36,000 blocks. Even though the timestamp itself will be preserved even on an expired NFT record, you will have to take care of a regular renewal in time to avoid any abuse of your NFT.

Definition of NFTs

On December 2, 2013, Vitalik Buterin published the Ethereum whitepaper, introducing the term “non-fungible assets“, referring explicitely to domain names on the Namecoin blockchain. On January 24, 2018, Ethereum introduced the Non-Fungible Token Standard (EIP-721). Since then, the term NFT has been used as a synonym for all types of assets secured on blockchains.

Technically, an NFT is a unique cryptographic asset (also called primary asset) that represents the secondary asset, which can be image data written directly to the blockchain or an external image linked by a URL. On Namecoin, the cryptographic asset is the key/value pair of the asset’s name and its data value (the payload data of the secondary asset). On the back-end, this asset is assigned to a cryptographic token, represented by the assigned NMC address and its private key. Due to the concept of Namecoin’s expiration, this cryptographic token will change after each name update, including renewals, transfers or re-registrations. With so called custom raw transactions, it is possible to renew the asset on the existing address.

However, the cryptographic asset is unique and exists forever since its creation, all historical data values are immutably attached. For more details, see chapter Data structure and integrity as well as section Sortable tables of the connected auction platform.

Searching for NFTs

To search for existing NFTs on the blockchain the implemented console of the Namecoin Core wallet can be taken. For Core version 0.13.99 the first ten results would be shown with the following command:

name_filter nft/ 36000 0 10

Please refer to section Searching for names for further details.

Registering NFTs

For registering an NFT on the Namecoin blockchain the nft/ namespace is used. Since this namespace is dedicated for file names and their metadata, no TLD (Top Level Domain) is assigned to it. While the filename is represented by the key of your record the value shows the hash and additional info such as author and URL. With the same procedure as domains are registered, the value of the first update operation would look like the example of our video intro:

{"MD5":"93443567f2268d8826172d4df1d4d841","author":"Uwe Martens","url":"www.namecoin.pro"}

The hash can be generated easily with different tools. Using the Windows command line interface (CMD) the command looks like:

certutil -hashfile "C:\Users\Administrator\Desktop\Namecoin_has_impact.mp4" MD5

The hash is then displayed in the console. The same command is used to verify a digital file. The resulting hash needs then just to be compared with the value on the blockchain.

For more detailed methods and specifications, please refer to section Specifications​ below!

Verifying ownership

In addition to the data specified in the value data, such as the origin URL, you can verify the ownership of an NFT via the unique cryptographic signature of the corresponding Namecoin address. To generate and verify the signature, a text string specified by the requestor is signed by the owner using his NFT’s private key. Any preferred text string can be used, but it is strongly recommended to use a unique string, for example, containing the current date and time. For instance, if you consider to buy an NFT or just verify the authorship, you can ask the owner to sign the string "verify 2021-12-22 18:00:00 CET" with his NFT.

To sign and verify, you need first to request the Namecoin address to which the NFT is assigned on the blockchain. If you didn’t get the address via a blockchain explorer, you can request it via the debug window e.g. of the Namecoin Core wallet, in most wallets: ➞ Window, ➞ Console, with the following command, for example:

name_show nft/Namecoin_has_impact.mp4

As the owner of the NFT, highlight and copy the address between the quotation marks of the result to the clipboard.

Please note that the wallet has to be unlocked to generate the signature! The following command is used to create a signature for the desired text string, in our example:

signmessage NCBYAqq96N9vURmdcNFsHzkSvJuUnkSZkc "verify 2021-12-22 20:12:59 CET"

You may also sign the string via the wallet menu ➞ File, ➞ Sign message (e.g. of the Core wallet). The generated signature is a Base64 encoded string with 88 characters and needs to be submitted to the requestor, e.g. by e-mail. As the requestor of the verification, you can use the menu ➞ File, ➞ Verify message to check easily the given signature for the defined text string, or go the debug window and use the command verifymessage followed by the Namecoin address, the signature and the text string, in our example:

verifymessage NCBYAqq96N9vURmdcNFsHzkSvJuUnkSZkc H2DiycV8ns9oFIOiYVhSHYFa3TKMMYB1WD0967Sp/0T9SqFR76655aexbOj+Nz8XszIB/N35MmmRCbuTsCR0xyI= "verify 2021-12-22 20:12:59 CET"

If the verification is done via the menu, "Message verified" is displayed in the window if the verification succeeded. In the debug window the result "true" is returned.

Last but not least, it has to be mentioned that the process of signing and verifying is not limited to the nft/ namespace and can be performed with all records on the blockchain, so of course with domains as well, which are technically also a type of NFTs.

Software compatibility

The example above was generated with Namecoin Core version 0.19. Please make sure that both the verifying requestor and the signing owner of the NFT use the same software wallet in the latest version. Both Namecoin Core and Electrum light wallet are capable of signing and verification. However, if you sign a verification string in, let’s say, Namecoin Core version 0.13.99 (with the additional name tab), the verification will fail in Core version 0.19 and vice versa. If the verification fails, either the owner of the NFT or the requestor would have to change their software version.

Please note further that the signing and verification process is enabled for records assigned to P2PKH legacy addresses (pay-to-public-key hash) in Base58 format only. Bech32 addresses (starting with nc1...) aren’t supported for now. This issue comes from the underlying Bitcoin code and will be fixed with BIP 322.

Under all circumstances, please note the section Upgrades, Backup & Restore on the Downloads page!

Specifications

NFT records typically include, at a minimum, a link to external media as seen in traditional historical NFTs, along with the file's cryptographic hash. However, more valuable NFTs store the actual payload, such as raw image data or other assets, directly on the blockchain, ensuring greater permanence and security. On-chain assets that do not exceed the maximum data value size of 520 bytes can be stored as hexadecimal raw data in a single data value, followed by the closing declaration record (NMC-B Standard).

Assets whose size exceeds the maximum data value size can be split into multiple parts (NMC-H and NMC-V​ Standard). Therefore, the file must be converted to a byte stream and stored in chunks no larger than 520 bytes. This is best done using Windows PowerShell with the FileSplitter module, which needs to be installed with the PS command:

Install-Module -Name FileSplitter

Afterwards, the parts can be generated, e.g. for the file Namecoin_Logo.svg, with the command:

Split-File "C:\Downloads\Namecoin_Logo.svg" -PartSizeBytes 520

Note that a single byte represents one ASCII character (such as a letter, number, or punctuation mark), and each byte itself ​is composed of two hexadecimal digits, ranging from 0-9 and A-F. Therefore, while a data value of 520 bytes contains 520 ASCII characters, it is represented by a hexadecimal string with a length of 1,040 digits.

So with the command line start parameter (or the name operation option) set to -valueencoding=hex, the parts can then be written to the Namecoin blockchain in two different ways. For the available methods and standards, see the specifications below:

Common Standard

• The filename of the on-chain asset MUST be in the nft/ namespace, so the name of the cryptographic asset consists of the nft/ prefix followed by the filename (e.g., nft/quantum.gif).

• The filename MUST follow the general file naming conventions of common computer systems, so it can contain Latin and non-Latin alphanumeric upper- and lowercase characters, spaces, dots (.), hyphens (-), and underscores (_).

• The final data value (declaration record) of the asset​ MUST include the hash of the file with either the JSON-formatted declaration "MD5" or "SHA256" (case-insensitive) for comparison with the reconstructed file.

• The entire dataset may be updated with a new cycle of data fragments, resulting in a new version of the on-chain asset.

• On regular maintenance updates (renewals, recommended between 500 and 400 blocks to go), the finalized asset SHALL be updated with the declaration record, otherwise it will no longer be recognized as an on-chain asset by the connected blockchain explorer.

• The NFT standard may be switched from one to the other, while the last one will be recognized by the blockchain explorer.

• A combination of all standards would be possible to speed up the minting process, but for now, only the partial records in the NMC-V standard would be recognized by the blockchain ​explorer.

NMC-B Standard

The basic way to mint smaller NFTs on the Namecoin blockchain is to create one single raw data record followed by the declaration record. Since this NFT consists of one basic raw data record, this NFT standard is called Namecoin Basic (NMC-B).

• The declaration record MUST include the JSON-formatted key "hex-data" and the sub-key "TxID" (case-insensitive) with the specification of the TxID (transaction ID) of the raw data record. The declaration of the raw data SHALL be preceded by the sub-key "Size" (case-insensitive) with the specification of the size in bytes. Example record nft/punk9999.png:

"Hex-data": {"Size":"200 bytes","TxID":"6958f36ff48b9629b130aedf9fd7585df565b0c289bda5e01e84b741ca442b92"}

NMC-H Standard

The classic (legacy) way to mint larger NFTs on the Namecoin blockchain is to create multiple records and declare their range in the main record. These partial records then exist side by side (horizontally) on the blockchain, so this NFT standard is called Namecoin Horizontal (NMC-H).

• The declaration record MUST include the JSON-formatted key "hex-data" (case-insensitive) with the specification of the range of the parts separated by a hyphen (-) to define the dataset, first data fragment first. The name extension of the parts MUST be .part with the numbering in front separated by a dot from the main file name. Example record nft/Namecoin_Logo.svg:

"hex-data": "nft/Namecoin_Logo.svg​.00.part - nft/Namecoin_Logo.svg.10.part"

The naming specification for​ the data fragments is applied by the PowerShell FileSplitter module by default.

NMC-V Standard

The alternative and more advanced way to mint especially larger on-chain NFTs is to store the data fragments in the update history of the record itself and declare the range of transactions (TxIDs) in the final declaration record. These partial data records then exist one below the other (vertically) in the update history, so this NFT standard is called Namecoin Vertical (NMC-V).

• The direction of the update history MUST be first data fragment first, ideally starting already with the name_firstupdate OP followed by the subsequent parts.

• The final record MUST include the JSON-formatted key "hex-data" with the declarations (sub-keys) "Entry TxID" and "Final TxID" (case-insensitive) to define the dataset, first data fragment first. The declaration of the raw data set SHALL be preceded by the sub-key "Properties" (case-insensitive) with the specification of the size in bytes and the total number of data fragments. Example record nft/quantum.gif:

"Hex-data":{"Properties":"8.86 MB (9,296,824 bytes), 17879 parts","Entry TxID":"3774e346b46d5531cc960355a1ad35b4a2984290a0731f3f9dea131ec2fbcf8a","Final TxID":"b87c586088daa511dbb5da63c8aa8795304a1a11af5d2bf69c02a16b9d308cdf"}

• All updates of a dataset, including the name_firstupdate OP, the closing declaration record and all subsequent renewals, SHALL be done on the same token (NMC address of the colored coin) via custom raw transactions. This satisfies the sometimes strict interpretation of the term "non-fungible token" by some community members, and furthermore helps keeping the key-pool and thus the wallet file small.

Extended declaration, NMC-V+ Standard

The NMC-H and NMC-V standards render the 520-byte limit for on-chain data obsolete in many contexts. However, this limitation still applies by default to the declaration record of an NFT and to regular Web3 ID records. Since the declaration record of an NFT closely resembles the structure of a typical Web3 ID, containing structured links and data to be shown in the block explorer, it is possible to apply the NMC-V standard to these records themselves. This enables splitting them into multiple records, each adhering to the 520-byte limit, within the asset’s update history as well, followed by the closing extension record defining the range of update transactions.

As this extended declaration applies to payload datasets minted under various standards while adhering to the NMC-V Standard itself, this extension is called NMC-V Plus (NMC-V+).

• The extended declaration may be applied to all NFT standards (NMC-B, NMC-H, and NMC-V) as well as to regular Web3 IDs across all namespaces.

• The order of the update history MUST follow a "first data fragment first" sequence.

• The closing extension record MUST include the outer JSON-formatted key "NMC-V declaration", followed by the inner declarations (sub-keys) "Entry TxID" and "Final TxID" (case-insensitive), first data fragment first. Example record namecoin.nmc:

{"NMC-V declaration":{"Entry TxID":"41ffe8f0dc19f021ebeba098621b239145ce7f041d7440c0db3f1bffa8a37194","Final TxID":"fa4fb6fcf1e92fe5f29481dd51e5549b5d4d90306210717b58a278523623bb3c"}}

• All updates to an NFT containing payloads, such as image data, prior to the extended declaration, including the closing extension record and all subsequent renewals, SHALL be executed on the same token (the NMC address of the colored coin) using custom raw transactions. Example record in the nft/ namespace: nft/Comedian.jpg

When applied to a regular Namecoin domain, this extension allows for the storage of unlimited structured text, including headers, subheaders, and links to connected records, thus hosting an on-chain blog entirely using Namecoin’s blockspace, mined and secured by the Bitcoin network. Call the emoji domain 💎🙌🏻.crypto to see the first-ever blog post minted fully on-chain with a total size of 4310 bytes.

To browse domains and ID records formatted in the NMC-V+ standard, you may take the connected Asset Viewer, which automatically renders the data in its JSON structure.

Proof of Minting (PoM)

Please note that only 25 pending updates can be broadcast at a time. While it is technically possible to generate and broadcast an unlimited number of successive updates using a series of undocumented command-line start parameters, these long chains of unconfirmed transactions would not be accepted by the mining nodes as they use the default settings to avoid flooding the network.

Furthermore, it should be noted that in most cases it will take two blocks to confirm a batch of 25 transactions. The timestamp written to the blockchain does not (and cannot) reflect the exact moment a new block is finalized. Instead, it marks the point at which the mining node takes a snapshot of the current mempool. Due to merged mining with Bitcoin, the snapshot cycles of both chains are asynchronous, typically resulting in two different timestamps that can differ by a few minutes. Below a recent example of two Namecoin blocks:

Block 736153

Timestamp: Tuesday 10th of September 2024 12:25:55 (GMT/UTC)

Blockhash: 5cde2e02dbf39717247845e79a9edf002ad5bf20e48fb5fc02488006313a507b

Parent-Timestamp: Tuesday 10th of September 2024 12:37:33 (GMT/UTC)

Parent-Blockhash: 000000000000000000039d605853d96b1a4b7c1dec51056845614d4f856de5d6

Block 736154

Timestamp: Tuesday 10th of September 2024 12:37:40 (GMT/UTC)

Blockhash: 63a414392115ee227fa281b9b83281ae286273a6fbae39108959960f5fa2a157

Parent-Timestamp: Tuesday 10th of September 2024 12:51:15 (GMT/UTC)

Parent-Blockhash: 000000000000000000030df2370a5e2c5587cb9a6efc6e69068d485874a554af

The submission of a new batch of updates to the Namecoin network depends on a third timestamp: the local receipt time of a new block, which is written to the debug log and aligns with the timestamp of the next (future) Namecoin block. This receipt time may vary by an additional 50-150 milliseconds on average across different geographic locations. Due to this latency in global synchronization and the instantaneous start of the mining process with the propagation of the last block, along with the asynchronous nature of merged mining, the new chain of transactions often does not reach the mining nodes’ mempool in time to be included in the next block.

So for larger files of a few MB, it can take up to a week to mine the entire NFT. This time commitment introduces an inherent Proof of Work (PoW) mechanism, requiring the creator to thoughtfully engage in the minting process particularly for larger NFTs, thus specified as Proof of Minting (PoM). The effort required to mint larger NFTs naturally limits their quantity, fostering scarcity and driving demand for premium assets. It also prevents oversaturation by low-effort collections and preserves the integrity of both the P2P network and the blockchain.

A prime example of the risks of unregulated minting is the ’Ordinals’ overload on Bitcoin, where the lack of deterrents beyond miner fees allow users to flood the mempool and bloat block space with mass-produced NFTs and excessive payload data. This Layer 2 overlay protocol assigns imaginary units of numbered satoshis to claim ownership of payload data hacked into the invisible witness data fields of unspendable transaction inputs, limited by Bitcoin’s virtual block size limit of 4 MB. This technological nonsense ​​regularly overwhelmed Bitcoin’s network and undermined its primary purpose – facilitating payments.

Namecoin, launched in April 2011 as a sidechain of Bitcoin, was specifically designed to handle non-payment data, offloading these transactions from Bitcoin’s parent chain. So by design, Namecoin NFTs are entirely based on Layer 1, written directly to the transaction’s output and cryptographically tied to the access token. Moreover, minting NFTs on Namecoin following the NMC-V standard imposes no inherent technical size limit, not even restricted by the maximum block size, since the data is distributed across multiple blocks.

Explore and restore our historic Namecoin and Bitcoin logos, along with rare collectibles and utility assets, such as whitepapers and executables, preserved in the NFT Time Capsule!