From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3F87C0012 for ; Tue, 14 Dec 2021 23:44:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id BF06B40597 for ; Tue, 14 Dec 2021 23:44:58 +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 RvcGDNWX1VCo for ; Tue, 14 Dec 2021 23:44:57 +0000 (UTC) X-Greylist: delayed 00:11:50 by SQLgrey-1.8.0 Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) by smtp2.osuosl.org (Postfix) with ESMTPS id 99C9540179 for ; Tue, 14 Dec 2021 23:44:57 +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 1BENX54q034735 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 14 Dec 2021 23:33:05 GMT Received: (from mcelrath@localhost) by mcelrath.org (8.14.4/8.14.4/Submit) id 1BENX55Z034734 for bitcoin-dev@lists.linuxfoundation.org; Tue, 14 Dec 2021 23:33:05 GMT X-Authentication-Warning: mcelrath.org: mcelrath set sender to bob@mcelrath.org using -f Date: Tue, 14 Dec 2021 23:33:05 +0000 From: Bob McElrath To: Bitcoin Protocol Discussion Message-ID: <20211214233305.GB30559@mcelrath.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 23:44:58 -0000 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 target, so as to get a better statistical measure of each miner's hashrate, which is used to subdivide profits. These are called "shares" and are entirely 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 I expect to earn 3 blocks 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 100 other miners paying me 1/100 as much 100 times, my payment is the same and must be proportional to the number of blocks I mine in the window. My variance is not reduced. Further, by making miners pay other miners within the window N, this results in N^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 the same problem and generated giant coinbases which competed with fee revenue. "Congestion control" makes this somewhat worse since is it is an absolute increase in the block space consumed for these N^2 payments. The only thing this proposal does do is smooth out fee revenue. While hedging on fee revenue is valuable, this is an extremely complicated and expensive way to go about it, that simultaneously *reduces* fee revenue due to all the extra block space used for miner payouts. Jeremy via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > Howdy, welcome to day 15! > > Today's post covers a form of a mining pool that can be operated as sort of a > map-reduce over blocks without any "infrastructure". > > https://rubin.io/bitcoin/2021/12/12/advent-15/ > > There's still some really open-ended questions (perhaps for y'all to consider) > around how to select an analyze the choice of window and payout functions, but > something like this could alleviate a lot of the centralization pressures > typically faced by pools. > > Notably, compared to previous attempts, combining the payment pool payout with > this concept means that there is practically very little on-chain overhead from > this approach as the chain-load > for including payouts in every block is deferred for future cooperation among > miners. Although that can be considered cooperation itself, if you think of it > like a pipeline, the cooperation happens out of band from mining and block > production so it really is coordination free to mine. > > > Cheers, > > Jeremy > > -- > @JeremyRubin > !DSPAM:61b626be345321821816715! > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > !DSPAM:61b626be345321821816715! -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken