Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DF5E8C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 May 2021 05:18:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D335B4027F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 May 2021 05:18:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 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,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.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 COE9xbb3tm96
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 May 2021 05:17:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 0396D4026F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 May 2021 05:17:58 +0000 (UTC)
Date: Mon, 03 May 2021 05:17:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1620019075;
 bh=P8yfHHp5E7DB/rN2aVjfLXGKKyqwuC6Q1pchjMT10bM=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=dNNKEVilRhtW0NYy5tv62HdZPg39jV9kSpTkCYXUskqz3CGKIP7KYiE1pbCIJBvtb
 00D4ojUIlAsOssoMIbuvGkMrCo3kVQNcgfNjoyL498ijjsDPS6x9CDkN15fU7MVIE0
 2uVcOxabwtmkzuQB6NLMxFvfEqtbbKpNO4UQG3c0=
To: Ruben Somsen <rsomsen@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com>
In-Reply-To: <CAPv7TjaLF-LeEvyfHXs6-4E2cqwDK6qvEQHzwyRy9SUpFA5G=g@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "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: Mon, 03 May 2021 05:18:01 -0000

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=
=C2=A0the 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 burni=
ng BTC, and circumvents creating bad speculative altcoin incentives. Anyone=
 can create a spacechain block and take the fees, and then try to get BTC m=
iners 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 ru=
les.
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).
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.

But the BMM on mainchain is done by bidding.
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.
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.
This triggers a bidding war.
Logically, further sidechain functionaries will now bid M+2 etc. until M=3D=
S (times exchange rates) and the highest bidder earns nothing.

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

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.

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.

So it does not seem to me that blinded merge mining would work at scale.
Maybe.

Regards,
ZmnSCPxj