Add rune index

[casey]

*NB: This implementation is not final and you are guaranteed to get rekt if you use it on mainnet."

This PR adds a rune index to ord behind the --index-runes flag, and only when not on mainnet.

All discussion of runes should be limited to this PR or the runestone repo, since early development and design will likely generate a lot of discussion, and it would be nice to keep it out of the ord repo for now.

[rot13maxi]

The ordinals ecosystem has a tendency of taking things with big “this is a quick hack, do NOT use this in production” signs on them and building products and services on top (cursed inscriptions on demand to try to get early negative numbers was a fun recent episode). As much as I LOVE the way this ecosystem says “whatever, nerd!” and does it anyway, i think we should be VERY deliberate about creating any dependency between ord and runes.

[rot13maxi]

I think unique symbols is a bad idea. A couple scenarios where this can go awry:

• bug (or new feature) in the indexer means that previously-unrecognized issuances are now valid for new indexes
• new token issuances can be front-run and nullified either by bots watching the mempool and outbidding them, or by miners directly

[casey]

I'm really of two minds of this. You're right about the two issues you mention, along with the fact that if a project has some token name that they want, they have to come up with a new one if it's already taken.

However, unique symbols is pretty cool. Having short, human readable names you can look things up by is nice, and having a symbol, if there are duplicates, seems pretty worthless to m.

Also, duplicate symbols make fake token scams easier. There have been a bunch of scams where someone has been sent, for example, a fake USDT token, and treated it like real tether, and sent eth in return.

[summraznboi]

Can we have unique symbols, but also make symbols not a requirement? Meaning that if a rune declares a symbol already in use or just doesn't declare a symbol by using empty string, it can only be referenced by its ID (which should be a number so as to have no possibility of colliding with symbol space)?

That should mollify concerns about token issuance validity, since any issuance can try to declare for a symbol without risk of the issuance failing (now or later due to an indexing bug fix); only thing in contention is the symbol ownership itself.

[rot13maxi]

Also, duplicate symbols make fake token scams easier. There have been a bunch of scams where someone has been sent, for example, a fake USDT token, and treated it like real tether, and sent eth in return.

maybe the better solution here is to make it easier for an issuer to share an output/pubkey/etc in a format that’s consumed by wallets. If Tether can vend a json file that says “here are my issuances”, and wallets can consume that, then wallets can say “this is tether”. That blob of json could be served up on a well known url path, or via a dns record or something else. Just spitballing.

We have the same issue with inscriptions: if someone issues a collection, anyone can make an inscription with the same artwork. So we need some offchain declaration from the artist (heres a link to the inscription) or a parent-child collection (but you need some way to get the authenticity of the parent)

[t4t5]

Unique symbols will make people rush in to squat anything remotely good, just like with BRC-20. It will diminish the chance of real USDT/USDC ever being issued on Runes imo

I think frauds around duplicate symbols is something that can be resolved on a higher layer. There could be public lists of notable token IDs shared by companies/DEXes/indexers, and they can show a little verified checkmark or something in the UI

[casey]

The ordinals ecosystem has a tendency of taking things with big “this is a quick hack, do NOT use this in production” signs on them and building products and services on top (cursed inscriptions on demand to try to get early negative numbers was a fun recent episode). As much as I LOVE the way this ecosystem says “whatever, nerd!” and does it anyway, i think we should be VERY deliberate about creating any dependency between ord and runes.

If this is a matter of “ord already has indexing, i want to reuse that”, maybe fork ord?

Definitely guilty as charged. A few things:

• Ord already has indexing. Forking ord and ripping out ordinals and inscriptions would be a lot of work, and maintaining a separate binary would be a lot of work. Ord also runs on ordinals.com, so getting runes up there would also be nice. The rune indexing is pretty simple (famous last words), it's behind an --index-runes flag, and there isn't any coupling between ordinals and runes.

• Adding metadata via an inscription envelope would require some code from ord, so that's convenient.

I definitely see the argument. Honestly, I don't know if it's personally worth it for me to write runes if it has to live in a separate binary, with all that entails. Now of course, maybe that's an argument not to do Runes at all.

[raphjaph]

Went through the following files:

• rune_updater.rs
• edict.rs
• rune.rs
• runes.rs

Functionality checked:

• etching without edict creates no rune
• etching with one edict creates rune with correct supply
• check that first rune in block is uncommon
• cannot allocate a rune below minimum for block
• runes have correct symbol
• runes have correct divisibility
• edicts can't allocate more runes than new etching maximum
• etching with one edict creates rune with correct supply which is less than max
• etching with two edicts creates rune with correct supply
• edict with invalid outputs are skipped
• edicts correctly transfer new runes to ouputs
• edicts correctly transfer input runes to ouputs
• unallocated runes are assigned to first non-op-return output when op return is not first output
• can't allocate a duplicate rune
• runes get correct id
• unallocated runes are assigned to first non-op-return output when op return is first output
• check that second rune in block is common
• edicts which refer to id 0 but are not in a tx with a etching are skipped
• edicts which refer to a rune with no balance are skipped
• edicts can't transfer more runes than are in inputs
• edicts which transfer 0 runes don't create balance entries
• balance entries for outputs with no runes are not present
• edicts may explicitly transfer runes to op_return outputs

Functionality still to check (not complete list):

• runestone::from_transaction
• varint::decode
• entry.rs
• rarity.rs
• server.rs

[summraznboi]

We need a mode to display the rune in a runic alphabet for the memes; one rune alphabet that's fairly well defined is https://en.wikipedia.org/wiki/Elder_Futhark, 24 symbols.

[raphjaph]

🚀💥

[sondotpin]

• etch is incorrect syntax OP_RETURN aaaaaa bbbbbb cccccc is valid?
• edict with invalid rune from inputs are skipped or not
• ord wallet etch + ord wallet transfer
• number of BTC to register characters

@casey

[casey]

@sondotpin This is an initial, incomplete implementation. Feel free to open issues on the https://github.com/casey/runestone/ repo, but do a search for dupes first, there are already a bunch of issues there.