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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 christopher.gilliard@gmail.com
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Precedence: list

--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>&gt;Merged mining at=
 present only needs one hash for a merkle root, and that&#39;s stored in th=
e coinbase.<div><br></div><div>Yes, but that method is not &quot;blind&quot=
;, meaning BTC miners have to validate=C2=A0the merged-mined chain, which i=
s a significant downside.</div><div><br></div><div>&gt;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>&gt;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 &quot;spacechain&quot;) 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 &quot;spacecoin&quot; 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>&gt;That isn&#39;t free in terms of storage

</div><div><br></div><div>

 It&#39;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&#39;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 &lt;<a=
 href=3D"mailto:yanmaani@cock.li">yanmaani@cock.li</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">&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>
</blockquote></div>

--0000000000005b7ed105c06c278f--