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