<pre>
  PIP: PIP-0044
  Title: Induplicatable NFT
  Type: Protocol
  Impact: Hard-Fork
  Author: Albert Molina <bpascalblockchain@gmail.com>  
  Copyright: Albert Molina, 2023 (All Rights Reserved)
  Comments-URI: https://discord.gg/Scr8mcwnrC (Discord channel #pip-44)
  Status: Proposed
  Created: 2023-03-14
</pre>

## Summary

NFT (Non-fungible-token) is a well known item in the blockchain industry. It's currently based on store the item (usually a HASH of a information) in the blockchain as a Proof-of-ownership of the item.

This means that this HASH of the item is stored in a transaction included in a block, and what really is used for transfers (buy/sell transactions) is a reference of the transaction, so **there is no warranty/prevention that same NFT HASH is stored in other blocks/transactions**

A true NFT must be something that is impossible to be duplicated, so we present a way to store Induplicatable NFT on the blockchain because the HASH will live on the Safebox struct (that is a representation of the ledger balance of the blockchain information) and **HASH will be induplicatable** on Safebox struct, **converting NFT owner in a PASA owner**

Also, thanks to Safebox current features, this Induplicatable NFT can be sold using same on-chain transactions mechanism without third party neither single point of failure (PIP-0002 - In-protocol PASA Exchange)

## Proposal

This PIP specifies how to use current Safebox struct and operations to store Induplicatable NFT on the PascalCoin blockchain

- Safebox PASA's has Account Names and Types as described on PIP-0004, that allows to store unique Account Names in the safebox

- Implementation of PIP-0004 limited Account Name to be Null or 3..64 characters long
 
- Implementation of PIP-0004 prevents first char to be a number ('0'..'9') to not confuse name as an account number

In order to use Account Name as a HASH, we must do one of proposals:

- Without protocol upgrade:

  - **Option A**: Use a "encode"/"decode" function to convert first char in a numeric/non-numeric char like convert "`ghijklmnop`" as "`0123456789`" for first char, so hash `9a737f6e41c58935c535fe7b08426006f246986810c21deeb808cc564b8ecdca` will be encoded to `pa737f6e41c58935c535fe7b08426006f246986810c21deeb808cc564b8ecdca` (transform 9 -> p)

- With protocol upgrade (Hard fork):

  - **Option B**: Start hash value with a suffix like "`nft_`" because first char cannot be an Hexadecimal numeric number, in this case the 64 characters length is a limitation because we cannot store 32 bytes hash plus suffix length in 64 chars

  - **Option C**: Allows usage of numeric first char when name is a representation of a 32 bytes hexadecimal value


This PIP-0044 will implement **Option C** allowing first char as a numberic "0".."9" char when name contains a 32 bytes (64 chars) hexadecimal value, this will prevent to use first number as an account number caused to overflow

## Implementation

```
  // Update ValidAccountName function introducing this exception:
  ...
  if (new_name[0] in [Ord('0')..Ord('9')]) then
    if (protocol_version>=CT_PROTOCOL_6) and
       (length(new_name)=64) and
       (IsHexadecimal(new_name))
    then continue
    else Error('Invalid numeric first char on a non-hash hexadecimal 32 bytes representation');
  end;
```

## Backwards Compatibility

This change is not backwards compatible and requires a hard-fork activation. 