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
175
176
177
178
179
180
181
182
183
|
Return-Path: <zachgrw@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 243F7C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 08:45:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 129A96063F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 08:45:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level:
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
tests=[BAYES_50=0.8, 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
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id o7PV23Q9FNUL
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 08:45:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com
[IPv6:2607:f8b0:4864:20::f36])
by smtp3.osuosl.org (Postfix) with ESMTPS id D9ED760663
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 08:45:43 +0000 (UTC)
Received: by mail-qv1-xf36.google.com with SMTP id l2so311087qvb.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 01:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=+6tTORajqh/CDpYEahe6Ln45spOxe0t2hKq4TrYGT/0=;
b=YifbGJoWX9ZyaCBSkpl5/wdNsWG9ECNnI5IMCJ7nMNA0cgEYRv3m9R3HgWQiCzBF5M
ArcYAuQiyy6JKYG4pFHK+BP1Ac+2phHU0rO0ze4JANckCzyobc+ZveRRecc1kpxhiKu2
LBee0j8jjki8puzMYXiSVkwvyU3k1OVRffKLbtO2oOxvFZbp7yWpcEA+GEB1QqL1EIfz
5ySBZmjwOjEvGbsp1c422s8wISlmiQsKqY5cIJGcf++cBANKlC4e2ABsceBkzCGxozg0
8PELIRTrjxQUlfIdC8ao4rnLsE5a9gmYd+mcK7XYB6Aa0vB6n80VfEVprf6wC+TIuDGU
Hgaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=+6tTORajqh/CDpYEahe6Ln45spOxe0t2hKq4TrYGT/0=;
b=SGL8msO2bKgpDMNDHkWYVevRxnCORHpKkfs00iM75iYGeCx6LjLIeul8/x/lcA1JfC
yglhtKJCb9aIKabqWA7btrE6MCaGupl6tpCu+tgLSfugRKeoipT6Bu/UDZpQXhhX6m6V
ksrlHuN4b4gXQsUffLGeXsV6WCg8q354aT0vXzb6t4XlpImcLQKvRaQSPdPFjKw67AWY
+J/w/5owOwI/Us1+IJyiZ3f60gufmXuCjGw6W2UuDPXZY5iaeAhFwtN9Yguzau+mAPrX
F08J0A3PXjJBntlDMgauhroSHAC3yBglsH37XW84KPEauf/Lz5rhkToNjSdIlV9uOMnJ
Wasg==
X-Gm-Message-State: AOAM532SGioiE2PVL/KpQ2tNY8fSZwpPaqkNV4rkPMgfNa1gt/XjN6tb
rLTa//LCd4L0oSA3gXSeQuCxEGmEBXdOxuDyBsk=
X-Google-Smtp-Source: ABdhPJwwQby1Pfhze5zoyzrFINvrvoDWZvQHbVPSJ4nvbNCd1kzrhe12K8esj9/vfZVfRsVH0/UXTcp3nG5rOKZtK14=
X-Received: by 2002:a0c:e2c5:: with SMTP id t5mr25549380qvl.27.1618908342623;
Tue, 20 Apr 2021 01:45:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
<CABE6yHscUPAcyK58DvqhOnxSOoPMBAy9aMUmReJYSkBit-Mekg@mail.gmail.com>
<CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com>
<050674b8bc51cff11e0a6e105880b647@cock.li>
In-Reply-To: <050674b8bc51cff11e0a6e105880b647@cock.li>
From: Zach Greenwood <zachgrw@gmail.com>
Date: Tue, 20 Apr 2021 10:45:31 +0200
Message-ID: <CAJ4-pEDEsQCqT9Yiz6WiWahPV5kkxc89XbsDydgEPuoZRU8MvQ@mail.gmail.com>
To: yanmaani@cock.li,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000afa21005c0637864"
X-Mailman-Approved-At: Tue, 20 Apr 2021 09:58:09 +0000
Cc: christopher.gilliard@gmail.com
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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: Tue, 20 Apr 2021 08:45:48 -0000
--000000000000afa21005c0637864
Content-Type: text/plain; charset="UTF-8"
[Note: this is my first post to the list]
Businesses storing data on-chain is undesirable but sadly unavoidable.
Therefore one might as well *facilitate* data storage beyond just OP_RETURN
by offering a more efficient way to store data on-chain, while still being
almost as expensive in use per byte of payload (i.e., data) compared to
using OP_RETURN.
Storing data using OP_RETURN is still inefficient per byte of payload so a
more efficient dedicated data storing facility might be created that stores
more payload data per on-chain byte. Such a facility should be (marginally)
cheaper to use per payload byte compared to using a hack such as OP_RETURN.
This would encourage the use of this facility in favor of OP_RETURN or
other hacks, while at the same time dramatically reducing the footprint of
storing data on-chain.
Zac
On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > If only one hash is allowed per block, then those who wish to utilize
> > the hash will have to out-bid each other ("fee-bidding"). This hash can
> > then be used to create another chain ("merged-mining")
>
> Merged mining at present only needs one hash for a merkle root, and
> that's stored in the coinbase. It would be even simpler to add the
> following rules:
>
> 1) No OP_RETURN transactions allowed at all
> 2) If you want to commit data, do so in that one transaction in the
> coinbase
>
> Also curious about how you'd handle the payment - do I need to put in a
> transaction that burns bitcoins for the tx fee? That isn't free in terms
> of storage either.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000afa21005c0637864
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">[Note: this is my first post to the list]<div><br></div><d=
iv>Businesses storing data on-chain is undesirable but sadly unavoidable. T=
herefore one might as well *facilitate* data storage beyond just OP_RETURN =
by offering a more efficient way to store data on-chain, while still being =
almost as expensive in use per byte of payload (i.e., data) compared to usi=
ng OP_RETURN.</div><div><br></div><div>Storing data using OP_RETURN is stil=
l inefficient per byte of payload so a more efficient dedicated data storin=
g facility might be created that stores more payload data per on-chain byte=
. Such a facility should be (marginally) cheaper to use per payload byte co=
mpared to using a hack such as OP_RETURN. This would encourage the use of t=
his facility in favor of OP_RETURN or other hacks, while at the same time d=
ramatically reducing the footprint of storing data on-chain.</div><div><br>=
</div><div>Zac</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin=
-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">> If only one hash is allowed per block, the=
n those who wish to utilize <br>
> the hash will have to out-bid each other ("fee-bidding"). Th=
is hash can <br>
> then be used to create another chain ("merged-mining")<br>
<br>
Merged mining at present only needs one hash for a merkle root, and <br>
that's stored in the coinbase. It would be even simpler to add the <br>
following rules:<br>
<br>
1) No OP_RETURN transactions allowed at all<br>
2) If you want to commit data, do so in that one transaction in the <br>
coinbase<br>
<br>
Also curious about how you'd handle the payment - do I need to put in a=
<br>
transaction that burns bitcoins for the tx fee? That isn't free in term=
s <br>
of storage either.<br>
_______________________________________________<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>
--000000000000afa21005c0637864--
|
