From: Aymeric Vitte <aymeric@peersm•com>
To: Vincenzo <vincenzopalazzodev@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Bitcoin NFT System
Date: Thu, 5 Jan 2023 11:46:59 +0100 [thread overview]
Message-ID: <53fcbcb8-8ad7-3742-1682-ee12e8c449d8@peersm.com> (raw)
In-Reply-To: <CPJPI27V6A4M.3R8QVF5TRF4K3@vincent>
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
Hi Vincent,
Indeed the gist was recorded (by mistake) as secret but the link is
supposed to work anyway, I have made it public, thanks for confirming
that it's working now, just in case I am attaching the text file
Regards
Aymeric
Le 04/01/2023 à 21:59, Vincenzo a écrit :
> On Thu Dec 29, 2022 at 5:49 PM CET, Aymeric Vitte via bitcoin-dev wrote:
>> I am not a fan of NFTs as currently designed and used, centralized,
>> insecure, duplicable, virtual, stealable, not signed, expensive
>>
>> But if you consider that a NFT is anything that you can buy or store, as
>> something real, or electronic, or whatever, in the real world, web or
>> metaverse, then it becomes interesting
>>
>> NFTs are mostly used on Ethereum, and a "mess" to describe this stuff is
>> a weak word
>>
>> Then I wrote: "A Bitcoin NFT system":
>> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 ,
>> decentralized, secure, not expensive
>>
> The link is gone or just private.
>
> Cheers!
>
> Vincent.
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
[-- Attachment #2: nft.txt --]
[-- Type: text/plain, Size: 18748 bytes --]
# A Bitcoin NFT system
## Introduction
NFT is another barbarous name invented by the crypto folks meaning quasi nothing, by NFT in this proposal we will refer to whatever can be sold or referenced from the real world, web and metaverse using a blockchain system
The easy way solution is usually to use Ethereum, create some NFT tokens via ERC-721/1155 contracts and/or use some marketplaces such as Opensea which always lead to a centralized and insecure system that can collapse at any moment, and which is still complicate since nobody understand what is behind, fortunately (or not) MetaMask will do the job for you without you understanding what you are doing, like wrapped ETH
This is explained here: [Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e)
Especially: [tokens and sidechains](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-2-tokens-and-sidechains)
And: [Opensea](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-6-opensea)
## Purpose
The purpose of this proposal is to propose <b>a simple NFT system based on the Bitcoin blockchain</b>, assuming that the main purpose of a NFT is to be sold/bought, but not only, it can be something that you keep for yourself proving your ownership on the blockchain, the advantages compared to using Ethereum or any blockchain/sidechain on both networks (or others) will be explained below
## Referencing a NFT
A NFT can be a physical good, an electronic item (such as image), something virtual or not, in fact anything
If we take a document or an image, a simple reference to the NFT is its hash (SHA-256), but it is not really relevant since it's easy for a thief to slightly modify the document or image which will lead to a different hash
Now in what follows we will allocate a hash to reference any NFT
## The final hash reference to a NFT
Depending on the conditions the hash can be known (public marketplace for example) or unknown (only the buyer and the seller know it or the owner)
Thererfore the reference to the NFT will be the SHA-256 of its hash, which then hides the original hash, this is of course useless if the hash is known but let's keep the same convention, called |reference| in what follows
## Minting a NFT on Bitcoin
"Minting a NFT" just means to record your ownership of the NFT in the blockchain
To mint a NFT that you own on Bitcoin, you can do a transaction whose output will be:
From address A (the seller):
OP_RETURN |reference|
DUST (A or B) or refund to an address of yourself (A or B)
Since the transaction is signed by A, we know that A is the owner of the reference, but note that from this point the public key of A is known, therefore if the purpose is to store a long term NFT then use another address B of yourself (because in some time it will be easier to crack a bitcoin address for which we know the public key rather than one that holds some bitcoins but has not been spent, so knowing only the hash of this address)
An OP_RETURN output is just something where you can store some data, limited to 512B
A lot of variations are possible in this article, for example you can decide to allocate one A address per NFT, it just depends on the use cases
For all the transactions mentioned in this article, opt-in for Replace By Fee must not be used [Replace By Fee](https://bitcoin.fr/replace-by-fee-rbf/)
It would be possible not to use OP_RETURN and for example store the |reference| in scriptSig, then construct an address (scriptPubKey) that will drop it while executing, but this would be a non standard transaction, so you shoud rely on some miners to mine it, without stealing your NFT, since it's easy for a miner to change the transaction and mint the NFT for himself
## Minting several NFTs in one transaction
You can do the very same using the Chainpoint protocol, which is to build a Merkle tree from |reference1| |reference2|....|reference N| (for which we recall will be the SHA-256 of the original NFTs hash), and replace the root of this tree in |reference| above
How Chainpoint work is well described here: [Chainpoint Proof](https://github.com/chainpoint/whitepaper/issues/5#issuecomment-304452107), basically while making a Chainpoint tree you get a proof to rebuild it from any |reference| (that you must know), which is just the other hashes that you need to know to reach the root
In that case only the owner of the multiple NFTs knows the proofs and/or the |references|, unless he decides to release them, which he should do as described in the next paragraph (because the hashes and proofs must be known to check the validity of NFT transfers)
In what follows we will make reference to a Chainpoint |reference|
## Avoiding double minting
Double minting of NFTs is quite trivial, as far as we know there are zero protections against this in existing systems (Ethereum and others), the principle is simple: you mint several time the same NFT and possibly sell it several time or get robbed (the thief does transactions using the |reference| that he saw), because it's easy for a malicious person to do the very same transaction that you did and pretend the ownership of the NFT, or it's easy for you to mint it to different marketplaces or mint it several time, and then sell it several time
To illustrate this, read [Solving the double minting problem](https://medium.com/geekculture/solving-the-nft-double-minting-problem-with-computer-vision-c57bbbb4652d)
Unfortunately the above article just refers to images and the solution does not work at all at the end, because associating the picture to the camera or whatever that took it does not work and is easy to fake
Coming back to our bitcoin case, it seems simple to elect you as the real owner of the NFT since you made the transaction first, then based on the timestamp you are definitely the owner, but no
The thief could intercept your transaction, decide not to broadcast it further, replace it by a transaction minting your NFT for himself, with higher network fees for example and more direct access to miners, then this transaction will be the first one and the thief would have stolen your NFT
You can't do anything against this without using a third party to record that you had the knowledge of the |reference| first
The same problematic exists for example for js code loading, see [Bitcoin-transactions wallet/tools](https://peersm.com/wallet), here our github account is used to check the code
Then the very same is proposed here, preferably using the [Wayback Machine](https://archive.org/web/) to store |reference| (that you are the only one to know at this stage) signed by A before minting the NFT, then for sure you are the owner of the NFT because you are the first one to have referenced |reference| and signed it with your address (note again that as soon as you sign something the public key of A is known)
You can use other systems, github, even Twitter
What if all of those systems disappear and I can't prove anything any longer? Well, then probably internet has disappeared too
Anyway like the WebRTC peer introduction mechanism you can do this by any means you like, your own website, even a letter, you just need to prove that A had the knowledge of the double hash first
Now the double minting case is supposed to be marginal, except if you are a thief yourself
## Transferring a NFT for free
For a gift or whatever other reason, A can decide to transfer a NFT for free to C, the transaction will be:
From address A (the seller):
OP_RETURN |some code||reference|
DUST (C) and refund to an address of yourself (A or B)
|some code| is just used to make the distinction between a minting operation
A sends the original hash to C
## C Buying a NFT from A
The transaction will be:
From address C (the buyer):
OP_RETURN |price||some code||reference|- signed by A
|price| to A and refund to C or other C address
Once A and C have agreed on a price then A should send to C the |price||some code||reference| signed by him, which proves that the deal is accepted
If C tries to cheat and does broadcast a transaction that does not match the agreed price (since C cannot fake the signature of A), then C is still not the owner of the NFT and has lost its bitcoin, if a thief intercepts the transaction and does another one for himself, that's the same, since he is not willing to pay for the price
If A receives the correct amount, then he will send to C the original hash of |reference|, the same principle applies for all following transactions
We can not really enforce this, A could not send the hash, but for what purpose? This represents the same trust model than when you are buying some goods (the hash is the ticket), now in normal conditions the original hash is not really mandatory
Note that we know from minting/signing the public key of A, therefore anybody can verify the signature in the OP_RETURN
Note again that the signature of A is enough to know its public key and check the signature, <b>therefore minting is not mandatory</b> (depending on the use cases again)
Note also that in Ethereum style, that's the other way around, where A would initiate the final transaction to the NFT contract that will transfer to C
## C selling a NFT to D
That's the same:
From address D (the buyer):
OP_RETURN |price||some code||reference|- signed by C
|price| to C and refund to D or other D address
C sends the original hash to D
## C Buying a NFT from A from a Chainpoint |reference|
A sends to C the |price||some code||reference||Chainpoint proof| signed by him, C then do the following transaction:
From address C (the buyer):
OP_RETURN |price||some code||reference||Chainpoint proof|- signed by A
|price| to A and refund to C or other C address
## Group/organization C of buyers
C is then a multisig address funded by the group, and as before:
From address C (the buyers):
OP_RETURN |price||some code||reference|- signed by A
|price| to A and refund to C or other C address
Same principle would apply for Chainpoint |reference|
## But, in all of this, what is the purpose of the double hash for |reference|?
Just to hide (if applicable) that the hash is only known by the buyer and the seller if the transactions are correct, then if anything unexpected happens they can prove that they are the only one to know the original hash of the NFT
We can take here the example of Kering (luxury group): [Kering NFT solution](https://www.ulysse-nardin.com/zh_en/blockchain-technology ), this is a variation of what is proposed here, when you buy a luxury product you get a certificate, then you go to their website, use the certificate information + your name & co, then you get a second certificate and the associated hash, the hash is then stored in the bitcoin blockchain in an OP_RETURN using the Chainpoint protocol via [Woleet](https://www.woleet.io/fr/accueil/) service
So here you are the only one to know the hash (with Kering), the problem of this solution is that it is very centralized and you can't correlate the hash to the product. That's where the double hash method could be used, you print on the luxury product the double hash (QR code or whatever) and give the original hash to the buyer, then if the product is counterfeit (with the same double hash) or stolen you can detect it since the malicious seller does not know the original hash
## Costs
Currently the network fees are 6-12 satoshis per byte, and the dust limit can be set at 546 satoshis
It's not possible to give a precise number here since the transactions depend on the number of inputs but an [estimation](https://www.bitstamp.net/learn/blockchain/how-are-btc-transaction-fees-determined/) would be less than 1 USD per transaction (probably 0.5 USD) against 70 to 100 USD on gas fees in Ethereum
This is far less than Ethereum NFT tokens see [Moxie experience](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-7-moxies-experience)
## Is this system centralized?
No unlike whatever exists about sidechains (except Lightning), Ethereum NFTs or Dstuff, it is not, because you do not rely on any centralized platform to use it (the third party is the one you choose and it can't interact with the transactions), or Oracles that would be involved in your transactions creation/confirmation/transfer
## Is this system anonymous?
Not totally as currently designed, like Lightning again, since buyer/seller must "know" each others, but they can do it via anonymous means like Signal, Protonmail, Telegram or other stuff, or Tor, the advise is to create a new good old gmail address for this purpose and use PGP keys
In any case others around do not know what is going on
## Why not a super sidechain instead?
You can read this conclusion from a previous article: [Conclusion](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#conclusion)
We have different examples, but let's take a few, Binance Smart Chain, supposedly compatible with Ethereum is a mess (or FTT/FTX token, see [Collapse of FTX and others: the Fxcking Token Theory](
https://www.linkedin.com/posts/aymeric-vitte-05855b26_the-fxcking-token-theory-as-a-coincidence-activity-6996493598653317120-vCpA)), and [Stacks](https://protos.com/what-is-stacks-and-does-it-really-serve-as-defi-for-bitcoin/) for Bitcoin supposedly allowing "smart contracts" and NFT on bitcoin is the same, both centralized, insecure, making it difficult to swap the tokens between one chain to another
Let's hope this article shows how powerfull (and less costly) is bitcoin, if we elaborate on Stacks it's another blockchain on top of Bitcoin, they register the blocks inside OP_RETURN in Bitcoin via a "proof of transfer". Why do they do this? No idea but surely because their blockchain is neither secured neither decentralized, this is just flooding the Bitcoin network with useless transactions duplicating proofs on two blockchains
There are many "proof-of-whatever" that are just fake stuff (like Filecoin proof of replication https://github.com/protocol/research/issues/4), useless, quite dubious, as stated in our conclusion above the intermediate states shoud be burned and only the final/relevant result stored in Bitcoin, this is very exactly what is doing Lightning
In any case, whatever sidechain/blockchain is proposed can only lead to something funny, because even the worldwide networks bitcoin and ethereum are still not decentralized today, despite of their age, because something like a few thousands nodes is not what we can call a decentralized system, then proposing something decentralized on top of it or not does not look serious, the only real decentralized network remains Bittorrent
This proposal seems to contradict one of our article [How stablecoins really work (Tether example), how to crack them and why you should take care if you use them](https://www.linkedin.com/pulse/how-stablecoins-really-work-tether-example-crack-them-aymeric-vitte/), but no in fact since everything is signed here
## Local Bitcoin
We will not talk here about the craziness of the Bitcoin forks period, which we have described here: ["Bitcoin Tartuffe - User guide: How to create your bitcoin fork in 5mn, fool everybody and become rich](https://www.linkedin.com/pulse/user-guide-how-create-your-bitcoin-fork-5mn-fool-everybody-vitte)
But we can envision a local Bitcoin, which would be limited to an area and is just a fork of the Bitcoin code (and not the Bitcoin network), restarting from the beginning
Then it's possible to adapt the rules according to the local area, for example reducing the costs by eliminating the dust limit, network fees by mining at lowest difficulty, unlimited supply and no halving
This seems to contradict the good practices of Bitcoin but not really, since the area is limited to people that are supposed to cooperate together, then the risk of attack is limited also
You might say that we are criticizing in [Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e) the fact that most of ERC-20/NFT tokens are of zero value, because coming from nowhere, but we are proposing the same
Not exactly, the local Bitcoin could be seen as a barter money, with a stable value, mined by everybody in the area, then unlike ERC-20 tokens you cannot issue 1 Billion of them all of a sudden
It remains decentralized since everybody is participating and get rewarded according to the probability distribution
To a certain extent, since the local area management might decide to shut down the system
An example is a cruise boat (who might have limited connectivity to interact with an outside blockchain and is not willing to burn its batteries with mining) where each element of the boat (cabins, kitchen, etc) would mine the local Bitcoin, then you can buy/exchange NFTs on the boat, services, use the token for the casino, restaurants, shops, the boat metaverse, etc
The local Bitcoin can be crawled from the outside and transactions can be sent from the outside, so, for example, luxury vendors and others can propose NFTs on board (and deliver them on board or when the boat is at some harbour), and NFTs can be proposed inside the boat shops/metaverse
Indeed since the local Bitcoin is not a fork of Bitcoin network, you don't have to implement replay protection (SIGHASH), then usual Bitcoin transactions can be built and sent to the local Bitcoin, of course you must not make mistakes between both chains
How can we bridge this with the Bitcoin network ? The first answer is: why would you need to do this? If so, then you need to use a bridge which will be of course something centralized, right now we are not aware of other possible methods (like atomic swap or other bulls)
This can apply to planes and many other local areas
## License and funding
While this work is public, it is not in the public area and under any open source license, then to use it, please contact: aymeric peersm com, PGP Key fingerprint : 65EF AE3D 973F D36A AB25 1225 2A1D 7B34 2627 AC39
The goal here is to reference who did fund this proposal
https://web.archive.org/web/20221231185645/https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
prev parent reply other threads:[~2023-01-05 11:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-29 16:49 Aymeric Vitte
2023-01-04 20:59 ` Vincenzo
2023-01-05 10:46 ` Aymeric Vitte [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53fcbcb8-8ad7-3742-1682-ee12e8c449d8@peersm.com \
--to=aymeric@peersm$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vincenzopalazzodev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox