<p>I cannot comment on the thread but I do want to clarify a talking point here and make my own assertion. First off</p>
<blockquote>
<p>what is a “malicious NFT”</p>
</blockquote>
<p>This is a great question.
I recently did some website work for a small NFT project and I did happen to get spammed some scammy random NFTs right after I interacted with some APIs on my public address. All of them had NULL URI metadata values which essentially meant I had to check for a situation which normally should not occur. Nevertheless this situation is not enough to make an alternative address that needs to verify receiving transactions practical, even though it is a personal example I have had of getting malicious NFTs sent to me for no apparent reason.</p>
<p>As for what the NFT could do that is economically harmful, that is a black box in the case of Ethereum smart contracts as far as I can tell. It could be anywhere from harmless if you don't ever touch it to steals all your assets if you interact with it, so in general the first approach is the overall safest recommendation DON'T interact with any random contract tokens you are sent for anyone reading. The implication for Bitcoin sidechains is still largely unknown as far as I can tell but IMO where there are smart contracts there are smart contract exploits possible so if bitcoin sidechains become massively adopted DO NOT interact with random contracts whoever is reading this in the future.</p>
<p>If your public key is disclosed to the Ethereum network at all it is essentially vulnerable to any sort of malicious contract-sendable-coin attack that you interact with. Would be nice to utterly prevent this type of interaction on btc sidechains that are issuing smart contracts.</p>
<p>My most optimistic half baked solution is to use a smart contract enabled side chain and have users of a certain NFT contract/contract standard verify the validity transactions upon the receiving end of the transaction with an additional signature before the contract can be interacted with in any other way. Essentially instead of manually spending an output to a burn address they could sign a transaction that renders that output burned aka sent to an incalculable public key or designated burn address OR sign a transaction that approves interaction between this contract and the senders public key (requires disclosure of the public key within this transaction, should be OKAY for privacy purposes because there is no movement of coins which could link accounts during this transaction). That way even if the user were to mistakenly interact with it down the line it would be an invalid double spend. There might even be a UTXO native  style contract interaction made possible by these side chains, which could allow this functionality with the same privacy preservation of UTXO sets.</p>

CC BY-SA 4.0
2023-01-27T21:46:25.503Z
Thanks, actually thinking of doing my own blockchain one day which takes advantage of a private key dual public key where the public key/address doesn't actually allow for deposit and rather you need a deposit key for that. This way open ledger is maintained and I can ensure only authorized people can make transactions into the wallet.
Adriano Mancino
CC BY-SA 4.0
2023-01-27T21:56:38.947Z
This sounds interesting, the issue I see is that you would have to pre-authorize each transaction right? What I mean is that the receiver would issue a new public key for each transaction they expect? I think if you are trying to avoid exploitation you should look closely at the operations being produce by any of the contracts or scripts that are being sent to any wallet. In bitcoin there are very clear standards that prevent normal looking transactions from containing malicious scripts in them. When preventing attack, never assume you have patched all the holes proceed cautiously.
Poseidon
CC BY-SA 4.0
2022-12-27T01:06:05.197Z
2023-01-21T00:36:49.590Z
2023-01-21T00:36:49.590Z
Poseidon
<p>I’ve been working on a project which will help manufacturers of physical products and NFT makers to distribute their NFTs in the real world. My solution is to box up a paper wallet loaded with the NFT.</p>
<p>Some NFT makers who do digital action figures may want the ability for their consumers to add “accessory” NFTs to the product and so those manufacturers are able to put a public key to allow the user to deposit the accessory NFTs to their action figure NFT. However some manufacturers may intend to make the NFT available for withdrawal only. And can’t have a public key on the paper wallet. However I want the consumer to have a different type of key to view balance, but not be able to add to it. As of now I would have to centralize it like standard serial numbers and rely on the manufacturer to give their consumers balance and proof of authenticity. It could be decentralized with a bit of help from Bitcoin developers and the BIP.</p>
<p>So I would like to propose a new type of key derived from the private key to the Bitcoin community in the hopes of adding a “Certification Key” to the architecture of Bitcoin.</p>
<p>The key should be derived from the same private key but be a number separate and incalculable given the public key. This certification key would act as a type of serial number. This type of public key would be used for verification of an account and transactions on the blockchain however it wouldn’t allow for funds to be sent to this address. This could solve the NFT junk problem of anyone sending tokens to your public address. The public address would become something you send to people you work with while the certification key becomes your publicly shareable key so no one can deposit scam NFTs in your wallet again.</p>
<p>If a public key is derived by some math using a fixed point G on the elliptical curve and k=G<em>K where K is the private key and k is the public key, could a second fixed point on the ecliptic curve “C” provide a unique “certification key”? If we did c=C</em>K to attain a certification key we would no longer have a key pair, but a key triplet.</p>
<p>Perhaps deriving the certification key from the public key is a better option? Not sure. But for my idea we need a third key.</p>
<p>This third key unlike the classic cryptography story should NOT allow a person in possession of the key to lock a message to the private key owner, however the owner of a certification key could “validate” if a locked message is intended for the recipient. Or in the case of Bitcoin it will allow you to see all the messages or transactions to and from the public/private key holders.</p>
<p>Does this make any sense? In a way the certification key is simply the wallet’s serial number. I’m currently deriving a unique serial number from the private key in my project and hashing it in the first transaction sent to the wallet as a sort of certificate of authenticity. This works only if someone knows the public key to validate their serial number.</p>
<p>I think this concept could also improve the Bitcoin network in countless ways. I’d love to see all the unique ways people would use a certification key.</p>
<p>I’m new to the crypto space and just learning development. I only have a few months of self-taught cryptography knowledge so forgive me if I’m not understanding concepts correctly. Please note this idea is purely theoretical and should be assessed by professionals to ensure that the keys generated will continue to mathematically protect the private key.</p>
<p>Anyway good morning all and have a wonderful day!</p>

