> Since it is spent it does not bloat the mempool.
This is not the case. If you post some 100 kB TapScript, with some Ordinal,
then it of course bloats mempools, because then other users could post 100 kB
less, when it comes to regular payments. If you have Ordinals in the current
form, then they take place of regular payments. Which means, you can include
some payment, or some data. You cannot include both, because you can produce 4
MB block per 10 minutes. It is always a choice: confirm this payment, or
confirm that data.
> Regardless of OP_RETURN the data will be on chain. What am I missing?
If you have regular OP_RETURN, the data is pushed on-chain. However, if your
OP_RETURN is part of your TapScript, then you cannot provide any valid input to
satisfy that kind of TapScript, so it cannot be pushed on-chain. Which means,
you have to use another TapScript branch, without OP_RETURN, or simply spend by
key. Note that regular OP_RETURNs are placed in transaction outputs, but in
that case, TapScript is revealed in transaction input (and to be more specific,
in the witness part), which prevents from posting a commitment on-chain, if it
contains OP_RETURN at the beginning of the TapScript.
> If there was no need for people in this list to discuss it before I don't see
> why a BIP is needed now.
It is needed, but for a different reason. There should be a BIP, but not to
promote Ordinals, but to handle them properly, and to provide regular users a
way, to compete with the currently posted Ordinals, in this fee-based
competition. Which means, regular users should have a way, to turn their
Ordinals into proper commitments. They should be hidden behind some R-value,
instead of being posted as a TapScript, and fully revealed in the witness. That
would make it smaller, cheaper, and will provide more room for more regular
payments, while preserving the strong cryptographical proof, that a given data
is connected with a given transaction input.
Also, it would allow them to be uncensorable, because then users could decide
to hide any Ordinal behind their signature, in any address type (it works even
on P2PK), and then reveal it later, but not on-chain, to not take a room of
other regular payments. In general, transactions should always contain
payments, and Ordinals could be attached as a feature, and not the other way
around, when the actual payment is just a feature to be discarded, and the
posted data is what people care about. Bitcoin is a payment system first, and
not a P2P cloud storage, so it should work as "always a payment, and optionally
also an Ordinal", and not "just a data push, and unfortunately a payment,
because the protocol forced us to include some satoshis".
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
