From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D745EC000D for ; Wed, 8 Sep 2021 10:03:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id D1587401AF for ; Wed, 8 Sep 2021 10: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: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=ctemplar.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECfqvRr1FLAx for ; Wed, 8 Sep 2021 10:03:13 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 6B90B4016F for ; Wed, 8 Sep 2021 10:03:13 +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=joZQ63A2TeYf5RHT/ljpNXWbWYFpf1h2Ibb6ijJRvz0=; b=tfqTIpeWQKG2cHAULiTQrV/Gp0 CioI/noIOqRLhyWO/ob+a7y7VZZEJ+wVv91OyeJfQ4rTpfiCD3KqJsXdHrmq1zJeevbXCQ8KHSD5I M9gAAqF2zav01kfdMR/WHCPyZ5BKwDhiLXwnbwEC4TQSSDVy1+84wC3eB1f2f2WjfFsQ=; Received: from ip6-localhost ([::1] helo=mail.ctemplar.com) by mail.ctemplar.com with esmtp (envelope-from ) id 1mNuQ5-0007kO-EZ; Wed, 08 Sep 2021 10:03:08 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "pool2win" To: zmnscpxj@protonmail.com, bitcoin-dev@lists.linuxfoundation.org Date: Wed, 08 Sep 2021 10:03:05 -0000 In-Reply-To: References: Message-Id: Feedback-ID: a29obGlAY3RlbXBsYXIuY29t:ctemplar X-Mailman-Approved-At: Wed, 08 Sep 2021 11:14:54 +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: Wed, 08 Sep 2021 10:03:14 -0000 > A thing I just realized about Braidpool is that the payout server is still a single central point-of-failure. > However, this probably complicates the design too much, and it may be more beneficial to get *something* working now. You have hit the nail on the head here and Chris Belcher's original proposal for using payment channels does provide a construction for multiple hubs [1]. In the Braidpool proposal however, the focus is on a single hub to describe the plan for an MVP. Decentralising hubs is the end goal here, and either Belcher's multiple hubs construction or a leadership election based construction along the lines you propose might be a good way forward. Belcher's idea has the added advantage that the required liquidity at each hub is reduced as more hubs join, with the cost that in case of a hubs defecting, it takes longer for miners to do cascading close on channels to all hubs. TBH, it might be a cost worth paying in the absence of better ideas. But as braidpool is built, more ideas will be appear as well. [1] Payment Channel Payouts: An Idea for Improving P2Pool Scalability: https://bitcointalk.org/index.php?topic=2135429.0 ---------- Original Message ---------- On Tue, September 7, 2021 at 11:39 PM, ZmnSCPxj via bitcoin-dev wrote: Good morning all, A thing I just realized about Braidpool is that the payout server is still a single central point-of-failure. Although the paper claims to use Tor hidden service to protect against DDoS attacks, its centrality still cannot protect against sheer accident. What happens if some clumsy human (all humans are clumsy, right?) fumbles the cables in the datacenter the hub is hosted in? What happens if the country the datacenter is in is plunged into war or anarchy, because you humans love war and chaos so much? What happens if Zeus has a random affair (like all those other times), Hera gets angry, and they get into a domestic, and then a random thrown lightning bolt hits the datacenter the hub is in? The paper relies on economic arguments ("such an action will end the pool and the stream of future profits for the hub"), but economic arguments tend to be a lot less powerful in a monopoly, and the hub effectively has a monopoly on all Braidpool miners. Hashers might be willing to tolerate minor peccadilloes of the hub, simply to let the pool continue (their other choices would be even worse). So it seems to me that it would still be nicer, if it were at all possible, to use multiple hubs. I am uncertain how easily this can be done. Perhaps a Lightning model can be considered. Multiple hubs may exist which offer liquidity to the Braidpool network, hashers measure uptime and timeliness of payouts, and the winning hasher elects one of the hubs. The hub gets paid on the coinbase, and should send payouts, minus fees, on the LN to the miners. However, this probably complicates the design too much, and it may be more beneficial to get *something* working now. Let not the perfect be the enemy of the good. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev