summaryrefslogtreecommitdiff
path: root/63/0b27a6483849332b7fa0b3c5264c86a951c1b6
blob: 7f88ccbf41f181dfe9069a2dbbe4b36debb478e6 (plain)
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
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 460A6910
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Sep 2018 23:19:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com
	[209.85.128.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FBCA716
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Sep 2018 23:19:40 +0000 (UTC)
Received: by mail-wm1-f46.google.com with SMTP id b19-v6so110986wme.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Sep 2018 16:19:40 -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=KkImIye1EdHimBHunwmOlWAKHwq7TozsCfOE/HkV+HE=;
	b=OWn5/Twn3LsZ3J+SsdCyodF13i0ucmYeMriXfSfuzexVtE11xw3ywIK9wWvFSJmVGp
	JXC5rFKdCdWGNxOswGJJnAC2V+Jh9yGzON5lkqSxTkE8cUg947PNGMvpexmmfnQr0sJy
	CCY/VF4RSU5ctuhUEp0q+kjD/c4Np4FlMi/oJuMTz1oOmorKon9gEPlFJ/uK/sqpWi9e
	WAD9db7Z3ZWwf8iXDlCCSFhJ6Z4Nm3fpDjhRDec1dembFPjQYuROj/uQg9LTA8PVoDzW
	a9ZC1Puk9nicWiM5p2lUDjSDpseBVQM/W5kFppfnY1jB1G70iJhHMKZzDE/gnFjRV1mF
	KV2Q==
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=KkImIye1EdHimBHunwmOlWAKHwq7TozsCfOE/HkV+HE=;
	b=Ng23fvQubl4EXSC0iKdeSRtLJUuk7l1B/DsRYhI+3J998kVuwr6epMlnBGyAN/MJBu
	upEwpOTBRrnFoMBxJGqL2p6Qx2Cq6Hdiwgh28ZpYHLHVB2I/py/HpvD9BYSXn7M/lJaU
	D6FSgKCMXcJaKX/IGA7Xw6P/Q5v7jaVvhA6/cYa1d0mGeN7xmFyajigvXfRz+XUST3Od
	0eGIr3UrLK9WHa+zSGBng/emfkXSXtup8M4Cyhwr38xp+AGJwncjDfY3EzYpcIkfF9JX
	r71f2Z3AWPQ2wRGnjjvADvZwyg61Wn7LZBYIL2n+XIA/CKJamtcV/8lrrzh6/b89Y2Hf
	cn7g==
X-Gm-Message-State: APzg51Ded/s4eanLND3QeKGzatY5TvKE/5ttBK2cg6LK6Gt8iZdcvHcw
	WF2Yi7iToybIPmBchoqlmzuwAiCyHZ8hy9MaS2KeJ23E
X-Google-Smtp-Source: ANB0VdbfWV2pfuaqapW0ps2Gqw0hqZamB2zcOt9PJl7j5N+HH1N8W2ETEbvjFei0OOnq5UEQvlgmT9XoinFBEniygEA=
X-Received: by 2002:a1c:1203:: with SMTP id 3-v6mr199250wms.46.1536880778504; 
	Thu, 13 Sep 2018 16:19:38 -0700 (PDT)
MIME-Version: 1.0
Sender: akaramaoun@gmail.com
Received: by 2002:a1c:e1c4:0:0:0:0:0 with HTTP; Thu, 13 Sep 2018 16:19:37
	-0700 (PDT)
In-Reply-To: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>
References: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
Date: Thu, 13 Sep 2018 23:19:37 +0000
X-Google-Sender-Auth: cjqOsUbCg1XFcpxr1jO0Ul3-RPA
Message-ID: <CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>
To: Bitcoin Dev <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 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: Fri, 14 Sep 2018 13:50:23 +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: Thu, 13 Sep 2018 23:19:41 -0000

I discussed this more at bitcointalk:
https://bitcointalk.org/index.php?topic=4998410.0

The attacks I'm interested in preventing are not only selfish mining
and collusion, but also more subtle attacks like block withholding,
and in general anything that aims to drive out the competition in
order to increase hashrate fraction. I also scrapped the idea of
changing the block subsidies, and I am only focuses on fees.

You can read more about the motivation and details in the bitcointalk
thread, but my proposal in short would be to add the concept of
"reserve fees". When a user makes a transaction, for each txout
script, they can add parameters that specify the fraction of the total
fee that is held in "reserve" and the time it is held in "reserve"
(can set a limit of 2016 blocks). This "reserve" part of the fee will
be paid to miners if the hashrate rises. So if hashrate is currently h
and peak hashrate (from past year) is p, then for each period (1 day),
a new hashrate is calculated h1, and if h1 > h, then the fraction
(h1-h)/p from the reserve fees created in the past 2016 blocks will be
released to miners for that period (spread out over the 144 blocks in
that period). And this will keep happening as long as hashrate keeps
rising, until the "contract" expires, and the leftover part can be
used by the owner of the unspent output, but it can only be used for
paying fees, not as inputs for future transactions (to save on block
space).

This should incentivize miners to not drive out the competition, since
if they do, there will be less of these reserve fees given to miners.
Yes in the end the miners will get all the fees, but with rising
hashrate they get an unconditional subsidy that does not require
transactions, thus more space for transactions with fees.

I can make a formal BIP and pull request, but I need to know if there
is interest in this. Now fees don't play such a large part of the
block reward, but they will get more important, and this change
wouldn't force anything (would be voluntary by each user), just miners
have to agree to it with a soft fork (so they don't spend from the
anyone-can-spend outputs used for reserve fees). Resource requirements
for validation are quite small I believe.

On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail.com> wrote:
> As I understand, selfish mining is an attack where miners collude to
> mine at a lower hashrate then with all miners working independently.
> What are the current strategies used to prevent this and what are the
> future plans?
>
> One idea I have is to let the block reward get "modulated" according
> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
> consisting of 144 blocks, h is the hashrate of the last 144 block (1
> day) period, and r is the base subsidy (12.5 BTC currently). You can
> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> peak you get the full reward. Otherwise you get less, down to a min of
> 0.5 r.
>
> If miners were to collude to mine at a lower than peak hashrate, then
> they may be able to do it profitably for 144 blocks, but after that,
> the reward would get modulated and it wouldn't be so much in their
> interest to continue mining at the lower hashrate.
>
> What flaws are there with this? I know it could be controversial due
> to easier mining present for early miners, so maybe it would have to
> be done in combination with a new more dynamic difficulty adjustment
> algorithm. But I don't see how hashrate can continue rising
> indefinitely, so a solution should be made for selfish mining.
>
> Also when subsidies stop and a fee market is needed, I guess a portion
> of the fees can be withheld for later if hashrate is not at peak.
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647



-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647