​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​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 f​rom 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 specify 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"
}

• The "Hex-data" key defining the range of TxIDs for an asset in the nft/ namespace MAY be nested within outer JSON instances to allow for flexible structuring of the asset's properties. The data will be rendered and formatted by the connected block explorer​, example record: nft/Comedian.jpg.

However, unlike the application in the nft/ namespace, using the NMC-V Standard for Web3 content creation in all other namespaces will render the declaration record invisible, so any data beyond the range declaration would be unused data ballast. Therefore, if used for payload reconstruction in all other namespaces, the "Hex-data" key MUST be the outer JSON instance, while​​ a finalizing declaration record is required in the NMC-V+ Standard​.

• Instead of a single transaction pair, the declaration record MAY optionally contain an array of multiple TxID ranges, consisting of the JSON-formatted key "Hex-data" with the subordinate array "Ranges" in square brackets, defined by the declarations (sub-sub-keys) "Entry TxID" and "Final TxID" (case-insensitive, JSON objects in ​curly brackets) to define the datasets, first transaction pair first. Each range specifies a contiguous sequence of transactions, listed in the order of readout. This allows reordering, skipping, and partial reuse of data that has already been written to the blockchain, concatenating it with updated or new datasets in any order. This helps in maintaining larger data records, e.g., updating specific sections or correcting minting errors without re-minting all data, while reducing blockchain bloat and retaining full data integrity.​ Example record nft/punks.png:

​​​"Hex-data": {
  "Properties": "828 kB (848,174 bytes), 1632 parts",
  "Ranges": [
    {
      "Entry TxID": "5d87f82675a8f103f16b8cdd0f4ddf1527675c1b61d9af7f3cbac0325d3a4e56",
      "Final TxID": "d49b1578d916ed97a42110f1aa18594b86f04ab475897790956077f4ca6dfd90"
    },
    {
      "Entry TxID": "803cdf07829b4ca83a8a631b342b4384fbd56e400d23076db7a3fd18a8ed1041",
      "Final TxID": "1b4d07488332ec03b3a705429e351e9cc6c94a99f16cd7a60dee3b2dc88f2cdd"
    }
  ]
}​

Depending on other data written to the declaration record, such as descriptions and URLs, the specification of transaction ranges may require an extended declaration record in the NMC-V+ Standard​ to adhere to the standard data value size of 520 bytes.

• The declaration of ranges MAY contain one single TxID defined by the JSON key "TxID" at any position, e.g.:

​​​"Hex-data": {
  "Properties": "828 kB (848,174 bytes), 1632 parts",
  "Ranges": [
    {
      "Entry TxID": "5d87f82675a8f103f16b8cdd0f4ddf1527675c1b61d9af7f3cbac0325d3a4e56",
      "Final TxID": "d49b1578d916ed97a42110f1aa18594b86f04ab475897790956077f4ca6dfd90"
    },
    "TxID": "803cdf07829b4ca83a8a631b342b4384fbd56e400d23076db7a3fd18a8ed1041"
​  ]
}​

• The declaration of ranges MAY be simplified by omitting ​the keys "Entry TxID", "Final TxID" and "TxID". In this case, a range MUST be defined as a sub-array of two TxIDs in square brackets, while single TxIDs are just defined as strings. This is useful for larger declaration records or when defining more than one single TxID:

​​​"Hex-data": {
  "Properties": "828 kB (848,174 bytes), 1632 parts",
  "Ranges": [
    [
      "5d87f82675a8f103f16b8cdd0f4ddf1527675c1b61d9af7f3cbac0325d3a4e56",
      "d49b1578d916ed97a42110f1aa18594b86f04ab475897790956077f4ca6dfd90"
    ],
  "803cdf07829b4ca83a8a631b342b4384fbd56e400d23076db7a3fd18a8ed1041",
    "1b4d07488332ec03b3a705429e351e9cc6c94a99f16cd7a60dee3b2dc88f2cdd"
​  ]
}​

• Defining particular ranges the simplified way as JSON sub-arrays (in square brackets) or single TxIDs without explicit keys may be intermixed with ranges defined as JSON objects (key–value pairs in curly brackets). However, consistency should be preserved as far as possible. It should also be considered that explicitly defined keys provide additional information since all JSON data is rendered by the connected ​block explorer​. This usability aspect of formatted JSON rendering is also why the specification of keys such for the ranges deviates from a purely technical naming convention (such as lowercase and underscore instead of whitespace). This approach prioritizes readability without breaking JSON decoding or compliance with general JSON specification.

• 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 for any kind of data. 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"
  }
}

• Instead of a single transaction pair, the extended declaration MAY optionally contain an array of multiple TxID ranges, consisting of the JSON-formatted key "NMC-V declaration" with the subordinate array "Ranges" in square brackets, defined by the declarations (sub-sub-keys) "Entry TxID" and "Final TxID" (case-insensitive, JSON objects in ​curly brackets) to define the datasets, first transaction pair first. Similar to the specifications for payload reconstruction (using the JSON key "Hex-data" following the NMC-V Standard), each range specifies a contiguous sequence of transactions, listed in the order of readout:

