summaryrefslogtreecommitdiff
path: root/c1/6b4e80556568d1eeb88016274c7b83ad792197
blob: 300440c6b6aaf206c83ab2e29a842d4d95a55465 (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
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1CE54C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:09:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id F2476405AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:09:40 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FEwe6HppjMhx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:09:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com
 [IPv6:2607:f8b0:4864:20::22a])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 198924051F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:09:37 +0000 (UTC)
Received: by mail-oi1-x22a.google.com with SMTP id m13so29177291oiw.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 14:09:36 -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=+PIKlfEcaCTFNQMfCRcfCq8p08tIMtlm6jS8piWNJqY=;
 b=OYTR1gFwxBjaBOy/jZFUtQca00q1xEMQxz6Vlp8Z0C1KdGwZ1Q104aApGnAZxaoJYj
 EzzWVL6ubPfz1BURBpGPFBARHV9DVvoo2+3YrXPpzTuOPM7LzRCFFm1rWaa2IPjvYB0s
 g6T1lTelNC8AEnSIaqnVM2QLBuhHIahMunaEa666dFGrkc95GGXcx261/VCTkRb93VRO
 SfxIjvybRXIqYdcXYhoI8t8oPsQ3619rtNFpIII/ywyOrkPQSeVblUOghnCOb0Js3BS6
 O8+em/l6FjzUZRwvJVrOka6/gRGn1SNza2Pd5uLAE+G3Gctr6ucMmbCkcVMef4cjaq2B
 uoiQ==
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=+PIKlfEcaCTFNQMfCRcfCq8p08tIMtlm6jS8piWNJqY=;
 b=NSYwpYLA/jc+RXTLrWLJ7BsAgJiNpwcVHQwc64oHeSDHSkRX7DKrtF4FDUjqhnRG1m
 tG1IZY3ritvyi7EBXO6bALerDxz7vvF5lXezqwHKZ0j3wMP6sM9czdUS/ETQ7fo1iGeN
 KbiEqOCe2Fa8cG6vHRy/2uxIQmRiineWnkBc8k5Mt541caeIkkK21n+uuig/ccnWv9qa
 UcByKgye7nBWq9RAL6VEK16tYIuat78796asP0VNbXI2LQW1SAnCLfD23czpgP8SNhfE
 vn5vkMtMFii+6XXWB37zfOO7f2PtEIzBphnqzrIrtD1Rilv+kJgo4GC5kjzb18zvSkZh
 pqHQ==
X-Gm-Message-State: AOAM531YHb938YVwnvovafz1EkP6+4G98rukfM/oeHNIng8Z26VgkyrD
 t+dyUv1yeNqZzW7RMuSz/Vn191IXnNC5b2B7eYg=
X-Google-Smtp-Source: ABdhPJw6gw26AjUygVQv6jtqYHPdIs05ZZzInQIxgRUqW1toBHCKXD6MFh/A5+MKMu5ZF4I/DrGyDlyVufzzQuliMj0=
X-Received: by 2002:a05:6808:4c4:: with SMTP id
 a4mr8145119oie.170.1618607376135; 
 Fri, 16 Apr 2021 14:09:36 -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>
In-Reply-To: <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Fri, 16 Apr 2021 21:09:25 +0000
Message-ID: <CAK=nyAynHnv_WmgkZecCXBGdJCbZ1s3jJf66g0gTSf8oJnH7ZA@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000af7a0505c01d65ac"
X-Mailman-Approved-At: Fri, 16 Apr 2021 21:39:08 +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: Fri, 16 Apr 2021 21:09:41 -0000

--000000000000af7a0505c01d65ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback. I will take at the links and the video and see if
there's anything that I can incorporate to the BIPs.

On Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi Chris,
>
> I agree with all the points that were made by others. You should also be
> aware that layer two ideas like yours have already been explored, both by
> myself and others. Allowing one hash per block allows for what I call
> "fee-bidding Blind Merged-Mining" (BMM), which as far as I know was first
> proposed by Paul Storc for Drivechains.[0]
>
> 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"), while the Bitcoin miners =
do
> not have to be aware of this other chain ("blind"). There are also non
> fee-bidding variants that function e.g. by burning or locking up bitcoins
> in order to create consensus.
>
> As it turns out, fee-bidding BMM can be achieved using only a covenant
> structure for transactions.[1] You'd have to create a sequence of
> transactions (one per block), to which a hash can be attached. These can
> simply be pre-signed transactions (requires forgetting a key, but the wor=
st
> that can happen is that the chain halts), or an actual covenant using
> either sighash_anyprevout or op_ctv (we don't have these yet) =E2=80=93 n=
o
> specialized soft fork (or hard fork) is required.
>
> You might think any decentralized alternative chain requires an altcoin,
> but this can also be avoided with a perpetual one-way peg.[2] For more
> details, I recommend watching this video of the full concept, which I cal=
l
> "spacechains": https://youtu.be/N2ow4Q34Jeg
>
> -- Ruben Somsen
>
>
>
> [0] Blind Merged-Mining for Drivechains:
> https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki
>
> [1] Fee-bidding Blind Merged-Mining with covenants:
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
> [2] Perpetual one-way peg:
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechain=
s-the-perpetual-one-way-peg-96cb2f8ac302
>
> On Fri, Apr 16, 2021 at 9:33 PM Kostas Karasavvas via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Christopher,
>>
>> Some feedback:
>>
>> "OP_RETURN is limited to 40 bytes of data."
>> It is 80 bytes.
>>
>> "A future BIP proposing such a layer two protocol will be forthcoming."
>> So what is this BIP about? Just saying that it would be a nice idea? Thi=
s
>> BIP should be the one that would go through this L2 suggestion. If one r=
oot
>> OP_RETURN substitutes all the rest it should say how that would be done.=
..
>> where would the merkle proofs be stored, what are the trust
>> assumptions that we need to make, etc.
>>
>> "Objections to this proposal" section
>> I agree with others re hard-fork, which would be a good thing of course.
>> My main objection with this proposal is that I don't see a proposal. It
>> seems like wishful thinking... if only we could substitute all the
>> OP_RETURNs with one :-)
>>
>> We have to make sure that a proposal like this (L2, etc.) would make sur=
e
>> that there are incentives that justify the added complexity for the user=
s.
>> Multisig is not the only way data could be stored the wrong way; P2PK,
>> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not g=
ood
>> enough people would start using these UTXO-bloat-heavy alternatives.
>>
>> There are a multitude of L2's (kind-of) that do this 'aggregation' of
>> data hashes using merkle trees. Factom is adding a single merkle root pe=
r
>> bitcoin block for the millions upon millions of records (of thousand of
>> users) that they keep in their network. Opentimestamps, tierion,
>> blockstacks and others do a similar thing. I have investigated several o=
f
>> those in the past, for one of my projects, but I ended up using plain ol=
d
>> OP_RETURN because the overhead of their (L2-like) solution and trust
>> assumptions where not to my liking; at least for my use case. They were
>> pretty solid/useful for other use cases.
>>
>> Unless the proposed L2 is flexible/generic enough it would really
>> prohibit this L2 innovation that OP_RETURN allowed (see above).
>>
>>
>>
>> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I have created a BIP which can be found here:
>>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>>
>>> I'm sending this email to start the discussion regarding this proposal.
>>> If there are any comments/suggestions, please let me know.
>>>
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Konstantinos A. Karasavvas
>> Software Architect, Blockchain Engineer, Researcher, Educator
>> https://twitter.com/kkarasavvas
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Thanks for the feedback. I will take at the links and the =
video and see if there&#39;s anything that I can incorporate to the BIPs.</=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gm=
ail.com">rsomsen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">Hi Chris,<div><br></div><div>I a=
gree with all the points that were made by others. You should also be aware=
 that layer two ideas like yours have already been explored, both by myself=
 and others. Allowing one hash per block allows for what I call &quot;fee-b=
idding Blind Merged-Mining&quot; (BMM), which as far as I know was first pr=
oposed by Paul Storc for Drivechains.[0]</div><div><br></div><div>If only o=
ne hash is allowed per block, then those who wish to utilize the hash will =
have to out-bid each other (&quot;fee-bidding&quot;). This hash can then be=
 used to create another chain (&quot;merged-mining&quot;), while the Bitcoi=
n miners do not have to be aware of this other chain (&quot;blind&quot;). T=
here are also non fee-bidding variants that function e.g. by burning or loc=
king up bitcoins in order to create consensus.</div><div><br></div><div>As =
it turns out, fee-bidding BMM can be achieved using only a covenant structu=
re for transactions.[1]

 You&#39;d have to create a sequence of transactions (one per block), to wh=
ich a hash can be attached. These can simply be pre-signed transactions (re=
quires forgetting a key, but the worst that can happen is that the chain ha=
lts), or an actual covenant using either sighash_anyprevout or op_ctv (we d=
on&#39;t have these yet) =E2=80=93 no specialized soft fork (or hard fork) =
is required.</div><div><br></div><div>You might think any decentralized alt=
ernative chain requires an altcoin, but this can also be avoided with a per=
petual one-way peg.[2] For more details, I recommend watching this video of=
 the full concept, which I call &quot;spacechains&quot;:=C2=A0<a href=3D"ht=
tps://youtu.be/N2ow4Q34Jeg" target=3D"_blank">https://youtu.be/N2ow4Q34Jeg<=
/a></div><div><br></div><div>-- Ruben Somsen</div><div><br></div><div><br><=
/div><div><br></div><div>[0] Blind Merged-Mining for Drivechains:=C2=A0<a h=
ref=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki" targ=
et=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0301.mediawik=
i</a></div><div><br></div><div>[1] Fee-bidding Blind Merged-Mining with cov=
enants: <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d=
8b34906b16a5" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4be6d=
18e5fa526b17d8b34906b16a5</a></div><div><br></div><div>[2] Perpetual one-wa=
y peg:=C2=A0<a href=3D"https://medium.com/@RubenSomsen/21-million-bitcoins-=
to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302" target=3D"_b=
lank">https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidec=
hains-the-perpetual-one-way-peg-96cb2f8ac302</a></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021=
 at 9:33 PM Kostas Karasavvas via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">Hi Christopher,<div><br></div><div>Some feedba=
ck:</div><div><br></div><div>&quot;OP_RETURN is limited to 40 bytes of data=
.&quot;</div><div>It is 80 bytes.</div><div><br></div><div>&quot;A future B=
IP proposing such a layer two protocol will be forthcoming.&quot;</div><div=
>So what is this BIP about? Just saying that it would be a nice idea? This =
BIP should be the one that would go through this L2 suggestion. If one root=
 OP_RETURN substitutes all the rest it should say how that would be done...=
 where would the merkle proofs be stored, what are the trust assumptions=C2=
=A0that we need to make, etc.</div><div><br></div><div>&quot;Objections to =
this proposal&quot; section</div><div>I agree with others re hard-fork, whi=
ch would be a good thing of course.=C2=A0 My main objection with this propo=
sal is that I don&#39;t see a proposal. It seems like wishful thinking... i=
f only we could substitute all the OP_RETURNs with one :-)</div><div><br></=
div><div>We have to make sure that a proposal like this (L2, etc.) would ma=
ke sure that there are incentives that justify the added complexity for the=
 users. Multisig is not the only way data could be stored the wrong way; P2=
PK, P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not =
good enough people would start using these UTXO-bloat-heavy alternatives.</=
div><div><br></div><div>There are a multitude of L2&#39;s (kind-of) that do=
 this &#39;aggregation&#39; of data hashes using merkle trees. Factom is ad=
ding a single=C2=A0merkle root per bitcoin block for the millions upon mill=
ions of records (of thousand of users) that they keep in their network. Ope=
ntimestamps, tierion, blockstacks and others do a similar thing. I have inv=
estigated several of those in the past, for one of my projects, but I ended=
 up using plain old OP_RETURN because the overhead of their (L2-like) solut=
ion and trust assumptions where not to my liking; at least for my use case.=
 They were pretty solid/useful for other use cases.</div><div><br></div><di=
v>Unless the proposed L2 is flexible/generic enough it would really prohibi=
t this L2 innovation that OP_RETURN allowed (see above).=C2=A0</div><div><b=
r></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></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">=
I have created a BIP which can be found here:=C2=A0<a href=3D"https://githu=
b.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki" target=3D"_blank=
">https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki</a=
><div><br></div><div>I&#39;m sending this email to start the discussion reg=
arding this proposal. If there are any comments/suggestions, please let me =
know.</div><div><br></div><div>Regards,</div><div>Chris</div></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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div><div>Konstantinos A. Karasavvas</div><div>Software A=
rchitect, Blockchain Engineer, Researcher, Educator</div><div dir=3D"ltr"><=
a href=3D"https://twitter.com/kkarasavvas" target=3D"_blank">https://twitte=
r.com/kkarasavvas</a><br></div></div></div></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>
</blockquote></div>

--000000000000af7a0505c01d65ac--