path: root/6b/25b39838554c16d0a73a09a283641b9a8459f9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5E003C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Dec 2021 17:18:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4630260E36
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Dec 2021 17:18:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.144
X-Spam-Level: 
X-Spam-Status: No, score=0.144 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,
 FREEMAIL_REPLY=1, 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=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3JntVBIW2csY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Dec 2021 17:18:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com
 [IPv6:2607:f8b0:4864:20::1034])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5A4D260E14
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Dec 2021 17:18:56 +0000 (UTC)
Received: by mail-pj1-x1034.google.com with SMTP id
 lr15-20020a17090b4b8f00b001b19671cbebso535818pjb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Dec 2021 09:18:56 -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=z4H2vCUCxeIjKfd3cT4FCbzp5OHIs1CR5oYSE7XIclo=;
 b=N8ckgXRJDSKjcgb1GXgj6o6uGIkBRdsQejvwG22EHFDExTYbV4ZD9OW1tsfv36c/EG
 s+LX8VBsT+GeFM5dCxzzSbdpKFr/OOm4ZqUemSbxtRSbsWygVLK12Z4vv/yGyeswA5jV
 oMYn6W9auaUUeeS/retOgw2sgp7+T+A2YwdRpB6K/P01Ze3N2+DH6FWEtcabPckxNUuC
 qsnMrQW5p40LOvilTepQEoAfwQwk8ctKqVy1DD3REg2rMBQOKEZJsqaNUODY97dv13oB
 Js1GBCNlZpahqFKPZZtbrJEDbcNfM1mTi8tdAAluYscpotHwU3v6zkbkmE0lBnogdgND
 oTLQ==
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=z4H2vCUCxeIjKfd3cT4FCbzp5OHIs1CR5oYSE7XIclo=;
 b=VRk0cTOdafAHAyBXCkX6cwIL1sdzrEF2sLECDjDxdXU4hoVfmdfVhBZsSn5Qh481Wg
 bCP/ZZIL8QvcfUL87W/luTlasnx3b5XZCTfbs94e/sijbevBUx4bm+7r3SCuzzqSRwjB
 lI4I5vFQnS5syPmacFwdvD2Kz9oRCCwP9IT7qSDCObK7B1/VztEVMAm1/dFUBS7z3FGE
 J984fkK1sxnYba2AMm7XKjKyr5ntxUp6d9Oe706LYSNy1S5I9Df0MM1MzgrmPuitgR7V
 PYCvdhfe5DH9KUlUOHBWgpja+6xDtRU/u5vk7KtExej5/DjBPxZV8l/W3QMsxwEQqasC
 7z0g==
X-Gm-Message-State: AOAM533VZKYlKpeaNWYB0nfMHlbotkgLASa1K8yg4yyZEhHTePC88+78
 cdAxSM3H7Nn/BLA/IiMlCZ+3Ox+3oLZ/QgbcCkH6yyFp
X-Google-Smtp-Source: ABdhPJwYfxWMjTILdtS63VlJqF1IcZzZXvNNaMtivxsAUzajfvu8yzpKkSeWu+mUu30LAZkdKgi2cc6WLUoTADx+wxA=
X-Received: by 2002:a17:902:d284:b0:148:d723:ba98 with SMTP id
 t4-20020a170902d28400b00148d723ba98mr18126933plc.154.1640020735579; Mon, 20
 Dec 2021 09:18:55 -0800 (PST)
MIME-Version: 1.0
References: <CAGpPWDbph1VPa6Kqy1HsB0XbZ=Warn+qN7m=yNdJfYwQ3G-nSw@mail.gmail.com>
 <150492262-e89b67dc2c010e65008ad976e2647ec1@pmq4v.m5r2.onet>
In-Reply-To: <150492262-e89b67dc2c010e65008ad976e2647ec1@pmq4v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 20 Dec 2021 09:18:44 -0800
Message-ID: <CAGpPWDbGTET27Hq8kKrQQoOavtOUEGzYkohVurSqZJ5r+o4gpQ@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="0000000000005e5a3105d3971540"
X-Mailman-Approved-At: Mon, 20 Dec 2021 18:05:17 +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: Mon, 20 Dec 2021 17:18:58 -0000

