summaryrefslogtreecommitdiff
path: root/53/b3d4725646ba768de6ddacf661356386654448
blob: 67368d0086d053729798fc31ddb9fd0f1eca8251 (plain)
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
Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DACA2C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Dec 2021 19:39:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B565F408C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Dec 2021 19:39:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id e0sJHvMF7pnD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Dec 2021 19:39:21 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 80FA3408C1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Dec 2021 19:39:21 +0000 (UTC)
Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com
 [209.85.208.169]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BEJdI6R015564
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 14 Dec 2021 14:39:19 -0500
Received: by mail-lj1-f169.google.com with SMTP id a37so28833293ljq.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Dec 2021 11:39:19 -0800 (PST)
X-Gm-Message-State: AOAM5309S29LGrOhWD2vsKch5mLvjqlQKOF4Hq9gHMxEErd0Ac756oJi
 gAf5Rdvfy6lxZiazHXPdD4Wec9/VxUEbojMhNh0=
X-Google-Smtp-Source: ABdhPJxZi6iRA8YggsfltvmqM/TqKFHa9gc4NY2GYH9H4roLlElh8bkHKySSwmVyqxWoItEatBkCWFoTuDm69jYRT2I=
X-Received: by 2002:a05:651c:1696:: with SMTP id
 bd22mr6655917ljb.57.1639510757980; 
 Tue, 14 Dec 2021 11:39:17 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
 <20211214190524.GA30559@mcelrath.org>
In-Reply-To: <20211214190524.GA30559@mcelrath.org>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 14 Dec 2021 11:39:06 -0800
X-Gmail-Original-Message-ID: <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
Message-ID: <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
To: Bob McElrath <bob_bitcoin@mcelrath.org>
Content-Type: multipart/alternative; boundary="00000000000055c2d905d32058c0"
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, 14 Dec 2021 19:39:23 -0000

--00000000000055c2d905d32058c0
Content-Type: text/plain; charset="UTF-8"

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

--00000000000055c2d905d32058c0
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:rgb(0,0,0)">Bitcoin didn&#39;t inv=
ent the concept of pooling: <a href=3D"https://en.wikipedia.org/wiki/Poolin=
g_(resource_management)">https://en.wikipedia.org/wiki/Pooling_(resource_ma=
nagement)</a>. This is a Bitcoin Mining Pool, although it may not be your f=
avorite kind, which is fixated on specific properties of computing contribu=
tions before finding a block. Pooling is just a general technique for aggre=
gating resources to accomplish something. If you have another name like poo=
ling that is in common use for this type of activity I would be more than h=
appy to adopt it.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">This sort of pool can hedge not only against =
fee rates but also against increases in hashrate since your historical rate=
 &#39;carries&#39; into the future as a function of the window. Further, wi=
ndows 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.</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">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 t=
he 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&#39;s also pos=
sible to add, without much validation or data, some &#39;uncle block&#39; t=
ype mechanism in an incentive compatible way (e.g., add 10 pow-heavy header=
s on the last block for cost 48 bytes header + 32 bytes payout key) such th=
at there&#39;s an incentive to include the heaviest ones you&#39;ve seen, n=
ot just your own, that are worth further study and consideration (particula=
rly because it&#39;s non-consensus, only for opt-in participation in the po=
ol).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">With respect to space usage, it seems you wholly reject th=
e 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 min=
ing? Is there a particular reason why you think it infeasible that &quot;st=
rongly online&quot; counterparties would be able to coordinate more efficie=
ntly? Is it preferable for miners, the nexus of decentralization for Bitcoi=
n, to prefer to use custodial services for pooling (which may require KYC/A=
M) over bearing a cost of some extra potential chainload?</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Las=
tly, with respect to complexity, the proposal is actually incredibly simple=
 when you take it in a broader context. Non Interactive Channels and Paymen=
t Pools are useful=C2=A0by themselves, so are the operations to merge them =
and swap balance across them. Therefore most of the complexity in this prop=
osal is relying on tools we&#39;ll likely see in everyday use in any case, =
DCFMP or no.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">Jeremy</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><=
/div></div>

--00000000000055c2d905d32058c0--