1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E6C70C0039
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <casey@rodarmor.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 20 Nov 2023 23:20:46 +0100
Message-Id: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<div>
<div>> 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.</div>
<div><br />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.</div>
<div><br />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.</div>
<div><br />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.</div>
<div><br />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.</div>
</div>
--===============5271140119223292099==--
|