--0000000000005e5a3105d3971540
Content-Type: text/plain; charset="UTF-8"

> you can assign some minimal difficulty,

I was assuming that would be part of the plan.

> Signing sounds more like Proof of Stake

Associating signing with proof of stake and thereby concluding that signing
is something to avoid sounds like superstitious thinking. A signing scheme
with proof of work would clearly not be proof of stake. I would suggest not
dismissing a design out of hand like that. The benefit of that over merge
mining would be no extra on chain foot print. What do you think the
downsides might be?

> if you use just hashes, then they could be random.

You're right. Nodes would of course need to validate the Bitcoin block
headers being included, so i concede hashing them doesn't gain you anything.


On Thu, Dec 16, 2021, 22:37 <vjudeu@gazeta.pl> wrote:

> > I was thinking that this would be a separate blockchain with separate
> headers that progress linearly like a normal blockchain.
>
> Exactly, that's what I called "superblocks", where you have a separate
> chain, just to keep block headers instead of transactions.
>
> > 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).
>
> You cannot "catch them all". If you do, you can end up with a lot of block
> headers, where each of them has difficulty equal to one. You need some
> limit, you can limit amount of blocks, you can assign some minimal
> difficulty, it does not matter that much, but some limit is needed, also
> because mining on top of the latest superblock should be more profitable
> than replacing someone else's reward in the previous superblock by your own
> reward and getting a bigger share in the previous superblock.
>
> > 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.
>
> I would pick merge mining, because it is more compatible with existing
> mining scheme. Signing sounds more like Proof of Stake and I am trying to
> avoid that solution. Also, there is no need to sign anything, because you
> are solo mining where you have your own coinbase transaction or you are
> mining in a pool, where you have some shared address, and then you cannot
> produce any incompatible superblock, because the protocol can tell you,
> which address you should use (and if it is N-of-N taproot multisig and you
> have some closing transaction, then you can safely mine it).
>
> > Really, you could even just use hashes of the block headers.
>
> Replacing transactions with block headers will do the same trick. Each
> transaction is first hashed with double SHA-256, in exactly the same way as
> block headers are. If you replace transactions with block headers, you
> would get a superblock header, then varint saying how many block headers
> are there, and then you can place all block headers. During superblock
> merkle tree construction, you will hash all block headers (so you will get
> block hashes as leaves), and then you will combine block hashes in the same
> way as transaction hashes are combined.
>
> From the Script point of view, you can always use "OP_SIZE 80
> OP_EQUALVERIFY OP_HASH256 <hash> OP_EQUAL". Then, you can just change the
> size, just to show which object is hashed. Value 80 will work for block
> headers, small values below 520 will work for small transactions, value 64
> will work for any merkle tree proof, no matter if it is for superblock or
> normal block. Also, by using block headers instead of hashes, you can prove
> that at least a proper amount of work was done to produce it, because if
> you use just hashes, then they could be random.
>
> On 2021-12-16 17:57:23 user Billy Tetrud <billy.tetrud@gmail.com> wrote:
>
> @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
> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEuGRE%2BJkYAEBM5BgkBElIaQgpBQUFBVCVGX18dBRtTEQcBF1UyQUoDEQ0TRQYNQUdjI1hCU0cyajZIblhVZRQcVlEe>>
> 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
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>>
>> 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
>>
>>

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

<div dir=3D"auto"><div dir=3D"auto">&gt; you can assign some minimal diffic=
ulty,</div><div dir=3D"auto"><br></div><div dir=3D"auto">I was assuming tha=
t would be part of the plan.</div><div dir=3D"auto"><br></div><div>&gt;=C2=
=A0Signing sounds more like Proof of Stake</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Associating signing with proof of stake and thereby conc=
luding that signing is something to avoid sounds like superstitious thinkin=
g. A signing scheme with proof of work would clearly not be proof of stake.=
 I would suggest not dismissing a design out of hand like that. The benefit=
 of that over merge mining would be no extra on chain foot print. What do y=
