path: root/a8/cb37b7dc7266995be61a73587bb6a3d96a2df3

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F06B6C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Dec 2021 17:25:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id DF8DD41516
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Dec 2021 17:25:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5T9etoB2WO_R
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Dec 2021 17:25:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [IPv6:2607:f8b0:4864:20::632])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A30AE410DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Dec 2021 17:25:28 +0000 (UTC)
Received: by mail-pl1-x632.google.com with SMTP id u17so17032100plg.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Dec 2021 09:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=IBadulXxG82TwaAXtKbkp0mDhr2GlH5to/Xj6/hL8rU=;
 b=OYdHLC/2z2U4MJF8eKd3ljlWBGDngxu9QHJbUMZaJjLt8yOypV/EjHAO7H0D2Uy9ho
 qyUA2VWyCZ4ESN8R6aAO+Ljpqd177rNFsyeG8N3uSTLPdb8tc4rhlE5D5496fkzJiZCB
 W/ksPH52PrpzhL8xumeT09XXTx4CNC9grKdGnmWvIg8rGyIC1cdQi4ZvllZBAfmDSs8e
 QWlHGLL2Eb9jWrQTF/Vu24lS3qWN3uojnpfLGEcvyPcR4eTCcVJD2jr08tlpwwO9Ub7r
 PyM0RhmQAQBX6io527yLNRLDlbAcW1+JoU9M8pTOU/XEKtWIkZGgEl99RuyErIXSoCV7
 gHSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=IBadulXxG82TwaAXtKbkp0mDhr2GlH5to/Xj6/hL8rU=;
 b=vMDL2ZafhZzdIS8jW1s2K+mESfYk92Tv8RRdFGlvOx/JdUuUUrtWDoMOVTEM+Yckig
 0oyAKPuNgKFbNnaqVUd96odCT/PlEAivI61SU07TXbG4z3C7KSBKPRrFRz8OCEgVDQ+2
 sGoDKs2pOjZ0rnbIPpI66lR4xLne5b8RGBDq+38dzxfTojrZiL3puWkhzBZi3JYr3IeM
 AheQRgePQWf5frF7Li2+MgNlgjuqAHoLG9J5pbBDJBBIdxlD6rpkTdJqn0RjoU1Zj8IG
 UpkpsoNgouRgGBE2qrfC49GtFb6ngM1iF7O7HcAPjAeDLc21n8+I1ERyA7vONK+sKL1h
 R6Ug==
X-Gm-Message-State: AOAM531m07GVenzXRNmvNn8Eiyc1PCcJ931cmXwat+9k5X8MWB2oyD+i
 wBPScnUYmpbI85dESBC4nGsh+BLa4aulo3EbFF9kcHG8
X-Google-Smtp-Source: ABdhPJxTWmXX/v7fly3xZdSa8byXBS7ufQEtj5yWye3RFLy/FjmVV3WyUxWgW977b4TqwncHh2ILLRo4T8TB5QD1IZw=
X-Received: by 2002:a17:902:7b88:b0:148:91ab:be83 with SMTP id
 w8-20020a1709027b8800b0014891abbe83mr9769118pll.88.1639589127902; Wed, 15 Dec
 2021 09:25:27 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
 <20211214190524.GA30559@mcelrath.org>
 <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
 <20211215001200.GA35108@mcelrath.org>
In-Reply-To: <20211215001200.GA35108@mcelrath.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 15 Dec 2021 09:25:15 -0800
Message-ID: <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
To: Bob McElrath <bob@mcelrath.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008bda6905d33297b8"
X-Mailman-Approved-At: Wed, 15 Dec 2021 18:00:29 +0000
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: Wed, 15 Dec 2021 17:25:30 -0000

--0000000000008bda6905d33297b8
Content-Type: text/plain; charset="UTF-8"

Looks like an interesting proposal, but it doesn't seem to quite match the
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.

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 pools.

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.

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 as
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 being
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 that
piece is a bit half baked, but it seems quite solvable. Wdyt?

One thing that jumped out at me as not safe is throwing block rewards into
a channel and being able to spend them immediately. There's a reason block
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 spending
block rewards at that point? Seems like the consequences would be the same.

On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You are hand waving. Attempting to redefine terms to justify your argument
> is
> intellectually dishonest. Bitcoin pools have *always* been about variance
> reduction. Your window function fundamentally CANNOT be used to hedge
> hashrate.
> Various suggestions below introduce dangerous new games that might be
> played by
> miners.
>
> The fact is that the half-baked design you posted is less than useless, and
> doesn't do anything that anyone wants.
>
> You are trying to justify CTV by making it be all things to all people.
> "When
> all you have is a hammer, every problem looks like a nail".  Instead I
> humbly
> suggest that you pick ONE problem for which CTV is demonstrably the right
> and
> best solution, instead of snowing us with a ton of half-baked things that
> *could* be done, and often don't even require CTV, and some (like this one)
> fundamentally don't work. I do like some of your ideas, but if you had to
> pick
> just one "use case", which would it be?
>
> Jeremy [jlrubin@mit.edu] wrote:
> > Bitcoin didn't invent the concept of pooling:
> https://en.wikipedia.org/wiki/
> > Pooling_(resource_management). This is a Bitcoin Mining Pool, although
> it may
> > not be your favorite kind, which is fixated on specific properties of
> computing
> > contributions before finding a block. Pooling is just a general
> technique for
> > aggregating resources to accomplish something. If you have another name
> like
> > pooling that is in common use for this type of activity I would be more
> than
> > happy to adopt it.
> >
> > This sort of pool can hedge not only against fee rates but also against
> > increases in hashrate since your historical rate 'carries' into the
> future as a
> > function of the window. Further, windows and reward functions can be
> defined in
> > a myriad of ways that could, e.g., pay less to blocks found in more rapid
> > succession, contributing to the smoothing functionality.
> >
> > With respect to sub-block pooling, as described in the article, this
> sort of
> > design also helps with micro-pools being able to split resources
> > non-custodially in every block as a part of the higher order DCFMP. The
> point
> > is not, as noted, to enable solo mining an S9, but to decrease the size
> of the
> > minimum viable pool. It's also possible to add, without much validation
> or
> > data, some 'uncle block' type mechanism in an incentive compatible way
> (e.g.,
> > add 10 pow-heavy headers on the last block for cost 48 bytes header + 32
> bytes
> > payout key) such that there's an incentive to include the heaviest ones
> you've
> > seen, not just your own, that are worth further study and consideration
> > (particularly because it's non-consensus, only for opt-in participation
> in the
> > pool).
> >
> > With respect to space usage, it seems you wholly reject the viability of
> a
> > payment pool mechanism to cut-through chain space. Is this a critique
> that
> > holds for all Payment Pools, or just in the context of mining? Is there a
> > particular reason why you think it infeasible that "strongly online"
> > counterparties would be able to coordinate more efficiently? Is it
> preferable
> > for miners, the nexus of decentralization for Bitcoin, to prefer to use
> > custodial services for pooling (which may require KYC/AM) over bearing a
> cost
> > of some extra potential chainload?
> >
> > Lastly, with respect to complexity, the proposal is actually incredibly
> simple
> > when you take it in a broader context. Non Interactive Channels and
> Payment
> > Pools are useful by themselves, so are the operations to merge them and
> swap
> > balance across them. Therefore most of the complexity in this proposal is
> > relying on tools we'll likely see in everyday use in any case, DCFMP or
> no.
> >
> > Jeremy
> > !DSPAM:61b8f2f5321461582627336!
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
>     -- H. L. Mencken
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000008bda6905d33297b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Looks like an interesting proposal, but it doesn&#39;t se=
em to quite match the goals you mentioned. As you do mention, this mining p=
ool coordination doesn&#39;t get rid of the need for mining pools in the fi=
rst place. So it doesn&#39;t satisfy item 1 on your goal list afaict.=C2=A0=
<div dir=3D"auto"><br></div><div dir=3D"auto">The primary benefits over wha=
t we have today that I can see are:</div><div dir=3D"auto">1. increased pay=
out regularity, which lowers the viable size of mining pools, and</div><div=
 dir=3D"auto">2. Lower on chain footprint through combining pay outs from m=
ultiple pools.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Am I miss=
ing some?</div><div dir=3D"auto"><br></div><div dir=3D"auto">These are inte=
resting benefits, but it would be nice if your post was clearer on that, si=
nce the goals list is not the same as the list of potential benefits of thi=
s kind of design.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As far=
 as enabling solo mining, what if this concept were used off chain? Have a =
public network of solo miners who publish &quot;weak blocks&quot; to that n=
etwork, and the next 100 (or 1000 etc) nice miners pay you out as long as y=
ou&#39;re also being nice by following the protocol? All the nice optimizat=
ions you mentioned about eg combined taproot payouts would apply i think. T=
he only goals this wouldn&#39;t satisfy are 3 and 5 since an extra network =
is needed, but to be fair, your proposal requires pools which all need thei=
r own extra network anyways.=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">The missing piece here would be an ordering of weak blocks to ma=
ke the window possible. Or at least a way to determine what blocks should d=
efinitely be part of a particular block&#39;s pay out. I could see this bei=
ng done by a separate ephemeral blockchain (which starts fresh after each B=
itcoin block) that keeps track of which weak blocks have been submitted, po=
tentially using the pow already in each block to secure it. Granted that pi=
ece is a bit half baked, but it seems quite solvable. Wdyt?</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">One thing that jumped out at me as no=
t safe is throwing block rewards into a channel and being able to spend the=
m immediately. There&#39;s a reason block rewards aren&#39;t spendable for =
a while, and channels don&#39;t solve that problem, do they? Why not simply=
 reduce the on chain wait time for spending block rewards at that point? Se=
