path: root/73/48f528972f1ee08a300e16ff41466c6ad87a9d

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2354BC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 16:57:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 049A183005
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 16:57:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level: 
X-Spam-Status: No, score=-0.856 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, NUMERIC_HTTP_ADDR=1.242,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 0bZTOc2HNaUd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 16:57:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
 [IPv6:2607:f8b0:4864:20::1036])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5548282CCB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 16:57:21 +0000 (UTC)
Received: by mail-pj1-x1036.google.com with SMTP id
 j6-20020a17090a588600b001a78a5ce46aso3222060pji.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 08:57:21 -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
 :cc; bh=SyY6ufpf31wSEiTdwyNoYIGNZL6XuflwsG+Mal8rivY=;
 b=D8jvodkvOZL7L1GygL83iW5PLtoBDtOloQINb7pPkZJNq0RL7V4buNqCYP05p2xEix
 p2r4OlJMOYWx8vLyPTi3PS5jsImcYe8KgxYND3/0KWKJzoYivoFtH8s4cjoTdC9YgMSo
 +xTDxgx96NTdwC9Mi/TQvvZZpTOENq7uQd+df3rngbdDqrtaK+sYe1mUWmLM8lFFTA+3
 s5dhM0J5mnTt9NwMrqEZFb2ht/xPEDafZV1YfBtZn3MZXihPzlm5Kv/EYWw8E2HRGFSq
 xbRNhM8mxeMofUsXMgwIy22nQHMuqv9w35MIz5sm2Lvv656jOIg/VjStigOP4d2l6Wjg
 Xaew==
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:cc;
 bh=SyY6ufpf31wSEiTdwyNoYIGNZL6XuflwsG+Mal8rivY=;
 b=OOO63ljJDJ1aJxqG9T/sqPBEUv3pfoLk8lrTLhpAJTUFxQOZwpGe299Rxr4pGiSTVV
 r9HxphzchclQDBJoIbwlAM92cUiDGs+Izx9E+XgkwKB+6I16Nhm1NmTe+LNsgxxP2UWQ
 FSFeYxIghVVNS005Eavg90Ja3U9cLB2lY/8S1nKhj78fOF0c42+LEwe7PU97wzG9cppN
 OvBZD8nK9iOoggbYtD5hs7lH8GPkhT5w1mNe9a18KL0CiBT8M/oD/xFEcb4MquLEWSEB
 BrihdiaWb8L100JrbCTIbHW78JiFbVYcudpie0v4yzvZPZ+xnQTkaa0KWU7kIlkIdtSH
 /4cg==
X-Gm-Message-State: AOAM532beSb4lnziQfctLot8cqte9FGA7h2fJOn9hih/vAXHlCShZz2f
 cfgIK+48vv5ITSeTkT/MN3admShrqKCskUUpg6oRrIKtic0=
X-Google-Smtp-Source: ABdhPJz6kFyb1bCPqFaDB0C/eF5zIL55sq22hcXCS0eYSo6CdKO8QBgG41qLz4CA372CkOHfw1qHvMepkcv4LRNVcXQ=
X-Received: by 2002:a17:902:d284:b0:148:d723:ba98 with SMTP id
 t4-20020a170902d28400b00148d723ba98mr189180plc.154.1639673840605; Thu, 16 Dec
 2021 08:57:20 -0800 (PST)
MIME-Version: 1.0
References: <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
 <125410522-883ad4a6e0feb9e4c1436bf1d9a3d2d9@pmq8v.m5r2.onet>
In-Reply-To: <125410522-883ad4a6e0feb9e4c1436bf1d9a3d2d9@pmq8v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 16 Dec 2021 08:57:03 -0800
Message-ID: <CAGpPWDbph1VPa6Kqy1HsB0XbZ=Warn+qN7m=yNdJfYwQ3G-nSw@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="000000000000d11ea005d34650c3"
X-Mailman-Approved-At: Thu, 16 Dec 2021 23:22:10 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 16 Dec 2021 16:57:23 -0000

--000000000000d11ea005d34650c3
Content-Type: text/plain; charset="UTF-8"