CC BY-SA 4.0
2022-12-20T21:45:34.813Z
You are reinventing the cryptographical wheel with regards to certification; you just have to use a public–private keypair the other way around (private key to sign messages, public key to verify signatures). But regardless, I don't understand your user story / use case. What good is an NFT if it isn't associated with a private key that you control? Can you give an example of what such an NFT would be, how it would be used, and what sort of guarantee of authenticity or other security/authenticity properties you want it to have?
Jivan Pal
CC BY-SA 4.0
2022-12-20T22:53:01.050Z
I need a non-deposit address that can be used to verify funds. Say I’m a toy producer. In the toy’s box I include a private key. Outside the box I include a public key. In a decentralized way how can I verify, using the public address, the token is associated with that key without exposing private keys and without allowing anyone to use the key to deposit to the wallet? I can do it in a centralized way using a serial number and a private database. Or if Bitcoin network approved of this idea I could use the verification key to see the contents of the wallet.
Adriano Mancino
CC BY-SA 4.0
2022-12-20T23:05:50.193Z
So you want sellers to be able to give customers NFTs as part of a product, but without the seller having to verify purchase in order to issue the NFT? This is doomed in practice for several reasons, e.g. one could just open the product packaging in the store without actually purchasing the item to steal the NFT, or the seller may intentionally not provide the right private key inside the packaging, or sellers may intentionally provide malicious NFTs.
Jivan Pal
CC BY-SA 4.0
2022-12-20T23:05:53.350Z
But regardless, this would be easy to implement by way of a new type of transaction output that makes it invalid for that address to receive anything else. No need for additional cryptography. The seller can digitally sign the NFT so that the prospective customer can check the address has the NFT in question and that it was created by the seller.
Jivan Pal
CC BY-SA 4.0
2022-12-21T02:19:36.723Z
First off, what is a “malicious NFT” and how could one prevent someone from simply sending a malicious NFT to their public address?
Adriano Mancino
CC BY-SA 4.0
2022-12-21T02:29:03.993Z
What about a crypto gift card? A company doesn’t want customers to load funds themselves, but wants to be able to reload on their customers behalf. How could a customers still check balances themselves?
Adriano Mancino
CC BY-SA 4.0
2022-12-21T02:33:17.657Z
Thing is there ARE applications for this idea. I’d rather you point out the flaws in the cryptography. Does adding a second public key give someone enough information to crack the hashing function used? A different hash could solve this but I’d rather you point out flaws in the tech and not argue about how it’s a bad idea to put a private key in a box. Truth is I’m not giving my specific examples to protect my ideas, as good or bad as they may be.
Adriano Mancino
CC BY-SA 4.0
2022-12-21T14:05:24.910Z
Like I said, to implement what you've described, there is *no need* for any additional cryptography. To say anything more specific would require you to be more specific about what you're trying to achieve. If there are specific applications you have in mind, it should be in your interest to discuss them with an engineer in detail so that they can help you implement them, if feasible.
Jivan Pal
CC BY-SA 4.0
2022-12-26T03:15:01.417Z
I don't think you grasp the concept. If you do it should be trivial to answer my latest question.
Adriano Mancino
CC BY-SA 4.0
2022-12-26T23:24:05.207Z
The answer is "you can implement this via a new coin type, no new cryptography needed."
Jivan Pal
<private-key><public-key><bip><learning>
Potential new BIP Proposal?
Adriano Mancino
# Potential new BIP Proposal?

