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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
Return-Path: <aubergemediale@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1E1FAC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2023 17:31:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id ECAE481353
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2023 17:31:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ECAE481353
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=Z2gXRv1q
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 smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nYng97j32xEL
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2023 17:31:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C362F8134A
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
[IPv6:2a00:1450:4864:20::22f])
by smtp1.osuosl.org (Postfix) with ESMTPS id C362F8134A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2023 17:31:56 +0000 (UTC)
Received: by mail-lj1-x22f.google.com with SMTP id y19so12834328ljq.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Feb 2023 09:31:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=Cy2UFSfskbYthBxKt0Fl6a4e8VUFhCVFLlDaZbmlqP4=;
b=Z2gXRv1qdgMpIIVqmOmA3cwFyoTMFLabeuBOzhIFr9Zs9S9HGgmPxMugyrQ6d39qRb
+I8e/nOB5PGKXOwK0U73udvynI0SMQkwzTvZlfkMJVzWp93RujEpEZTo7/+lIN5+E0vV
Fp0C2R264DofcQwXne5Gm1ahzQBXw5LIZxg19e4YQtNYCsfCk/fa+u1n78YMOcOX3+dV
ORflZ1tdgeIWY/K7VFT6TMaLUwoZPPu6T90mjIsTCYyTGJmhgSy+HfLU3guO/x4u4HO8
V/yHHIvize192y4Vlc581zEm9M8G/N077GbF/gMHLx17lLQShP756Ya22eXU0snMH/v+
9JDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
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=Cy2UFSfskbYthBxKt0Fl6a4e8VUFhCVFLlDaZbmlqP4=;
b=Bvk9t5Vg76czvDe5adYIsGq6j4cb7gyWWKoXsFatnqRxW/EvZoC2QnGML6F11tYl7W
lbSKGn/pEe0PJjYdTUMWcHMosYroPezr53Yf1ylBge0R+zAlSXIS7P/YYwHKssFGTfgw
oNzyzSZ1hZHgwXLE9GZpUpPw5L1YHIAeP0yv20+F6JS64YxYI/v3X6OJbdNB89M9VnCe
9cjH3gd1AGJOW7fJXuI5TZnlOrRu4qOVBZvK/Nhoxd9JzKGwTOgNXlrR4bl0LYY5ToRG
wMz6f+NLfbH87vGPPxglUEEL3yS6MNhJ1oSEKIDEWFNgArBAuQZYk1i36mApIgodwMUz
Wcuw==
X-Gm-Message-State: AO0yUKXyPh+MBPDs01y4YPZIEkhb2KG/kAcN6FbSm/Z6+O4WNdF4ehD6
TOT8mZp3cw6d5wXeA+s5kWCNumnZjBi6nX1u9tA=
X-Google-Smtp-Source: AK7set9Z+xtxGWl3SJMRwYNEuzewWEJhGeP4oSRbiY+F1GglPcHaYv6D4M2pxVKpoS457hAEMyV+q/cKCOUjgLudSkM=
X-Received: by 2002:a2e:720c:0:b0:290:54d6:8a58 with SMTP id
n12-20020a2e720c000000b0029054d68a58mr2580590ljc.49.1675704714564; Mon, 06
Feb 2023 09:31:54 -0800 (PST)
MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
In-Reply-To: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
From: Claus Ehrenberg <aubergemediale@gmail.com>
Date: Mon, 6 Feb 2023 18:31:45 +0100
Message-ID: <CANPykMqJ823NcCPxdwHvjOdW2MQPE8oA2JzThFQ2rUa8zHGUvA@mail.gmail.com>
To: Robert Dickinson <robert.lee.dickinson@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004298bb05f40b68bd"
X-Mailman-Approved-At: Mon, 06 Feb 2023 17:34:24 +0000
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
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, 06 Feb 2023 17:31:58 -0000
--0000000000004298bb05f40b68bd
Content-Type: text/plain; charset="UTF-8"
The inscriptions are designed to be easy to use, they even specify that
mime types should be used. I'd say, the way the data is stored is anything
but 'obscure'. UIs will be popping up to make this really easy. The main
chain can't be censored, what's in a block is in a block. I'm predicting a
huge success.
So, are we ready to accept that we'll likely see the first pictures with
insults or worse in the Bitcoin chain? I really like the idea, but the risk
is pretty obvious. I think it would be prudent to have at least an opt-out
feature for the data. So that it's possible to use the chain without the
potentially malicious content. That means the content shouldn't live in the
essential data of the main chain. Better would be something like the
extension blocks in Litecoin.
Best Regards
Claus
On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000004298bb05f40b68bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The inscriptions are designed to be easy to use, they even=
specify that mime types should be used. I'd say, the way the data is s=
tored is anything but 'obscure'. UIs will be popping=C2=A0up to mak=
e this really easy. The main chain can't be censored, what's in a b=
lock is in a block. I'm predicting a huge success.<div><br></div><div>S=
o, are we ready to accept that we'll likely see the first pictures with=
insults or worse in the Bitcoin chain? I really like the idea, but the ris=
k is pretty obvious. I think it would be prudent=C2=A0to have at least an o=
pt-out feature for the data. So that it's possible to use the chain wit=
hout the potentially=C2=A0malicious content. That means the content shouldn=
't live in the essential data of the main chain. Better would be someth=
ing like the extension blocks in Litecoin.</div><div><br></div><div>Best Re=
gards</div><div>Claus</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson=
via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I'm curious wh=
at opinions exist and what actions might be taken by core developers regard=
ing storing unlimited amounts of NFT (or other?) content as witness data (<=
a href=3D"https://docs.ordinals.com/inscriptions.html" target=3D"_blank">ht=
tps://docs.ordinals.com/inscriptions.html</a>). The ordinal scheme is elega=
nt and genius IMHO, but when I think about the future disk use of all unpru=
ned nodes, I question whether unlimited storage is wise to allow for such u=
se cases. Wouldn't it be better to find a way to impose a size limit si=
milar to OP_RETURN for such inscriptions?<br><br>I think it would be useful=
to link a sat to a deed or other legal construct for proof of ownership in=
the real world, so that real property can be transferred on the blockchain=
using ordinals, but storing the property itself on the blockchain seems no=
nsensical to me.<br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000004298bb05f40b68bd--
|
