From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 546D1C0039 for ; Tue, 21 Nov 2023 12:14:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 208F940B59 for ; Tue, 21 Nov 2023 12:14:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 208F940B59 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=ljDMS6dN X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axxvXvfb6lAz for ; Tue, 21 Nov 2023 12:14:07 +0000 (UTC) Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3B25540B30 for ; Tue, 21 Nov 2023 12:14:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3B25540B30 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-5c9169300caso31545277b3.2 for ; Tue, 21 Nov 2023 04:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700568846; x=1701173646; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EFOuZ/nP8qnhAnBEauLPtIDHB48zbvbyn6RmcMjuSUo=; b=ljDMS6dNaqpXRBmH+ANV/UCTwmOU5HEBkQq7FyoGEmBAyqPGC76JK9xMG3Ln9FT8i+ xTBJIh+nYkqckvjoRCbDySGRWvyK/Kd5YIzfehmoNlSh4abqqxxdnYi2kJkLqfw9cw/W Wtt171wx245c51DwtWfA7tQOw6/2eaDTDhPaeIt2RrTlo5F7oedoXLEg3FGBwZuzgXxC MoHCqh76y+SluIvRptN/roJ/OMFJ9qkJNdkARoySbt0T6ElzVutRlP/gt35ZudmJsH+b Ql8yZfbC+plsC0IXcW0tdr4W1TFx+IgM3ymif03MCw+J65FrPAKNU1AOysTIZIb/xhqa cCqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700568846; x=1701173646; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EFOuZ/nP8qnhAnBEauLPtIDHB48zbvbyn6RmcMjuSUo=; b=l1FaF2yxn508sWjwxiHtF5idNqywpI7uAALqlaUyHdUBuXi0do2tJgYwjYwFywV01S YH25mLXyK95ha7QOB9GC80vUG73siSfQ+ikRBTthVgyDUbeXODBwbnK6/JVFZ92c9uHZ DVOk8hN3IXjDjYCHsDJTB8lR6xv+5oebb6cvIyXhnJWQMyAKFKjzumunNgrT5Agf2EED XYzjntt8AjX/eQHevDCnHuoFuaQzhZFSI17J79Wh4Po15jqom3cJ2053+oNtsZGHuY3Y 95Ut9eL6fa1ld/GX1ZegxQBQUNEtPZl/0GUm8ZpI1YL4uTrxnDALay2Wg3PR2s5V3LSr OGlg== X-Gm-Message-State: AOJu0Yz1FgJLrd/LFBZPnEMaexM/oCta2ErslRZ8YXKM0fdz8hbpeFtF n6aVY17O0786Q7Eh1vB8ou0xrsMAeMJOrxWAKS0= X-Google-Smtp-Source: AGHT+IHUdWKWYm3UrLTweF4BALTMq/bISaWeFwHlL9vFJQ/RYfQcrGylRfjty8cnf8D1XJZARnJBHcliSaVB8hefhVc= X-Received: by 2002:a81:bd0e:0:b0:5cb:246a:736f with SMTP id b14-20020a81bd0e000000b005cb246a736fmr4116462ywi.38.1700568845979; Tue, 21 Nov 2023 04:14:05 -0800 (PST) MIME-Version: 1.0 References: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet> In-Reply-To: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet> From: Kostas Karasavvas Date: Tue, 21 Nov 2023 14:13:55 +0200 Message-ID: To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000fb1650060aa88984" X-Mailman-Approved-At: Tue, 21 Nov 2023 13:05:14 +0000 Subject: Re: [bitcoin-dev] Ordinals BIP PR X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2023 12:14:09 -0000 --000000000000fb1650060aa88984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see inline. On Tue, Nov 21, 2023 at 3:21=E2=80=AFAM 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 i= s > 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-chai= n. > 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 t= o > Taproot at all, but just the R-value of a signature, from any address typ= e, > 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 signatu= re > 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 uplo= ad > data, if they were already uploaded in a different form. For example, the= re > 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 trie= d > 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 t= he > same data again, and again. Because in some use cases, like NFTs, it coul= d > 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 > --=20 https://twitter.com/kkarasavvas --000000000000fb1650060aa88984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see inline.

On Tue, Nov 21, 2023 at 3:21=E2= =80=AFAM vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= /div>
> I've commented a few times asking the BIP editors to let me k= now what is needed for the BIP to either be merged or rejected.

I would accept it, if each Ordinal would require including OP_RETU= RN 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 signatur= e.

I am not sure I understand = this. The data are published when spending the taproot (in the witness). Si= nce it is spent it does not bloat the mempool. Regardless of OP_RETURN the = data will be on chain. What am I missing?
=C2=A0
Or, even better, creat= ing a new Ordinal should not require sending them to Taproot at all, but ju= st 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 signat= ure could contain some Ordinal.


Actually, wrt to ordi= nals design I agree with comments like this suggesting a different design. = Why? I understand that the BIP process is fundamentally to discuss a propos= al. Something is suggested people tweak on it, improve it and when they agr= ee 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 subm= itting it for a BIP; i.e. asking for legitimacy after the fact? Shouldn'= ;t people agree/disagree with the design?

Why do y= ou want ordinals as a BIP (apologies if you explained this before and I mis= sed 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 ab= ove.
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?
=C2=A0
Also, Ordinals should support scann= ing the chain in a similar way as Silent Payments could do. Which means, us= ers 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 whitep= aper, 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 user= s to post that data again on-chain.

Another thing to address is the content of each Ordinal: some peop= le 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 tha= t "hey, the whitepaper was already pushed by someone, in a multisig, l= ong time ago", so the Ordinals protocol should prevent users from uplo= ading the same data again, and again. Because in some use cases, like NFTs,= it could be misleading.

I don&= #39;t agree with this. This seems to be a business logic change and not a t= echnical one. People can and will create other similar protocols that force= (or not) uniqueness regardless of what ordinals do.=C2=A0

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

Re this BIP proposal:
I would n= ot 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 bef= ore I don't see why a BIP is needed now.

Regar= ds,
Kostas


=C2=A0
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
--000000000000fb1650060aa88984--