path: root/7b/4b7d9038ea8a9e48bfe7eb0c14547e8b36515e

Return-Path: <rsomsen@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 57321C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 May 2021 12:51:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 46CB384367
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 May 2021 12:51:29 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rF7jAFyW5COw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 May 2021 12:51:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 547148434A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 May 2021 12:51:27 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id w3so12984318ejc.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 04 May 2021 05:51:27 -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=GZ0+FDejAFnYIpXqRvLiSLE6n7MNXPhdDTdZq4TgDeA=;
 b=hEyzvaoqc1CGuW+LFUdagHbnu+bMMtrxLn9ow+YmA5dUxpl5ghv9r3osAIseerqn6c
 pKbHsstDrGovwmZ/jCgtfxmHUXtmth3mInb9QYFVX7F35OKtSYLMPzTGGcocfpNWWgH/
 DpYavKRbwIwDOIden08pdYE0wT6/dUqxQfvt+p1zFu/ymApCb7K4r/fG1rmtIIpsBCuk
 DovEXVvL7FvAwJliD3qS5OngTcfcyvQUY/4XEyZc27rpkipFyhjWUBGZICp2u65VK6pr
 VfIXmuDmu4S5Kc0EounirRjep90gLE523vzxNQ7p8pMZpDoOv2QQKY0JcKgws5aVgEF0
 DF1Q==
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=GZ0+FDejAFnYIpXqRvLiSLE6n7MNXPhdDTdZq4TgDeA=;
 b=s7sP/4fRo+MMw+02ZUyJ9PPg/SlhaM1tnru41YlKwCOXuSAvocQxflDXTJKJt9e2Lc
 jJwicEnoWqAHOSp4b4dUz+7Ie+aGTrkalBs0pjTIOfisMundwZlmZK2orPU0+7MfDwec
 a+iTH3mQwseq2K87/nZdx2xSFitrdswOV9sXWlvTF0z40EycOQfOfvPFivrIky8dKjEj
 JQLinc2B8BOdt/SJwmTYIs15UF/nQHMxT7vCFeVzha+yrCN5D6r2zWMJ+7jlMNx2Gv13
 Fo6eQq4S9DwWKb9qtFtvZtUvZX1WQdpj+GbKK2Y/YtmwScQMUroGD2Xjjsx7vGq8d5Zn
 ehRA==
X-Gm-Message-State: AOAM5333D7wBfmS47OJW4dhHfRxMsaSafQY3WhXfVlEBVx7reln1T0R9
 wc568SPcKWTVC2cpChcB8SxWTo6O+9uXHwpxYPU=
X-Google-Smtp-Source: ABdhPJwwsSlmiF7BRu9Rt4HwLLeHLoLK/bjhZdk9M0WLCbxaWwnTQn/NNonmlCCEUl+kRZuEZYvE8ZeWgkDnk5CuxyU=
X-Received: by 2002:a17:907:7ba5:: with SMTP id
 ne37mr10919644ejc.113.1620132685540; 
 Tue, 04 May 2021 05:51:25 -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>
 <CAPv7TjaLF-LeEvyfHXs6-4E2cqwDK6qvEQHzwyRy9SUpFA5G=g@mail.gmail.com>
 <1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com>
In-Reply-To: <1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 4 May 2021 14:51:14 +0200
Message-ID: <CAPv7TjYpMRRH563BmhWu64g5LuLH=Q1NXdFS-8_ivKeFwqTCuA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000035f35c05c1808908"
X-Mailman-Approved-At: Tue, 04 May 2021 12:52:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "christopher.gilliard@gmail.com" <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, 04 May 2021 12:51:29 -0000

--00000000000035f35c05c1808908
Content-Type: text/plain; charset="UTF-8"

Good evening ZmnSCPxj,

Thanks for thinking it through. I appreciate the time and effort.

>sidechain functionaries will not earn anything once there are at least 2
functionaries [...] they are doing all this work of validating the
sidechain blocks, but gain nothing [...] the entire sidechain depends on
this one sidechain functionary

I think your description is accurate, and while it may intuitively sound
problematic, it turns out it does not actually cause any issues.

Even in a scenario where one entity is consistently creating all the
spacechain blocks, they can only do so as long as they consistently leave 0
profit on the table for others. This is actually perfectly acceptable,
because that means this entity is not censoring anyone. As soon as they try
to abuse their position with censorship, it's trivial for anyone to step in
and outbid them.

