Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E0F11C0012 for ; Wed, 15 Dec 2021 18:39:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C761140562 for ; Wed, 15 Dec 2021 18:39:45 +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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1brH0WV74OAt for ; Wed, 15 Dec 2021 18:39:44 +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 B14F6402C3 for ; Wed, 15 Dec 2021 18:39:43 +0000 (UTC) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BFIde08022350 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 15 Dec 2021 13:39:41 -0500 Received: by mail-lj1-f169.google.com with SMTP id bn20so34715322ljb.8 for ; Wed, 15 Dec 2021 10:39:41 -0800 (PST) X-Gm-Message-State: AOAM531FOwRb1JIQ3feF+M75Q3ssSYAXUqbdskcq3rSnDVjnSSFRUpta ly+CMg05LT5bNFoSIR779NKS/56QH//ocWPWIYc= X-Google-Smtp-Source: ABdhPJxvL7B0/XIsWOn0ur8uv7BmFqPvaWZ6TqMDjjfBKtYKTMzIKihYi/zJc/8+aASTz4CLv2gCi5w9wG7bCTIeGQk= X-Received: by 2002:a2e:86cb:: with SMTP id n11mr11800116ljj.425.1639593580068; Wed, 15 Dec 2021 10:39:40 -0800 (PST) MIME-Version: 1.0 References: <20211214190524.GA30559@mcelrath.org> <20211215001200.GA35108@mcelrath.org> In-Reply-To: From: Jeremy Date: Wed, 15 Dec 2021 10:39:28 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ea839705d333a0aa" 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 18:39:46 -0000 --000000000000ea839705d333a0aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Billy! Thanks for your response. Some replies inline: On Wed, Dec 15, 2021 at 10:01 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Looks like an interesting proposal, but it doesn't seem to quite match th= e > goals you mentioned. As you do mention, this mining pool coordination > doesn't get rid of the need for mining pools in the first place. So it > doesn't satisfy item 1 on your goal list afaict. > It does, actually :) Point 1 was 1. Funds should not be centrally custodied, ever, if at all And for top-level pool participants there is never any central custody. What the windows are there (100 blocks, 2016, 4032, etc) is up to the specific implementation which sets limits on how small you can be to participate. Further, for the entities that are too small: from the article: *> **The blocks that they mine should use a taproot address/key which is a multisig of some portion of the workshares, that gets included in the top-level pool as a part of Payment Pool.* The micro-pools embed a multisig of top-contributors, 'reputable' members, or on a rotating basis, as a leaf node to the parent. They then opt-out of having their leaf channel-ized, as noted. This would be fully non-custodial if we always included all miners. The issue is that opens up DoS if one miner goes away, so you do want to anchor around a few. In this mode, you can set the protocol up such that immediately after getting a reward in a block, you should see the chosen nodes for multi-sigs distribute the spoils according to the schedule that is agreed on in the block causing the share to be granted. the main issue is data availability, without extra in-band storage local mining pools have to track the work shares (which can be committed to in a block) locally for auditing. This is not fully non-custodial, but it doesn't have to be centrally custodied by one party. We can multisig immediately after every block (and nodes should quit their pool if they don't get sigs quickly perhaps). Further, nodes can hash into multiple pools dividing their risk (modulo sybil attack) across many pools. If we had stronger covenants (CAT, AMOUNT, DIVIDE/MUL), we could make every leaf node commit to payment pools that operate on percents instead of fixed amounts and we'd be able to handle this in a manner that the payment pools work no matter what amount is assigned to them. The primary benefits over what we have today that I can see are: > 1. increased payout regularity, which lowers the viable size of mining > pools, and > 2. Lower on chain footprint through combining pay outs from multiple pool= s. > > Am I missing some? > > These are interesting benefits, but it would be nice if your post was > clearer on that, since the goals list is not the same as the list of > potential benefits of this kind of design. > I think I hit all the benefits mentioned: 1. Funds should not be centrally custodied, ever, if at all. see above -- we can do better for smaller miners, but we hit this for miners above the threshold. 2. No KYC/AML. see above, payouts are done 'decentralized' by every miner mining to the payout 3. No =E2=80=9CExtra network=E2=80=9D software required. you need the WASM, but do not need any networked software to participate, so there are no DoS concerns from participating. You do need extra software to e.g. use channels or cut-through multiple pools, but only after the fact of minding. 4. No blockchain bloat. Very little, if cut-through + LN works. 5. No extra infrastructure. Not much needed, if anything. I don't really know what 'infrastructure' means, but I kind of imagined it to mean 'big expensive things' that would make it hard to partake. 6. The size of a viable pool should be smaller. Remember our singer =E2=80= =93 if you just pool with one other songwriter it doesn=E2=80=99t make your expect= ed time till payout in your lifetime. So bigger the pools, more regular the payouts. We want the smallest possible =E2=80=9Cunits of control=E2=80=9D w= ith the most regular payouts possible. I think this works, roughly? > As far as enabling solo mining, what if this concept were used off chain? > Have a public network of solo miners who publish "weak blocks" to that > network, and the next 100 (or 1000 etc) nice miners pay you out as long a= s > you're also being nice by following the protocol? All the nice > optimizations you mentioned about eg combined taproot payouts would apply= i > think. The only goals this wouldn't satisfy are 3 and 5 since an extra > network is needed, but to be fair, your proposal requires pools which all > need their own extra network anyways. > > The missing piece here would be an ordering of weak blocks to make the > window possible. Or at least a way to determine what blocks should > definitely be part of a particular block's pay out. I could see this bein= g > done by a separate ephemeral blockchain (which starts fresh after each > Bitcoin block) that keeps track of which weak blocks have been submitted, > potentially using the pow already in each block to secure it. Granted tha= t > piece is a bit half baked, but it seems quite solvable. Wdyt? > > Yeah, it's worth thinking more about 100%. This post wasn't a deployable thing, more an exposition of a technique. I'd love to see a weak-block based pool, the main issue as noted is the extra software component + data availability, but perhaps that's solvable! > One thing that jumped out at me as not safe is throwing block rewards int= o > a channel and being able to spend them immediately. There's a reason bloc= k > rewards aren't spendable for a while, and channels don't solve that > problem, do they? Why not simply reduce the on chain wait time for spendi= ng > block rewards at that point? Seems like the consequences would be the sam= e. > Miners could already do this if they mine to e.g. a multisig (trustlessly if they form blocks with their counterparty and pre-sign before hashing). Also in lightning we don't generally have to check that our routes channels exist, we don't care as long as they are happy. Thus it doesn't "hurt" anyone except for the miners who are taking the not fully locked in funds risk, a risk they already take. But that risk can't infect the rest of Bitcoin's users. --000000000000ea839705d333a0aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Billy= !

