forked from PascalCoinDev/PascalCoin
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #72 from PascalCoinDev/master
PIP-0044 - Induplicatable NFT
- Loading branch information
Showing
8 changed files
with
120 additions
and
46 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
<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 i 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) | ||
|
||
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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters