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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <akaramaoun@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CB59E13AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Sep 2018 20:26:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
[209.85.221.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 17AFA7D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Sep 2018 20:26:18 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id v90-v6so3490983wrc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Sep 2018 13:26:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=+easKDryOlR4AJF9SDFIPE6PM0y9sWptPanOpxSnlfY=;
b=Vfa2lOQxavXSiqtNUNJIyuOuKFiMtaMR4EPK+vb88fC96Ntxdn6q4mz+Wxc7cNe5hI
UrupRHZy5herxwMjY09HHJZqNI0OGiHsyOsUmBosj9PK5cGY9gOH4TH4MyGU1KTgAKoc
U7D/7Heuci7rfxBYMjxNBXYVWzTa0nRmx2aCePxS6v7Yi93yP1Q+SjQQmPlKlqCrJz6J
fbq/nyf/8rsnBo0viUNHOKD8TN5ub7tKlXLPtLJYcMoUbcXpGtRPWTS4J6Uu1riI2vpN
sMUN/Mtd7bgOH/28z/REdp13H4eyncHIGoqfKj1tgktpxuYi1NzTtc7JZZIZBXJxTsA6
0ABg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=+easKDryOlR4AJF9SDFIPE6PM0y9sWptPanOpxSnlfY=;
b=OmG6AzUbnckcCx/LOKQJooyli0AI8J8eoqYtU9ICYROIahKWOzfOIfW26PcgqtaJtF
rPWjnut4UxPMnVL2uYqBX9qhPR8dD79fun9Fsun63n+RcbcNDoMQz1YjAn06tM5q3o/h
5qbZNJKSWL7ciw0l1tKLy+0ZtmGc43HGckI9vtdG3wtAo8PPdcONUi6gV1YxrAmg9i2p
bD36KAXzufJVm+mqiNnNHJzIwx8Z+/Jy3RZV/Zoki0nCN4MmnVaBso/iZt/sWuQFGlJD
o4gwr+qgXMVKjs0mBDQo/txBUypZVqFhofVhA5r2Vv5zGac85d3uFFclV2KndxlDMCte
dITw==
X-Gm-Message-State: APzg51C/EIDpl0rkWhNatdnhJ8o0mT3RVMAxmwBD9fMqfySSAXMYkwkF
gNLcbI0EPkrf988n5+K+h3FpVscWFXEOmyxq3Zo=
X-Google-Smtp-Source: ANB0VdaspanYzR5W991L2JrlmvB35TeNhU6MHqlYBSt8yGDzsr5sTE8vtxlbZEjQNtUr0aOL3h3U4Oqge4qzEsPhHo0=
X-Received: by 2002:adf:ad47:: with SMTP id
p65-v6mr25359376wrc.222.1537302377531;
Tue, 18 Sep 2018 13:26:17 -0700 (PDT)
MIME-Version: 1.0
Sender: akaramaoun@gmail.com
Received: by 2002:a1c:e1c4:0:0:0:0:0 with HTTP; Tue, 18 Sep 2018 13:26:16
-0700 (PDT)
In-Reply-To: <CADtTMvmG8af1+iav6A7y14EPtSgatoGwY5Rpxunm_qLuWMasgw@mail.gmail.com>
References: <CADtTMvmG8af1+iav6A7y14EPtSgatoGwY5Rpxunm_qLuWMasgw@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
Date: Tue, 18 Sep 2018 20:26:16 +0000
X-Google-Sender-Auth: fFwcgp3JSDH5i8X6Rg9r6GBtfVw
Message-ID: <CAL8tG=mKsyN25RPVosGGp4ur_y2QiGwj+puzib2xPdPet8eOPw@mail.gmail.com>
To: Zawy <wordsgalore@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 19 Sep 2018 13:18:31 +0000
Subject: Re: [bitcoin-dev] Selfish Mining Prevention
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 18 Sep 2018 20:26:19 -0000
@ Eric: Yes I forgot to mention that cost (in addition to price) also
determines the profitability of mining and thus the total hashpower. I
disagree with your assessment of merge mining as really what matters
is opportunity cost of honestly mining vs attacking, and one reason we
are currently safe from other networks attacking is that SHA256 is
ASIC friendly and currently the main network utilising this (the
ASICs) is Bitcoin mining. It would be hard for people computing prime
numbers to quickly switch to Bitcoin mining, since they would need the
ASICs. But if you really want to discuss this then I suggest opening a
new thread here or bitcointalk since this is off-topic from my thread.
Also there is a discussion about merge mining here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html
On Mon, Sep 17, 2018 at 2:09 PM, Zawy via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The 51% problem is deep. Any discussion of a solution to it should
> begin with a link to an article that shows a profound discovery has
> been made. Selfish mining prevention and pollution should be on
> bitcoin-discussion, but it appears that list is not active.
>
> The problem with Andrew's idea below is that it is a positive feedback
> loop that amplifies oscillations. If h goes up or down due to price
> changes or random solvetime variation, then the net reward goes in the
> same direction, which motivates miners to cause h to go even further
> in the same direction, which is a positive feedback loop until some
> limit is reached. To make matters worse, miner profit motivation in
> choosing which coin to mine is a non-linear function: a 30% drop in
> difficulty (or 30% increase in this reward function) in an alt coin
> can cause a 300% increase in hashrate.
>
> Average of 144 past blocks to determine h are needed so that it does
> not vary too much. A selfish mine of 72 blocks would result in only a
> 12.5% loss compared to not using this pro-oscillation function. I've
> tried similar reward functions in trying to reduce on-off mining.
>
> There may also be a problem of issuing too many or too few coins,
> depending on how fast h rises in the long term.
>
> An alternative is to increase difficulty with this or a similar
> function instead of reward. From a miner's perspective, there is not a
> difference (they are only interested in the (price+fees)/difficulty
> ratio. This would have the same problems.
@Zawy: Are you talking about my proposal to modulate the subsidies?
Because if you read my second post you see that I scrapped that part
as it can be disruptive, and I am only proposing to let users have
more control over how their fees are spent. A certain portion of fees
is put in reserve and gets allocated to miners based on hashrate
conditions, and once the "contract" expires, the remaining part goes
back to the user for future fee payments. I understand it is unclear
whether this will cause a significant benefit (I can work on
simulations if I have time), but what could possibly go wrong with
giving users more choice over how their fees are spent?
Also if you see my post, I am not just trying to prevent Selfish
Mining (33%) or 51% attacks, but in general any types of attacks that
try to drive away mining competition (like block withholding attacks,
networking attacks, etc).
Someone on bitcointalk was also worried about a positive feedback
loop, and I think my answer remains valid:
"First, I think a price drop will be slightly offset by the lower rate
of coins being mined. Also, confirmation times will get longer: Both
the time to get a block will increase and the number of confirmations
needed to have enough work done on the chain so that your transaction
is considered safe. The fees would likely rise and this would increase
rewards to miners, especially in a fee-market dominated future." Merge
mining can also help to smooth hashrate so it doesn't depend so much
on price, but even without merge mining it is not so clear that a
there would be a destructive feedback loop and that's where
simulations / math equations would help.
Your idea of increasing difficulty, I haven't thought about much, but
I don't think it's the same effect. When you increase the difficulty,
the reward per block remains the same, only reward per real time
falls, but it could also have the negative effect of incentivizing
selfish mining or timestamp attacks to reverse the increased
difficulty. Though actually timestamp attacks would sort of be
dis-incentivized if underestimates of hashrate led to lower rewards.
Obviously I will not work on a pull request if there is no strong
interest for this. I think it is a harmless addition, so if I have
time I can work on simulations to try to prove that there is a
significant benefit with doing this.
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
|