ou think the downsides might be?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">&gt; if you use just hashes, then they could be random.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">You&#39;re right. Nodes would of =
course need to validate the Bitcoin block headers being included, so i conc=
ede hashing them doesn&#39;t gain you anything.</div><div dir=3D"auto"><spa=
n style=3D"font-size:12.8px"><br></span><br><div class=3D"gmail_quote" dir=
=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 16, 2021, 22:37=
  &lt;<a href=3D"mailto:vjudeu@gazeta.pl">vjudeu@gazeta.pl</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div>&gt; I was thinking that this w=
ould be a separate blockchain with separate headers that progress linearly =
like a normal blockchain.<br><br>Exactly, that&#39;s what I called &quot;su=
perblocks&quot;, where you have a separate chain, just to keep block header=
s instead of transactions.<br><br>&gt; A block creator would collect togeth=
er as many blocks that haven&#39;t been collected yet into the next superbl=
ock (and maybe receive a reward proportional to how many / how much weight =
they include).<br><br>You cannot &quot;catch them all&quot;. If you do, you=
 can end up with a lot of block headers, where each of them has difficulty =
equal to one. You need some limit, you can limit amount of blocks, you can =
assign some minimal difficulty, it does not matter that much, but some limi=
t is needed, also because mining on top of the latest superblock should be =
more profitable than replacing someone else&#39;s reward in the previous su=
perblock by your own reward and getting a bigger share in the previous supe=
rblock.<br><br>&gt; This could be done using merge mining, or it could be d=
one using a signing scheme (eg where the block creator signs to say &quot;I=
 created this superblock&quot; and have mechanisms to punish those who sign=
 multiple superblocks at the same height.<br><br>I would pick merge mining,=
 because it is more compatible with existing mining scheme. Signing sounds =
more like Proof of Stake and I am trying to avoid that solution. Also, ther=
e is no need to sign anything, because you are solo mining where you have y=
our own coinbase transaction or you are mining in a pool, where you have so=
me shared address, and then you cannot produce any incompatible superblock,=
 because the protocol can tell you, which address you should use (and if it=
 is N-of-N taproot multisig and you have some closing transaction, then you=
 can safely mine it).<br><br>&gt; Really, you could even just use hashes of=
 the block headers.<br><br>Replacing transactions with block headers will d=
o the same trick. Each transaction is first hashed with double SHA-256, in =
exactly the same way as block headers are. If you replace transactions with=
 block headers, you would get a superblock header, then varint saying how m=
any block headers are there, and then you can place all block headers. Duri=
ng superblock merkle tree construction, you will hash all block headers (so=
 you will get block hashes as leaves), and then you will combine block hash=
es in the same way as transaction hashes are combined.<br><br>From the Scri=
pt point of view, you can always use &quot;OP_SIZE 80 OP_EQUALVERIFY OP_HAS=
H256 &lt;hash&gt; OP_EQUAL&quot;. Then, you can just change the size, just =
to show which object is hashed. Value 80 will work for block headers, small=
 values below 520 will work for small transactions, value 64 will work for =
any merkle tree proof, no matter if it is for superblock or normal block. A=
lso, by using block headers instead of hashes, you can prove that at least =
a proper amount of work was done to produce it, because if you use just has=
hes, then they could be random.<br><br></div>
<div>On 2021-12-16 17:57:23 user Billy Tetrud &lt;<a href=3D"mailto:billy.t=
etrud@gmail.com" target=3D"_blank" rel=3D"noreferrer">billy.tetrud@gmail.co=
m</a>&gt; wrote:</div>
<blockquote style=3D"margin-left:7px;border-left:2px solid orange;padding-l=
eft:8px">
<div dir=3D"ltr">
<div id=3D"m_7099304871181977130gmail-:1tx" style=3D"direction:ltr;min-heig=
ht:85px">
<div>@Jeremy</div>
&gt;=C2=A0 <span style=3D"color:#000000;font-family:arial,helvetica,sans-se=
rif">=C2=A0for top-level pool participants there is never any central custo=
dy.</span>
<div>=C2=A0</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 definitely satisfies=
 all your goals in a modular way, the fact that it relies on pools means th=
at unless the pools can also satisfy the goals, the total system also doesn=
&#39;t satisfy the goals (even tho the piece of that system you designed do=
es).=C2=A0</div>
<div>=C2=A0</div>
<div>&gt;=C2=A0<span style=3D"color:#000000;font-family:arial,helvetica,san=
s-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:#000000;font-family:arial,helvetica,sans-serif">=
=C2=A0</span></div>
<div><span style=3D"color:#000000">True, it only potentially hurts whoever =
the channel partner is accepting the unspendable coins. And no one can real=
ly stop anyone from taking that risk if they really want to. But in that ca=
se, its not exactly a fully functional channel, since recourse mechanisms c=
ouldn&#39;t be performed. Wouldn&#39;t that open such a channel up to a pre=
tty bad theft possibility?</span></div>
<div><span style=3D"color:#000000">=C2=A0</span></div>
<div><span style=3D"color:#000000">@Bob<br></span></div>
<div><span style=3D"color:#000000">&gt;=C2=A0</span>Increased payout regula=
rity does not lower the viable size of mining pools, because smaller mining=
 pools using this mechanism still have higher variance.</div>
