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
164
165
166
167
168
169
170
171
172
173
|
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 451B0142B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jul 2019 14:15:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9EE271C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jul 2019 14:15:13 +0000 (UTC)
Date: Thu, 18 Jul 2019 14:15:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1563459311;
bh=yIIAIrse/qcs/+ixQDE3+ABZ4wPcXzGlfw1+ci3GL1s=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=ezegondKFQGkkevlmcsn4ow8MgfUcVwEGM/hJbk2iku8HjKwuYkZ1vZA0StcPn35U
s//6oL6Edj5w0VI/RKpb7ugO5b2u5yUK6fngrnvovG9dF7x13tKFrUN28HuMQV9dva
+3XPzO8iAc8jfFxO/t9Jy4FGqtHFTEV+vJ5DZFzA=
To: "Kenshiro []" <tensiam@hotmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com>
In-Reply-To: <DB6PR10MB183268A7D3C744B1269E46EAA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
<DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
<207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>,
<brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
<DB6PR10MB183268A7D3C744B1269E46EAA6C80@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: Thu, 18 Jul 2019 15:21:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 18 Jul 2019 14:15:15 -0000
Good morning,
> I think there is some misunderstanding here. A single node can be isolate=
d from the rest of the network any time and when it reconnects it only has =
to follow the longest chain as always. Checking with a block-explorer or a =
friend's node is only required under the extreme situation of being under a=
51% attack, but that is also a problem for Proof Of Work. Both protocols r=
equire manual intervention:
>
> -PoS: Burn the funds of the attacker with a hard fork
> -PoW: Change the PoW algorithm with a hard fork
Again: under proof-of-work, 51% attacks are a lot less feasible than under =
proof-of-stake.
You really should have researched this by this point, but in any case.
The primary source of energy on Earth is the formation of the solar system.
Some areas were seeded with radioactive materials.
Later on, some areas were seeded with carbohydrates from dying biological p=
rocesses.
Regardless, continuously the sun shines upon the just and unjust alike.
Thus, while there is significant variance in energy availability, it is sti=
ll reasonably spread out.
A 51% attack under proof-of-work is only possible, in general, if some sing=
ular entity were able to have physical control of almost 50%, or some such =
close number, of the globe, simply due to the fact that energy availability=
is somewhat distributed over the globe.
Looking into latest human political maps, I cannot find any singular entity=
that can claim this.
Secondly: change of hashing algorithm is pointless in the highly unlikely c=
ase of a 51% attack, because what matters is control of energy sources.
In case of hashing algorithm change, the exact same sources of energy can b=
e utilized with whatever hardware is most efficient, and distribution of ha=
shpower will still be the same.
The fact that proof-of-work is strongly bound to physical limitations is a =
feature, not a bug.
Economic incentives imply simply that market forces will move hashpower tow=
ards efficient usage.
Nothing can be more efficient than proof-of-work, and the proof-of-stake de=
lusion is simply a perpetual motion machine that attempts to get something =
from nothing.
>
> The other extreme situation would be if the network or internet itself is=
splitted more than N blocks. If that happens, it should require manual int=
ervention to merge both chains. But in PoW it's much worse because the long=
est chain wins and it erases all history of the losing chain. Are you sure =
that's better? All transactions of one day (or more) could be erased foreve=
r.
Yes, that is better.
You must understand that removing the chain tip puts the transactions in th=
at block back in the mempool, before we ever start following the longer cha=
in.
Thus, transactions on the shorter chain will simply find themselves in the =
mempool waiting to be confirmed again.
Of course, they are still subject to replacement since they become unconfir=
med, and there is still some risk involved.
> >>>To expand on this: by censoring ***all*** transactions one is able to =
prevent spending of all funds.
> This will crash the value of the staked funds also, but note that the sta=
ker could use techniques like short options to leverage this and potentiall=
y earn more than the value of their staked funds, effectively stealing the =
entire marketcap of the attacked coin.
>
> Yes but I think this can be solved in PoS, because there should be only 2=
possible cases:
>
> 1 - The attacker doesn't stop making blocks in the main chain an he only =
censors transactions in his blocks: in this case, there is always some hone=
st block so he can only slow the network
> 2 - The attacker does a 51% attack stopping doing blocks in the main chai=
n, so the longest chain is his "private" chain which only has his blocks: t=
hen he can censor every transaction, but that attack is very evident and a =
hard fork could burn his funds.
Do note the comment of "political money".
Hard forks are very difficult to coordinate as the user set increases in si=
ze.
>
> >>>=C2=A0Aside from that, this is possible to evade by running 10000 mast=
ernodes and splitting your staking funds among them.
>
> It's possible to give more staking weight to coins together in a single a=
ddress than splitted coins like with this formula (or some improved version=
)
>
> stakingWeight =3D numberOfCoins ^ 1000
This solution is worse than the problem, and speeds up the dominance of lar=
ge stakers over the coin, trivially letting someone with the largest stake =
in the coin grow their stake even faster.
> >>>=C2=A0Another thing is that Ethereum itself is going to PoS next year,=
but with a different implementation that I'm proposing here.
>
> >>>Just another nail in the coffin.
>
> Do you think Ethereum PoS will fail?
>
No, I think it will be very successful in ensuring that smart individuals w=
ill spend their time actually doing things that benefit the economy and tec=
hnology instead of wasting their time being distracted with Ethereum and pr=
oof-of-stake.
Regards,
ZmnSCPxj
|
