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
|
Return-Path: <robert.lee.dickinson@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9344EC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2023 12:44:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 6933540B2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2023 12:44:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6933540B2F
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=O9LXnLtI
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 EHIt5ApE1ryo
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2023 12:44:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6CB704040D
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
[IPv6:2607:f8b0:4864:20::b2b])
by smtp2.osuosl.org (Postfix) with ESMTPS id 6CB704040D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2023 12:44:23 +0000 (UTC)
Received: by mail-yb1-xb2b.google.com with SMTP id b1so5782032ybn.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2023 04:44:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=VFvVvCoxGQjADL4uHEh8+DCyhV+kCrPv52y7RFl+eqU=;
b=O9LXnLtIHaBPtVVkVF24JPPDLm0zmVog4cxcku5nSl+cqpVTs1nc8idxg+YIvVYNYz
sDeAnGVkOWSfwCeKJnRT25K3oXUs/Z/Kcgc4U4ayGAvbEfn3+HyXlLXMmxYRIIkOpBTw
5YFA7i5yx5GoQxr5MeL+E4QzdgIuKnOe20QLpjlu895+GkhmM+OkTOpz5wEqI4R/HJ/h
Usnc8VdIqHJHTvYYgjfNhRwNxP1D03YELErC5eXlTmHU43AYeTAQYhD4tVJorKSKzdxW
RACdtbvWZjgCHJNYzeTh9KQJvzT8N11mNUtlbtmx/AbJ59mx4+l2SLlDeklMMaeleTQO
E+rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=VFvVvCoxGQjADL4uHEh8+DCyhV+kCrPv52y7RFl+eqU=;
b=0vs9noqdvmhgrH0Ewi8wShz4vRqqU9WZM5+pFeboPVT7PCtxlmz82Jhs5HKaBXC0Q/
u7hWj4S22GOolryO89x0TqOBujwoWHk1/o1pYfW2VU5gmCXqoYGs1tiTLCC7nHGPkMWZ
W6o1YUnas0dHm63vpejjB0luzEAXsahYD/eyQr5O5LfF+zSMHVH8kzk7ytz/BFKPAe2A
O+t6klqRB9sfwMJMukM0hDfyGpD2AaFl8KyXs0yJ58uR1s5HLx6675yXFaK/iEl99oTv
kX7snmAXsQo3jNyMa1tQfYlVp947FuSSpJfd2kqM54DxI5cHKfq9MMgVUeHwqNZt+vs/
+pzw==
X-Gm-Message-State: AFqh2koBCeC/SiEifZB8kf/MGMyJ+l8D8blbv5DjuDXewsnjHc+NTxJz
fTJBsdp+GlpoXTf5ZTUrN9NrD16V5SWZtogEZSXONuOkjQ==
X-Google-Smtp-Source: AMrXdXuX62zi84ubv8GRnEKc+6rpH4G7RFzyAU9EoMzLVK0YEKB4koJZV8m5KfCHpqpsXIyzCg6sFB7ufnQa9WI3WPI=
X-Received: by 2002:a25:3c42:0:b0:740:b601:45e6 with SMTP id
j63-20020a253c42000000b00740b60145e6mr3792353yba.121.1674823462019; Fri, 27
Jan 2023 04:44:22 -0800 (PST)
MIME-Version: 1.0
From: Robert Dickinson <robert.lee.dickinson@gmail.com>
Date: Fri, 27 Jan 2023 09:44:10 -0300
Message-ID: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000083e6e205f33e39fd"
X-Mailman-Approved-At: Fri, 27 Jan 2023 12:47:12 +0000
Subject: [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: Fri, 27 Jan 2023 12:44:24 -0000
--00000000000083e6e205f33e39fd
Content-Type: text/plain; charset="UTF-8"
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.
--00000000000083e6e205f33e39fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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 (<a href=3D"https://docs.ordinals.com/insc=
riptions.html">https://docs.ordinals.com/inscriptions.html</a>). The ordina=
l 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 impos=
e a size limit similar to OP_RETURN for such inscriptions?<br><br>I think i=
t would be useful to link a sat to a deed or other legal construct for proo=
f 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 bl=
ockchain seems nonsensical to me.<br></div>
--00000000000083e6e205f33e39fd--
|