@Jeremy
>   for top-level pool participants there is never any central custody.

I definitely see that. That was actually what I meant when I said the goals
aren't the same as benefits. While your idea definitely satisfies all your
goals in a modular way, the fact that it relies on pools means that unless
the pools can also satisfy the goals, the total system also doesn't satisfy
the goals (even tho the piece of that system you designed does).

> Thus it doesn't "hurt" anyone except for the miners who are taking the
not fully locked in funds risk

True, it only potentially hurts whoever the channel partner is accepting
the unspendable coins. And no one can really stop anyone from taking that
risk if they really want to. But in that case, its not exactly a fully
functional channel, since recourse mechanisms couldn't be performed.
Wouldn't that open such a channel up to a pretty bad theft possibility?

@Bob
> Increased payout regularity does not lower the viable size of mining
pools, because smaller mining pools using this mechanism still have higher
variance.

Yes, smaller mining pools will always have higher variance. However, lower
variance has diminishing benefits. Below a certain amount of variance, less
variance isn't very valuable. So increased payout regularity does indeed
lower the viable size of mining pools because a given low-enough level of
variance can be achieved with less pool hashpower.

> The on-chain footprint is *higher* due to the increased payout regularity.

That's a reasonable point. However, I think there is a difference here
between the regularity of rewards vs payouts. Rewards for each miner can be
more regular without necessarily increasing the number of on-chain payouts.
In fact, theoretically, an individual miner could let their rewards
accumulate in a pool over many rewards and only redeem when they need the
coins for something. The incentive is there for each miner to be judicious
on how much onchain space they take up.

@vjudeu

> how many block headers should be stored per one "superblock"?

I was thinking that this would be a separate blockchain with separate
headers that progress linearly like a normal blockchain. A block creator
would collect together as many blocks that haven't been collected yet into
the next superblock (and maybe receive a reward proportional to how many /
how much weight they include). This could be done using merge mining, or it
could be done using a signing scheme (eg where the block creator signs to
say "I created this superblock" and have mechanisms to punish those who
sign multiple superblocks at the same height. For merge mining, I could
even imagine the data necessary to validate that it has been merge mined
could be put into a taproot script branch (creating an invalid script, but
a valid hash of the superblock).

> we can collect all headers with the same previous block hash, and
distribute block reward between all coinbase transactions in those headers

Exactly.

> we would just have block headers instead of transactions

Yeah, I think that would be the way to go. Really, you could even just use
hashes of the block headers. But the size doesn't matter much because it
would be both a small blockchain and an ephemeral one (which can be fully
discarded after all parties have been paid out, or at least their payout
has been committed to on the bitcoin blockchain).

On Thu, Dec 16, 2021 at 1:35 AM <vjudeu@gazeta.pl> wrote:

> > 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?
>
> I thought about something like that, but there is one problem: how many
> block headers should be stored per one "superblock"? Currently, we have
> single block header, where the whole coinbase transaction is taken by some
> mining pool or solo miner. But instead, each miner could submit its own
> block header. Then, we can collect all headers with the same previous block
> hash, and distribute block reward between all coinbase transactions in
> those headers. One "superblock" then would be created in a similar way as
> existing blocks, we would just have block headers instead of transactions.
> If most transactions inside those blocks will be the same, then each block
> could be expressed just as a set of transaction hashes, only coinbase
> transactions or custom, non-broadcasted transactions included by miners
> will be revealed, everything else will be known.
>
> > 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.
>
> All coinbase rewards are unspendable for 100 blocks, it is enforced by
> consensus. It does not matter if there are outputs owned directly by
> miners, or if there is one huge N-of-N taproot multisig for the whole pool,
> where every miner signed the closing transaction. The only option to take
> coins faster I can see is swapping the coins by some LN transaction. But
> then, the other party can check if some deposit to the LN channel is a part
> of the coinbase transaction or not, and then decide if it is acceptable to
> do the swap.
>
> On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>>
> 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
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcWASdWVkpbCxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D>]
>> 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
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div id=3D"gmail-:1tx" class=3D"gmail-Am gmail-aO9 gmail-A=
l editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label=3D"Message Body=
" aria-multiline=3D"true" tabindex=3D"1" style=3D"direction:ltr;min-height:=
85px" aria-haspopup=3D"false" aria-expanded=3D"false"><div>@Jeremy<br></div=
>&gt;=C2=A0

