path: root/54/fa3bd0957854d37f14c268799e33aa05e64d9e

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C350EC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 14:11:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A212C6F2D6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 14:11:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
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 N1GQEPQLu8A2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 14:10:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl
 [213.180.149.143])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B70B96059F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Dec 2021 14:10:58 +0000 (UTC)
Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4JCNhV04dSz1yBc;
 Mon, 13 Dec 2021 15:10:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1639404650; bh=44ITudYWHoqyD3f7Ebdd6DITTLBmw2C9vc2FFs/Fa+8=;
 h=From:Cc:To:Date:Subject:From;
 b=Uoaf0N/A3/GshrcaTqMSHOsRxaVHbcvvyRWS6Vz74W/6d3W5rqGBYm8ldmkQ0carv
 IY1Q4lyKBtj2GXLUTb1KOMj4RMTirztFWBZxB/mGEx29l3KWbNOcub7FM6+JsCDG2g
 75bqb1WdFWjab6MXaR0703ThThuQs/VQPcP+J01A=
Content-Type: multipart/alternative;
 boundary="===============4857360730779384453=="
MIME-Version: 1.0
Received: from [82.177.167.2] by pmq4v.m5r2.onet via HTTP id ;
 Mon, 13 Dec 2021 15:10:49 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Jeremy <jlrubin@mit.edu>
Date: Mon, 13 Dec 2021 15:10:49 +0100
Message-Id: <150216403-2fc1a5b1e9f48639bccf4fa9a5ebd62e@pmq4v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;2
X-Mailman-Approved-At: Mon, 13 Dec 2021 14:23:05 +0000
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 14:11:00 -0000

This is a multi-part message in MIME format.
--===============4857360730779384453==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> Can you maybe try stating the goals of your payout function, and then dem=
onstrate how what you're proposing meets that?
=C2=A0
The goals are quite simple: if you are a solo miner, you are trying to mine=
 a block that meets the network difficulty. If you are using some kind of p=
ool, then you are trying to mine N times easier blocks and receive N times =
lower reward for doing that. If many miners work on similar transactions, t=
hen each miner can validate each transaction once and assign transaction fe=
e to transaction id, in this way the coinbase reward can be quickly checked=
, because you have to check only those transactions, which were unknown to =
you and for example included only by this miner and not broadcasted. Assumi=
ng that most of the transactions will be the same and included by most of t=
he miners, that verification would be quick and can be simplified only to c=
hecking "what is different from what I am mining".
Also, to determine the proper amount of shares received, you can assign a d=
ifficulty for each miner. So, if you are connected to eight mining nodes, y=
ou can assign a difficulty to each of them, just to limit how much work for=
 each share they can produce to have it accepted and included for payments.=
 It is needed to avoid spamming by producing a lot of shares at difficulty =
one by bigger miners, they should find it more profitable to create bigger =
shares, because by accumulating them, it is cheaper to receive one bigger p=
ayment than a lot of smaller payments.
On 2021-12-13 14:59:58 user Jeremy <jlrubin@mit.edu> wrote:
Hey there!
=C2=A0
Thanks for your response!
=C2=A0
One of the reasons to pick a longer window of, say, a couple difficulty per=
iods would be that you can make participation in the pool hedge you against=
 hashrate changes.
=C2=A0
You're absolutely spot on to think about the impact of pooling w.r.t. varia=
nce when fees > subsidy. That's not really in the analysis I had in the (ol=
d) post, but when the block revenues swing, dcfmp over longer periods can r=
eally smooth out the revenues for miners in a great way. This=C2=A0can also=
 help with the "mind the gap" problem when there isn't a backlog of transac=
