NFTs on XRPL... How?

[KarmaCoverage]

1 hour ago, RambeauTeasebox said:

Looking forward to your comments and, hopefully, some NFTs!

Damn dude, well done! Seems legit to me.

You also brought up some other good considerations around using memo field, etc. 

[RambeauTeasebox]

1 hour ago, KarmaCoverage said:

Damn dude, well done! Seems legit to me.

You also brought up some other good considerations around using memo field, etc. 

Thanks! I'm going to try to create some on mainnet when I get a chance later this week.

Reading this over again, one change I'd make is to format the Memo data as JSON so that it's easily readable/usable. Instead of:

NFT object IPFS hash:
QmU7jY9pnxfmzLRjhS87WzVxJeLUz2RhM43Jmt9sSo1jSL
NFT metadata IPFS hash:
Qmcc6igFwkSs4jKyGBNEX9VTqU3Sy7X6bpC3BDWCue1ejD

Perhaps something like this:

{
  "NFT": {
    	"Data Network": "IPFS",
        "Pointers": {
        	"Object_1": "QmU7jY9pnxfmzLRjhS87WzVxJeLUz2RhM43Jmt9sSo1jSL",
          	"Metadata_1": "Qmcc6igFwkSs4jKyGBNEX9VTqU3Sy7X6bpC3BDWCue1ejD"
        }
  }
}

Or maybe doing whatever is standard for ERC-271 contracts or some of the larger NFT platforms like Rarible or OpenSea. I haven't looked into this yet.

[PunishmentOfLuxury]

Discussion/proposal started on Github by Wietse Wind:

https://github.com/XRPLF/XRPL-Standards/discussions/30

Quote

Issuing tokens on the XRPL

A simple issue procedure of a token on the XRP Ledger:

Issuing account signs & submits an AccountSet transaction, setting flag 8: "Default Rippling". This is required for future Trust Lines set up by users, to allow them to send the token to each other.

Receiving Hot Wallet signs & submits an TrustSet transaction, trusting the token code to be issued by the Issuing account (this process should be repeated by all future recipients of this token)

Issuing account signs & submits a Payment transaction to issue X amount of the token code to the Receiving Hot Wallet

Optionally, the Issuer account 'Black Holes' the account, so no more tokens can be issued. To do this, the Issuing account:

Sets a regular key SetRegularKey to an account that can't be accessed by anyone, eg. rrrrrrrrrrrrrrrrrrrrBZbvji

Sets flag 4 using an AccountSet to disable the native key of the keypair to that account

The procedure outlined above works & is actively being used, but results in fungible tokens: they can be send partially, and any value of the issued cannot be uniquely identified.

Issuing NFTs the XRPL

The XRP Ledger has an issued token precision of 15 significant figures. The smallest amount of an issued token the XRPL can handle is 1000000000000000e-96. The decimal value of this scientific notation is:
0.000000000000000000000000000000000000000000000000000000000000000000000000000000001
0.{80 zeroes}1

This is a quite unusual amount of decimal positions for real life use cases. There is no likely use case that requires that amount of decimal places to ever be used, as there will always be something closer to the decimal sign. This results in the last digits being sliced off anyway (because of the XRPL supported 15 significant figures). Even some value of a BTC IOU (8 decimal places) + Transfer Fee + rounding doesn't even come close to using anything close to the available decimal places.

Proposal

Let's assign the last (say) 11 figures to client side / user interface 'NFT behaviour':

The smallest possible amount on the XRPL:
0.000000000000000000000000000000000000000000000000000000000000000000000000000000001

Not NFT, as the last possible 11 figures aren't used:
0.0000000000000000000000000000000000000000000000000000000000000000000001

Is NFT (smallest possible amount, as (at least one of) the last possible 11 figures are being used):
0.0000000000000000000000000000000000000000000000000000000000000000000000|00000000001

As you can't divide values it even further (they are already behind the decimal separator, and will be turned into the scientific notation when querying the XRPL), if only one (1) token value is issued, only one (1) token value can be sent.

So: if the value of issued currency is in the range of 1000000000000000e-85 - 1000000000000000e-96, clients should handle (represent, mostly a user interface affair) the amount as NFT.

This requires no amendment on the XRPL side, as all of this is possible today.

 

[KarmaCoverage]

6 hours ago, PunishmentOfLuxury said:

Discussion/proposal started on Github by Wietse Wind:

https://github.com/XRPLF/XRPL-Standards/discussions/30

 

Link didnt work?

I'm not sure I understand the the part following "Proposal". Why 11?

6 hours ago, PunishmentOfLuxury said:

Proposal

Let's assign the last (say) 11 figures to client side / user interface 'NFT behaviour':

 

[RambeauTeasebox]

7 hours ago, PunishmentOfLuxury said:

Discussion/proposal started on Github by Wietse Wind:

https://github.com/XRPLF/XRPL-Standards/discussions/30

 

Thanks for the link; I'll be joining that discussion.

I does look like I used the incorrect issuance amount, as I noted. I'm still a bit confused over the 1e-15 vs. 1000000000000000e-96, so hopefully @Wietse@WietseWind and the github discussion can clear things up for me.

