path: root/20/5ee0d8055fa8730b7b056cc2e22fe35e70be4b

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E0F11C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Dec 2021 13:39:41 -0500
Received: by mail-lj1-f169.google.com with SMTP id bn20so34715322ljb.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
 <20211214190524.GA30559@mcelrath.org>
 <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
 <20211215001200.GA35108@mcelrath.org>
 <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
In-Reply-To: <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 15 Dec 2021 10:39:28 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhgk_2Es-YvRPnwjjpOChPmQwHeFaM9LQ1T8L+hYdz45Q@mail.gmail.com>
Message-ID: <CAD5xwhhgk_2Es-YvRPnwjjpOChPmQwHeFaM9LQ1T8L+hYdz45Q@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Hi Billy=
!</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">Thanks for your response. Some replies inline:</div><br></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec=
 15, 2021 at 10:01 AM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">Looks like an in=
teresting proposal, but it doesn&#39;t seem to quite match the goals you me=
ntioned. As you do mention, this mining pool coordination doesn&#39;t get r=
id of the need for mining pools in the first place. So it doesn&#39;t satis=
fy item 1 on your goal list afaict.=C2=A0</div></blockquote><div><br></div>=
<div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)">It does, actually :) Point 1 was=
=C2=A0</div><ol style=3D"box-sizing:border-box;margin-top:0px;margin-bottom=
:1rem"><li style=3D"box-sizing:border-box">Funds should not be centrally cu=
stodied, ever, if at all<span class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span></li></=
ol><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><span=
 style=3D"caret-color: rgb(0, 0, 0);"><span class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">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.=
</span></span></font></div><div><font color=3D"#000000" face=3D"arial, helv=
etica, sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);"><span class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></span></span></font></div><div><font color=
=3D"#000000" face=3D"arial, helvetica, sans-serif"><span style=3D"caret-col=
or: rgb(0, 0, 0);"><span class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Further, for the en=
tities that are too small:</span><br></span></font></div></div><div><font c=
olor=3D"#000000" face=3D"arial, helvetica, sans-serif"><span style=3D"caret=
-color: rgb(0, 0, 0);"><span class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></span></sp=
an></font></div><span class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><div class=3D"gmail_qu=
ote">from the article:</div><i>&gt; </i></span><i>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.</i></div><div class=3D"gmail_quote"><i><br></i><div><span style=3D"c=
olor:rgb(0,0,0);font-family:arial,helvetica,sans-serif">The micro-pools emb=
ed <span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">a</span>=C2=A0<span class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">multisig of top-contributors, &#39;reputable&#39; members, =
or on a rotating basis,=C2=A0</span>as a leaf node to the parent. They then=
 opt-out of having their leaf channel-ized, as noted.</span><span style=3D"=
color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></span></div><div>=
<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br=
></span></div>T<span class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">his would be fully non-=
custodial if we always included all miners.=C2=A0</span><span class=3D"gmai=
l_default">The issue is tha</span><span class=3D"gmail_default" style=3D"co=
lor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></span><span class=
=3D"gmail_default" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sa=
ns-serif"></span><span class=3D"gmail_default" style=3D"color:rgb(0,0,0);fo=
nt-family:arial,helvetica,sans-serif">t opens up DoS if one miner goes away=
, so you do want to anchor around a few.</span></div><div class=3D"gmail_qu=
ote"><div><span class=3D"gmail_default" style=3D"color:rgb(0,0,0);font-fami=
ly:arial,helvetica,sans-serif"><br></span></div><div><span class=3D"gmail_d=
efault" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">I=
n this mode, you can set the protocol up such that immediately after gettin=
g a reward in a block, you should see the chosen nodes for multi-sigs distr=
ibute the spoils according to the schedule that is agreed on in the block c=
ausing the share to be granted.</span></div><div><span class=3D"gmail_defau=
lt" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br><=
/span></div><div><span class=3D"gmail_default" style=3D"color:rgb(0,0,0);fo=
nt-family:arial,helvetica,sans-serif">the main issue is data availability, =
without extra in-band storage local mining pools have to track the work sha=
res (which can be committed to in a block) locally for auditing.</span></di=
v><div><span class=3D"gmail_default" style=3D"color:rgb(0,0,0);font-family:=
arial,helvetica,sans-serif"><br></span></div><div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">This is not fully non-custodial, but it doesn&#39;t have to be c=
entrally custodied by one party. We can multisig immediately after every bl=
ock (and nodes should quit their pool if they don&#39;t get sigs quickly pe=
rhaps). Further, nodes can hash into multiple pools dividing their risk (mo=
dulo sybil attack) across many pools.</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">If we had stronger covena=
nts (CAT, AMOUNT, DIVIDE/MUL), we could make every leaf node commit to paym=
ent pools that operate on percents instead of fixed amounts and we&#39;d be=
 able to handle this in a manner that the payment pools work no matter what=
 amount is assigned to them.</div><br></div></div><div class=3D"gmail_quote=
