From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id EE429C000D for ; Sat, 11 Sep 2021 01:09:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id D75BE40691 for ; Sat, 11 Sep 2021 01:09:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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=protonmail.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 ApUwGmY7J7aA for ; Sat, 11 Sep 2021 01:09:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp2.osuosl.org (Postfix) with ESMTPS id 158F44020B for ; Sat, 11 Sep 2021 01:09:38 +0000 (UTC) Date: Sat, 11 Sep 2021 01:09:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1631322576; bh=0I/vxbQWR9kqg9LaF/5P6luaudtj93pWEacT2G8CQjI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=VQjAU9zy0tL0GbO3doHlRyFBCvYmBGUEt52ZAQMyM7Ran96StbKK+2+sMltjEY64Q LHXw0g+iLp0ed53p6GhncCUKCwfxEEIWeXTVA5Z+HfaFSwPVb7kGyDseg4jQxXFOgf 0oK4Vw6AzJUh33pk27KT9unekfmKur0jqoeOrDmM= To: Filippo Merli , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 11 Sep 2021 01:09:41 -0000 Good morning Filippo, > Hi! > > From the proposal it is not clear why a miner must reference other miners= ' shares in his shares. > What I mean is that there is a huge incentive for a rogue miner to not re= ference any share from > other miner so he won't share the reward with anyone, but it will be paid= for the share that he > create because good miners will reference his shares. > The pool will probably become unprofitable for good miners. > > Another thing that I do not understand is how to resolve conflicts. For e= xample, using figure 1 at > page 1, a node could be receive this 2 valid states: > > 1. L -> a1 -> a2 -> a3 -> R > 2. L -> a1* -> a2* -> R > > To resolve the above fork the only two method that comes to my mind are: > > 1. use the one that has more work > 2. use the longest one > Btw both methods present an issue IMHO. > > If the longest chain is used: > When a block (L) is find, a miner (a) could easily create a lot of share = with low difficulty > (L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real = hashrate (L -> a1 -> a2) > and publish them so they get referenced. If someone else finds a block he= gets the reward cause he > has been referenced. If he finds the block he just attaches the funded bl= ock to the longest chain > (that reference no one) and publishes it without sharing the reward > (L -> a1* -> a2* -> ... -> an* -> R). > > If is used the one with more work: > A miner that has published the shares (L -> a1 -> a2 -> a3) when find a b= lock R that alone has more > work than a1 + a2 + a3 it just publish (L -> R) and he do not share the r= eward with anyone. My understanding from the "Braid" in braidpool is that every share can refe= rence more than one previous share. In your proposed attack, a single hasher refers only to shares that the has= her itself makes. However, a good hasher will refer not only to its own shares, but also to s= hares of the "bad" hasher. And all honest hashers will be based, not on a single chain, but on the sha= re that refers to the most total work. So consider these shares from a bad hasher: BAD1 <- BAD2 <- BAD3 A good hasher will refer to those, and also to its own shares: BAD1 <- BAD2 <- BAD3 ^ ^ ^ | | | | | +------+ | +-----+ | | | | +--- GOOD1 <- GOOD2 <- GOOD3 `GOOD3` refers to 5 other shares, whereas `BAD3` refers to only 2 shares, s= o `GOOD3` will be considered weightier, thus removing this avenue of attack= and resolving the issue. Even if measured in terms of total work, `GOOD3` also contains the work tha= t `BAD3` does, so it would still win. Regards, ZmnSCPxj