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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
|
Return-Path: <bob@mcelrath.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3DCCCC0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 18:51:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2B3A840A06
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 18:51:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
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 gbY5kh2-k-vR
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 18:51:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
by smtp2.osuosl.org (Postfix) with ESMTPS id 90AD840562
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Dec 2021 18:51:44 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 1BFIpgus048234
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Wed, 15 Dec 2021 18:51:42 GMT
Received: (from mcelrath@localhost)
by mcelrath.org (8.14.4/8.14.4/Submit) id 1BFIpfHW048233;
Wed, 15 Dec 2021 18:51:41 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
bob@mcelrath.org using -f
Date: Wed, 15 Dec 2021 18:51:41 +0000
From: Bob McElrath <bob@mcelrath.org>
To: Billy Tetrud <billy.tetrud@gmail.com>
Message-ID: <20211215185140.GB35108@mcelrath.org>
References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
<20211214190524.GA30559@mcelrath.org>
<CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
<20211215001200.GA35108@mcelrath.org>
<CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 18:51:46 -0000
You basically described Braidpool:
https://github.com/pool2win/braidpool
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019371.html
We're working on this actively and will have some updates soon. Additional
contributors are most welcome.
To your points below:
1. Increased payout regularity does not lower the viable size of mining pools,
because smaller mining pools using this mechanism still have higher variance.
2. The on-chain footprint is *higher* due to the increased payout regularity.
For a talk a while back I computed that if you want to have a 1% annual variance
on your profits, you need a pool that is about 20% of the network. The only way
to get this is with smaller, faster blocks or "shares".
https://www.youtube.com/watch?v=91WKy7RYHD4
There is a discussion forum at:
https://matrix.to/#/#braidpool:matrix.org
and a mailing list:
https://sourceforge.net/p/braidpool/mailman/
All of the existing discussion has been happening privately unfortunately but
I'll try to start using Matrix. ;-)
We've been discussing alternatives for both fee-rate and hashrate derivatives
lately. I'm not opposed to using CTV for some of the things in braidpool, if it
makes sense. Payment pools and unilateral channel openings may be interesting in
this context.
P.S. if anyone wants me to write up a blurb of exactly *why* a construction
without shares cannot be used for hashrate derivatives I can do that, just ask.
It comes down to maximum likelihood estimators for the Poisson distribution...
Billy Tetrud [billy.tetrud@gmail.com] wrote:
> Looks like an interesting proposal, but it doesn't seem to quite match the
> goals you mentioned. As you do mention, this mining pool coordination doesn't
> get rid of the need for mining pools in the first place. So it doesn't satisfy
> item 1 on your goal list afaict.
>
> The primary benefits over what we have today that I can see are:
> 1. increased payout regularity, which lowers the viable size of mining pools,
> and
> 2. Lower on chain footprint through combining pay outs from multiple pools.
>
> Am I missing some?
>
> These are interesting benefits, but it would be nice if your post was clearer
> on that, since the goals list is not the same as the list of potential benefits
> of this kind of design.
>
> As far as enabling solo mining, what if this concept were used off chain? Have
> a public network of solo miners who publish "weak blocks" to that network, and
> the next 100 (or 1000 etc) nice miners pay you out as long as you're also being
> nice by following the protocol? All the nice optimizations you mentioned about
> eg combined taproot payouts would apply i think. The only goals this wouldn't
> satisfy are 3 and 5 since an extra network is needed, but to be fair, your
> proposal requires pools which all need their own extra network anyways.
>
> The missing piece here would be an ordering of weak blocks to make the window
> possible. Or at least a way to determine what blocks should definitely be part
> of a particular block's pay out. I could see this being done by a separate
> ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps
> track of which weak blocks have been submitted, potentially using the pow
> already in each block to secure it. Granted that piece is a bit half baked, but
> it seems quite solvable. Wdyt?
>
> One thing that jumped out at me as not safe is throwing block rewards into a
> channel and being able to spend them immediately. There's a reason block
> rewards aren't spendable for a while, and channels don't solve that problem, do
> they? Why not simply reduce the on chain wait time for spending block rewards
> at that point? Seems like the consequences would be the same.
>
> On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> You are hand waving. Attempting to redefine terms to justify your argument
> is
> intellectually dishonest. Bitcoin pools have *always* been about variance
> reduction. Your window function fundamentally CANNOT be used to hedge
> hashrate.
> Various suggestions below introduce dangerous new games that might be
> played by
> miners.
>
> The fact is that the half-baked design you posted is less than useless, and
> doesn't do anything that anyone wants.
>
> You are trying to justify CTV by making it be all things to all people.
> "When
> all you have is a hammer, every problem looks like a nail". Instead I
> humbly
> suggest that you pick ONE problem for which CTV is demonstrably the right
> and
> best solution, instead of snowing us with a ton of half-baked things that
> *could* be done, and often don't even require CTV, and some (like this one)
> fundamentally don't work. I do like some of your ideas, but if you had to
> pick
> just one "use case", which would it be?
>
> Jeremy [jlrubin@mit.edu] wrote:
> > Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/
> wiki/
> > Pooling_(resource_management). This is a Bitcoin Mining Pool, although it
> may
> > not be your favorite kind, which is fixated on specific properties of
> computing
> > contributions before finding a block. Pooling is just a general technique
> for
> > aggregating resources to accomplish something. If you have another name
> like
> > pooling that is in common use for this type of activity I would be more
> than
> > happy to adopt it.
> >
> > This sort of pool can hedge not only against fee rates but also against
> > increases in hashrate since your historical rate 'carries' into the
> future as a
> > function of the window. Further, windows and reward functions can be
> defined in
> > a myriad of ways that could, e.g., pay less to blocks found in more rapid
> > succession, contributing to the smoothing functionality.
> >
> > With respect to sub-block pooling, as described in the article, this sort
> of
> > design also helps with micro-pools being able to split resources
> > non-custodially in every block as a part of the higher order DCFMP. The
> point
> > is not, as noted, to enable solo mining an S9, but to decrease the size
> of the
> > minimum viable pool. It's also possible to add, without much validation
> or
> > data, some 'uncle block' type mechanism in an incentive compatible way
> (e.g.,
> > add 10 pow-heavy headers on the last block for cost 48 bytes header + 32
> bytes
> > payout key) such that there's an incentive to include the heaviest ones
> you've
> > seen, not just your own, that are worth further study and consideration
> > (particularly because it's non-consensus, only for opt-in participation
> in the
> > pool).
> >
> > With respect to space usage, it seems you wholly reject the viability of
> a
> > payment pool mechanism to cut-through chain space. Is this a critique
> that
> > holds for all Payment Pools, or just in the context of mining? Is there a
> > particular reason why you think it infeasible that "strongly online"
> > counterparties would be able to coordinate more efficiently? Is it
> preferable
> > for miners, the nexus of decentralization for Bitcoin, to prefer to use
> > custodial services for pooling (which may require KYC/AM) over bearing a
> cost
> > of some extra potential chainload?
> >
> > Lastly, with respect to complexity, the proposal is actually incredibly
> simple
> > when you take it in a broader context. Non Interactive Channels and
> Payment
> > Pools are useful by themselves, so are the operations to merge them and
> swap
> > balance across them. Therefore most of the complexity in this proposal is
> > relying on tools we'll likely see in everyday use in any case, DCFMP or
> no.
> >
> > Jeremy
> >
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> !DSPAM:61ba2512470948607217095!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
|