How trivial, you may wonder? Well, there is very little difference between
being a spacechain miner and a spacechain user. Both are expected to run
full nodes, the only difference is that the miner has some BTC available
and is willing to use it to "mine" the block reward in the spacechain. This
means that the barrier for users to act as miners is low to the point where
it may happen altruistically, and, interestingly, it also doubles as an
appealing way for users to purchase spacecoins in a decentralized fashion.

Btw, I personally prefer not to call a "BMM chain" a sidechain, because in
my eyes it's not a sidechain if the chain has its own altcoin. The
spacechain design (which avoids the use of an altcoin) comes closer to
being a sidechain in that regard, but even there the use of the term
"sidechain" is debatable.

I hope this clarifies things.

Cheers,
Ruben





On Mon, May 3, 2021 at 7:17 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben,
>
> > 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).
>
> What bothers me about BMM is the B.
>
> Mainchain miners assume that sidechain functionaries check the sidechain
> rules.
> Their rule is that if the sidechain functionary is willing to pay an
> amount, then obviously the sidechain functionary must benefit by at *least*
> that amount (if not, the sidechain functionary is losing funds over time
> and will go out of business at some point).
> Thus the BMM is an economic incentive for sidechain functionaries to be
> honest, because dishonesty means that sidechain nodes will reject their
> blocks and they will have earned nothing in the sidechain that is of equal
> or greater value than what they spend on the mainchain.
>
> But the BMM on mainchain is done by bidding.
> Suppose a sidechain functionary creates a block where it gets S fees, and
> it pays (times any exchange rates that arise due to differing security
> profiles of mainchain vs sidechain) M in fess to mainchain miners to get
> its commitment on the mainchain.
> Then any other competing sidechain functionary can create the same block
> except the S fees go to itself, and paying M+1 in fees to mainchain miners
> to get *that* commitment mainchain.
> This triggers a bidding war.
> Logically, further sidechain functionaries will now bid M+2 etc. until M=S
> (times exchange rates) and the highest bidder earns nothing.
>
> That means that sidechain functionaries will not earn anything once there
> are at least 2 functionaries, because if there are two sidechain
> functionaries then they will start the above bidding war and all earnings
> go to mainchain miners, who are not actually validating anything in the
> sidechain.
> So they are doing all this work of validating the sidechain blocks, but
> gain nothing thereby, and are thus not much better than fullnodes.
>
> Even if you argue that the sidechain functionaries might gain economic
> benefit from the existence of the sidechain, that economic benefit can be
> quantified as some economic value, that can be exchanged at some exchange
> rate with some number of mainchain tokens, so M just rises above S by that
> economic benefit and sidechain functionaries will still end up earning 0
> money.
>
> If there is only one sidechain functionary the above bidding war does not
> occur, but then the entire sidechain depends on this one sidechain
> functionary.
>
> So it does not seem to me that blinded merge mining would work at scale.
> Maybe.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Good evening=C2=A0ZmnSCPxj,<div><br></div><div>Thanks for =
thinking it through. I appreciate the time and effort.<br><div><br></div><d=
iv>&gt;sidechain functionaries will not earn anything once there are at lea=
st 2 functionaries [...] they are doing all this work of validating the sid=
echain blocks, but gain nothing [...] the entire sidechain depends on this =
one sidechain functionary

</div><div><br></div><div>I think your description is accurate, and while i=
t may intuitively sound problematic, it turns out it does not actually caus=
e any issues.</div><div><br></div><div>Even in a scenario where one entity =
is consistently creating all the spacechain blocks, they can only do so as =
long as they consistently leave 0 profit on the table for others. This is a=
ctually perfectly acceptable, because that means this entity is not censori=
ng anyone. As soon as they try to abuse their position with censorship, it&=
#39;s trivial for anyone to step in and outbid them.</div><div><br></div><d=
iv>How trivial, you may wonder? Well, there is very little difference betwe=
en being a spacechain miner and a spacechain user. Both are expected to run=
 full nodes, the only difference is that the miner has some BTC available a=