<div>=C2=A0</div>
<div>Yes, smaller mining pools will always have higher variance. However, l=
ower 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 mining pools because a given low-enough le=
vel of variance can be achieved with less pool hashpower.</div>
<div>=C2=A0</div>
<div>&gt; The on-chain footprint is *higher* due to the increased payout re=
gularity.</div>
<div>=C2=A0</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 c=
an be more regular without necessarily increasing the number of on-chain pa=
youts. In fact, theoretically, an individual miner could let their rewards =
accumulate in a pool over many rewards and only redeem when they need the c=
oins for something. The incentive is there for each miner to be judicious o=
n how much onchain space they take up.</div>
<div>=C2=A0</div>
<div>@vjudeu</div>
<div>=C2=A0</div>
<div>&gt; how many block headers should be stored per one &quot;superblock&=
quot;?</div>
<div>=C2=A0</div>
<div>I was thinking that this would be a separate blockchain with separate =
headers that progress linearly like a normal blockchain. A block creator wo=
uld collect together as many blocks that haven&#39;t been collected yet int=
o 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 t=
o say &quot;I created this superblock&quot; and have mechanisms to punish t=
hose 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 mi=
ned could be put into a taproot script branch (creating an invalid script, =
but a valid hash of the superblock).=C2=A0</div>
<div>=C2=A0</div>
<div>&gt; we can collect all headers with the same previous block hash, and=
 distribute block reward between all coinbase transactions in those headers=
</div>
<div>=C2=A0</div>
<div>Exactly.</div>
<div>=C2=A0</div>
<div>&gt; we would just have block headers instead of transactions</div>
<div>=C2=A0</div>
<div>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&#39;t matter much beca=
use 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 pay=
out has been committed to on the bitcoin blockchain).=C2=A0</div>
</div>
</div>
<br>
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Thu, Dec 16, 2021 at 1:35 AM &lt;<=
a href=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEuGRE%2B=
JkYAEBM5BgkBElIaQgpBQUFBVCVGX18dBRtTEQcBF1UyQUoDEQ0TRQYNQUdjI1hCU0cyajZIblh=
VZRQcVlEe" target=3D"_blank" rel=3D"noreferrer">vjudeu@gazeta.pl</a>&gt; wr=
ote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid #cccccc;padding-left:1ex">
<div>&gt; The missing piece here would be an ordering of weak blocks to mak=
e the window possible. Or at least a way to determine what blocks should de=
finitely be part of a particular block&#39;s pay out. I could see this bein=
g done by a separate ephemeral blockchain (which starts fresh after each Bi=
tcoin block) that keeps track of which weak blocks have been submitted, pot=
entially using the pow already in each block to secure it. Granted that pie=
ce is a bit half baked, but it seems quite solvable. Wdyt?<br>=C2=A0<br>I t=
hought about something like that, but there is one problem: how many block =
headers should be stored per one &quot;superblock&quot;? 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 bl=
ock header. Then, we can collect all headers with the same previous block h=
ash, and distribute block reward between all coinbase transactions in those=
 headers. One &quot;superblock&quot; then would be created in a similar way=
 as existing blocks, we would just have block headers instead of transactio=
ns. If most transactions inside those blocks will be the same, then each bl=
ock could be expressed just as a set of transaction hashes, only coinbase t=
ransactions or custom, non-broadcasted transactions included by miners will=
 be revealed, everything else will be known.<br><br>&gt; One thing that jum=
