Issues with first-hash-mines method of pushing reveal costs to minters

[casey]

I saw a post on Twitter mentioning that a project was publishing a list of image hashes and then considering the first hash of the image that gets mined as an inscription is the "canonical" inscription.

The advantage of this method is that it shifts minting costs to minters.

The disadvantages are that minters will spam the mempool with transactions racing to mint the same inscription, with no mutual exclusion mechanism to reduce mempool congestion and duplicate inscriptions if the do get mined.

I think the official project position should be to discourage this, and provide a better solution that allow projects to shift minting costs to minters, without this downside.

[casey]

Sketch:

• Project mines commit transactions. Instead of including a checksigverify, the tapscript spend path is anyone can spend, and all the script contains is the script envelope. Key-path spend is as normal.
• Project gives minters enough information to broadcast and pay for reveal transactions themselves.
• Users must bid fees to be accepted into the mempool, and to be most preferred by miners, and thus mined.
• Mempool spam is reduced, aside from transactions getting replaced in mempool
• Commit transaction UTXOs act as mutices, so only one tx may be mined, eliminating chain spam
• Miners get paid extra fees 💪

We should consider using the "mint pass" terminology that is popular in other ecosystems. Compared to other mint pass systems:

• no failed transactions, you get your inscription and pay the fee, or not
• you can see exactly what you're getting

[cyclomancer]

This could be combined with the "ask" protocol in #802 to give minters payment atomicity:

• Keep the checksigverify
• Project provides minter with an ask+reveal PSBT
• Minter checks out the goods, adds their payment input and ordinal output, finalizes and broadcasts