summaryrefslogtreecommitdiff
path: root/86/6c6ab563dfde3e198200e063a92cc855769f7a
blob: 7752b66e84f93a13c3e70b7ee1ecd41d1bdb9ffe (plain)
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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4C8CBC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Apr 2021 17:12:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 48E0B401F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Apr 2021 17:12:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 8D7z_XmMf6KL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Apr 2021 17:12:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com
 [IPv6:2607:f8b0:4864:20::332])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3382E40254
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Apr 2021 17:12:47 +0000 (UTC)
Received: by mail-ot1-x332.google.com with SMTP id
 5-20020a9d09050000b029029432d8d8c5so10498974otp.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Apr 2021 10:12:47 -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=dJ/rp+8BtMkhsFVnGto7TBB6z9umbHAu+3Hi710pIjY=;
 b=k9VDj5FTHKMWpTv4klnu+rQ73gD9gu4OYs13/mC/DJL7Lr0BnuOatbKEqhUQdMF7/i
 8vh9zyaDM2ZVMorb9hjFVazG7hF6CxR0IP14mLOd8Y84z1mpf0dvKMDicsM7GhEaPUQx
 OeRBqnk4qopxcCMszVoLvbJEqVa8ezsNnTvXpUh2UVDu0yGKRMbD3n0ZoI/yaEl0I/Gu
 /VBx9wyRdCADTbdaeNW2X/0ZclUDhMojjZcEsjpoztDqcgRqV+n0jL/PmhXpPh5IzX1S
 A88npnCXl83N6VodXbClx8rTIT2ZKMGECF3TivzeYtamZMRTT7AaHrvlEi7RatmKHZ1l
 4v0A==
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=dJ/rp+8BtMkhsFVnGto7TBB6z9umbHAu+3Hi710pIjY=;
 b=PZlBnpGZBKVTlkHr9otwww+DtsFfySVMLkTN9SUZSBEP9bczPyMGEkOH0ny5mXCith
 YrswiZcWbbRS6UDyzkm9qMZaffPfNOOOOo4qDF4dyVd7OuWEBU3PJ+6EgE8P340+EyD0
 a5UriqxeT70IEMdZPjakW/m8SkAdzg7hEUwIZ0TmJKXJvSCR5A52fdwUjL3R6xI2ovrl
 J96ZJ5UpmPw4lzwW/gOtSdv6ZQ/D+5Y9IWHU+GHPzvIlRnD8Q2T5O/eQFxPgwsTv3Mua
 Vq4K0usd4NDoovwICq9bfFrgIS9xjrhyPMO79yW56tgV2P+k9krvPBWrrdCTKVRIpFXh
 J17Q==
X-Gm-Message-State: AOAM533HUAOqQs8q6wAY0W3tQCJ27TTW4xX0xGW/OKhc6estiOG6Bvt+
 K/ESfLENIh1gLuYTthzQJKgDXHibXgriHz35yo4=
X-Google-Smtp-Source: ABdhPJwEyQ1vRd7fiHEesWODUfTMtQOM/Qv5j1TPfaXHPB15a5WC2kDsr8nJ5n6JRdsUVQcN5yMjj0gZ6Qzyixlt6WE=
X-Received: by 2002:a05:6830:14cd:: with SMTP id
 t13mr19982721otq.74.1618938766302; 
 Tue, 20 Apr 2021 10:12:46 -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>
 <CAJ4-pEDEsQCqT9Yiz6WiWahPV5kkxc89XbsDydgEPuoZRU8MvQ@mail.gmail.com>
In-Reply-To: <CAJ4-pEDEsQCqT9Yiz6WiWahPV5kkxc89XbsDydgEPuoZRU8MvQ@mail.gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Tue, 20 Apr 2021 10:12:35 -0700
Message-ID: <CAK=nyAxmNc087YPwxr-3i9J1zm+1+VWMy_u1a=Rcc1spdZBHKw@mail.gmail.com>
To: Zach Greenwood <zachgrw@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000141fad05c06a8e5b"
X-Mailman-Approved-At: Tue, 20 Apr 2021 18:23:21 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 17:12:51 -0000

--000000000000141fad05c06a8e5b
Content-Type: text/plain; charset="UTF-8"

Zach,

Thanks for the comments. I just sent out another email to the dev alias
with the other two BIPs that I mentioned last week. It is pending approval
now. I think it will talk about some of the things you mentioned. To avoid
having a lot of comments about those BIPs on this thread, let's use the new
thread for discussing those BIPs.

--Chris

On Tue, Apr 20, 2021 at 1:45 AM Zach Greenwood <zachgrw@gmail.com> wrote:

> [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
>>
>

--000000000000141fad05c06a8e5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Zach,<div><br></div><div>Thanks for the comments. I just s=
ent out another email to the dev alias with the other two BIPs that I menti=
oned last week. It is pending approval now. I think it will talk about some=
 of the things you mentioned. To avoid having a lot of comments about those=
 BIPs on this thread, let&#39;s use the new thread for discussing those BIP=
s.</div><div><br></div><div>--Chris</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 20, 2021 at 1:45 AM Za=
ch Greenwood &lt;<a href=3D"mailto:zachgrw@gmail.com">zachgrw@gmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr">[Note: this is my first post to the list]<div><br></div><div>B=
usinesses storing data on-chain is undesirable but sadly unavoidable. There=
fore one might as well *facilitate* data storage beyond just OP_RETURN by o=
ffering a more efficient way to store data on-chain, while still being almo=
st as expensive in use per byte of payload (i.e., data) compared to using O=
P_RETURN.</div><div><br></div><div>Storing data using OP_RETURN is still in=
efficient per byte of payload so a more efficient dedicated data storing fa=
cility might be created that stores more payload data per on-chain byte. Su=
ch a facility should be (marginally) cheaper to use per payload byte compar=
ed 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 drama=
tically reducing the footprint of storing data on-chain.</div><div><br></di=
v><div>Zac</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">&gt; If only one hash is allowed =
per block, then those who wish to utilize <br>
&gt; the hash will have to out-bid each other (&quot;fee-bidding&quot;). Th=
is hash can <br>
&gt; then be used to create another chain (&quot;merged-mining&quot;)<br>
<br>
Merged mining at present only needs one hash for a merkle root, and <br>
that&#39;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&#39;d handle the payment - do I need to put in a=
 <br>
transaction that burns bitcoins for the tx fee? That isn&#39;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>
</blockquote></div>

--000000000000141fad05c06a8e5b--