Allow/Restrict Duplicate Symbols about runestone HOT 29 CLOSED

Another option is simply not to have symbols at the protocol level at all, and instead identify runes by BLOCK.TX, which is completely unambiguous. I'm almost of the opinion that duplicate symbols at the protocol level are worse than not having symbols at all. After all, what is the point of a symbol that means nothing, be spoofed, and doesn't allow looking up runes by symbol. If the protocol doesn't have symbols, then people can make up whatever symbol they want for their runes.

from runestone.

Instead of requiring unique ticker symbols, think about allowing non-unique symbols while adding a paid verification process for a projects. Those with genuine use cases can pay a reasonable fee. This approach discourages squatting and brings in revenue for the main indexer.

To go even further, make the first mint RUNE a fair mint like (Trac,pipe) implementation, and let RUNE holders vote on future changes on the indexer and share some of the revenue as dividends.

from runestone.

I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

Practically speaking, this shouldn't be an issue. Bitcoin's security model is basically that 6 block reorgs don't happen, so waiting 6 blocks after token issuance should be safe.

from runestone.

On the main topic of this discussion, I am in support of allowing duplicate symbols. There are drawbacks, but I believe that the alternative leads to over-engineering to resolve issues that we can just avoid ever creating by allowing duplicates.

from runestone.

I am in favor or duplicate symbols, symbol alone is not sufficient for degens to ape in anyhow, gotta DYOR.

from runestone.