ems like the consequences would be the same.</div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 14, 2021, 16:=
12 Bob McElrath via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yo=
u are hand waving. Attempting to redefine terms to justify your argument is=
<br>
intellectually dishonest. Bitcoin pools have *always* been about variance<b=
r>
reduction. Your window function fundamentally CANNOT be used to hedge hashr=
ate.<br>
Various suggestions below introduce dangerous new games that might be playe=
d by<br>
miners.<br>
<br>
The fact is that the half-baked design you posted is less than useless, and=
<br>
doesn&#39;t do anything that anyone wants.<br>
<br>
You are trying to justify CTV by making it be all things to all people. &qu=
ot;When<br>
all you have is a hammer, every problem looks like a nail&quot;.=C2=A0 Inst=
ead I humbly<br>
suggest that you pick ONE problem for which CTV is demonstrably the right a=
nd<br>
best solution, instead of snowing us with a ton of half-baked things that<b=
r>
*could* be done, and often don&#39;t even require CTV, and some (like this =
one)<br>
fundamentally don&#39;t work. I do like some of your ideas, but if you had =
to pick<br>
just one &quot;use case&quot;, which would it be?<br>
<br>
Jeremy [<a href=3D"mailto:jlrubin@mit.edu" rel=3D"noreferrer noreferrer" ta=
rget=3D"_blank">jlrubin@mit.edu</a>] wrote:<br>
&gt; Bitcoin didn&#39;t invent the concept of pooling: <a href=3D"https://e=
n.wikipedia.org/wiki/" rel=3D"noreferrer noreferrer noreferrer" target=3D"_=
blank">https://en.wikipedia.org/wiki/</a><br>
&gt; Pooling_(resource_management). This is a Bitcoin Mining Pool, although=
 it may<br>
&gt; not be your favorite kind, which is fixated on specific properties of =
computing<br>
&gt; contributions before finding a block. Pooling is just a general techni=
que for<br>
&gt; aggregating resources to accomplish something. If you have another nam=
e like<br>
&gt; pooling that is in common use for this type of activity I would be mor=
e than<br>
&gt; happy to adopt it.<br>
&gt; <br>
&gt; This sort of pool can hedge not only against fee rates but also agains=
t<br>
&gt; increases in hashrate since your historical rate &#39;carries&#39; int=
o the future as a<br>
&gt; function of the window. Further, windows and reward functions can be d=
efined in<br>
&gt; a myriad of ways that could, e.g., pay less to blocks found in more ra=
pid<br>
&gt; succession, contributing to the smoothing functionality.<br>
&gt; <br>
&gt; With respect to sub-block pooling, as described in the article, this s=
ort of<br>
&gt; design also helps with micro-pools being able to split resources<br>
&gt; non-custodially in every block as a part of the higher order DCFMP. Th=
e point<br>
&gt; is not, as noted, to enable solo mining an S9, but to decrease the siz=
e of the<br>
&gt; minimum viable pool. It&#39;s also possible to add, without much valid=
ation or<br>
&gt; data, some &#39;uncle block&#39; type mechanism in an incentive compat=
ible way (e.g.,<br>
&gt; add 10 pow-heavy headers on the last block for cost 48 bytes header + =
32 bytes<br>
&gt; payout key) such that there&#39;s an incentive to include the heaviest=
 ones you&#39;ve<br>
&gt; seen, not just your own, that are worth further study and consideratio=
n<br>
&gt; (particularly because it&#39;s non-consensus, only for opt-in particip=
ation in the<br>
&gt; pool).<br>
&gt; <br>
&gt; With respect to space usage, it seems you wholly reject the viability =
of a<br>
&gt; payment pool mechanism to cut-through chain space. Is this a critique =
that<br>
&gt; holds for all Payment Pools, or just in the context of mining? Is ther=
e a<br>
&gt; particular reason why you think it infeasible that &quot;strongly onli=
ne&quot;<br>
&gt; counterparties would be able to coordinate more efficiently? Is it pre=
ferable<br>
&gt; for miners, the nexus of decentralization for Bitcoin, to prefer to us=
e<br>
&gt; custodial services for pooling (which may require KYC/AM) over bearing=
 a cost<br>
&gt; of some extra potential chainload?<br>
&gt; <br>
&gt; Lastly, with respect to complexity, the proposal is actually incredibl=
y simple<br>
&gt; when you take it in a broader context. Non Interactive Channels and Pa=
yment<br>
&gt; Pools are useful=C2=A0by themselves, so are the operations to merge th=
em and swap<br>
&gt; balance across them. Therefore most of the complexity in this proposal=
 is<br>
&gt; relying on tools we&#39;ll likely see in everyday use in any case, DCF=
MP or no.<br>
&gt; <br>
&gt; Jeremy<br>
&gt; !DSPAM:61b8f2f5321461582627336!<br>
--<br>
Cheers, Bob McElrath<br>
<br>
&quot;For every complex problem, there is a solution that is simple, neat, =
and wrong.&quot;<br>
=C2=A0 =C2=A0 -- H. L. Mencken <br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000008bda6905d33297b8--