<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">=C2=
=A0for top-level pool participants there is never any central custody.</spa=
n><div><br></div><div>I definitely see that. That was actually what I meant=
 when I said the goals aren&#39;t the same as benefits. While your idea def=
initely satisfies all your goals in a modular way, the fact that it relies =
on pools means that unless the pools can also satisfy the goals, the total =
system also doesn&#39;t satisfy the goals (even tho the piece of that syste=
m you designed does).=C2=A0</div><div><br></div><div>&gt;=C2=A0<span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Thus it doesn&=
#39;t &quot;hurt&quot; anyone except for the miners who are taking the not =
fully locked in funds risk</span></div><div><span style=3D"color:rgb(0,0,0)=
;font-family:arial,helvetica,sans-serif"><br></span></div><div><font color=
=3D"#000000" face=3D"arial, helvetica, sans-serif">True, it only potentiall=
y hurts whoever the channel partner is accepting the unspendable coins. And=
 no one can really stop anyone from taking that risk if they really want to=
. But in that case, its not exactly a fully functional channel, since recou=
rse mechanisms couldn&#39;t be performed. Wouldn&#39;t that open such a cha=
nnel up to a pretty bad theft possibility?</font></div><div><font color=3D"=
#000000" face=3D"arial, helvetica, sans-serif"><br></font></div><div><font =
color=3D"#000000" face=3D"arial, helvetica, sans-serif">@Bob<br></font></di=
v><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">&gt;=
=C2=A0</font>Increased payout regularity does not lower the viable size of =
mining pools, because smaller mining pools using this mechanism still have =
higher variance.</div><div><br></div><div>Yes, smaller mining pools will al=
ways have higher variance. However, lower variance has diminishing benefits=
. Below a certain amount of variance, less variance isn&#39;t very valuable=
. So increased payout regularity does indeed lower the viable size of minin=
g pools because a given low-enough level of variance can be achieved with l=
ess pool hashpower.</div><div><br></div><div>&gt; The on-chain footprint is=
 *higher* due to the increased payout regularity.</div><div><br></div><div>=
That&#39;s a reasonable point. However, I think there is a difference here =
between the regularity of rewards vs payouts. Rewards for each miner can be=
 more regular without necessarily increasing the number of on-chain payouts=
. In fact, theoretically, an individual miner could let their rewards accum=
ulate in a pool over many rewards and only redeem when they need the coins =
for something. The incentive is there for each miner to be judicious on how=
 much onchain space they take up.</div><div><br></div><div>@vjudeu<br></div=