So long as the IDs (#8) are sufficiently distinguishable, I support allowing duplicate symbols.

As I work for a mining pool, the option of restricting duplicates may present an exploitable hole in the model as we approach symbols with less than 4 characters. There would be an economic motivation for us to engage in MEV and preclaim ALL these symbols for later sell (with no method of competition/fairness other than becoming a miner to hope to beat us to the block). I dislike this game theory conclusion so have no choice but to support duplicates.

@starcox64 makes a very valid point for the other extreme though that we will always have users who don't know to check IDs and allowing duplicates will facilitate easier methods of defrauding those non-savvy users. Is that risk our responsibility?

This is a very challenging decision.

from runestone.

I think that fully skipping the ticker is likely to be a breaking point in terms of degen usage, but would be superior in terms of a fungible token protocol. Maybe expose it as part of a protocol field as mentioned in #18? This lets people who don't need that feature stay very lean in terms of bytes while allowing degens who insist they need this data to larp.

I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

from runestone.

Maybe expose it as part of a protocol field as mentioned in #18?

@Psifour the user push data? yes I think users can have flex to add or point to metadata to include ticker or even point to an inscription like an sns .name or .bitmap or even a BRC that was deployed with zero or 1 token supply (just a name squat).
This makes the ticker layer portable and defined by users, not the RUNE protocol. Unique tickers are prob the only reason to have them as part of protocol, otherwise it is just open-ended metadata.

from runestone.

I'm not totally opposed to the symbol + number approach. I still don't totally like it, for reasons aesthetics and confusion, and I think it devalues the original rune, since there are now other runes with the same name.

But I think it's worth considering. So the first rune, let's say PEPE, would just be PEPE, and you could access it at /rune/PEPE. It's natural for me to think of the original PEPE as PEPE zero, but having the next one be PEPE1 might be confusing, since people might assume that PEPE1 was the first. So maybe the next one would be PEPE2. I would probably include a separator. Either PEPE-2, or a middle dot, since they're cute: PEPE·2, and people have kind of become familiar with them from things like DALL·E.

from runestone.

Another possibility is to make symbols unique but optional. If you want to have a unique symbol, you can try to get it. But if you want to rely on the social layer to identify your rune, you can omit the name, and just reference it by the rune ID, which is unambiguous. This kind of combines unique names, plus no names, e.g. if you want a unique name, you can try to get it, but if you don't, you can opt out and just not have a name.

from runestone.

And, yet another possibility to make unique names better, add a spacing character to the characters that can be in a name, so you can break up a long name with spaces, dashes, or middle dots.

from runestone.

This is a crosscutting issue with issue#7 or has a dependency rather.
Restricting duplicates (particularly at lower lengths) could result in an 'unfair' distribution of those tickers.
Current or novel brc20 tickers could be squatted on.
On the other hand duplicate ticker scams would be rife.

from runestone.

While I personally am in favor of letting people make whatever naming decisions they want and people DYORing, duplicate ERC20 symbol names have personally made my life as a corporate analyst hell trying to explain to non-technical project managers why the token USDC might not be the USDC they think it is

from runestone.

Unique symbols would need anti-squat consideration which could be an interesting challenge and solution but might not be worth it for this specific protocol. I saw this play out with Counterparty back in the day and ofc all domain name related systems... and of course recently with BRC-20.

I do think the unique name itself is attractive to degen for most tokens that are not launched with a project. It is something they speculate absent of anything else.

I just don't think the game theory of unique names is something that RUNE will dedicate much attention to so I also am leaning non-unique symbols off the bat or else scope creep could be a thing.

from runestone.

+1 on allow duplicate symbols, there are 17927 unique symbols for 3 char or less. It costs roughly 0.5 BTC to issue all of them.

from runestone.

@Psifour One idea to help with non-savvy users is to always include the ID with the symbol, but to make the ID more memorable, we encode it to words using a word list such as BIP-32. For either sequence-style ID or blockheight/txindex ID, we’d only need 3 words to encode, which makes for a fairly easy memorable phrase to remember and check for compared to just a large integer.

from runestone.

@starcox64 makes a very valid point for the other extreme though that we will always have users who don't know to check IDs and allowing duplicates will facilitate easier methods of defrauding those non-savvy users. Is that risk our responsibility?

I definitely support duplicate symbols. In Solidity, users check a contract's address for authenticity. Similarly, they can learn to verify a rune by its index. While @starcox64's concern is valid, proper education can mitigate risks.

from runestone.

+1 to allow duplicate symbols. I think web3 friends above have discussed well enough technical ideas; but I want to point that for the purposes of growing the protocol enabling duplicated symbols is better than scarcity of symbols (as people trying to issue runes can always pick their desired symbol to make a rune; rather than giving up on the idea of launching a rune because their desired symbol is already taken)

from runestone.

@starcox64 makes a very valid point for the other extreme though that we will always have users who don't know to check IDs and allowing duplicates will facilitate easier methods of defrauding those non-savvy users. Is that risk our responsibility?

I definitely support duplicate symbols. In Solidity, users check a contract's address for authenticity. Similarly, they can learn to verify a rune by its index. While @starcox64's concern is valid, proper education can mitigate risks.

The cons of enforcing non-duplicate symbols seem to far outweigh the pros. I’m fully supportive of duplicate symbols

from runestone.

Another option is simply not to have symbols at the protocol level at all

I agree and was going to propose this earlier but it felt so unconventional and sort of anti-degen. unique or non-unique names, it is still a label that ppl are attracted to. But this sort of stuff can just be put in metadata as long as it can be referenced from the RUNE object.

Save some bytes and skip the ticker!

from runestone.

I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

agree

from runestone.

To go even further, make the first mint RUNE a fair mint like (Trac,pipe) implementation, and let RUNE holders vote on future changes on the indexer and share some of the revenue as dividends.

I am not a lawyer, but that sounds like an unregistered security. We are small fish that the SEC and FTC don't care about for now, but if you believe something will grow to a scale they may care about.. Probably best to seek some legal counsel first.

Practically speaking, this shouldn't be an issue. Bitcoin's security model is basically that 6 block reorgs don't happen, so waiting 6 blocks after token issuance should be safe.

I would agree that reorgs beyond a certain threshold are statistically improbable/'impossible', but using an identifier that has to 'mature' before becoming (statistically) stable sounds like it would lead to invalid transfer attempts if an issuance is reorg'd that already has children. So long as the logic to handle the possible scenarios it creates are handled, then blockheight could be a more compact form to store it as:

• The case where a transfer has already happened, but the blockheight/txindex now points to something other than an issuance.
• The case where a transfer has already happened, but the blockheight/txindex now points to a different issuance.

The main concern being that if the transfer is invalid the blog post (which is NOT the specification, which is why I raise this concern now) originally stated, "Runes input to a transaction with an invalid protocol message are burned." It is incredibly unlikely, but someone losing unrelated runes just because they were involved in a transaction that uses a "reorg'd" rune seems like unexpected/undesirable behavior from the users perspective.

from runestone.

The main concern being that if the transfer is invalid the blog post (which is NOT the specification, which is why I raise this concern now) originally stated, "Runes input to a transaction with an invalid protocol message are burned."

I believe using an invalid ID doesn't make the protocol message invalid - the blog post also mentions that "Excess assignments are ignored", and if we treat any unissued rune to be equivalent to having a supply of 0, then it is just an ignored assignment.

from runestone.

I believe using an invalid ID doesn't make the protocol message invalid - the blog post also mentions that "Excess assignments are ignored", and if we treat any unissued rune to be equivalent to having a supply of 0, then it is just an ignored assignment.

I agree that is the expected behavior for an attempt to transfer an unissued rune. However, does that resolve the (incredibly statistically unlikely without purposeful manipulation by a miner) scenario of the same height:txindex now pointing to a different issuance? Depending on how you interpret "excess assignments" it could, but that is why I say we need to define the logic for these two scenarios.

from runestone.

Blockstream Liquid (L-BTC) did not succeed due to duplicate symbols , and ENS (Ethereum Name Service) struggled to gain traction because of name squatting. We can learn from these experiences and seek a middle ground solution, possibly involving a verification process.

In regards to the revenue-sharing aspect, I'm not a legal expert, but it seems to lean more towards utility. However, in my opinion, even if it were classified as a security, it might not be a major issue. The worst that could happen is that it gets registered as a security, which isn't necessarily a significant problem

from runestone.

Blockstream Liquid (L-BTC) did not succeed due to duplicate symbols , and ENS (Ethereum Name Service) struggled to gain traction because of name squatting. We can learn from these experiences and seek a middle ground solution, possibly involving a verification process.

In regards to the revenue-sharing aspect, I'm not a legal expert, but it seems to lean more towards utility. However, in my opinion, even if it were classified as a security, it might not be a major issue. The worst that could happen is that it gets registered as a security, which isn't necessarily a significant problem

I would argue blockstream liquid didnt take off because blockstream is cancer and noone wants to use their bloatware. Nothing to do with duplicate symbols.

Posted this in the wrong Issue earlier so reposting here:

I'm fairly sure not many of you guys actually buy altcoins and are just throwing "cool sounding" things at the wall to help you feel like you're not creating a shitcoin machine, but any form of uniqueness is tickers is most definitely not a good thing.

-You lose the ability to reuse tickers some moron is squatting, and/or chose a horrible supply etc
-Stuck with supply of said moron if you "buy it out" (if at all possible, likely not)
-What about v2 tokens requiring the same ticker as the v1?
-I can front run any project now, hijacking their tickers for fun.
-Complexity is not good if your goal is to allow people to use Bitcoin over ETH in this situation. ETH already makes it 1000x easier and likely will continue.
-Makes BRC20 more likely to survive long term vs the Runes protocol, which I am sure is not Casey's goal.
-Someone will instantly fork Runes and add non unique tickers.
-Pepe:1, Pepe:2, Pepe:3 is also basically unique tickers and a fairly cringe suggestion imo.
-Ticker length is not an issue, people ape extremely long tickers all day long.
-If you want users, don't make the UX complicated. Don't make the system hard to comprehend. Do not try to reinvent the wheel in some "special bitcoin" way. It's a waste of time. Make a tool that allows people to efficiently launch tokens on Bitcoin. -That's it. The rest is just dev ego wanting to do something quirky, it won't work.

Source: been shitcoining since Darkcoin

Happy this is an open discussion for what it's worth, even if you guys ignore me and go based off your minimal shitcoin experiences.

Thanks!

from runestone.

non-unique ticker symbol

then combine non-unique ticker symbol + (insert naming service here, e.g. blah.sats) of etching wallet to limit confusion when referring to symbol in dashboards etc

from runestone.

And, yet another possibility to make unique names better, add a spacing character to the characters that can be in a name, so you can break up a long name with spaces, dashes, or middle dots.

Basically, we are looking for a solution on how to make the tickets unique but repeatable (sorry, I'm limited in answering questions correctly © I'm a robot): And so we decided that everything will be unique but will have its own gradation when moving from one to another, we need to find the best solution for this.
Yes it's fine PEPE.2, PEPE·2, PEPE2, PEPE-2, but it's better more readable through dashes for the visually impaired: PEPE-2, or no PEPE2 characters at all.
Name-2, Name2 I think this is the optimal solution, but need an innovative idea for improvement. Perhaps there is a better solution. We need numbering approaches. Please contact the ticket numbering center. Have a nice day everyone! Leonid.sats

from runestone.

I've decided to go forward with unique names, but with some things which should help alleviate some of the concerns:

• An etching may now not specify a rune, in which case one is allocated automatically. This means that anyone who doesn't care about getting a particular rune can just have one allocated, and consider it an implementation detail. It also means that if a protocol requires etchings to always succeed, they have that option.
• @arik-so came up with a really clever way to prevent front-running by committing to a rune, blinding factor, and one of the transaction inputs, which we can implement before mainnet launch.

from runestone.