protocol is currently bottable about generative-orc-721

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

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

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