Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 445E3C0012 for ; Wed, 15 Dec 2021 21:54:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3A8F780C53 for ; Wed, 15 Dec 2021 21:54:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5d1cWoZuU5s for ; Wed, 15 Dec 2021 21:54:05 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 00BA180C3B for ; Wed, 15 Dec 2021 21:54:04 +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 1BFLs2Kl024624 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 15 Dec 2021 16:54:03 -0500 Received: by mail-lf1-f45.google.com with SMTP id z7so45722771lfi.11 for ; Wed, 15 Dec 2021 13:54:03 -0800 (PST) X-Gm-Message-State: AOAM532HqtPrWrtac4rFyNAzGh3yi0x0VcWNX0QUoqDZiCqCSSaJPQba kkqNtG5vqsvkGPr4tFzFprIMCY7yGaEyiDBP2U8= X-Google-Smtp-Source: ABdhPJxNocUNMYMY9VghYHU4M31VwnsmqyQtof5iIgzmnE1anfK5FY14weilOwDvJV3oSJMTJpswBUrifIwGYNgiwF8= X-Received: by 2002:ac2:4353:: with SMTP id o19mr11258003lfl.670.1639605241653; Wed, 15 Dec 2021 13:54:01 -0800 (PST) MIME-Version: 1.0 References: <5b87372e0a6a825e2927656a7a5d9cc9@cock.li> In-Reply-To: <5b87372e0a6a825e2927656a7a5d9cc9@cock.li> From: Jeremy Date: Wed, 15 Dec 2021 13:53:50 -0800 X-Gmail-Original-Message-ID: Message-ID: To: yanmaani@cock.li Content-Type: multipart/alternative; boundary="00000000000000321505d33658df" Cc: Bitcoin Protocol Discussion 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: Wed, 15 Dec 2021 21:54:06 -0000 --00000000000000321505d33658df Content-Type: text/plain; charset="UTF-8" I could add a comparison to p2pool if you want, but bear in mind this is a blog post designed to introduce a complex topic to a wide audience, not a literature review of all possible designs and prior art. In particular, while P2Pool and DCFMP share a goal (decentralize mining), the approaches to them bear very little similarity as DCFMP is focused on making the pooling a pure client side validatable function of the existing chain, and not create a major risk to mining centralization with a reliance on a new network running on top of Bitcoin. DCFMP also lacks the core value prop of P2Pool which is higher resolution on share assignment. Further, DCFMP's core innovations are Payment Pool and non interactive channel based, something the P2Pool does not have, but could adopt, in theory, to solve their payout problems[^note]. I still believe that making a unified layer of networked software all miners are running on top of Bitcoin in the loop of mining is a major risk and architecturally bad idea, hence my advocacy for doing such designs as micro pools inside a DCFMP; It would be possible to make the "micropools" run on a P2Pool like software, the DCFMP allows for smaller P2Pools to aggregate their hashrate trustlessly with the main DCFMP shares. [^note]: for what it's worth, I was not familiar with p2pool very much before I came up with DCFMP. The lineage of my conceptual work was determinism, payment pools, and then realizing they could do something for mining. -- @JeremyRubin On Wed, Dec 15, 2021 at 1:11 PM wrote: > How does this differ from p2pool? > > If you've just re-invented p2pool, shouldn't you credit their prior art? > > Monero is doing their implementation of p2pool. They have viable solo > mining, as far as I understand. The basic idea is you have several > P2pools. If you have a block time of 10 minutes, p2pool has 20% of > hashrate, and there's 100 p2pool chains, each chain gets 0.2% of net > hash. If you're OK with 20s block times (orphans aren't really a big > problem), you need (20/600) * (0.02/100) = 0.00067% of network hash to > get a payout every 10m. > --00000000000000321505d33658df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I could add a comparison = to p2pool if you want, but bear in mind this is a blog post designed to int= roduce a complex topic to a wide audience, not a literature review of all p= ossible designs and prior art.

In particular, while P2Pool and DCFMP = share a goal (decentralize mining), the approaches to them bear very little= similarity as DCFMP is focused on making the pooling a pure client side va= lidatable function of the existing chain, and not create a major risk to mi= ning centralization with a reliance on a new network running on top of Bitc= oin. DCFMP also lacks the core value prop of P2Pool which is higher resolut= ion on share assignment.

Further, DCFMP's core innovations are Pa= yment Pool and non interactive channel based, something the P2Pool does not= have, but could adopt, in theory, to solve their payout problems[^note]. I= still believe=C2=A0that making a unified layer of networked software all m= iners are running on top of Bitcoin in the loop of mining is a major risk a= nd architecturally bad idea, hence my advocacy for doing such designs as mi= cro pools inside a DCFMP; It would be possible to make the "micropools= " run on a P2Pool like software, the DCFMP allows for smaller P2Pools = to aggregate their hashrate trustlessly with the main DCFMP=C2=A0shares.



[^note]: for what it's worth, I was not familiar with p2= pool very much before I came up with DCFMP. The lineage of my conceptual wo= rk was determinism, payment pools, and then realizing they could do somethi= ng for mining.


On Wed, Dec 15, 2021 at 1:11 PM &l= t;yanmaani@cock.li> wrote:
How does this differ from p2pool?
If you've just re-invented p2pool, shouldn't you credit their prior= art?

Monero is doing their implementation of p2pool. They have viable solo
mining, as far as I understand. The basic idea is you have several
P2pools. If you have a block time of 10 minutes, p2pool has 20% of
hashrate, and there's 100 p2pool chains, each chain gets 0.2% of net hash. If you're OK with 20s block times (orphans aren't really a bi= g
problem), you need (20/600) * (0.02/100) =3D 0.00067% of network hash to get a payout every 10m.
--00000000000000321505d33658df--