1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
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
|
