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: <rsomsen@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3BD20C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 19:07:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2F67340475
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 19:07:19 +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 IITYIPVfIT5C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 19:07:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
[IPv6:2a00:1450:4864:20::529])
by smtp2.osuosl.org (Postfix) with ESMTPS id 82CD3402A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 19:07:14 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id cq11so2767329edb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Apr 2021 12:07:14 -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=c4s2A6VEpdSxYreOprBBY64VflqVxNmbXqYEAwHLCZY=;
b=YqhMDugi8n78aZVNV2+7o1TwNZ2PUOuFhZbGoCPswuf9qnV5E69pbMt8UnxiqcAgzb
oCRXJLGCVT8ka7aWwCNA07i8sxW/P77eQdB0RlHqraLTfHaY7Qfry+shoyo3d4LvnIqZ
xy96epLa3p1NZ149E6CIg3tPymxH8acRYTtnonEVoD7mtoc0VWEyDUBfbuEozqNF6Haa
032ewhop/dQB6o4fU/6GM/JwR/mE/iYkMUUVOigqs9JgxpYq8mt5esl+27ihB+rvjjAv
W6XEf/WJduLCfSJk63Xf2KCTC/gprEELlEL4tHiNzLZHxsrZvkrZAgKbBOrQV7ejdlSv
pBbg==
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=c4s2A6VEpdSxYreOprBBY64VflqVxNmbXqYEAwHLCZY=;
b=te351sHXX7PQgOOeSgL7W2cVeylB7bVOZIYA0CX7rgPzXRvm4vkAUdPPhetnsKYWD2
GLVhzSJTmlgw5k+Z6iDo6nK46n3kL6DKu4gtFeygZnRTdue+PHLyT0gu5ObR0auUbnPk
IRIwQtMaOAEsRkNZDNeFu/OHxkLh/xpVsBXb0uXuemciscF1rnqcxoVrsjGoUGwd0UB5
8fgfxS5ymEMju6IRlDwYcPz6ZUMio6NXh9hFGKyYVTnsQxbBCVvZKh1JJO4vRlt++Kok
nd9sjiGDAUX9ZZB4XJIL3j4jAVM8QI9XiA1IUMdGEZvqRvji7ndNhjLEEpOGKWoKaSLm
/Qxw==
X-Gm-Message-State: AOAM530wSXKbfVTX0IodOBrVbQsBMfTvPkZ65RvecVybSrcMImaQAtbL
x/DieDMZdo8O/2wBDUK28dJh7qwYkjYojlg3qQk=
X-Google-Smtp-Source: ABdhPJxoOKSEaqEGJaDMrggjntQG3WXCu9jE7aKywNVyNQ4ye1ge5uWsj9dFn0UMGiufB6oZU4pc0XQY9cS7gw/gVcM=
X-Received: by 2002:a05:6402:706:: with SMTP id
w6mr26968028edx.15.1618945632860;
Tue, 20 Apr 2021 12:07:12 -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: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 20 Apr 2021 21:07:00 +0200
Message-ID: <CAPv7TjaLF-LeEvyfHXs6-4E2cqwDK6qvEQHzwyRy9SUpFA5G=g@mail.gmail.com>
To: yanmaani@cock.li
Content-Type: multipart/alternative; boundary="0000000000005b7ed105c06c278f"
X-Mailman-Approved-At: Tue, 20 Apr 2021 19:08:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
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 19:07:19 -0000
--0000000000005b7ed105c06c278f
Content-Type: text/plain; charset="UTF-8"
Hi Yanmaani,
>Merged mining at present only needs one hash for a merkle root, and that's
stored in the coinbase.
Yes, but that method is not "blind", meaning BTC miners have to
validate the merged-mined chain, which is a significant downside.
>It would be even simpler to add the following rules
That would require a specific soft fork, whereas the method described in my
post avoids doing that.
>do I need to put in a transaction that burns bitcoins for the tx fee
The blind merged-mined chain (which I call a "spacechain") needs its own
native token in order to pay for fees. The mechanism I proposed for that is
the perpetual one-way peg, which allows fair "spacecoin" creation by
burning BTC, and circumvents creating bad speculative altcoin incentives.
Anyone can create a spacechain block and take the fees, and then try to get
BTC miners to include it by paying a higher fee than others (via RBF).
>That isn't free in terms of storage
It's not necessary for everyone to burn individually. My preferred design
is to only let BMM block creators burn BTC, then others will have to buy
spacecoins from them. This limits the potential burn outputs to one per
block (likely much less, because BTC will logically only get burned when
spacecoin demand increases). It's also possible to create more spacechains
inside the initial spacechain, at no additional storage cost to Bitcoin.
I highly recommend checking out the links in my prior post
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018803.html>
if you wish to learn more, particularly the video
<https://youtu.be/N2ow4Q34Jeg>.
Cheers,
Ruben
On Tue, Apr 20, 2021 at 3:23 AM <yanmaani@cock.li> 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.
>
--0000000000005b7ed105c06c278f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Yanmaani,</div><div><br></div>>Merged mining at=
present only needs one hash for a merkle root, and that's stored in th=
e coinbase.<div><br></div><div>Yes, but that method is not "blind"=
;, meaning BTC miners have to validate=C2=A0the merged-mined chain, which i=
s a significant downside.</div><div><br></div><div>>It would be even sim=
pler to add the following rules</div><div><br></div><div>That would require=
a specific soft fork, whereas the method described in my post avoids doing=
that.</div><div><br></div><div>>do I need to put in a transaction that =
burns bitcoins for the tx fee</div><div><br></div><div>The blind merged-min=
ed chain (which I call a "spacechain") needs its own native token=
in order to pay for fees. The mechanism I proposed for that is the perpetu=
al one-way peg, which allows fair "spacecoin" creation by burning=
BTC, and circumvents creating bad speculative altcoin incentives. Anyone c=
an create a spacechain block and take the fees, and then try to get BTC min=
ers to include it by paying a higher fee than others (via RBF).</div><div><=
br></div><div>>That isn't free in terms of storage
</div><div><br></div><div>
It's not necessary for everyone to burn individually. My preferred des=
ign is to only=C2=A0let BMM block creators burn BTC, then others will have =
to buy spacecoins from them. This limits the potential burn outputs to one =
per block (likely much less, because BTC will logically only get burned whe=
n spacecoin demand increases). It's also possible to create more spacec=
hains inside the initial spacechain, at no additional storage cost to Bitco=
in.</div><div><br></div><div>I highly recommend checking out the links in <=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Apri=
l/018803.html">my prior post</a> if you wish to learn more, particularly th=
e <a href=3D"https://youtu.be/N2ow4Q34Jeg">video</a>.<br></div><div><br></d=
iv><div>Cheers,</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 20, 2021 at 3:23 AM <<a=
href=3D"mailto:yanmaani@cock.li">yanmaani@cock.li</a>> 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">> If only one hash is =
allowed per block, then 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>
</blockquote></div>
--0000000000005b7ed105c06c278f--
|