Thanks for your response. Some replies inline:


<= div class=3D"gmail_quote">
On Wed, Dec= 15, 2021 at 10:01 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:

=
It does, actually :) Point 1 was= =C2=A0
  1. Funds should not be centrally cu= stodied, ever, if at all
    2. And for top-level pool participants there is never any central custody. W= hat the windows are there (100 blocks, 2016, 4032, etc) is up to the specif= ic implementation which sets limits on how small you can be to participate.=

    Further, for the en= tities that are too small:

from the article:
> The blocks that they mine= should use a taproot address/key which is a multisig of some portion of th= e workshares, that gets included in the top-level pool as a part of Payment= Pool.

The micro-pools emb= ed a=C2=A0multisig of top-contributors, 'reputable' members, = or on a rotating basis,=C2=A0as a leaf node to the parent. They then= opt-out of having their leaf channel-ized, as noted.
=
This would be fully non-= custodial if we always included all miners.=C2=A0The issue is that opens up DoS if one miner goes away= , so you do want to anchor around a few.



see above -- we can do better for smaller miners, bu= t we hit this for miners above the threshold.

2. No KYC/AML.
see above, payouts are done 'decentrali= zed' by every miner mining to the payout

3.=C2=A0No =E2=80=9CExtra network=E2=80=9D software = required.
you need the WASM, but do not need any networked software to participate= , so there are no DoS concerns from participating.

You do need = extra software to e.g. use channels or cut-through multiple pools, but only= after the fact of minding.

4. No blockchain bloat.

Very little, if cut-through=C2=A0+ LN works.


5. <= /span>No extra infrastructure.

Not much neede= d, if anything. I don't really know what 'infrastructure' means= , but I kind of imagined it to mean 'big expensive things' that wou= ld make it hard to partake.


<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0)">6. The size of a viable pool sho= uld be smaller. Remember our singer =E2=80=93 if you just pool with one oth= er songwriter it doesn=E2=80=99t make your expected time till payout in you= r lifetime. So bigger the pools, more regular the payouts. We want the smal= lest possible =E2=80=9Cunits of control=E2=80=9D with the most regular payo= uts possible.

I think this works, roughly?


As far as enabling solo mining, what if this= concept were used off chain? Have a public network of solo miners who publ= ish "weak blocks" to that network, and the next 100 (or 1000 etc)= nice miners pay you out as long as you're also being nice by following= the protocol? All the nice optimizations you mentioned about eg combined t= aproot payouts would apply i think. The only goals this wouldn't satisf= y are 3 and 5 since an extra network is needed, but to be fair, your propos= al requires pools which all need their own extra network anyways.=C2=A0

The missing piece here woul= d be an ordering of weak blocks to make the window possible. Or at least a = way to determine what blocks should definitely be part of a particular bloc= k's pay out. I could see this being done by a separate ephemeral blockc= hain (which starts fresh after each Bitcoin block) that keeps track of whic= h weak blocks have been submitted, potentially using the pow already in eac= h block to secure it. Granted that piece is a bit half baked, but it seems = quite solvable. Wdyt?

<= div>
One thin= g that jumped out at me as not safe is throwing block rewards into a channe= l and being able to spend them immediately. There's a reason block rewa= rds aren't spendable for a while, and channels don't solve that pro= blem, do they? Why not simply reduce the on chain wait time for spending bl= ock rewards at that point? Seems like the consequences would be the same.

M= iners could already do this if they mine to e.g. a multisig (trustlessly if= they form blocks with their counterparty and pre-sign before hashing). Als= o in lightning we don't generally have to check that our routes channel= s exist, we don't care as long as they are happy. Thus it doesn't &= quot;hurt" anyone except for the miners who are taking the not fully l= ocked in funds risk, a risk they already take. But that risk can't infe= ct the rest of Bitcoin's users.


--000000000000ea839705d333a0aa--