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
|
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 4E927E5A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jul 2019 01:13:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5052725A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Jul 2019 01:13:31 +0000 (UTC)
Date: Thu, 18 Jul 2019 01:13:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1563412408;
bh=Rcn/5BJHtUGPQYPWtN1/IB7mGvJFI1AmrR7js9x924s=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=W5S+ZAwHBeZypnM2Afge4Hg18RbI22UhknlrdBxYyhucZ3mfWbvcznKV7ojn+zSAX
aM6ycbOGN4QwKbHYY/KMipKHY/qCZaVCT3PYm1GqyKreKuxce+dHUiswIUGGPMajRB
WAHy+gTjiL39nktj9o63iEY2u1pwkPQ9tu6yvBIw=
To: Eric Voskuil <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
In-Reply-To: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>
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>
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 01:19:02 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"Kenshiro \[\]" <tensiam@hotmail.com>
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 01:13:32 -0000
Good morning all,
> > >>>Under the trust-minimization requirement of Bitcoin this is simply n=
ot acceptable.
> > As there is no way to trust-minimally heal from a network split (and ev=
ery time a node is shut down, that is indistinguishable from a network spli=
t that isolates that particular node), this is not a trust-minimizing conse=
nsus algorithm.
>
> That=E2=80=99s nonsense, one is a feature (systemic trust), the other is =
a bug (code accident). But there is a way to minimize actual forks - try no=
t to change the consensus rules in the code you ship.
I am uncertain what you mean here.
What I am attempting to compare are:
1. A network split (maybe better term is "network partition"?) wherein som=
e number of nodes are temporarily unable to contact the rest of the network=
.
This has the degenerate but very common case where a single node is tem=
porarily unable to communicate with the rest of the network.
AND
2. A node being shut down, then brought back online again.
Neither seems to match "feature" or "bug", as both are simply accidents of =
deployment.
The point (as I understand it) of a consensus algorithm is to be able to ge=
t all nodes into agreement about the global state, even after a network par=
tition.
Ideally, such an algorithm would place as little trust as possible on some =
other node, and would work even in adversarial conditions.
To my understanding, the proposal from Kenshiro is not able to get all node=
s into agreement about global state after a network partition, without trus=
t in some node, when in adversarial conditions.
> > >>> History rewrites are not the only attack possible.
> > The worst attack is a censorship attack, and a 99% staker can easily ce=
nsor on the creation of new blocks.
> >
> > I don't agree, history rewrite attacks are much worse than censorship b=
ecause they can be used to steal funds from people.
>
> Censorship can steal everybody=E2=80=99s money.
To expand on this: by censoring ***all*** transactions one is able to preve=
nt spending of all funds.
This will crash the value of the staked funds also, but note that the stake=
r could use techniques like short options to leverage this and potentially =
earn more than the value of their staked funds, effectively stealing the en=
tire marketcap of the attacked coin.
>
> > In PoS staking addresses are public, so maybe it should be possible to =
detect if some transaction in the mempool is repeatedly=C2=A0being ignored =
and what staking deposit is repeatedly ignoring transactions. After some ti=
me, a hard fork could burn the funds of the evil validator.
>
> Political money.
Aside from that, this is possible to evade by running 10000 masternodes and=
splitting your staking funds among them.
Rent from a botnet, and it appears the masternodes are geographically diver=
se.
Then it becomes hard to accuse the network of actually being controlled str=
ongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might alrea=
dy be strongly controlled, but appear "healthy" because masternodes *appear=
* geographically diverse, but in actuality are controlled by a single entit=
y)
Further, "detect if some transaction in the mempool" cannot provide a proof=
, as no construct ever precommits to the state of the mempool at a particul=
ar time (if it did, the mempool would cease to be a mempool and would be pa=
rt of the block).
I can generate a completely new transaction, then accuse the masternodes of=
censoring it.
Other nodes may not believe me, as they have not seen my transaction on the=
ir mempool, but note that the mempools of nodes are ***not*** strongly sync=
hronized.
By careful timing and control of the connectivity of the network, it become=
s possible to effectively split the consensus algorithm by showing my trans=
action to some non-masternode nodes but keeping my transaction away from ma=
sternodes, then have the non-masternode nodes accuse the masternodes of cen=
soring my transaction and hereby penalizing them.
But the masternodes would not agree, not having seen my transaction in thei=
r mempool, and thus is the network consensus destroyed.
Basically: "never base consensus rules on mempool state" is a good rule of =
thumb for ensuring that consensus can be maintained.
Consensus rules should consider only data that is committed to some block, =
and the mempool is not intended to be committed to in every block.
> > https://www.coingecko.com/en/coins/nxt
> >
> > Another thing is that Ethereum itself is going to PoS next year, but wi=
th a different implementation that I'm proposing here.
>
> Just another nail in the coffin.
I agree.
Regards,
ZmnSCPxj
|
