From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6C70C0039 for ; Mon, 20 Nov 2023 22:20:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CA4124096E for ; Mon, 20 Nov 2023 22:20:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CA4124096E Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=nWDEyAxK X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaRgwRAK5PxY for ; Mon, 20 Nov 2023 22:20:55 +0000 (UTC) Received: from smtpa34.poczta.onet.pl (smtpa34.poczta.onet.pl [213.180.142.34]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1DAE34096C for ; Mon, 20 Nov 2023 22:20:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1DAE34096C Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4SZ25W0rmFzjDg; Mon, 20 Nov 2023 23:20:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1700518847; bh=5e9To2e+QZ4/WzyBUITbjhXHSORW6oEHdH7YjQkdxco=; h=From:To:Date:Subject:From; b=nWDEyAxK3VdUe2Rg8g/U152sxND1Cz6Wpcogr331iJHW8nJykUJiCkFsFfA7RO6of 5aPKtv+/lzaTDJ1Xcw3rnErqTglA5lQmLKWovqeroWnibJILAEaH1CHlI66l/pCqbp pdqpXqBN4mUhL9dGEbGFhWsjuIxYXVYcfd0GMEtY= Content-Type: multipart/alternative; boundary="===============5271140119223292099==" MIME-Version: 1.0 Received: from [5.173.240.149] by pmq3v.m5r2.onet via HTTP id ; Mon, 20 Nov 2023 23:20:47 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: Casey Rodarmor , Bitcoin Protocol Discussion , Bitcoin Protocol Discussion Date: Mon, 20 Nov 2023 23:20:46 +0100 Message-Id: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.240.149;PL;2 X-Mailman-Approved-At: Tue, 21 Nov 2023 01:21:13 +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: Mon, 20 Nov 2023 22:20:58 -0000 This is a multi-part message in MIME format. --===============5271140119223292099== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > 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, ev= en better, creating a new Ordinal should not require sending them to Taproo= t at all, but just the R-value of a signature, from any address type, shoul= d be sufficient to make a commitment. Which means, if some user has some legacy address, then it should be possib= le 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, a= nd it was wrapped in a multisig in some old transaction. Which means, Ordin= als should allow scanning the chain, and discovering old data, without rein= venting 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 enforc= ed. And by scanning the chain for similar data, it should note that "hey, t= he 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 mislea= ding. --===============5271140119223292099== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> 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_RE= TURN at the beginning of the TapScript, to prevent them from being pushed o= n-chain. In that case, they could still be moved by a single Schnorr signat= ure. Or, even better, creating a new Ordinal should not require sending the= m 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 shoul= d be possible to sign a regular transaction, and then, R-value of that sign= ature could contain some Ordinal.

Also, Ordinals should support scanning the chain in a similar wa= y as Silent Payments could do. Which means, users should not be forced to u= pload 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 alre= ady done, and it was wrapped in a multisig in some old transaction. Which m= eans, Ordinals should allow scanning the chain, and discovering old data, w= ithout reinventing the wheel, and forcing users to post that data again on-= chain.

Another thing to address is the content of each Ordinal: some pe= ople tried to create something like NFT. In that case, the uniqueness shoul= d be enforced. And by scanning the chain for similar data, it should note t= hat "hey, the whitepaper was already pushed by someone, in a multisig, long= time ago", so the Ordinals protocol should prevent users from uploading th= e same data again, and again. Because in some use cases, like NFTs, it coul= d be misleading.
--===============5271140119223292099==--