tions, since producing an empty block still has some value (in order to inc=
entivize mining transaction at all and not cheating, we need to reward txn =
inclusion as I think you're trying to point out.
=C2=A0
Sadly, I've read the rest of your email a couple times and I don't really g=
et what you're proposing at all. It jumps right into "things you could comp=
ute". 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 mor=
e to miners that do x?
=C2=A0
=C2=A0
=C2=A0
=C2=A0
--===============4857360730779384453==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt; Can you maybe try stating the goals of your payout function, and =
then demonstrate how what you're proposing meets that?</div>
<div>&nbsp;</div>
<div><br />The goals are quite simple: if you are a solo miner, you are try=
ing to mine a block that meets the network difficulty. If you are using som=
e kind of pool, then you are trying to mine N times easier blocks and recei=
ve N times lower reward for doing that. If many miners work on similar tran=
sactions, then each miner can validate each transaction once and assign tra=
nsaction fee to transaction id, in this way the coinbase reward can be quic=
kly checked, because you have to check only those transactions, which were =
unknown to you and for example included only by this miner and not broadcas=
ted. Assuming that most of the transactions will be the same and included b=
y most of the miners, that verification would be quick and can be simplifie=
d only to checking "what is different from what I am mining".<br /><br /><b=
r />Also, to determine the proper amount of shares received, you can assign=
 a difficulty for each miner. So, if you are connected to eight mining node=
s, you can assign a difficulty to each of them, just to limit how much work=
 for each share they can produce to have it accepted and included for payme=
nts. It is needed to avoid spamming by producing a lot of shares at difficu=
lty one by bigger miners, they should find it more profitable to create big=
ger shares, because by accumulating them, it is cheaper to receive one bigg=
er payment than a lot of smaller payments.<br /><br /></div>
<div>On 2021-12-13 14:59:58 user Jeremy &lt;jlrubin@mit.edu&gt; wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Hey there!</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Thanks for your response!</div>
</div>
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">&nbsp;</div>
<div class=3D"gmail_attr"><span style=3D"color: #000000; font-family: arial=
,helvetica,sans-serif;"><span class=3D"gmail_default" style=3D"font-family:=
 arial,helvetica,sans-serif; font-size: small; color: #000000;">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 c=
hanges.</span></span></div>
<div class=3D"gmail_attr"><span class=3D"gmail_default" style=3D"color: #00=
0000; font-family: arial,helvetica,sans-serif;">&nbsp;</span></div>
<div class=3D"gmail_attr"><span class=3D"gmail_default" style=3D"color: #00=
0000; font-family: arial,helvetica,sans-serif;">You're absolutely spot on t=
o think about the impact of pooling w.r.t. variance when fees &gt; subsidy.=
 That's not really in the analysis I had in the (old) post, but when the bl=
ock revenues swing, dcfmp over longer periods can really smooth out the rev=
enues for miners in a great way. This&nbsp;</span><span style=3D"color: #00=
0000; font-family: arial,helvetica,sans-serif;"><span class=3D"gmail_defaul=
t" style=3D"font-family: arial,helvetica,sans-serif; font-size: small; colo=
r: #000000;">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 v=
alue (in order to incentivize mining transaction at all and not cheating, w=
e need to reward txn inclusion as I think you're trying to point out.</span=
></span></div>
<div class=3D"gmail_attr"><span style=3D"color: #000000; font-family: arial=
,helvetica,sans-serif;"><span class=3D"gmail_default" style=3D"font-family:=
 arial,helvetica,sans-serif; font-size: small; color: #000000;">&nbsp;</spa=
n></span></div>
<div class=3D"gmail_attr"><span style=3D"color: #000000; font-family: arial=
,helvetica,sans-serif;"><span class=3D"gmail_default" style=3D"font-family:=
 arial,helvetica,sans-serif; font-size: small; color: #000000;">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 y=
ou maybe try stating the goals of your payout function, and then demonstrat=
e how what you're proposing meets that? E.g., we want to pay more to miners=
 that do x?</span></span></div>
<div class=3D"gmail_attr"><span style=3D"color: #000000; font-family: arial=
,helvetica,sans-serif;"><span class=3D"gmail_default" style=3D"font-family:=
 arial,helvetica,sans-serif; font-size: small; color: #000000;">&nbsp;</spa=
n></span></div>
<div class=3D"gmail_attr">&nbsp;</div>
<div class=3D"gmail_attr" dir=3D"ltr">&nbsp;</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0.8ex; border-left-w=
idth: 1px; border-left-style: solid; border-left-color: #cccccc; border-rig=
ht-width: 1px; border-right-style: solid; border-right-color: #cccccc; padd=
ing-left: 1ex; padding-right: 1ex;">
<blockquote style=3D"margin-left: 7px; border-left-width: 2px; border-left-=
style: solid; border-left-color: orange; padding-left: 8px;">
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div dir=3D"ltr">&nbsp;</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
</div>
</div>
</blockquote>

--===============4857360730779384453==--