nd is willing to use it to &quot;mine&quot; the block reward in the spacech=
ain. This means that the barrier for users to act as miners is low to the p=
oint where it may happen altruistically, and, interestingly, it also double=
s as an appealing way for users to purchase spacecoins in a decentralized f=
ashion.<br></div><div><br></div><div>Btw, I personally prefer not to call a=
 &quot;BMM chain&quot; a sidechain, because in my eyes it&#39;s not a sidec=
hain if the chain has its own altcoin. The spacechain design (which avoids =
the use of an altcoin) comes closer to being a sidechain in that regard, bu=
t even there the use of the term &quot;sidechain&quot; is debatable.</div><=
div><br></div><div>I hope this clarifies things.</div><div><br></div><div>C=
heers,</div><div>Ruben</div><div><br></div><div><br></div><div><br></div><d=
iv><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Mon, May 3, 2021 at 7:17 AM ZmnSCPxj &lt;<a href=3D"m=
ailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Ruben,<b=
r>
<br>
&gt; Hi Yanmaani,<br>
&gt;<br>
&gt; &gt;Merged mining at present only needs one hash for a merkle root, an=
d that&#39;s stored in the coinbase.<br>
&gt;<br>
&gt; Yes, but that method is not &quot;blind&quot;, meaning BTC miners have=
 to validate=C2=A0the merged-mined chain, which is a significant downside.<=
br>
&gt;<br>
&gt; &gt;It would be even simpler to add the following rules<br>
&gt;<br>
&gt; That would require a specific soft fork, whereas the method described =
in my post avoids doing that.<br>
&gt;<br>
&gt; &gt;do I need to put in a transaction that burns bitcoins for the tx f=
ee<br>
&gt;<br>
&gt; The blind merged-mined chain (which I call a &quot;spacechain&quot;) n=
eeds its own native token in order to pay for fees. The mechanism I propose=
d for that is the perpetual one-way peg, which allows fair &quot;spacecoin&=
quot; creation by burning BTC, and circumvents creating bad speculative alt=
coin incentives. Anyone can create a spacechain block and take the fees, an=
d then try to get BTC miners to include it by paying a higher fee than othe=
rs (via RBF).<br>
<br>
What bothers me about BMM is the B.<br>
<br>
Mainchain miners assume that sidechain functionaries check the sidechain ru=
les.<br>
Their rule is that if the sidechain functionary is willing to pay an amount=
, then obviously the sidechain functionary must benefit by at *least* that =
amount (if not, the sidechain functionary is losing funds over time and wil=
l go out of business at some point).<br>
Thus the BMM is an economic incentive for sidechain functionaries to be hon=
est, because dishonesty means that sidechain nodes will reject their blocks=
 and they will have earned nothing in the sidechain that is of equal or gre=
ater value than what they spend on the mainchain.<br>
<br>
But the BMM on mainchain is done by bidding.<br>
Suppose a sidechain functionary creates a block where it gets S fees, and i=
t pays (times any exchange rates that arise due to differing security profi=
les of mainchain vs sidechain) M in fess to mainchain miners to get its com=
mitment on the mainchain.<br>
Then any other competing sidechain functionary can create the same block ex=
cept the S fees go to itself, and paying M+1 in fees to mainchain miners to=
 get *that* commitment mainchain.<br>
This triggers a bidding war.<br>
Logically, further sidechain functionaries will now bid M+2 etc. until M=3D=
S (times exchange rates) and the highest bidder earns nothing.<br>
<br>
That means that sidechain functionaries will not earn anything once there a=
re at least 2 functionaries, because if there are two sidechain functionari=
es then they will start the above bidding war and all earnings go to mainch=
ain miners, who are not actually validating anything in the sidechain.<br>
So they are doing all this work of validating the sidechain blocks, but gai=
n nothing thereby, and are thus not much better than fullnodes.<br>
<br>
Even if you argue that the sidechain functionaries might gain economic bene=
fit from the existence of the sidechain, that economic benefit can be quant=
ified as some economic value, that can be exchanged at some exchange rate w=
ith some number of mainchain tokens, so M just rises above S by that econom=
ic benefit and sidechain functionaries will still end up earning 0 money.<b=
r>
<br>
If there is only one sidechain functionary the above bidding war does not o=
ccur, but then the entire sidechain depends on this one sidechain functiona=
ry.<br>
<br>
So it does not seem to me that blinded merge mining would work at scale.<br=
>
Maybe.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000035f35c05c1808908--