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