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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 445E3C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 21:54:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3A8F780C53
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 21:54:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 v5d1cWoZuU5s
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 21:54:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.osuosl.org (Postfix) with ESMTPS id 00BA180C3B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 21:54:04 +0000 (UTC)
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com
[209.85.167.45]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BFLs2Kl024624
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Dec 2021 16:54:03 -0500
Received: by mail-lf1-f45.google.com with SMTP id z7so45722771lfi.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 13:54:03 -0800 (PST)
X-Gm-Message-State: AOAM532HqtPrWrtac4rFyNAzGh3yi0x0VcWNX0QUoqDZiCqCSSaJPQba
kkqNtG5vqsvkGPr4tFzFprIMCY7yGaEyiDBP2U8=
X-Google-Smtp-Source: ABdhPJxNocUNMYMY9VghYHU4M31VwnsmqyQtof5iIgzmnE1anfK5FY14weilOwDvJV3oSJMTJpswBUrifIwGYNgiwF8=
X-Received: by 2002:ac2:4353:: with SMTP id o19mr11258003lfl.670.1639605241653;
Wed, 15 Dec 2021 13:54:01 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
<5b87372e0a6a825e2927656a7a5d9cc9@cock.li>
In-Reply-To: <5b87372e0a6a825e2927656a7a5d9cc9@cock.li>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 15 Dec 2021 13:53:50 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhSVL9XvzrvdJAs1aPYyn8Qq0EZh+3KVhSo10Q+n9GG+w@mail.gmail.com>
Message-ID: <CAD5xwhhSVL9XvzrvdJAs1aPYyn8Qq0EZh+3KVhSo10Q+n9GG+w@mail.gmail.com>
To: yanmaani@cock.li
Content-Type: multipart/alternative; boundary="00000000000000321505d33658df"
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: Wed, 15 Dec 2021 21:54:06 -0000
--00000000000000321505d33658df
Content-Type: text/plain; charset="UTF-8"
I could add a comparison to p2pool if you want, but bear in mind this is a
blog post designed to introduce a complex topic to a wide audience, not a
literature review of all possible designs and prior art.
In particular, while P2Pool and DCFMP share a goal (decentralize mining),
the approaches to them bear very little similarity as DCFMP is focused on
making the pooling a pure client side validatable function of the existing
chain, and not create a major risk to mining centralization with a reliance
on a new network running on top of Bitcoin. DCFMP also lacks the core value
prop of P2Pool which is higher resolution on share assignment.
Further, DCFMP's core innovations are Payment Pool and non interactive
channel based, something the P2Pool does not have, but could adopt, in
theory, to solve their payout problems[^note]. I still believe that making
a unified layer of networked software all miners are running on top of
Bitcoin in the loop of mining is a major risk and architecturally bad idea,
hence my advocacy for doing such designs as micro pools inside a DCFMP; It
would be possible to make the "micropools" run on a P2Pool like software,
the DCFMP allows for smaller P2Pools to aggregate their hashrate
trustlessly with the main DCFMP shares.
[^note]: for what it's worth, I was not familiar with p2pool very much
before I came up with DCFMP. The lineage of my conceptual work was
determinism, payment pools, and then realizing they could do something for
mining.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Wed, Dec 15, 2021 at 1:11 PM <yanmaani@cock.li> wrote:
> How does this differ from p2pool?
>
> If you've just re-invented p2pool, shouldn't you credit their prior art?
>
> Monero is doing their implementation of p2pool. They have viable solo
> mining, as far as I understand. The basic idea is you have several
> P2pools. If you have a block time of 10 minutes, p2pool has 20% of
> hashrate, and there's 100 p2pool chains, each chain gets 0.2% of net
> hash. If you're OK with 20s block times (orphans aren't really a big
> problem), you need (20/600) * (0.02/100) = 0.00067% of network hash to
> get a payout every 10m.
>
--00000000000000321505d33658df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">I could add a comparison =
to p2pool if you want, but bear in mind this is a blog post designed to int=
roduce a complex topic to a wide audience, not a literature review of all p=
ossible designs and prior art.</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">In particular, while P2Pool and DCFMP =
share a goal (decentralize mining), the approaches to them bear very little=
similarity as DCFMP is focused on making the pooling a pure client side va=
lidatable function of the existing chain, and not create a major risk to mi=
ning centralization with a reliance on a new network running on top of Bitc=
oin. DCFMP also lacks the core value prop of P2Pool which is higher resolut=
ion on share assignment.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">Further, DCFMP's core innovations are Pa=
yment Pool and non interactive channel based, something the P2Pool does not=
have, but could adopt, in theory, to solve their payout problems[^note]. I=
still believe=C2=A0that making a unified layer of networked software all m=
iners are running on top of Bitcoin in the loop of mining is a major risk a=
nd architecturally bad idea, hence my advocacy for doing such designs as mi=
cro pools inside a DCFMP; It would be possible to make the "micropools=
" run on a P2Pool like software, the DCFMP allows for smaller P2Pools =
to aggregate their hashrate trustlessly with the main DCFMP=C2=A0shares.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">[^note]: for what it's worth, I was not familiar with p2=
pool very much before I came up with DCFMP. The lineage of my conceptual wo=
rk was determinism, payment pools, and then realizing they could do somethi=
ng for mining.</div><div><div dir=3D"ltr" data-smartmail=3D"gmail_signature=
"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=
=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" tar=
get=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 15, 2021 at 1:11 PM &l=
t;<a href=3D"mailto:yanmaani@cock.li" target=3D"_blank">yanmaani@cock.li</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex">How does this differ from p2pool?<br=
>
<br>
If you've just re-invented p2pool, shouldn't you credit their prior=
art?<br>
<br>
Monero is doing their implementation of p2pool. They have viable solo <br>
mining, as far as I understand. The basic idea is you have several <br>
P2pools. If you have a block time of 10 minutes, p2pool has 20% of <br>
hashrate, and there's 100 p2pool chains, each chain gets 0.2% of net <b=
r>
hash. If you're OK with 20s block times (orphans aren't really a bi=
g <br>
problem), you need (20/600) * (0.02/100) =3D 0.00067% of network hash to <b=
r>
get a payout every 10m.<br>
</blockquote></div>
--00000000000000321505d33658df--
|