summaryrefslogtreecommitdiff
path: root/b8/1809a8bdfeda40b859852089ea63a78eef9f6b
blob: a22dafa1a665b9c1ede0d71270c87a62e5dd5b05 (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
Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 26EA6C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 01:31:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1539660EE1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 01:31:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wT_VdiViRVI0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 01:31:56 +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 smtp3.osuosl.org (Postfix) with ESMTPS id B301360E36
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 01:31:56 +0000 (UTC)
Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com
 [209.85.167.48]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BD1VrW3018019
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 12 Dec 2021 20:31:54 -0500
Received: by mail-lf1-f48.google.com with SMTP id z7so28032183lfi.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Dec 2021 17:31:54 -0800 (PST)
X-Gm-Message-State: AOAM533zfZ5mAT2aN5/k2Am1h5y7LWSV0uAKnzzo2LqcDSoeTBVnc3Eg
 thDMm3b9SQbEayaUk0HVVLH5nI0MYwJs6FQHzo8=
X-Google-Smtp-Source: ABdhPJzHxUn5tzpE5gfLCXEEVxiw4XEJ1IWZZByPgvvpAW9GyhpIxnwGbSI9sEx4kgFc064/798SQIktudvAqLBuuRk=
X-Received: by 2002:a19:f242:: with SMTP id d2mr26059351lfk.516.1639359113257; 
 Sun, 12 Dec 2021 17:31:53 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
 <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet>
In-Reply-To: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 12 Dec 2021 17:31:42 -0800
X-Gmail-Original-Message-ID: <CAD5xwhgPFxm9_K_z4gomDa9AV1FAdhCq+-YYnreJAS+jcW+4Sw@mail.gmail.com>
Message-ID: <CAD5xwhgPFxm9_K_z4gomDa9AV1FAdhCq+-YYnreJAS+jcW+4Sw@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="0000000000009ae87905d2fd093a"
Cc: Bitcoin development mailing list <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: Mon, 13 Dec 2021 01:31:58 -0000

--0000000000009ae87905d2fd093a
Content-Type: text/plain; charset="UTF-8"

Hey there!

Thanks for your response!

One of the reasons to pick a longer window of, say, a couple difficulty
periods would be that you can make participation in the pool hedge you
against hashrate changes.

You're absolutely spot on to think about the impact of pooling w.r.t.
variance when fees > subsidy. That's not really in the analysis I had in
the (old) post, but when the block revenues swing, dcfmp over longer
periods can really smooth out the revenues for miners in a great way. This can
also help with the "mind the gap" problem when there isn't a backlog of
transactions, since producing an empty block still has some value (in order
to incentivize mining transaction at all and not cheating, we need to
reward txn inclusion as I think you're trying to point out.

Sadly, I've read the rest of your email a couple times and I don't really
get what you're proposing at all. It jumps right into "things you could
compute". Can you maybe try stating the goals of your payout function, and
then demonstrate how what you're proposing meets that? E.g., we want to pay
more to miners that do x?

--0000000000009ae87905d2fd093a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hey t=
here!</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">Thanks for your response!</div></div><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr"><br></div><div class=3D"gmail_=
attr"><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-seri=
f"><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">One of the reasons to pick a longer=
 window of, say, a couple difficulty periods would be that you can make par=
ticipation in the pool hedge you against hashrate changes.</span></span></d=
iv><div class=3D"gmail_attr"><span class=3D"gmail_default" style=3D"color:r=
gb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div cla=
ss=3D"gmail_attr"><span class=3D"gmail_default" style=3D"color:rgb(0,0,0);f=
ont-family:arial,helvetica,sans-serif">You&#39;re absolutely spot on to thi=
nk about the impact of pooling w.r.t. variance when fees &gt; subsidy. That=
&#39;s not really in the analysis I had in the (old) post, but when the blo=
ck revenues swing, dcfmp over longer periods can really smooth out the reve=
nues for miners in a great way. This=C2=A0</span><span class=3D"gmail_defau=
lt" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></spa=
n><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><=
span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">can also help with the &quot;mind the g=
ap&quot; problem when there isn&#39;t a backlog of transactions, since prod=
ucing an empty block still has some value (in order to incentivize mining t=
ransaction at all and not cheating, we need to reward txn inclusion as I th=
ink you&#39;re trying to point out.</span></span></div><div class=3D"gmail_=
attr"><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-seri=
f"><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"><br></span></span></div><div class=
=3D"gmail_attr"><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica=
,sans-serif"><span class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">Sadly, I&#39;ve read the =
rest of your email a couple times and I don&#39;t really get what you&#39;r=
e proposing at all. It jumps right into &quot;things you could compute&quot=
;. Can you maybe try stating the goals of your payout function, and then de=
monstrate how what you&#39;re proposing meets that? E.g., we want to pay mo=
re to miners that do x?</span></span></div><div class=3D"gmail_attr"><span =
style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><span cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></span></span></div><div class=3D"gmail_att=
r"><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">=
<span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"></span></span></div><div dir=3D"ltr" c=
lass=3D"gmail_attr"><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);border-right-width:1px;border-right-style:solid;border=
-right-color:rgb(204,204,204);padding-left:1ex;padding-right:1ex"><blockquo=
te style=3D"margin-left:7px;border-left-width:2px;border-left-style:solid;b=
order-left-color:orange;padding-left:8px"><div dir=3D"ltr"><div><div dir=3D=
"ltr"><div dir=3D"ltr"></div>
</div>
</div>
</div>
</blockquote>
</blockquote></div></div>

--0000000000009ae87905d2fd093a--