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
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 64CECC002F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 18:15:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 52D69405D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 18:15:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001,
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 OBrQmnxRwGL1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 18:15:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
[IPv6:2a00:1450:4864:20::536])
by smtp2.osuosl.org (Postfix) with ESMTPS id 25ABE40146
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 18:15:34 +0000 (UTC)
Received: by mail-ed1-x536.google.com with SMTP id m4so83246724edb.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 10:15:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=9ZhPIW+BID7HypKJFUCb1X2nnRUSkwKW2B40BAon9k4=;
b=LkTd1P2yQvsOeN6XEmO4W6Ci+B9q3tejm7BFlzT5HcpMny5EjzjwsJY5h5mjHC8FGK
Gny3Fr/wfXBLf2u/mdTT8Bptny235isS51uWfsVXGJiIC54wqRldwVTK1tdvZZGVUpSB
LYy4f0TLgTJ4BdAOczAwWtECpq6KfDQ4v7Cu+OqWvootF1slvlIpD7E+2Hqmi0CO0o1r
U1TNiZMWE9m6qmtPNd1endLdyoJmWCKrmoFDOmfXhU3+mHNFnilYmu9P4jkvNH4mPEtc
HcYGjwo8uyvtxLMX10BwxQYebmBPq0F2DOnGbJmgor7wE6fbN7SkcCkUJXTXWXkWf5Qj
UFuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=9ZhPIW+BID7HypKJFUCb1X2nnRUSkwKW2B40BAon9k4=;
b=1hWB4m94iTMjkN+yS/rtiQQo3xEepPyx/NYLdKQTe+MeUkdugaRWg41x5VM81pKL/C
wYEL6QakITkoYukGhmujAHxrMYg42p6+Qz14uQGo+OBbh1ba8F9pNFCeUd5hd+StBTul
SyIBD6senJ6YuQsifubQV4JNuixLhV2mRgXCZM00wMRGD8yzgXAToEOc4Umfr7QhV74l
sjals3T30XTFWkne2R1riykm6Gq5GNc7bf2n3BzIzO7IC816bovSXe9i7hYnzVtrDE9G
0uytuZ5G0C9sRhEV/2i2M6Rbnz/zz0OTRq64TrHmHBUdEv0xQyFHgGgUhI/teW+dqyRS
xNPw==
X-Gm-Message-State: AOAM533IHqoidYxBk3JN0X/S5mP0tanvrscR315V1NK1vjyViESAK8KB
lmQZuwjCh5PtwTEj9gPJQbOQvc0nsS1Zvpb2vt0=
X-Google-Smtp-Source: ABdhPJxLAblW5riOabJR47ES7Y/dNPGxkTkyS/U4HK6ltXoTzx4ttCBoigPhrnNaOpOR+s5NcN3g0BqH9RncqZxMWIg=
X-Received: by 2002:a17:906:dc95:: with SMTP id
cs21mr12221350ejc.709.1642529732226;
Tue, 18 Jan 2022 10:15:32 -0800 (PST)
MIME-Version: 1.0
References: <CAGpPWDbGTET27Hq8kKrQQoOavtOUEGzYkohVurSqZJ5r+o4gpQ@mail.gmail.com>
<151161119-8858833d76ec6beed19cf87cc542dc62@pmq3v.m5r2.onet>
<CAD5xwhhNgVp1wb3+CEAnGmCoYHFKQPPqRg-WvkCuaD+8WAAG_Q@mail.gmail.com>
In-Reply-To: <CAD5xwhhNgVp1wb3+CEAnGmCoYHFKQPPqRg-WvkCuaD+8WAAG_Q@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 12:15:15 -0600
Message-ID: <CAGpPWDaTb0+jbWzC46K9jnS6-DRb5opDXnmA83P5SeTzACBuaA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000038f58a05d5df41e7"
X-Mailman-Approved-At: Tue, 18 Jan 2022 19:14:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized
Coordination Free Mining Pools
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, 18 Jan 2022 18:15:35 -0000
--00000000000038f58a05d5df41e7
Content-Type: text/plain; charset="UTF-8"
@vjudeu
> If you introduce signing into mining, then you will have cases, where
someone is powerful enough to produce blocks, but cannot, because signing
is needed.. your consensus is no longer "the heaviest chain"
You've misunderstood my suggestion. This would not be possible with what I
suggested. Why do you think of the signature as some kind of barrier? What
I was suggesting was that, when a miner participating in this protocol
mines a valid bitcoin block, they then sign a superblock with a public key
that can be verified alongside the coinbase output (eg say with data in the
first tapleaf of the output address). The block is still connected to
something secured by PoW. You really made a lot of incorrect assumptions
about what I suggested.
On Thu, Dec 23, 2021 at 1:05 PM Jeremy <jlrubin@mit.edu> wrote:
> If you introduce signing into mining, then you will have cases, where
>> someone is powerful enough to produce blocks, but cannot, because signing
>> is needed. Then, your consensus is no longer "the heaviest chain", but "the
>> heaviest signed chain". That means, your computing power is no longer
>> enough by itself (as today), because to make a block, you also need some
>> kind of "permission to mine", because first you sign things (like in
>> signet) and then you mine them. That kind of being "reliably unreliable"
>> may be ok for testing, but not for the main network.
>
>
> this is a really great point worth underscoring. this is the 'key
> ingredient' for DCFMP, which is that there is no signing or other network
> system that is 'in the way' of normal bitcoin mining, just an opt-in set of
> rules for sharing the bounties of your block in exchange for future shares.
>
--00000000000038f58a05d5df41e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>@vjudeu<br></div>>=C2=A0
If you introduce signing into mining, then you will have cases, where someo=
ne is powerful enough to produce blocks, but cannot, because signing is nee=
ded..=C2=A0
<span style=3D"color:rgb(80,0,80)">your consensus is no longer "the he=
aviest chain"</span><div><br></div><div>You've misunderstood my su=
ggestion. This would not be possible with what I suggested. Why do you thin=
k of the signature as some kind of barrier? What I was suggesting was that,=
when a miner participating=C2=A0in this protocol mines a valid bitcoin blo=
ck, they then sign a superblock with a public key that=C2=A0can be verified=
alongside the coinbase output (eg say with data in the first tapleaf of th=
e output address). The block is still connected to something secured by PoW=
. You really made a lot of incorrect assumptions about what I suggested.=C2=
=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Dec 23, 2021 at 1:05 PM Jeremy <<a href=3D"mailto:jlrub=
in@mit.edu">jlrubin@mit.edu</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)"></div></div><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex">If you introduce signing into mining, t=
hen you will have cases, where someone is powerful enough to produce blocks=
, but cannot, because signing is needed. Then, your consensus is no longer =
"the heaviest chain", but "the heaviest signed chain". =
That means, your computing power is no longer enough by itself (as today), =
because to make a block, you also need some kind of "permission to min=
e", because first you sign things (like in signet) and then you mine t=
hem. That kind of being "reliably unreliable" may be ok for testi=
ng, but not for the main network.</blockquote><div><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">this is a really great point worth underscoring. this=
is the 'key ingredient' for DCFMP, which is that there is no signi=
ng or other network system that is 'in the way' of normal bitcoin m=
ining, just an opt-in set of rules for sharing the bounties of your block i=
n exchange for future shares.</div></div></div>
</blockquote></div>
--00000000000038f58a05d5df41e7--
|