(Asked by: username_0 on 2022-12-20)

I’ve been working on a project which will help manufacturers of physical products and NFT makers to distribute their NFTs in the real world. My solution is to box up a paper wallet loaded with the NFT.

Some NFT makers who do digital action figures may want the ability for their consumers to add “accessory” NFTs to the product and so those manufacturers are able to put a public key to allow the user to deposit the accessory NFTs to their action figure NFT. However some manufacturers may intend to make the NFT available for withdrawal only. And can’t have a public key on the paper wallet. However I want the consumer to have a different type of key to view balance, but not be able to add to it. As of now I would have to centralize it like standard serial numbers and rely on the manufacturer to give their consumers balance and proof of authenticity. It could be decentralized with a bit of help from Bitcoin developers and the BIP.

So I would like to propose a new type of key derived from the private key to the Bitcoin community in the hopes of adding a “Certification Key” to the architecture of Bitcoin.

The key should be derived from the same private key but be a number separate and incalculable given the public key. This certification key would act as a type of serial number. This type of public key would be used for verification of an account and transactions on the blockchain however it wouldn’t allow for funds to be sent to this address. This could solve the NFT junk problem of anyone sending tokens to your public address. The public address would become something you send to people you work with while the certification key becomes your publicly shareable key so no one can deposit scam NFTs in your wallet again.

If a public key is derived by some math using a fixed point G on the elliptical curve and k=G*K where K is the private key and k is the public key, could a second fixed point on the ecliptic curve “C” provide a unique “certification key”? If we did c=C*K to attain a certification key we would no longer have a key pair, but a key triplet.

Perhaps deriving the certification key from the public key is a better option? Not sure. But for my idea we need a third key.

This third key unlike the classic cryptography story should NOT allow a person in possession of the key to lock a message to the private key owner, however the owner of a certification key could “validate” if a locked message is intended for the recipient. Or in the case of Bitcoin it will allow you to see all the messages or transactions to and from the public/private key holders.

Does this make any sense? In a way the certification key is simply the wallet’s serial number. I’m currently deriving a unique serial number from the private key in my project and hashing it in the first transaction sent to the wallet as a sort of certificate of authenticity. This works only if someone knows the public key to validate their serial number.

I think this concept could also improve the Bitcoin network in countless ways. I’d love to see all the unique ways people would use a certification key.

I’m new to the crypto space and just learning development. I only have a few months of self-taught cryptography knowledge so forgive me if I’m not understanding concepts correctly. Please note this idea is purely theoretical and should be assessed by professionals to ensure that the keys generated will continue to mathematically protect the private key.

Anyway good morning all and have a wonderful day!

**Tags:** private-key, public-key, bip, learning