[RambeauTeasebox]

I've repeated this experiment using @Wietse @WietseWind's NFT proposal here: https://github.com/XRPLF/XRPL-Standards/discussions/30

This attempt is different in a few ways from my first. Namely:

1. It uses the correct minimum amount to issue the token, i.e. 

1000000000000000e-96 (== 1e-81 == 0.000000000000000000000000000000000000000000000000000000000000000000000000000000001)

instead of

1e-15

which I was mistaken about. So now we actually have a single, indivisible token unit being issued. (Telling rippled to use less than this absolute value amount is equivalent to 0.)

2. Instead of pointing to the NFT object in the Payment Memo field during the issuance transaction, I use the Domain field during the AccountSet transaction. When viewing the Issuer's Domain, you now see an IPFS pointer to the simple metadata file for the object. This metadata points to the NFT object of interest. With one pointer, you can potentially issue many NFTs from this account at once by pointing to multiple objects in the metadata, including other metadata files, and using unique currency codes for each unique NFT or NFT set.

3. I transacted in the order suggested by the proposal.

Accounts:

Issuer:

rHgT5R6brH6pK6JJfoo4F7wqFmXwGUh7Ke (https://test.bithomp.com/explorer/rHgT5R6brH6pK6JJfoo4F7wqFmXwGUh7Ke)

Distributor:

rHZZ3QAedovwfq9stGKYGWsKkxNisKR9Hi (https://test.bithomp.com/explorer/rHZZ3QAedovwfq9stGKYGWsKkxNisKR9Hi)

Purchaser:

rPLJzvrX5JQtFdhELUH5kxsY2CiQkxd1x (https://test.bithomp.com/explorer/rPLJzvrX5JQtFdhELUH5kxsY2CiQkxd1x)

IPFS objects:

NFT object IPFS pointer:
QmU7jY9pnxfmzLRjhS87WzVxJeLUz2RhM43Jmt9sSo1jSL (https://ipfs.io/ipfs/QmU7jY9pnxfmzLRjhS87WzVxJeLUz2RhM43Jmt9sSo1jSL)
NFT metadata IPFS pointer:
Qmcc6igFwkSs4jKyGBNEX9VTqU3Sy7X6bpC3BDWCue1ejD (https://ipfs.io/ipfs/Qmcc6igFwkSs4jKyGBNEX9VTqU3Sy7X6bpC3BDWCue1ejD)

Currency (Nonstandard) Code:

$ echo "QmU7jY9pnxfmzLRjhS87WzVxJeLUz2RhM43Jmt9sSo1jSL" | sha1sum
212e5fc6a2bbc0df22df1f1a83dfb6c6af5599a3  -

Issuer "Domain":

"ipfs://Qmcc6igFwkSs4jKyGBNEX9VTqU3Sy7X6bpC3BDWCue1ejD" in HEX:
"697066733a2f2f516d636336696746776b5373346a4b7947424e455839565471553353793758366270433342445743756531656a44"

Transactions:

Set DefaultRipple on issuing account (P2P sending without Trustlines) AND Set Domain field pointing to IPFS object (here, object's metadata):

TXID: A7A99DFEB4485AEAC6222CB7626E547CC46A9BCDF464CABF37A82DA7158B0626 (https://test.bithomp.com/explorer/A7A99DFEB4485AEAC6222CB7626E547CC46A9BCDF464CABF37A82DA7158B0626)

Distributor Trusts Issuer for minimal currency amount (1000000000000000e-96):

TXID: 108A22B80BEFC46D5874714C6492F4AA63F61C4141D4B687A88EB08825897740 (https://test.bithomp.com/explorer/108A22B80BEFC46D5874714C6492F4AA63F61C4141D4B687A88EB08825897740)

Create NFT asset and send to Distributor account (1000000000000000e-96 unit of currency):

TXID: F623823986EA16099D4A3DFD66357893181C1E604FBF8DD2CABF61CC46023C02 (https://test.bithomp.com/explorer/F623823986EA16099D4A3DFD66357893181C1E604FBF8DD2CABF61CC46023C02)

Remove ability to issue more of the NFT:

Set RegularKey to Blackhole account:

TXID: 0D089A27613036DD9884E37C6BBA8699C6B3350E22CE3FFE986244F241C5C526 (https://test.bithomp.com/explorer/0D089A27613036DD9884E37C6BBA8699C6B3350E22CE3FFE986244F241C5C526)

Remove use of MasterKey for the issuing account:

TXID: 528ED64DAE7A2523F8B0A1A61A5735B7C9CF229BDFF794EE2CD835509E217B9E (https://test.bithomp.com/explorer/528ED64DAE7A2523F8B0A1A61A5735B7C9CF229BDFF794EE2CD835509E217B9E)

Distributor account offers NFT for sale (against XRP):

TXID: CF5B676C228B9049D7C5C3E5A547255166900FC56C861B45EFBBDCA6EEAA503F (https://test.bithomp.com/explorer/CF5B676C228B9049D7C5C3E5A547255166900FC56C861B45EFBBDCA6EEAA503F)

Purchaser account buys NFT with XRP:

TXID: B10D29248CCDC4F16AF2B99F878CD073E45014048AB64F032315E44CB2F4FC3B (https://test.bithomp.com/explorer/B10D29248CCDC4F16AF2B99F878CD073E45014048AB64F032315E44CB2F4FC3B)

Edited February 26, 2021 by RambeauTeasebox
corrections

[PunishmentOfLuxury]

@KarmaCoverage Link works for me, and apparently for at least one other person.

Hubert's blog: Introduction to NFT on the XRP Ledger

[KarmaCoverage]

16 hours ago, PunishmentOfLuxury said:

Hubert's blog: Introduction to NFT on the XRP Ledger

There are considerably 3 possible ways of creating NFTs on the XRPL:

1. One account can issue (mint) one token, after that the account will be blackholed, which means it would be impossible to create new tokens after.

2. One account can issue (mint) multiple tokens as a batch, after that the account will be blackholed

3. One account continuously issues (mint) new tokens because it can be trusted. (Set a domain and emailhash). Also doesn’t get blackholed.

Is this 3rd method just a cold wallet issuer, with a hot wallet stacked on top?

Also, if the Issuing wallet isn't blackholed, it could represent a situation where you have a celebrity content creator, who makes Distribution deals with Hot wallet outlets (YouTube, twitter, etc)

This way a consumer can know the origin aka "Provenance" of a thing, and provenance is one of the economically valuable things a Blockchain can do that other accounting tools cannot.

That's why the Diamond industry was one of the first to fund a blockchain startup that was putting the public key on the Diamonds, so their sale history could be tracked from provenance... the mine.

Edited February 27, 2021 by KarmaCoverage

[RambeauTeasebox]

29 minutes ago, KarmaCoverage said:

3. One account continuously issues (mint) new tokens because it can be trusted. (Set a domain and emailhash). Also doesn’t get blackholed.

Is this 3rd method just a cold wallet issuer, with a hot wallet stacked on top?

Also, if the Issuing wallet isn't blackholed, it could represent a situation where you have a celebrity content creator, who makes Distribution deals with Hot wallet outlets (YouTube, twitter, etc)

Yes, essentially. I think another variation for issuing would be for the hot/warm distributing wallet to be "permanent." Every time a new set of NFTs needs to be issued, a new issuing wallet can be created, the distributing wallet extends trust to that wallet for the new NFTs, and then NFTs will be issued to this hot/warm distributing wallet before blackholing. Third parties can deal with the same, known distributing wallet while still guaranteeing that a certain vintage of NFTs cannot be created again.

I think you're spot-on about the provenance. I think that when it comes to art and art-like NFTs, verifiable provenance will be as important or even more important to NFT value than uniqueness. (Though I'm not sure that they're really separate properties.)

Edited February 27, 2021 by RambeauTeasebox
typos

[KarmaCoverage]

29 minutes ago, RambeauTeasebox said:

Yes, essentially. I think another variation for issuing would be for the hot/warm distributing wallet to be "permanent." Every time a new set of NFTs needs to be issued, a new issuing wallet can be created, the distributing wallet extends trust to that wallet for the new NFTs, and then NFTs will be issued to this hot/warm distributing wallet before blackholing. Third parties can deal with the same, known distributing wallet while still guaranteeing that a certain vintage of NFTs cannot be created again.

Hum, I guess you could blackhole the Distributing hot wallet, after "reissuing" (make a market 1:1 to the original issued NFT)... then even if the original Issuing wallet issued more of the NFT, it wouldn't/couldn't be the "special addition" version that was originally distributed through the blackholed hot wallet.

Or maybe somehow only allow 1 trustline for that NFT, from that Issuer? Not sure if you can reject inbound Trustlines?

I guess you can limit the Hot/Distributing wallet's trustline, and if it's blackholed that quantity cant change.

That could enable the fractionalization of NFTs, in a way that if you reassembled a whole NFT you would have one, (because while the NFT is non-fungible, the fractions of the NFT are fungible amongst themselves, from that reissuer / Hot wallet).

Edited February 27, 2021 by KarmaCoverage

[PunishmentOfLuxury]

 

[hammertoe]

If you want to see some more info about experiments issuing NFTs on the XRP Ledger, then come join the live RippleX Developer Twitch stream today:

 

[KarmaCoverage]

14 hours ago, hammertoe said:

If you want to see some more info about experiments issuing NFTs on the XRP Ledger, then come join the live RippleX Developer Twitch stream today:

 

Still watching, thanks for posting. 

Around the 21:20 mark you start talking about a concept which "Blockchain" accidentally adopts into its noun. The Chain part.

One key market dynamic of NFTs is that without what in Real Estate is called a "Chain of title" an NFT is just another copy/paste.

Same applies to a BTC "NFT", lose that block"chain of title", and you got nothing.

Edit: after watching, very much worth the time. Some great ideas are discussed. Thank you.

Edited March 24, 2021 by KarmaCoverage