> I've commented a few times asking the BIP editors to let me know what is
> needed for the BIP to either be merged or rejected.
I would accept it, if each Ordinal would require including OP_RETURN at the
beginning of the TapScript, to prevent them from being pushed on-chain. In that
case, they could still be moved by a single Schnorr signature. Or, even better,
creating a new Ordinal should not require sending them to Taproot at all, but
just the R-value of a signature, from any address type, should be sufficient to
make a commitment.
Which means, if some user has some legacy address, then it should be possible
to sign a regular transaction, and then, R-value of that signature could
contain some Ordinal.
Also, Ordinals should support scanning the chain in a similar way as Silent
Payments could do. Which means, users should not be forced to upload data, if
they were already uploaded in a different form. For example, there was a user,
trying to upload the whitepaper, even though it was already done, and it was
wrapped in a multisig in some old transaction. Which means, Ordinals should
allow scanning the chain, and discovering old data, without reinventing the
wheel, and forcing users to post that data again on-chain.
Another thing to address is the content of each Ordinal: some people tried to
create something like NFT. In that case, the uniqueness should be enforced. And
by scanning the chain for similar data, it should note that "hey, the
whitepaper was already pushed by someone, in a multisig, long time ago", so the
Ordinals protocol should prevent users from uploading the same data again, and
again. Because in some use cases, like NFTs, it could be misleading.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
