Re: [bitcoin-dev] Ordinals BIP PR

From: Kostas Karasavvas <kkarasavvas@gmail•com>
To: vjudeu@gazeta•pl,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Date: Tue, 21 Nov 2023 14:13:55 +0200	[thread overview]
Message-ID: <CABE6yHtoj_bp18h-pouk_Ja27o6h7PTR-XsgvQgvLutpG5702w@mail.gmail.com> (raw)
In-Reply-To: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet>

[-- Attachment #1: Type: text/plain, Size: 4117 bytes --]

Please see inline.

On Tue, Nov 21, 2023 at 3:21 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

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

I am not sure I understand this. The data are published when spending the
taproot (in the witness). Since it is spent it does not bloat the mempool.
Regardless of OP_RETURN the data will be on chain. What am I missing?

> 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.
>
>
Actually, wrt to ordinals design I agree with comments like this suggesting
a different design. Why? I understand that the BIP process is fundamentally
to discuss a proposal. Something is suggested people tweak on it, improve
it and when they agree they might assign it a number. To Casey (and to
other contributors), you designed ordinals without consulting this list,
you finalized the design, created an implementation and it is running for
months and now you are submitting it for a BIP; i.e. asking for legitimacy
after the fact? Shouldn't people agree/disagree with the design?

Why do you want ordinals as a BIP (apologies if you explained this before
and I missed it)?
1) If you don't care about legitimacy then ordinals is live, you are good
to go.
2) If you are asking legitimacy then you should accept potential design
modifications like the one mentioned above.
3) If you want the BIP for standardisation it makes no sense. People can
design similar protocols anyway. It's permissionless.
4) For another reason?

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

I don't agree with this. This seems to be a business logic change and not a
technical one. People can and will create other similar protocols that
force (or not) uniqueness regardless of what ordinals do.

Besides, in any chain, NFTs can only enforce uniqueness per contract. A
different contract can have exactly the same NFTs. Uniqueness is kind-of
acquired because of the legitimacy of the person who issued the collection.

Re this BIP proposal:
I would not have an issue to accept this proposal if it was submitted for
discussion beforehand. If there was no need for people in this list to
discuss it before I don't see why a BIP is needed now.

Regards,
Kostas

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

-- 
https://twitter.com/kkarasavvas

[-- Attachment #2: Type: text/html, Size: 5560 bytes --]