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
|
Return-Path: <alicexbt@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 81F42C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2023 10:58:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 50090405F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2023 10:58:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 50090405F9
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=E0XKsowA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 xB6gGdVp-x4H
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2023 10:58:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4C973405F5
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4C973405F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2023 10:58:21 +0000 (UTC)
Date: Sat, 28 Jan 2023 10:58:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1674903498; x=1675162698;
bh=7hKVRtUnlJ/w/MQIsstuLJoSoPwuWcnDQDINus+0b7c=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=E0XKsowAE8EOQ13xMIljLcnEhTrbqPH1oM5NWQ7+G+D8vzfOyT5hcqmeLe0HAWoa6
4DZErCG5CTcLFwT+neYc5OX77rK9K2r5noLwv2hCtgMPp2Dctfa3BOchzuafCL3u5h
e/o22+vLLqh1UsP7r0191DqSA0VjUzuQWqpK/mu5ucKvHy+f366xeRDRWrE/XMVUS6
OX8L71ZRdDtEBZGrcfNGJ3W8AU1TitEAl2xqe8fpENhPyRAO/r/1uvgmLq8T88njXa
i9L6mfxYnu6bLYBNv3o07z4WqDA+f2h+HPT1C0bgCvyNpVnEszrqAnFFgLkl40le9+
KXNvsv8Z7FcmA==
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <dVxjcXpVSms-352cXBUbHI893qnlQ7uuF8V9dER5-MgWc2dgXecGCUu1TMIF8z3m_hWUvtAnILxGpcQlV_KIMdUS2D-UCCf24N8JIOTnpS4=@protonmail.com>
In-Reply-To: <hhgUoi2km8Iv3HQ0aTaZiBXOHq8baEXtG5SEX_VkyYxw-4G0dewhLaj-IiFvAJsZSHW5fXSS3tukOvgzkLcvwdJIzRdBMscd2QMpA_iQBk0=@protonmail.com>
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
<hhgUoi2km8Iv3HQ0aTaZiBXOHq8baEXtG5SEX_VkyYxw-4G0dewhLaj-IiFvAJsZSHW5fXSS3tukOvgzkLcvwdJIzRdBMscd2QMpA_iQBk0=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 28 Jan 2023 15:28:49 +0000
Cc: Robert Dickinson <robert.lee.dickinson@gmail.com>
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: Sat, 28 Jan 2023 10:58:22 -0000
Hi Bitcoin Developers,
> Anyone who runs an unpruned bitcoin node should be capacity-planning thei=
r disk space assuming that in the future blocks will be more full - as dema=
nd for blockspace increases, people will make better use of the space that =
we already have and average block weight will trend upwards. If you=
=E2=80=99re thinking about how much disk you will need when we have consist=
ently full blocks, ordinal inscriptions don=E2=80=99t change that number.=
=C2=A0
I completely agree with this.
> If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys.
> There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold.
Initially I considered ordinals and the use of witness for inscriptions use=
less and harmful. However I have changed my opinion after looking at differ=
ent things and reading several comments. I do not consider such things 'use=
less' or 'crap' and it won't affect bitcoin fee market negatively. There is=
no threat to LN as well.
I consider every bitcoin transaction a legit use case and would like to sha=
re an example and different perspective of how such inscriptions might be u=
sed at different places:
During the festival of Diwali, it is a common tradition among many Indian f=
amilies to buy gold coins with the image of the goddess Laxmi, the goddess =
of wealth and prosperity. The coins are often bought as a symbol of good lu=
ck and prosperity for the upcoming year. They may also be given as gifts to=
family and friends or used as a form of investment. The coins can be purch=
ased from a variety of sources, including jewelry stores and online retaile=
rs.
If people start buying bitcoin during Diwali, and sellers use the witness t=
o include the image of Laxmi in the inputs used, it would be an innovative =
way of combining traditional customs with modern technology. Since some use=
rs consider bitcoin as digital gold, I won't be surprised if this really ha=
ppens in future and won't consider it bad as the transactions are paying fo=
r block space used.
/dev/fd0
floppy disc guy
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, January 27th, 2023 at 6:28 PM, rot13maxi via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
> Hello,
>=20
> =E2=80=9CUnlimited storage=E2=80=9D isn=E2=80=99t really accurate. It=
=E2=80=99s witness data in a taproot transaction, so the block size limit s=
till applies. Anyone who runs an unpruned bitcoin node should be capacity-p=
lanning their disk space assuming that in the future blocks will be more fu=
ll - as demand for blockspace increases, people will make better use of the=
space that we already have and average block weight will trend upwards. If=
you=E2=80=99re thinking about how much disk you will need when we have con=
sistently full blocks, ordinal inscriptions don=E2=80=99t change that numbe=
r.=C2=A0
>=20
> - rijndael
>=20
> On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>=20
> > 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 u=
se of all unpruned nodes, I question whether unlimited storage is wise to a=
llow for such use cases. Wouldn't it be better to find a way to impose a si=
ze limit similar to OP_RETURN for such inscriptions?
> >=20
> > I think it would be useful to link a sat to a deed or other legal const=
ruct for proof of ownership in the real world, so that real property can be=
transferred on the blockchain using ordinals, but storing the property its=
elf on the blockchain seems nonsensical to me.
|
