rmrk-team/rmrk-spec

RIP-0013 accept change issuer

Yuripetusko opened this issue · 9 comments

Yuripetusko commented

RIP Summary

The new owner of the collection should fire an ACCEPT command after it was passed to him through CHANGEISSUER

RIP Details

In order to prevent phishing attempts due to the fact that CHANGEISSUER only passes collection to the new owner and not NFTs, a new owner should ACCEPT incoming collection for issuer change to apply.

Original issuer retains all rights until the new issuer accepts it. The new issuer can only ACCEPT the incoming collection and nothing else

Examples

In the extrinsic version of RMRK standard, this can look like

RMRK::ACCEPTCOLLECTION::1.0.0::${collection_id}

Open Questions

Need to check a dump if someone did CHANGEISSUER multiple times on the same collection, as it should have failed because it wasn't accepted after the first time.

Prior work (optional)

?

Impact

In RMRK1 we need to make sure this doesn't affect any of existing collections. But since there's nothing that an issuer can do with his collection except for CHANGEISSUER again this shouldn't be a problem.

So the only thing that we need to check if someone did CHANGEISSUER multiple times on the same collection, as it should have failed because it wasn't accepted after the first time.

We also need to sync with Kodadot (@vikiival, @yangwao) and any indexer services like SubQuery and SubSquid

Thanks to @mmvds for hilighting this case

Yuripetusko commented

Probably a new field is needed pendingIssuer

Then original issuer retains all the rights of a collection until pendingIssuer calls ACCEPTCOLLECTION. Once ACCEPTCOLLECTION is called, the issuer is changed to an address under pendingIssuer field and pendingIssuer is cleared

Swader commented

LGTM

vikiival commented

Hey,

@Yuripetusko slid into my DMs a couple of days ago.
As I understand it correctly the main problem is that:

i.e. someone can create a collection with NFTs, changeIssuer to RMRK - and it will look like legitimate

but since NFT ownership stays - you can now sell NFTs that look like created by the RMRK team

But having a pending state is not good IMHO.

May @Swader can explain the use case (why you need change issuer).

In my thinking process, I only allow changing issuer for empty collections.

Swader commented
  • selling a collection
  • thinking your keys are compromised
  • proxy miting for other people
  • merging brands and consolidating IP
  • etc
Yuripetusko commented

Hey,

@Yuripetusko slid into my DMs a couple of days ago. As I understand it correctly the main problem is that:

i.e. someone can create a collection with NFTs, changeIssuer to RMRK - and it will look like legitimate

but since NFT ownership stays - you can now sell NFTs that look like created by the RMRK team

But having a pending state is not good IMHO.

May @Swader can explain the use case (why you need change issuer).

In my thinking process, I only allow changing issuer for empty collections.

No need for p

Yuripetusko commented

p?

@Yuripetusko

Sorry not sure what happened there. And I don't remember what I was going to write. But I don't see a problem with pending Issuer approach

yangwao commented

selling a collection

Can you elaborate more on this @Swader ? If I'm paying for collection, should I explicitly accept it? Why is that? Isn't value in transaction enough?

thinking your keys are compromised

How does this solve this ACCEPT? If the author (A) of the collection has compromised keys, how prevent ACCEPT not sending them away to desired and owned account?

merging brands and consolidating IP

Like if someone accidentally sends me their brand?

Swader commented

The question was when is change issuer necessary. My answers address this question by giving a few examples, they do not focus on the accept side of things.