Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

protocol is currently bottable #2

Open
jokie88 opened this issue May 31, 2023 · 6 comments
Open

protocol is currently bottable #2

jokie88 opened this issue May 31, 2023 · 6 comments

Comments

@jokie88
Copy link
Contributor

jokie88 commented May 31, 2023

One issue I see w/ the protocol as it is, is that there is no way for a deployer to control who mints it.

That is nice for free-for-all collections and the free market ethos of crypto but it does limit the usecases orc-721 can support.

Example: Lets say I want to do an orc-721 collection. I spend a lot of time creating the art and I want everyone to have a fair shot at minting.

I first inscribe the sprite file
Then the deploy json with a mint max of 1000.

a scanner spots the deploy json in the mempool and decides to claim 90% of the mint.

arguably this is a problem that solves itself as it can start to be a waste of money but it may mean hyped projects could not use this protocol to launch.

@ZimmerAllDay
Copy link

This is a good point @jokie88. Can bots do the same thing with BRC-20 right now, and do they? I really don't know.

@geraldb
Copy link
Member

geraldb commented Jun 1, 2023

yeah good point one idea is to add a private key flag or such e.g.

 "private": true   

meaing only the original deployer can mint (or really only the mints from the owner address are accepted) another is to add a owner(s) key option or such e.g.

 "owner":  "address here"  or
 "owners": ["address 1","address 2",]

maybe only allow one owner bitcoin address - and let schnorr multi-sig in one sig handle it. Anyways, it's still early - let's collect / research possible extensions. More suggestions welcome

@jokie88
Copy link
Contributor Author

jokie88 commented Jun 1, 2023

you can sort of prevent it w/ brc-20 by deploying and minting the whole supply to yourself in the same block (2 inscriptions)

then you can transfer smaller quantities during the mint to the minters.

not as easy w/ orc-721 due to the fact that each one is a separate inscription

@ZimmerAllDay
Copy link

If you really wanted to couldn't you still initiate all the inscriptions in a batch right after the deploy confirms, similar to minting all of the brc20? I realize it's many more txns, but could still be done in one block most likely, right? Plus, if a bot's transactions confirm before the deploy, they would be invalid, so it is an even playing field after the deploy block confirms.

The bot would have to pay higher fees than the inscribers, which would be unlikely because the inscribers would be doing way smaller numbers and would likely be willing to pay higher fees than a bot whose transactions could end up invalid.

@jokie88
Copy link
Contributor Author

jokie88 commented Jun 2, 2023

yes i guess brc-20 is bottable too but in that case not much is lost. you can just reinscribe the two inscriptions with a slightly different attribute.

with orc-721 you have to inscribe your entire collection which leave a lot of gaps for anyone watching the pool (or makes it expensive like you say -- to try to rush it all in.)

@geraldb
Copy link
Member

geraldb commented Jun 2, 2023

i think one trouble still to research / better understand for the validation rule is the diyordibots deploy that was possible done in one block BUT:

  • the first mints in the block are ordinals before the deploy inscription and
  • the spritesheet inscription is after the deploy inscription

not a memory pool expert or block ordering / mining specialist - i might be wrong here (and it was not done in a block and not sure if the order within a block is assigned random or you can determine if you submit).

for now the thinking for validation is - to reject mints before deploy - still undecided about deploys before spritesheets (for now the plan is to accept as valid if the inscription exists - maybe add the rule within the same block if in the future).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@geraldb @jokie88 @ZimmerAllDay and others