ped out at me as not safe is throwing block rewards into a channel and bein=
g able to spend them immediately. There&#39;s a reason block rewards aren&#=
39;t spendable for a while, and channels don&#39;t solve that problem, do t=
hey? Why not simply reduce the on chain wait time for spending block reward=
s at that point? Seems like the consequences would be the same.<br><br>All =
coinbase rewards are unspendable for 100 blocks, it is enforced by consensu=
s. 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 m=
iner 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.<br=
><br></div>
<div>On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev &lt;<a href=
=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7=
EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAs=
zLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=3D"_blank=
" rel=3D"noreferrer">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"noopener noreferrer noreferrer" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid #cccccc;padding-left:1ex">You are hand waving. Attempting to=
 redefine terms to justify your argument is<br>intellectually dishonest. Bi=
tcoin pools have *always* been about variance<br>reduction. Your window fun=
ction fundamentally CANNOT be used to hedge hashrate.<br>Various suggestion=
s below introduce dangerous new games that might be played 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 t=
o justify CTV by making it be all things to all people. &quot;When<br>all y=
ou 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 demonstrably =
the right and<br>best solution, instead of snowing us with a ton of half-ba=
ked things that<br>*could* be done, and often don&#39;t even require CTV, a=
nd 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/QlIkBFQ6Q=
UFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcWASdWVkpb=
CxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D" rel=3D"noopener noreferrer norefe=
rrer noreferrer" target=3D"_blank">jlrubin@mit.edu</a>] wrote:<br>&gt; Bitc=
oin didn&#39;t invent the concept of pooling: <a href=3D"https://en.wikiped=
ia.org/wiki/" rel=3D"noopener noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://en.wikipedia.org/wiki/</a><br>&gt; Pooling_(resou=
rce_management). This is a Bitcoin Mining Pool, although it may<br>&gt; not=
 be your favorite kind, which is fixated on specific properties of computin=
g<br>&gt; contributions before finding a block. Pooling is just a general t=
echnique for<br>&gt; aggregating 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 can hedge not only against fee rates but also against<b=
r>&gt; increases in hashrate since your historical rate &#39;carries&#39; i=
nto the future as a<br>&gt; function of the window. Further, windows and re=
ward functions can be defined in<br>&gt; a myriad of ways that could, e.g.,=
 pay less to blocks found in more rapid<br>&gt; succession, contributing to=
 the smoothing functionality.<br>&gt; <br>&gt; With respect to sub-block po=
oling, 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 e=
very block as a part of the higher order DCFMP. The point<br>&gt; is not, a=
s noted, to enable solo mining an S9, but to decrease the size of the<br>&g=
t; minimum viable pool. It&#39;s also possible to add, without much validat=
ion or<br>&gt; data, some &#39;uncle block&#39; type mechanism in an incent=
ive compatible way (e.g.,<br>&gt; add 10 pow-heavy headers on the last bloc=
k 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 consideration<br>&gt; (par=
ticularly 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 y=
ou wholly reject the viability of a<br>&gt; payment pool mechanism to cut-t=
hrough chain space. Is this a critique that<br>&gt; holds for all Payment P=
ools, or just in the context of mining? Is there a<br>&gt; particular reaso=
n why you think it infeasible that &quot;strongly online&quot;<br>&gt; coun=
terparties would be able to coordinate more efficiently? Is it preferable<b=
r>&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 to complexity, the proposal is actually incredibly sim=
ple<br>&gt; when you take it in a broader context. Non Interactive Channels=
 and Payment<br>&gt; Pools are useful=C2=A0by themselves, so are the operat=
ions 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 likel=
y see in everyday use in any case, DCFMP 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, a=
nd wrong.&quot;<br>=C2=A0 =C2=A0 -- H. L. Mencken <br><br>_________________=
______________________________<br>bitcoin-dev mailing list<br><a href=3D"ht=
tp://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl=
9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQ=
VV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" rel=3D"noopener norefe=
rrer noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a><br><a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" rel=3D"noopener noreferrer noreferrer noreferrer noreferrer=
" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev</a></blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote></div></div></div>

--0000000000005e5a3105d3971540--