"><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=
=3D"auto">The primary benefits over what we have today that I can see are:<=
/div><div dir=3D"auto">1. increased payout regularity, which lowers the via=
ble size of mining pools, and</div><div dir=3D"auto">2. Lower on chain foot=
print through combining pay outs from multiple pools.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Am I missing some?</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">These are interesting benefits, but it would be ni=
ce if your post was clearer on that, since the goals list is not the same a=
s the list of potential benefits of this kind of design.</div></div></block=
quote><div><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think I hit all =
the benefits mentioned:</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">1. </span>Funds should not be centrall=
y custodied, ever, if at all.</div><div class=3D"gmail_quote"><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">see above -- we can do better for smaller miners, bu=
t we hit this for miners above the threshold.</div><br><span class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">2. </span>No KYC/AML.</div><div class=3D"gmail_quote"><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">see above, payouts are done &#39;decentrali=
zed&#39; by every miner mining to the payout</div><br><span class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">3.=C2=A0</span>No =E2=80=9CExtra network=E2=80=9D software =
required.</div><div class=3D"gmail_quote"><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">you need the WASM, but do not need any networked software to participate=
, so there are no DoS concerns from participating.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">You do need =
extra software to e.g. use channels or cut-through multiple pools, but only=
 after the fact of minding.</div></div><div class=3D"gmail_quote"><br><span=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">4. </span>No blockchain bloat.</div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">Very little, if cut-through=C2=A0+ LN works.</div><br></d=
iv><div class=3D"gmail_quote"><br><span class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5. <=
/span>No extra infrastructure.</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote"><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Not much neede=
d, if anything. I don&#39;t really know what &#39;infrastructure&#39; means=
, but I kind of imagined it to mean &#39;big expensive things&#39; that wou=
ld make it hard to partake.</div><br></div><div class=3D"gmail_quote"><br><=
span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">6. </span>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.<div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">I think this works, roughly?</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"aut=
o"><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 publ=
ish &quot;weak blocks&quot; to that network, and the next 100 (or 1000 etc)=
 nice miners pay you out as long as you&#39;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&#39;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</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">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&#39;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><div dir=3D"auto"><br></div></div></blockquote><=
div><br></div><div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Yeah, it&#39;s worth=
 thinking more about 100%. This post wasn&#39;t a deployable thing, more an=
 exposition of a technique. I&#39;d love to see a weak-block based pool, th=
e main issue as noted is the extra software component + data availability, =
but perhaps that&#39;s solvable!</div><br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">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&#39;s a reason block rewa=
rds aren&#39;t spendable for a while, and channels don&#39;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.</=
div></div></blockquote><div><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;t generally have to check that our routes channel=
s exist, we don&#39;t care as long as they are happy. Thus it doesn&#39;t &=
quot;hurt&quot; 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&#39;t infe=
ct the rest of Bitcoin&#39;s users.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></div></div>

--000000000000ea839705d333a0aa--