diff options
| author | Bob McElrath <bob@mcelrath.org> | 2021-12-15 00:12:00 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-12-15 00:12:02 +0000 |
| commit | ccb8fe14900cc099dd8d188f597595eac8542ccb (patch) | |
| tree | 53bfdc09876b39af2a4653b51074815c2aafdf7d /20 | |
| parent | 143cfcecc967849ec4306976e9e90791b33c9411 (diff) | |
| download | pi-bitcoindev-ccb8fe14900cc099dd8d188f597595eac8542ccb.tar.gz pi-bitcoindev-ccb8fe14900cc099dd8d188f597595eac8542ccb.zip | |
Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
Diffstat (limited to '20')
| -rw-r--r-- | 20/fb3259dd4807cd0f58414bcac4009a20a9f3ad | 131 |
1 files changed, 131 insertions, 0 deletions
diff --git a/20/fb3259dd4807cd0f58414bcac4009a20a9f3ad b/20/fb3259dd4807cd0f58414bcac4009a20a9f3ad new file mode 100644 index 000000000..0033e83f0 --- /dev/null +++ b/20/fb3259dd4807cd0f58414bcac4009a20a9f3ad @@ -0,0 +1,131 @@ +Return-Path: <bob@mcelrath.org> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 8BA35C0012 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Dec 2021 00:12:02 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 6688D8131F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Dec 2021 00:12:02 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.902 +X-Spam-Level: +X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +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 q8iE6I1b2Llc + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Dec 2021 00:12:01 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 7DCB081313 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Dec 2021 00:12:01 +0000 (UTC) +Received: from mcelrath.org (localhost [127.0.0.1]) + by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 1BF0C0Eh035963 + (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Dec 2021 00:12:00 GMT +Received: (from mcelrath@localhost) + by mcelrath.org (8.14.4/8.14.4/Submit) id 1BF0C0sE035962 + for bitcoin-dev@lists.linuxfoundation.org; Wed, 15 Dec 2021 00:12:00 GMT +X-Authentication-Warning: mcelrath.org: mcelrath set sender to + bob@mcelrath.org using -f +Date: Wed, 15 Dec 2021 00:12:00 +0000 +From: Bob McElrath <bob@mcelrath.org> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20211215001200.GA35108@mcelrath.org> +References: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com> + <20211214190524.GA30559@mcelrath.org> + <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com> +User-Agent: Mutt/1.5.23 (2014-03-12) +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 00:12:02 -0000 + +You are hand waving. Attempting to redefine terms to justify your argument is +intellectually dishonest. Bitcoin pools have *always* been about variance +reduction. Your window function fundamentally CANNOT be used to hedge hashrate. +Various suggestions below introduce dangerous new games that might be played by +miners. + +The fact is that the half-baked design you posted is less than useless, and +doesn't do anything that anyone wants. + +You are trying to justify CTV by making it be all things to all people. "When +all you have is a hammer, every problem looks like a nail". Instead I humbly +suggest that you pick ONE problem for which CTV is demonstrably the right and +best solution, instead of snowing us with a ton of half-baked things that +*could* be done, and often don't even require CTV, and some (like this one) +fundamentally don't work. I do like some of your ideas, but if you had to pick +just one "use case", which would it be? + +Jeremy [jlrubin@mit.edu] wrote: +> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/ +> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may +> not be your favorite kind, which is fixated on specific properties of computing +> contributions before finding a block. Pooling is just a general technique for +> aggregating resources to accomplish something. If you have another name like +> pooling that is in common use for this type of activity I would be more than +> happy to adopt it. +> +> This sort of pool can hedge not only against fee rates but also against +> increases in hashrate since your historical rate 'carries' into the future as a +> function of the window. Further, windows and reward functions can be defined in +> a myriad of ways that could, e.g., pay less to blocks found in more rapid +> succession, contributing to the smoothing functionality. +> +> With respect to sub-block pooling, as described in the article, this sort of +> design also helps with micro-pools being able to split resources +> non-custodially in every block as a part of the higher order DCFMP. The point +> is not, as noted, to enable solo mining an S9, but to decrease the size of the +> minimum viable pool. It's also possible to add, without much validation or +> data, some 'uncle block' type mechanism in an incentive compatible way (e.g., +> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes +> payout key) such that there's an incentive to include the heaviest ones you've +> seen, not just your own, that are worth further study and consideration +> (particularly because it's non-consensus, only for opt-in participation in the +> pool). +> +> With respect to space usage, it seems you wholly reject the viability of a +> payment pool mechanism to cut-through chain space. Is this a critique that +> holds for all Payment Pools, or just in the context of mining? Is there a +> particular reason why you think it infeasible that "strongly online" +> counterparties would be able to coordinate more efficiently? Is it preferable +> for miners, the nexus of decentralization for Bitcoin, to prefer to use +> custodial services for pooling (which may require KYC/AM) over bearing a cost +> of some extra potential chainload? +> +> Lastly, with respect to complexity, the proposal is actually incredibly simple +> when you take it in a broader context. Non Interactive Channels and Payment +> Pools are useful�by themselves, so are the operations to merge them and swap +> balance across them. Therefore most of the complexity in this proposal is +> relying on tools we'll likely see in everyday use in any case, DCFMP or no. +> +> Jeremy +> !DSPAM:61b8f2f5321461582627336! +-- +Cheers, Bob McElrath + +"For every complex problem, there is a solution that is simple, neat, and wrong." + -- H. L. Mencken + + |