Thread for general meta-protocol indexing discussion
1 Like
Any news for the decentralized on-chain Indexer youâre working with Alex team, domo?
4 Likes
Iâm gonna need an ORC-CASH Protocol Channel~
2 Likes
Soon sir. Plan is to slowly open up to new topics. Thanks for patience
1 Like
There was a great discussion on the ordinals show last week! The ALEX oracle initiate is the second segment of the show.
https://twitter.com/i/spaces/1vAxRADwArzJl
1 Like
im really excited about the oracle!
having more secure brc-20 data validation is needed for others to build on top of brc-20
another thing that i would really like to see is brc-20 data verified and stored onchain where applications can access the data without needing any api keys or running an indexer themselves
i think it would accelerate the adoption of brc-20 and it would catch up with erc-20 when developers can query unlimited brc-20 data with just one line of code, for free
4 Likes
additionally, in regards to issues that would arise because of changes to ord see topic brc-20-cursed-inscription-content
having an onchain, transparent, single source of truth for all brc-20 data that has been verified & âblessedâ by domo and major indexers, we avoid confusion
newcomers wouldnât have to worry whether cursed inscriptions are recognized and we wouldnât have to run debates for years around the social consensus of brc-20 due to ord changes
most importantly, instead of developers focusing on creating and running indexers, they would focus on creating applications around brc-20 that end-users would use
Can someone explain what a âdecentralizedâ on-chain indexer is? Is that different from an open-source indexer?
Iâve been looking for software I can personally run to index BRC-20, like Iâd run Bitcoin Core, but Iâm having trouble finding something that works out of the box.
Hi Josh, itâs a good question. The current phase of the project, which ALEX have termed the âBitcoin Oracle,â is envisioned as the initial move towards the ultimate goal: a decentralized on-chain indexer. Another step in the right direction will be the release of a reference client that you can run similarly to bitcoin core. This is hopefully coming soon.
1 Like
Thanks @domo! Perhaps this is a dumb question, but why is the âBitcoin Oracleâ necessary? It seems to me that a reference client with regular, consensus-driven hard forks is a more transparent way to upgrade the protocol? At least until it ossifies.
Posting here because I donât think I have permissions to create a new topic.
TLDR what prevents ticker squatting?
The docs specify:
The first deployment of a ticker is the only one that has claim to the ticker. Tickers are not case sensitive (DOGE = doge).
- There are only $26^4 = 456,976$ different 4-letter tickers available. Increase to $36^4 = 1,679,616$ if including digits. Letâs assume none of those tickers are currently deployed yet.
- It requires about 200 bytes of witness data to create a BRC-20 deploy inscription.
- One can render a ticker useless by deploying it with a very low limit (e.g. a limit of zero), unless there is some minimum limit iâm not aware of.
What prevents someone from simply spamming BRC20 deploy inscriptions to squat on ticker symbols?
Letâs assume a pretty high fee rate of 400 sat/vbyte. Each witness byte thus costs about 100 sats to submit (since a witness byte is $\frac{1}{4}$ of a vbyte).
100 sats per witness byte * 200 bytes per deploy * 456,976 deploys = 91.39 BTC.
You could reduce that number significantly by prioritizing pronounceable tickers and common acronyms.
The current design doesnât specifically discourage squatting, except for the restriction on users issuing tokens themselves. So far, there have been about 60,000 deployments, and there doesnât seem to be an immediate issue with this. However, we are considering expanding to include 5+ (possibly even 3) in the future, which should help mitigate squatting concerns. When that happens, weâll likely implement additional measures to further prevent squatting to these new namespaces.