Return-Path: <ZmnSCPxj@protonmail.com> Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id EE429C000D for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <fmerli1@gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <pqkX9ft1aIX7oRHcgAL2jxwO1VZlnSpWrwNiwhD0ru_-zH9LpQbc5008jmR3dg_z0q_k5zwCQPrhPryLRIYP7aUn8EvjpSeX7zfMztLsfzs=@protonmail.com> In-Reply-To: <CAO1K=nnGXasdu_M4NgCkcCFMB16sW5r-Xd462d6jfR9mBBCgSA@mail.gmail.com> References: <MiuahdA--3-2@tutanota.de> <ceFmn7ZHyPHN70rDuE66lnPEwjgjQ7LtZLwyFgIVUpPvPDvSZSsLHUf_yiBvXTpjdEju4UxAOnDgilZaQAMvQzYcUbOkZsYvOIpuBG7japo=@protonmail.com> <edbbb44e247d4e639659e1b9b989dd84-kohli@ctemplar.com> <CAO1K=nnGXasdu_M4NgCkcCFMB16sW5r-Xd462d6jfR9mBBCgSA@mail.gmail.com> 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 <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: 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