><div><br></div><div>&gt; how many block headers should be stored per one &=
quot;superblock&quot;?</div><div><br></div><div>I was thinking that this wo=
uld be a separate blockchain with separate headers that progress linearly l=
ike a normal blockchain. A block creator would collect together as many blo=
cks that haven&#39;t been collected yet into the next superblock (and maybe=
 receive a reward proportional to how many / how much weight they include).=
 This could be done using merge mining, or it could be done using a signing=
 scheme (eg where the block creator signs to say &quot;I created this super=
block&quot; and have mechanisms to punish those who sign multiple superbloc=
ks at the same height. For merge mining, I could even imagine the data nece=
ssary to validate that it has been merge mined could be put into a taproot =
script branch (creating an invalid script, but a valid hash of the superblo=
ck).=C2=A0</div><div><br></div><div>&gt; we can collect all headers with th=
e same previous block hash, and distribute block reward between all coinbas=
e transactions in those headers</div><div><br></div><div>Exactly.</div><div=
><br></div><div>&gt; we would just have block headers instead of transactio=
ns</div><div><br></div><div>Yeah, I think that would be the way to go. Real=
ly, you could even just use hashes of the block headers. But the size doesn=
&#39;t matter much because it would be both a small blockchain and an ephem=
eral one (which can be fully discarded after all parties have been paid out=
, or at least their payout has been committed to on the bitcoin blockchain)=
.=C2=A0</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Thu, Dec 16, 2021 at 1:35 AM &lt;<a href=3D"mailto:vj=
udeu@gazeta.pl">vjudeu@gazeta.pl</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div>&gt; The missing piece here would be =
an ordering of weak blocks to make the window possible. Or at least a way t=
o determine what blocks should definitely be part of a particular block&#39=
;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 wea=
k blocks have been submitted, potentially using the pow already in each blo=
ck to secure it. Granted that piece is a bit half baked, but it seems quite=
 solvable. Wdyt?<br>=C2=A0<br>I thought about something like that, but ther=
e is one problem: how many block headers should be stored per one &quot;sup=
erblock&quot;? Currently, we have single block header, where the whole coin=
base transaction is taken by some mining pool or solo miner. But instead, e=
ach miner could submit its own block header. Then, we can collect all heade=
rs with the same previous block hash, and distribute block reward between a=
ll coinbase transactions in those headers. One &quot;superblock&quot; then =
would be created in a similar way as existing blocks, we would just have bl=
ock headers instead of transactions. If most transactions inside those bloc=
ks will be the same, then each block could be expressed just as a set of tr=
ansaction hashes, only coinbase transactions or custom, non-broadcasted tra=
nsactions included by miners will be revealed, everything else will be know=
n.<br><br>&gt; One thing that jumped out at me as not safe is throwing bloc=
k rewards into a channel and being able to spend them immediately. There&#3=
9;s a reason block rewards aren&#39;t spendable for a while, and channels d=
on&#39;t solve that problem, do they? Why not simply reduce the on chain wa=
it time for spending block rewards at that point? Seems like the consequenc=
es would be the same.<br><br>All coinbase rewards are unspendable for 100 b=
locks, it is enforced by consensus. It does not matter if there are outputs=
 owned directly by miners, or if there is one huge N-of-N taproot multisig =
for the whole pool, where every miner signed the closing transaction. The o=
nly option to take coins faster I can see is swapping the coins by some LN =
transaction. But then, the other party can check if some deposit to the LN =
channel is a part of the coinbase transaction or not, and then decide if it=
 is acceptable to do the swap.<br><br></div>
<div>On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:</div>
<blockquote style=3D"margin-left:7px;border-left:2px solid orange;padding-l=
eft:8px">
<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">=C2=A0</div>
<div dir=3D"auto">The primary benefits over what we have today that I can s=
ee are:</div>
<div dir=3D"auto">1. increased payout regularity, which lowers the viable s=
ize of mining pools, and</div>
<div dir=3D"auto">2. Lower on chain footprint through combining pay outs fr=
om multiple pools.</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Am I missing some?</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">These are interesting benefits, but it would be nice if y=
our post was clearer on that, since the goals list is not the same as the l=
ist of potential benefits of this kind of design.</div>
<div dir=3D"auto">=C2=A0</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;wea=
k 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 taproot payout=
s would apply i think. The only goals this wouldn&#39;t satisfy are 3 and 5=
 since an extra network is needed, but to be fair, your proposal requires p=
ools which all need their own extra network anyways.=C2=A0</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">The missing piece here would be an ordering of weak block=
s to make the window possible. Or at least a way to determine what blocks s=
hould definitely be part of a particular block&#39;s pay out. I could see t=
his being done by a separate ephemeral blockchain (which starts fresh after=
 each Bitcoin block) that keeps track of which weak blocks have been submit=
ted, 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?</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">One thing that jumped out at me as not safe is throwing b=
lock rewards into a channel and being able to spend them immediately. There=
&#39;s a reason block rewards aren&#39;t spendable for a while, and channel=
s don&#39;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 consequ=
ences would be the same.</div>
</div>
<br>
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Tue, Dec 14, 2021, 16:12 Bob McElr=
ath via bitcoin-dev &lt;<a href=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhI=
VRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVD=
EyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQ=
UQUoDQlAiBFY8" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">You are hand waving. Atte=
mpting to redefine terms to justify your argument is<br>intellectually dish=
onest. Bitcoin pools have *always* been about variance<br>reduction. Your w=
indow function fundamentally CANNOT be used to hedge hashrate.<br>Various s=
uggestions below introduce dangerous new games that might be played by<br>m=
iners.<br><br>The fact is that the half-baked design you posted is less tha=
n 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. &quot;When=
<br>all you have is a hammer, every problem looks like a nail&quot;.=C2=A0 =
Instead I humbly<br>suggest that you pick ONE problem for which CTV is demo=
nstrably the right and<br>best solution, instead of snowing us with a ton o=
f half-baked things that<br>*could* be done, and often don&#39;t even requi=
re 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"http://../NowaWiadomosc/Do/=
QlIkBFQ6QUFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgc=
WASdWVkpbCxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D" rel=3D"noreferrer norefe=
rrer" target=3D"_blank">jlrubin@mit.edu</a>] wrote:<br>&gt; Bitcoin didn&#3=
9;t invent the concept of pooling: <a href=3D"https://en.wikipedia.org/wiki=
/" rel=3D"noopener noreferrer noreferrer noreferrer" target=3D"_blank">http=
s://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; contribution=
s before finding a block. Pooling is just a general technique for<br>&gt; a=
ggregating resources to accomplish something. If you have another name like=
<br>&gt; pooling that is in common use for this type of activity I would be=
 more than<br>&gt; happy to adopt it.<br>&gt; <br>&gt; This sort of pool ca=
n hedge not only against fee rates but also against<br>&gt; increases in ha=
shrate since your historical rate &#39;carries&#39; into the future as a<br=
>&gt; function of the window. Further, windows and reward functions can be =
defined in<br>&gt; a myriad of ways that could, e.g., pay less to blocks fo=
und in more rapid<br>&gt; succession, contributing to the smoothing functio=
nality.<br>&gt; <br>&gt; With respect to sub-block pooling, as described in=
 the article, this sort of<br>&gt; design also helps with micro-pools being=
 able to split resources<br>&gt; non-custodially in every block as a part o=
f the higher order DCFMP. The point<br>&gt; is not, as noted, to enable sol=
o mining an S9, but to decrease the size of the<br>&gt; minimum viable pool=
. It&#39;s also possible to add, without much validation or<br>&gt; data, s=
ome &#39;uncle block&#39; type mechanism in an incentive compatible way (e.=
g.,<br>&gt; add 10 pow-heavy headers on the last block for cost 48 bytes he=
ader + 32 bytes<br>&gt; payout key) such that there&#39;s an incentive to i=
nclude the heaviest ones you&#39;ve<br>&gt; seen, not just your own, that a=
re worth further study and consideration<br>&gt; (particularly because it&#=
39;s non-consensus, only for opt-in participation in the<br>&gt; pool).<br>=
&gt; <br>&gt; With respect to space usage, it seems you wholly reject the v=
iability 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 c=
ontext of mining? Is there a<br>&gt; particular reason why you think it inf=
easible that &quot;strongly online&quot;<br>&gt; counterparties would be ab=
le to coordinate more efficiently? Is it preferable<br>&gt; for miners, the=
 nexus of decentralization for Bitcoin, to prefer to use<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 t=
o complexity, the proposal is actually incredibly simple<br>&gt; when you t=
ake it in a broader context. Non Interactive Channels and Payment<br>&gt; P=
ools are useful=C2=A0by themselves, so are the operations to merge them 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, DCFMP or no.<br>&gt; <br>&gt; Jeremy<br>&gt; !DSPAM:61b8f2f532=
1461582627336!<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"http://../NowaWiadomosc/=
Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJX=
QFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgA=
MGAMXBQJfW1sdXRQUQUoDQlAiBFY8" rel=3D"noreferrer noreferrer" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noopener noreferrer=
 noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote>
</blockquote></div>

--000000000000d11ea005d34650c3--