Add Smart Contract to Handle Receiving Digital Art Pieces (NFTs) in Physical Art Work

[andytudhope]

Currently, we have only one simple smart contract that returns 1 of 12 key words which can be used to unlock a Status account that is preloaded with a reward.

The inimitable Will King has suggested that we add the ability to find unique NFTs in addition to the simple key words - i.e. we want to make it possible and easy to get your own digital art pieces from within the larger, physical artwork :mind_blown:

My feeling on this is that we write a smart contract that can hold an array of NFTs and can send them to whoever sends the correct signed transaction to them first.

The required function(s) would take as parameters some random data included only in the QR (which poses some interesting security challenges) and the receiver's address, check if it has already been sent (and prob fire an event if it had so we could gracefully display Art already claimed to the slower seekers), and if it hasn't pass on ownership of the NFT to the first person to find it.

This particular issue is only for the smart contract itself to feel out if this is even possible. Would love some feedback from @JasoonS, @3esmit and @shrugs (and others that I will mail) before setting up a bounty on this and then getting the frontend side of thing set up (will be done under separate issue & bounty).

Biggest and most immediate issue is how to do this without incurring gas costs for users who have just installed Status...

[shrugs]

Very into NFT collectibles for interacting with this art piece. The NFTs should be "reloadable" each day and showing so we can issue more per-visit.

Don't think an event would work if the tx failed, but we can use tx failure as a notice to show the correct error message in this case. At least until revert(status, message) is implemented a ways down the road.

All of this is possible, yeah. Gas costs will actually be a problem, though. Perhaps we just eat those costs and, say, have an off-chain script do all the logic (instead of a smart contract) and then pay the gas to transfer the NFTs to the receiver's address.

[andytudhope]

I'm very into how into NFTs you are @shrugs 😉 Fully agree on being reloadable, but - honestly - have no idea how to do that. Happy to eat gas costs with an external script, that was where my mind was headed last night anyway.

If you give me a time estimation for how long you think it would take to write a smart contract and gas script (and hopefully a test or two to go with it?) then I can assign a bounty here...

[JasoonS]

Very cool, I'm into everything you guys are into it seems 😉 Yes it is definitely possible. Would we be able to update the QR codes when we reload the NFT? (otherwise people can see the contents of the QR from the transaction or just share the QR) Simplest would be a hash commit scheme in the smart contract (where the key is stored on the QR code, and its hash is stored in the smart contract), but fancy ring signatures etc could also be used instead (but I don't know too much about them yet, and over the top anyway).

I'm trying to understand how the art is laid out, is it deterministic or generative art? How distributed spatially will it be?

The other concern is how many attempts at the 12 work phrase will be given? Because 12! (factorial) = 479001600, the number of permutations of those words means it is unlikely you'll get winner. Will users addresses be white-listed or is this open to the public?

Although doing everything server side makes sense, it defeats the purpose of using Status and new users will not really learn what it is like to interact with the blockchain via status.

(I won't be able to look at this until Tuesday next week, so count me out until then)

[andytudhope]

Hey @JasoonS - most details queried here can be found in the #ArtProject proposal.

Basically, the actual #ArtProject is a massive structure people can walk through. The 12 QRs that reveal key words will be hidden around it with clues as to their actual place in the array given there (so people physically present can easily guess it, while hackers working remotely have a tougher job, as you rightly point out). The only server-side stuff that will happen is firing off a simple POST request or the like when a user scans a QR that can be used to do some funky lights or movement on the structure itself, otherwise yes, it would defeat the purpose entirely.

Updating the QRs is likely too manual to work well, and I think Matt has some better, simpler and cooler ideas around how we could handle that programmatically in smart contracts instead.

[shrugs]

So this whole issue is solved by zkSNARKs (lol) but no we shouldn't be using that.

The solution here is to just have a server that people need to trust. This also lets us eat all possible gas costs.

So the secrets are generated and loaded into QR codes. The secrets are sent back to the server to get the word that it pertains to (and trigger a thing with websockets that the art can listen to and/or transfer an NFT token to the correct user). Then once all 12 are collected they can re-order them and query the same backend server to check the correct order. once the order is correct we can send the winner the reward, whatever that is. No need for them to log into a separate status account, etc.

It's "weird" that we're not using ethereum for this, but it's not the right tool for the job in this case, imo.

[andytudhope]

lol indeed.

This comment has changed my thinking though. I like your description, but want to flesh it out. The smart contract with the correct words (though not necessarily in the right order) MUST still be on Ethereum. The call() will go from the server as you have described, and we need still to show that Ethereal interaction somehow on the structure, initiated as it is by each individual's interaction.

The first person to query the server with the correct order can win both an NFT and be provided with a password with which they can unlock a preloaded Reward Status account using the 12 words + pswd combo (this is important for us and our marketing team).

Everyone else who guesses the right order can also be provided with their own, unique NFT as well, which is awesome and inclusive and very much in line with the ethos of the whole project (up to say, at a guess, 200 or so that we don't over-expose ourselves).

And yes, this can solve the gas problem with NFTs neatly and is, I agree, the correct tool for the job while ensuring that we do still leverage the benefits of Ethereum and show off in a physical way what is really happening in these decentralized, digital spaces (which is the core focus of this DApp). If you are happy with this, I can create a new issue and ready it for bounty?

[JasoonS]

Perfect, I agree that every non-meaningful interaction (ie not creating a NFT) shouldn't be a blockchain transaction from the user. But I do think that we should get the user to get their own NFT if they want it via a transaction that they create.

So essentially we can get the server to sign the users address + the id of the token in question (or something similar), and then the issueNFT (it will actually probably just be a modified transfer function of sorts) function on the smart contract can verify that this signature originates from the server and give the user the NFT. (if the signature is incorrect then not of course) This way the server does the issuing of the NFT but user still gets the experience of using ethereum how it is meant to be used and can claim it in their own time; that is if they actually want the NFT.

tldr - give the users a chance to use Status how status was meant to be used please 😁

I'd like to build this part (the signing server side + the smart contract verification mechanism), I think it is self contained enough to be its own issue/bounty. That is of course if you agree with the setup I described above?

[andytudhope]

Cool, I am ALL about your tldr @JasoonS. Could you create the issue for the part you wish to do so that I can assess scope and assign a bounty? Sorry, there are 1000 other things I need to do today and you are in a better position to describe scope accurately.

[JasoonS]

Sure, I'll do that in a bit :)

@shrugs Will you be using Node server side? (definitely my first pick, but wouldn't mind using golang, haskell or even PureScript too :P )

[shrugs]

@JasoonS I don't have the bandwidth, so it's all you!

[andytudhope]

Closed by #6