Date: Sat, 11 Sep 2021 01:09:30 +0000
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
Precedence: list

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