protocol is currently bottable

[jokie88]

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]

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]

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]

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]

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]

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]

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).