path: root/5e/af8717bbd47293b350475174f052a874036e9d

Return-Path: <fmerli1@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D70ADC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Sep 2021 07:55:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B55F3406B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Sep 2021 07:55:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.852
X-Spam-Level: 
X-Spam-Status: No, score=0.852 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3hhT5YQRHABI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Sep 2021 07:55:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com
 [IPv6:2607:f8b0:4864:20::12f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 973C74068C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Sep 2021 07:55:10 +0000 (UTC)
Received: by mail-il1-x12f.google.com with SMTP id a1so4551748ilj.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Sep 2021 00:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Bkw+ZYx6iIT+Sm5oqwFmhZ6xsMo+TD2qX1iCvj+1nfI=;
 b=bxSrQIeKTi5B/GT7/D/uB5FM6zCu8vCM5njhmbDvLUgYbfSN+aIon7xVyHfcYwlBrV
 KshkGdQZoVLuBf3rv/Vrr8wdTYA7WihSjSmvGAN7WniWGs9YdlEfaJcDKj1KEPbGatoM
 tbRP3ZRxC86vb+vMoFYDhIJTUQ1zR2ND3py24u+ytEwxXQ/Lt9jDfciYP+2fg3r8QkFY
 slx6zEz74jOozZs9b3im8vWEywnvPvp2Dk3no/plrfpd7mr82zObhXQK9vQvmdz5+9YE
 FXNb5CGfr/uzizqwD85yK0+j/Su0VG4clyrYk8GgLgF+3rmXXHEdmtOuYuRBMX446sz1
 WJhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=Bkw+ZYx6iIT+Sm5oqwFmhZ6xsMo+TD2qX1iCvj+1nfI=;
 b=pTLhIYPoQHnQPo3M3bJHg/KjO2xgkCEz7/oN5AMDdayYE/n4BlfhDz7AEJvs/Vw0c6
 ysWKrzVdGN4O5O5m/eq89vgz5B3P+07zi3eoijzY8ZSa2ow9zuvEE9H80El2yhJ98oda
 yJsIVqRXR6s33+9VHCAJrxLm/baCN4K8wsu1SJ5Eeem8AAyw62++L0dEgDclgGgnUu0B
 phOn8KPbbt8OVHeAckiCf4FOYK6OLPcSkDQEqVSh8SAQkPyeqaRzWH3P0HyTxh11Sl1z
 xAqK3WzU45FNwBUqhBO/QuIJtkmVmwgMwPp9B0e0y50BjeClviJmU8uKtZBlNkq4Kj3a
 2Q6A==
X-Gm-Message-State: AOAM532igqnLHkC2TFUEen+qFPYy4d9mUpRcXSqN6Aj0mcELXIuant+W
 E7hFdwfdVZ7rdHRuIZWh+Y2dauzfH/YRVF+6+J4ET9pl
X-Google-Smtp-Source: ABdhPJxldvlJN2aomIHFhJ+pzOjzo41CVGm/NVsWyW1QkKDUVzdhOCAtLqA71y6mqGHyIdEl6AAYS0VUfCaT1lNvlwk=
X-Received: by 2002:a92:d848:: with SMTP id h8mr1128506ilq.230.1631346909540; 
 Sat, 11 Sep 2021 00:55:09 -0700 (PDT)
MIME-Version: 1.0
References: <MiuahdA--3-2@tutanota.de>
 <ceFmn7ZHyPHN70rDuE66lnPEwjgjQ7LtZLwyFgIVUpPvPDvSZSsLHUf_yiBvXTpjdEju4UxAOnDgilZaQAMvQzYcUbOkZsYvOIpuBG7japo=@protonmail.com>
 <edbbb44e247d4e639659e1b9b989dd84-kohli@ctemplar.com>
 <CAO1K=nnGXasdu_M4NgCkcCFMB16sW5r-Xd462d6jfR9mBBCgSA@mail.gmail.com>
 <pqkX9ft1aIX7oRHcgAL2jxwO1VZlnSpWrwNiwhD0ru_-zH9LpQbc5008jmR3dg_z0q_k5zwCQPrhPryLRIYP7aUn8EvjpSeX7zfMztLsfzs=@protonmail.com>
In-Reply-To: <pqkX9ft1aIX7oRHcgAL2jxwO1VZlnSpWrwNiwhD0ru_-zH9LpQbc5008jmR3dg_z0q_k5zwCQPrhPryLRIYP7aUn8EvjpSeX7zfMztLsfzs=@protonmail.com>
From: Filippo Merli <fmerli1@gmail.com>
Date: Sat, 11 Sep 2021 09:54:58 +0200
Message-ID: <CAO1K=nmhhMuisAXdddC1OSDUP2q8XsQjAUO4CVnyx8+BBvvwTw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000c74cb05cbb38d15"
X-Mailman-Approved-At: Sat, 11 Sep 2021 08:04:00 +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 <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 07:55:12 -0000

--0000000000000c74cb05cbb38d15
Content-Type: text/plain; charset="UTF-8"

From my understanding of the posted proposal, a share to get rewarded must
"prove" to be created before the rewarded share. (between L and R)
If GOOD3 refers to BAD2 the only thing that I can prove is that BAD2 has
been mined before GOOD2.

So if  BAD3 is a valid block (I call it R like in the pdf) the only thing
that I can certainly know is that between L and R there is BAD1 and BAD2
and they should be the ones that get the rewards.
Btw rereading the proposal I'm not sure about how the rewards are
calculated, what let me think that is the way that I illustrate above is
the figure 2: c3 is referring to a3 but is not included in the first reward.

To clarify I'm talking about two things in my previous email, the first one
is: what if a bad miner does not refer to good miners' shares?
The second thing is: what if a bad miner publishes two (or more)
conflicting versions of the DAG?


On Sat, Sep 11, 2021 at 3:09 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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
> reference 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
> example, 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
> block 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
> block R that alone has more
> > work than a1 + a2 + a3 it just publish (L -> R) and he do not share the
> reward with anyone.
>
>
> My understanding from the "Braid" in braidpool is that every share can
> reference more than one previous share.
>
> In your proposed attack, a single hasher refers only to shares that the
> hasher itself makes.
>
> However, a good hasher will refer not only to its own shares, but also to
> shares of the "bad" hasher.
>
> And all honest hashers will be based, not on a single chain, but on the
> share 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,
> so `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
> that `BAD3` does, so it would still win.
>
> Regards,
> ZmnSCPxj
>
>

--0000000000000c74cb05cbb38d15
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>From my understanding of the posted proposal, a share=
 to get rewarded must &quot;prove&quot; to be created before the rewarded s=
hare. (between L and R)<br></div><div>If GOOD3 refers to BAD2 the only thin=
g that I can prove is that BAD2 has been mined before GOOD2. <br></div><div=
><br></div><div>So if=C2=A0 BAD3 is a valid block (I call it R like in the =
pdf) the only thing that I can certainly know is that between L and R there=
 is BAD1 and BAD2 and they should be the ones that get the rewards.</div><d=
iv>Btw rereading the proposal I&#39;m not sure about how the rewards are ca=
lculated, what let me think that is the way that I illustrate above is the =
figure 2: c3 is referring to a3 but is not included in the first reward.<br=
></div><div><br></div><div>To clarify I&#39;m talking about two things in m=
y previous email, the first one is: what if a bad miner does not refer to g=
ood miners&#39; shares?</div><div>The second thing is: what if a bad miner =
publishes two (or more) conflicting versions of the DAG?<br></div><div><br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Sat, Sep 11, 2021 at 3:09 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCP=
xj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Good morning Filippo,<br>
<br>
&gt; Hi!<br>
&gt;<br>
&gt; From the proposal it is not clear why a miner must reference other min=
ers&#39; shares in his shares.<br>
&gt; What I mean is that there is a huge incentive for a rogue miner to not=
 reference any share from<br>
&gt; other miner so he won&#39;t share the reward with anyone, but it will =
be paid for the share that he<br>
&gt; create because good miners will reference his shares.<br>
&gt; The pool will probably become unprofitable for good miners.<br>
&gt;<br>
&gt; Another thing that I do not understand is how to resolve conflicts. Fo=
r example, using figure 1 at<br>
&gt; page 1, a node could be receive this 2 valid states:<br>
&gt;<br>
&gt; 1. L -&gt; a1 -&gt; a2 -&gt; a3 -&gt; R<br>
&gt; 2. L -&gt; a1* -&gt; a2* -&gt; R<br>
&gt;<br>
&gt; To resolve the above fork the only two method that comes to my mind ar=
e:<br>
&gt;<br>
&gt; 1. use the one that has more work<br>
&gt; 2. use the longest one<br>
&gt; Btw both methods present an issue IMHO.<br>
&gt;<br>
&gt; If the longest chain is used:<br>
&gt; When a block (L) is find, a miner (a) could easily create a lot of sha=
re with low difficulty<br>
&gt; (L -&gt; a1* -&gt; a2* -&gt; ... -&gt; an*), then start to mine shares=
 with his real hashrate (L -&gt; a1 -&gt; a2)<br>
&gt; and publish them so they get referenced. If someone else finds a block=
 he gets the reward cause he<br>
&gt; has been referenced. If he finds the block he just attaches the funded=
 block to the longest chain<br>
&gt; (that reference no one) and publishes it without sharing the reward<br=
>
&gt; (L -&gt; a1* -&gt; a2* -&gt; ... -&gt; an* -&gt; R).<br>
&gt;<br>
&gt; If is used the one with more work:<br>
&gt; A miner that has published the shares (L -&gt; a1 -&gt; a2 -&gt; a3) w=
hen find a block R that alone has more<br>
&gt; work than a1 + a2 + a3 it just publish (L -&gt; R) and he do not share=
 the reward with anyone.<br>
<br>
<br>
My understanding from the &quot;Braid&quot; in braidpool is that every shar=
e can reference more than one previous share.<br>
<br>
In your proposed attack, a single hasher refers only to shares that the has=
her itself makes.<br>
<br>
However, a good hasher will refer not only to its own shares, but also to s=
hares of the &quot;bad&quot; hasher.<br>
<br>
And all honest hashers will be based, not on a single chain, but on the sha=
re that refers to the most total work.<br>
<br>
So consider these shares from a bad hasher:<br>
<br>
=C2=A0 =C2=A0 =C2=A0BAD1 &lt;- BAD2 &lt;- BAD3<br>
<br>
A good hasher will refer to those, and also to its own shares:<br>
<br>
=C2=A0 =C2=A0 =C2=A0BAD1 &lt;- BAD2 &lt;- BAD3<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0^=C2=A0 =C2=A0 =C2=A0 =C2=A0^=C2=A0 =C2=A0 =C2=
=A0 =C2=A0^<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+------+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--- GOOD1 &lt;- GOOD2 &lt;- GOOD3<br>
<br>
`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.<br>
Even if measured in terms of total work, `GOOD3` also contains the work tha=
t `BAD3` does, so it would still win.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>

--0000000000000c74cb05cbb38d15--