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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 29A26D30
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jul 2019 08:11:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7FA6363D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jul 2019 08:11:36 +0000 (UTC)
Date: Wed, 17 Jul 2019 08:11:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1563351094;
bh=uAOEsJFGdtHWBlhViEgvleKVXm22DFi8DAX2YB0UAkc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=OFNkUwtmYWu2jjnTZAAAVlBhwIbi+3l2CWOOHja1CkCxJv0KmtUytfnMZB3T69wbg
8ONikbE8akpSC8vG1a9EPiXdWPrKwi9XlhLgeblsm73dYQCql1ANhM02tk042nDniF
NkyQ5HZ2HEpMKScDtKs6/upDzy0mXlFDCmr9cmsE=
To: "Kenshiro \\[\\]" <tensiam@hotmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <D-LJd2MDCfyPvBy7Px7FFjsh6ZrD2fmCCZ66tKQEMpBf5VEJ2RTh6GsE24uu4ow4bD_O-a_vyZh6qLaWOJIpkfO4EzOKbvO_xW5Bwjf_yPI=@protonmail.com>
In-Reply-To: <DB6PR10MB1832257D676DDA7B4F55E658A6CE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
<CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
<DB6PR10MB1832257D676DDA7B4F55E658A6CE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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, 17 Jul 2019 08:22:45 +0000
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
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: Wed, 17 Jul 2019 08:11:37 -0000
Good morning Kenshiro,
> 4 - In any given block, only one staker gets the authorization to create =
that block, so other stakers can't spam the network with many different blo=
cks as they are illegal.=C2=A0
This leaves the consensus algorithm liable to stake-grinding attacks.
Often, the selection of the "single staker" for each block is based on some=
hashing of some number of the previous headers.
This allows the single staker to do some trivial grinding of the `R` of som=
e signature of some transaction of some money from itself to itself.
This grinding is likely to change the hash of the current block.
Changing the hash of the current block is enough to change the hash that is=
used in the selection of the **next** single staker.
Note that the staker will of course only publish the version of that block =
that makes itself the **next** staker.
This is the well-known stake-grinding attack; did you not encounter it in y=
our proof-of-stake research?
This is a basic objection to proof-of-stake, together with the nothing-at-s=
take.
Suppose the staker owns 49% of the staked funds.
It is now trivial for it to continuously grind so that it is again the next=
staker for the next block, as 49% of the time, it would be selected as the=
next staker.
Further, this is easily hideable, as the staker can simply run 100000 maste=
rnodes and split its funds to all of them, so that it becomes very non-obvi=
ous that there is in fact only one staker running the entire network.
(Did you consider how much energy such a staker would be willing to spend o=
n grinding so that it remains the next staker forevermore?
In particular, the staker would be willing to spend energy up to the block =
reward in such grinding --- a property that proof-of-work has, and ***openl=
y*** admits it has.)
In particular, this allows that one staker to impose any censorship it like=
s.
Thus, Bitcoin cannot support any kind of proof-of-stake that is vulnerable =
to this stake-grinding attack.
Regards,
ZmnSCPxj
|