​​​"NMC-V declaration": {
  "Ranges": [
    {
      "Entry TxID": "ff813aa26732c9ca90a67b9c6b3af5f048c5f85404dedbf19c8ad57e0e56e814",
      "Final TxID": "c0b0ed52c81b2caaf397ed168edb55fec331cd30e75b938a67a25287569ad596"
    },
    {
      "Entry TxID": "fe94a7efb3641332c15247f2d2a143b2cf88858378b81273502f164a79877770",
      "Final TxID": "d529b2aa82cdf298bd38d640c590e49525933b37e2d202c4e95e6606765fabcf"
    }
  ]
}​

• The declaration of ranges MAY contain one single TxID defined by the JSON key "TxID" at any position, e.g.:

​​​"NMC-V declaration": {
  "Ranges": [
    {
      "Entry TxID": "ff813aa26732c9ca90a67b9c6b3af5f048c5f85404dedbf19c8ad57e0e56e814",
      "Final TxID": "c0b0ed52c81b2caaf397ed168edb55fec331cd30e75b938a67a25287569ad596"
    },
    "TxID": "fe94a7efb3641332c15247f2d2a143b2cf88858378b81273502f164a79877770"
​  ]
}​

• The declaration of ranges MAY be simplified by omitting ​the keys "Entry TxID", "Final TxID" and "TxID". In this case, a range MUST be defined as a sub-array of two TxIDs in square brackets, while single TxIDs are defined as strings. This is useful for complex declaration records or when defining more than one single TxID. Example record namecoin.crypto:

​​​"NMC-V declaration": {
  "Ranges": [
    [
      "ff813aa26732c9ca90a67b9c6b3af5f048c5f85404dedbf19c8ad57e0e56e814",
      "c0b0ed52c81b2caaf397ed168edb55fec331cd30e75b938a67a25287569ad596"
    ],
  "fe94a7efb3641332c15247f2d2a143b2cf88858378b81273502f164a79877770",
    "d529b2aa82cdf298bd38d640c590e49525933b37e2d202c4e95e6606765fabcf"
​  ]
}​

• Defining particular ranges as JSON sub-arrays (in square brackets) or single TxIDs without explicit keys may be intermixed with ranges defined as JSON objects (key–value pairs in curly brackets). However, consistency should be preserved as far as possible.

• The extended declaration using ranges MUST adhere to the 520-byte restrictio​n for name update operations. This allows for the definition of a maximum of three transaction ranges and one single TxID for declaration reconstruction if using the simplified syntax without JSON keys.​ However, if the extended declaration is directly ​used for Web3 IDs containing larger link containers or for general Web3 content creation, such as block posts, the declaration of multiple datasets using the NMC-V+ Standard may exceed this limitation. In this case, the content must be outsourced to the preceding payload reconstruction using the JSON key "Hex-data" to define the datasets following the NMC-V Standard. In this case, the key "NMC-V declaration" must be changed to "Hex-data"​, and a new NMC-V+ declaration appended to define the preceding NMC-V declaration. Such content will be rendered by the connected ​block explorer as well as by the Asset Viewer​.

• Even if the declaration record for Web3 IDs and block posts does not exceed the 520-byte data size of a name update operation, it MUST be declared as "NMC-V declaration" indicating the NMC-V+ Standard for declaration reconstruction. So direct payload reconstruction using the "Hex-data"​ key indicating the NMC-V Standard is reserved for the nft/ namespace and will be rendered by the ​block explorer only.

• 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.

Web3 content creation

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. To generate the JSON code of your text-based content, please refer to the Namecoin JSON Editor​, designed for extended IDs, blog posts and declaration records! The WYSIWYG editor with integrated UTF-8 to hex converter provides a live preview of how your NMC-V+ formatted content will be rendered by the Asset Viewer.

For sharing your post on social media, the Asset Viewer dynamically renders the relevant HTML meta tags based on the content of your post. The headline and title will be taken from the first H1 header in the post. The description will be extracted up to 160 characters from the first JSON value found. To define the author meta tag, your post must contain an H1 header titled "Author", followed by your name or pseudonym, optionally by any other data you would like to include. Up to two additional author's data, such as your Web3 ID, will be included in the meta tag. All JSON data are supported up to an H3 header.

To define your desired keyword meta tags, your post must contain an H1 header titled "Keywords", followed by keywords or keyword pairs separated by commas or semicolons. For readability, the keywords may be separated by an additional whitespace. Keywords exceeding a total length of 255 characters will be skipped. For the image meta tag, the identicon shown in the header will be taken, which is generated from the SHA-256 hash of the asset’s name. This way, each identicon is unique since the asset’s name can only exist once on the blockchain.

Please also see the announcment ⚙ New Minting Standards​ with additional facts around the specifications!

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!