From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4577AC001B for ; Mon, 6 Sep 2021 09:03:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1CBF8403FC for ; Mon, 6 Sep 2021 09:03:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=ctemplar.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMZwXgGY9W_d for ; Mon, 6 Sep 2021 09:03:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.ctemplar.com (mail.ctemplar.com [82.221.128.126]) by smtp4.osuosl.org (Postfix) with ESMTPS id 50924403F2 for ; Mon, 6 Sep 2021 09:03:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ctemplar.com; s=ctemplar; h=Message-Id:References:In-Reply-To:Date:To:From: Subject:Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lB5d1dnzizkqssmKqRrG6aix3tKFGaL8w+YakyH3GTU=; b=Fa+Nh1JswAu3pdAFDHCVGkdolX mUBHjjloPHKKTv1gq98KY+h9sGipDFRMiAReTqO/NIlFcPPcuWcfg0mYdEDSl8nszPhWsQYrPiRfB 7OgCfKVyU4ZySH+gNHu+jm+6WGtbfsvLe/WJdy4m637ih5fmBMnXZMN+2esSvIzBNXxI=; Received: from ip6-localhost ([::1] helo=mail.ctemplar.com) by mail.ctemplar.com with esmtp (envelope-from ) id 1mNAWw-00013h-GH; Mon, 06 Sep 2021 09:03:07 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "pool2win" To: eric@voskuil.org, bitcoin-dev@lists.linuxfoundation.org, billy.tetrud@gmail.com Date: Mon, 06 Sep 2021 09:03:06 -0000 In-Reply-To: <944064B6-B9CC-4325-ADA7-22B786A80A3B@voskuil.org> References: <20210906075430.hk44gaueu3njdkl3@ganymede> <944064B6-B9CC-4325-ADA7-22B786A80A3B@voskuil.org> Message-Id: <3b2fd0d3066c4f649e9a398a73ee5ded-kohli@ctemplar.com> Feedback-ID: a29obGlAY3RlbXBsYXIuY29t:ctemplar X-Mailman-Approved-At: Mon, 06 Sep 2021 09:51:33 +0000 Subject: Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 09:03:14 -0000 I see Braidpool as an improvement to P2Pool - i.e. make a peer to peer pool work at scale. This is in contrast to Stratum v2, which brings some very good and much needed engineering improvements to centralised pools. Specifically about transaction selection in Stratum V2, as far as I understand, the pool still controls both accepting the proposed block and also as Eric says, they still could refuse payouts. Here's a quote from the Stratum V2 docs[1]: "The name Job ‘Negotiation’ Protocol is telling, as job selection is indeed a negotiation process between a miner and a pool. The miner proposes a block template, and it is up to a pool to accept or reject it." As David says, a miner is free to hop pools, but generally pool hopping can be detrimental to a pool [2]. Further still, the immediate payouts to miners will work if they opt for PPS. But most centralised pools still use PPLNS(*) or equivalent. I'd like to highlight an additional problem with centralised pools using PPLNS. These pools are opaque, at least to smaller miners, who can't view the shares received by the pool. Miners are forced to simply trust centralised pools to be honest and compute rewards fairly. A bug in their share tracking or reward calculation protocol could go unnoticed for a long time. With Braidpool you get: 1. Transparent view of the shares received by the pool - thus have the ability to verify reward calculation, even with a PPLNS like scheme. This is the same advantage as P2Pool. 2. Payouts over one-way channel, so we don't consume block space for miner rewards payouts. This is different from P2Pool. 3. Using the transparent view of shares, we can build delivery of such shares to market makers providing futures contracts for hashrate. This is nigh impossible with opaque centralised pools. 4. We prepare for any attacks on centralised mining pools in the future - which we want to keep as the central aim of Braidpool. All the other advantages attract miners to Braidpool now, while preparing our defense against future attacks. [1] Stratum V2: https://braiins.com/stratum-v2 [2] Analysis of Bitcoin Pooled Mining Reward Systems: https://arxiv.org/abs/1112.4980 (*) Starting a new PPS based pool requires a lot of funds. The probability of bankruptcy for pools providing PPS is pretty high. ---------- Original Message ---------- On Mon, September 6, 2021 at 8:01 AM, David A. Harding via bitcoin-dev wrote: On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote: > It doesn’t centralize payment, which ultimately controls transaction selection (censorship). Yeah, but if you get paid after each share via LN and you can switch pools instantly, then the worst case with centralized pools is that you don't get paid for one share. If the hasher sets their share difficulty low enough, that shouldn't be a big deal. I'm interested in whether braidpool offers any significant benefits over an idealized version of centralized mining with independent transaction selection. -Dave _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev