From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 92DF3C0012 for ; Tue, 14 Dec 2021 19:50:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8DF27405EA for ; Tue, 14 Dec 2021 19:50:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9jNYQTynNBS for ; Tue, 14 Dec 2021 19:50:48 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 660AB40114 for ; Tue, 14 Dec 2021 19:50:48 +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 1BEJojaX024017 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 14 Dec 2021 14:50:46 -0500 Received: by mail-lf1-f45.google.com with SMTP id m6so27132216lfu.1 for ; Tue, 14 Dec 2021 11:50:46 -0800 (PST) X-Gm-Message-State: AOAM5308+ohfBQV1xuHqDwOcbhjG3eNiq3pbnhndtJVpmQcS0afxGuDa b/MhaoHnLPDPZcZ1D233r3bjjy3is03GH5omIYU= X-Google-Smtp-Source: ABdhPJwmtp8ncY2Y9BSbcRTvVmNRHr5oTvWDe52G7949YY35K9irRwBHG+XgDO4BXwOhuok6uLYLa2NaTGvmqxxAV1M= X-Received: by 2002:a05:6512:1113:: with SMTP id l19mr6526504lfg.247.1639511445092; Tue, 14 Dec 2021 11:50:45 -0800 (PST) MIME-Version: 1.0 References: <20211214190524.GA30559@mcelrath.org> In-Reply-To: From: Jeremy Date: Tue, 14 Dec 2021 11:50:33 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bob McElrath , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004a434505d3208145" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 19:50:49 -0000 --0000000000004a434505d3208145 Content-Type: text/plain; charset="UTF-8" I've received some confused messages that whatever I was replying to didn't come through, I've reproduced Bob's e-mail below that I was responding to for context: *This, quite simply, is not a "pool". A pool is by definition a tool to reduceprofit variance by miners by collecting "weak blocks" that do not meet thedifficulty target, so as to get a better statistical measure of each miner'shashrate, which is used to subdivide profits. These are called "shares" and areentirely absent here.The only available information here to decide payouts is the blocks themselves,I do not have any higher statistics measurement to subdivide payments. If Iexpect to earn 3 blocks within the window, sometimes I will earn 2 and sometimesI will earn 4. Whether I keep the entire coinbase in those 2-4 blocks, or I have100 other miners paying me 1/100 as much 100 times, my payment is the same andmust be proportional to the number of blocks I mine in the window. My varianceis not reduced.Further, by making miners pay other miners within the window N, this results inN^2 payments to miners which otherwise would have had N coinbase payments. So,this is extremely block-space inefficient for no good reason. P2Pool had thesame problem and generated giant coinbases which competed with fee revenue."Congestion control" makes this somewhat worse since is it is an absoluteincrease in the block space consumed for these N^2 payments.The only thing this proposal does do is smooth out fee revenue. While hedging onfee revenue is valuable, this is an extremely complicated and expensive way togo about it, that simultaneously *reduces* fee revenue due to all the extrablock space used for miner payouts.* > --0000000000004a434505d3208145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've= received some confused messages that whatever I was replying to didn't= come through, I've reproduced Bob's e-mail below that I was respon= ding to for context:

This, quite simply, is not a "pool"= . A pool is by definition a tool to reduce
profit variance by miners by= collecting "weak blocks" that do not meet the
difficulty tar= get, so as to get a better statistical measure of each miner'shash= rate, which is used to subdivide profits. These are called "shares&quo= t; and are
entirely absent here.

The only available information here = to decide payouts is the blocks themselves,
I do not have any higher st= atistics measurement to subdivide payments. If I
expect to earn 3 block= s within the window, sometimes I will earn 2 and sometimes
I will earn= 4. Whether I keep the entire coinbase in those 2-4 blocks, or I have
<= span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">1= 00 other miners paying me 1/100 as much 100 times, my payment is the same a= nd
must be proportional to the number of blocks I mine in the window.= =C2=A0 My variance
is not reduced.

Further, by making miners pay othe= r miners within the window N, this results in
N^2 payments to miners wh= ich otherwise would have had N coinbase payments. So,
this is extremely= block-space inefficient for no good reason. P2Pool had the
same proble= m and generated giant coinbases which competed with fee revenue.
"= Congestion control" makes this somewhat worse since is it is an absolu= te
increase in the block space consumed for these N^2 payments.<= br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">The o= nly thing this proposal does do is smooth out fee revenue. While hedging on=
fee revenue is valuable, this is an extremely complicated and expensiv= e way to
go about it, that simultaneously *reduces* fee revenue due to = all the extra
block space used for miner payouts.
<= /div>
--0000000000004a434505d3208145--