5 ms·
This is one of the more interesting use cases I've seen posed for NFTs. Use an NFT when a user buys the game and then they can resell the game later.
by pythonaut_16 6y ago
This is one of the more interesting use cases I've seen posed for NFTs. Use an NFT when a user buys the game and then they can resell the game later.
- aaronax 6y agoWhat is the advantage of an NFT versus a record in Valve's database?
- Lionga 6y agoIt's Crypto!!!1111
- derefr 6y agoOpen standards, sort of. People could in theory take a game license they bought through some other service supporting NFT game licenses, and move it to Steam, or vice-versa. Steam et al would essentially be crypto wallets that let you download+play the games corresponding to the licenses they held. (Better yet if they’re non-custodial, actually. Decouple the responsibilities of originating licenses [i.e. buying games] from fulfilling game installs given licenses.) Also, presuming Steam was coerced by industry/government pressure into supporting NFTs, it would also mean that you could resell the games even if Valve didn’t want to support that. As long as the game-license NFT was a regular ERC722 token, its owner would always be able to move it around—such as to someone else in exchange for payment.
- dmingod666 6y agoThat's a good use case, buy and actually own copies of digital assets.
- aaronax 6y agoOK, so when the game starts up it needs to see some proof that you own a license for it. So it needs to see proof that you own an NFT. I am not aware of the technical details of various NFTs but I'm going to assume that you prove ownership similarly to how it can be done in Bitcoin--signing a transaction/message with a private key that corresponds to the public key of the asset in question. I would be happy to learn of some other way to do this! An issue here is that this does not prove unique ownership. I could share the private key with other people, and everyone could play the game at the same time. Admittedly, these would have to be trustworthy people since I imagine that the holder of the private key would be able to transfer ownership. Maybe you could sign a bunch of messages ahead of time and distribute those to your friends? That could be averted by having the game require a random number and/or datecode to be part of the message. Maybe the game can require a transaction to be posted on the NFT chain saying that you have started playing the game at x time, and eventually a corresponding stopped-playing message. So it would not let you play if it sees that a previous session hasn't been closed? Is your play time now publicly logged? It isn't intuitive to me (as someone with solid familiarity only with how Bitcoin works) how this could work. I would love to see a more technical analysis.
- derefr 6y agoYou prove you own the NFT the same way you prove to your bank that you have money: by letting the bank hold it for you. You deposit or lock the NFT into the service (essentially making it a staking contract). This associates the NFT with an account within the service's smart-contract (of the depositor's choice), which can then be mirrored by an oracle-process observing on the service's backend to become "a record in Valve's database." You then log into Steam as normal. The difference from "just using Steam" is that, at any time, you can tell the Steam NFT-staking-contract to unlock your NFT and give it back to you. Their oracle will observe this and erase the equivalent "record in Valve's database." (Note how the order of operations flows smart-contract → database in both cases. This isn't an arcade machine, where you have to convince the machine you put your token into to spit it out before you can exchange it back for cash. Effectively, you're asking for your money back at the exchange counter, and it's the arcade's responsibility to then — asynchronously — extract your token from the machine.) It's easier to make analogies if you don't think about non-fungible tokens (which don't have many real-world analogies besides deeds, and people aren't very familiar with the mechanics of deeds), but rather just with tokens generally. Say you're at a grocery store. How do you reserve a shopping cart? You insert a token that you own into a slot on the cart, which unlocks the cart from the cart next to it in line. The cart then acts as a staking contract for that token. While it's holding the token, it unlocks permissions for you to do something with the cart itself — wheel it around the store. The cart doesn't need to exist within the same abstract financial system that the token exists in, but merely needs to have some mechanism sticking up into that system — a coin slot — which can observe a token being locked in, and then report that event to a physical backend. Where the analogy breaks down, is that you have to take your cart back to the chained-up carts in order to get your token out. In equivalent staking-contract scenario, you'd instead withdraw the token, and that would cause the cart to return to being chained up to the rest of the carts. A→B lock, A→B unlock; rather than A→B lock, B→A unlock. Also, with a physical shopping cart, it's merely social norms and a common-sense observation of the mechanism that suggest that a shopping cart won't "eat" your locked token (i.e. not give it back when you fulfill the unlock condition.) Smart-contracts, meanwhile, can constrain themselves by the interfaces they implement; and can be static-analyzed for their theoretically-possible range of behavior, with the results published by reliable third-parties. So you can actually guarantee whether Steam's smart-contract has any internal capability to "eat" your deposited token or not, without anyone ever having to learn that the hard way.