> **Comments:**
> **username_1**: You are reinventing the cryptographical wheel with regards to certification; you just have to use a public–private keypair the other way around (private key to sign messages, public key to verify signatures). But regardless, I don't understand your user story / use case. What good is an NFT if it isn't associated with a private key that you control? Can you give an example of what such an NFT would be, how it would be used, and what sort of guarantee of authenticity or other security/authenticity properties you want it to have?  
> **username_0**: I need a non-deposit address that can be used to verify funds. Say I’m a toy producer. In the toy’s box I include a private key. Outside the box I include a public key. In a decentralized way how can I verify, using the public address, the token is associated with that key without exposing private keys and without allowing anyone to use the key to deposit to the wallet? I can do it in a centralized way using a serial number and a private database. Or if Bitcoin network approved of this idea I could use the verification key to see the contents of the wallet.  
> **username_1**: So you want sellers to be able to give customers NFTs as part of a product, but without the seller having to verify purchase in order to issue the NFT? This is doomed in practice for several reasons, e.g. one could just open the product packaging in the store without actually purchasing the item to steal the NFT, or the seller may intentionally not provide the right private key inside the packaging, or sellers may intentionally provide malicious NFTs.  
> **username_1**: But regardless, this would be easy to implement by way of a new type of transaction output that makes it invalid for that address to receive anything else. No need for additional cryptography. The seller can digitally sign the NFT so that the prospective customer can check the address has the NFT in question and that it was created by the seller.  
> **username_0**: First off, what is a “malicious NFT” and how could one prevent someone from simply sending a malicious NFT to their public address?  
> **username_0**: What about a crypto gift card? A company doesn’t want customers to load funds themselves, but wants to be able to reload on their customers behalf. How could a customers still check balances themselves?  
> **username_0**: Thing is there ARE applications for this idea. I’d rather you point out the flaws in the cryptography. Does adding a second public key give someone enough information to crack the hashing function used? A different hash could solve this but I’d rather you point out flaws in the tech and not argue about how it’s a bad idea to put a private key in a box. Truth is I’m not giving my specific examples to protect my ideas, as good or bad as they may be.  
> **username_1**: Like I said, to implement what you've described, there is *no need* for any additional cryptography. To say anything more specific would require you to be more specific about what you're trying to achieve. If there are specific applications you have in mind, it should be in your interest to discuss them with an engineer in detail so that they can help you implement them, if feasible.  
> **username_0**: I don't think you grasp the concept. If you do it should be trivial to answer my latest question.  
> **username_1**: The answer is "you can implement this via a new coin type, no new cryptography needed."  

---

## 1 answers

### Answer by username_2 on 2022-12-27. Score: 0

I cannot comment on the thread but I do want to clarify a talking point here and make my own assertion. First off

> what is a “malicious NFT”

This is a great question.
I recently did some website work for a small NFT project and I did happen to get spammed some scammy random NFTs right after I interacted with some APIs on my public address. All of them had NULL URI metadata values which essentially meant I had to check for a situation which normally should not occur. Nevertheless this situation is not enough to make an alternative address that needs to verify receiving transactions practical, even though it is a personal example I have had of getting malicious NFTs sent to me for no apparent reason.

As for what the NFT could do that is economically harmful, that is a black box in the case of Ethereum smart contracts as far as I can tell. It could be anywhere from harmless if you don't ever touch it to steals all your assets if you interact with it, so in general the first approach is the overall safest recommendation DON'T interact with any random contract tokens you are sent for anyone reading. The implication for Bitcoin sidechains is still largely unknown as far as I can tell but IMO where there are smart contracts there are smart contract exploits possible so if bitcoin sidechains become massively adopted DO NOT interact with random contracts whoever is reading this in the future.

If your public key is disclosed to the Ethereum network at all it is essentially vulnerable to any sort of malicious contract-sendable-coin attack that you interact with. Would be nice to utterly prevent this type of interaction on btc sidechains that are issuing smart contracts.

My most optimistic half baked solution is to use a smart contract enabled side chain and have users of a certain NFT contract/contract standard verify the validity transactions upon the receiving end of the transaction with an additional signature before the contract can be interacted with in any other way. Essentially instead of manually spending an output to a burn address they could sign a transaction that renders that output burned aka sent to an incalculable public key or designated burn address OR sign a transaction that approves interaction between this contract and the senders public key (requires disclosure of the public key within this transaction, should be OKAY for privacy purposes because there is no movement of coins which could link accounts during this transaction). That way even if the user were to mistakenly interact with it down the line it would be an invalid double spend. There might even be a UTXO native style contract interaction made possible by these side chains, which could allow this functionality with the same privacy preservation of UTXO sets.

> **Comments:**
> **username_0**: Thanks, actually thinking of doing my own blockchain one day which takes advantage of a private key dual public key where the public key/address doesn't actually allow for deposit and rather you need a deposit key for that. This way open ledger is maintained and I can ensure only authorized people can make transactions into the wallet.  
> **username_2**: This sounds interesting, the issue I see is that you would have to pre-authorize each transaction right? What I mean is that the receiver would issue a new public key for each transaction they expect? I think if you are trying to avoid exploitation you should look closely at the operations being produce by any of the contracts or scripts that are being sent to any wallet. In bitcoin there are very clear standards that prevent normal looking transactions from containing malicious scripts in them. When preventing attack, never assume you have patched all the holes proceed cautiously.  

---

