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 86BBD2419
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Jul 2019 11:07:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 707A4E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Jul 2019 11:07:22 +0000 (UTC)
Date: Sat, 20 Jul 2019 11:07:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1563620839;
bh=1+Yb/6Hv0UCvwUQvzxyZLduvqLEfFLh2uCyK9imvI3o=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=SBHLU/7Slfcii9RocFMWbxaFoa5EQLdfjPqwW0+t2Qp/zk8wruKM3MgwvAgZisES9
SjnFOSQdlF9lSnHrW23IH4EkOQhtNaxmZIU3FnFmV1Q6PNSnDF+PhgMBDNUa9mNIpX
6NotJjWToLo3eFZ+z9loluMAoNVa5UDZbhgg2MZk=
To: "Kenshiro []" <tensiam@hotmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <LDVRsI_WqicA9u8WYrBo71H0Xkw7FgwZbjvkWCh_aycSY2awgRdlYsoba2Vf0cRLiye3Sh5ISR2pVI1mUcceVDP0sLukRbrEgYM3ngIza9o=@protonmail.com>
In-Reply-To: <DB6PR10MB1832F6395C1E6337FD896235A6CA0@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>,
<-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com>
<DB6PR10MB1832C21C602126F797132A4AA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
<hv2EyhKHfNd-TmH2j-8jLFWw6nUMYHOsNF_5Vy-eZLQLessR9Quy4uXn8ZVYLK4dZrwcVq3QeCcEXdCHPOJ0tgya5P34S1seEAGSRyPYpks=@protonmail.com>
<DB6PR10MB1832EF2ACF6539E03494A381A6CB0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
<zs4_imeOmpTHJLNyl90kuY8HWoLEjgmCcims6fESt2Fg5goLfUdcKdcPIsKCWRfojPifaNfg5XKi24fwAIRW_LUnAz-yzwOA6S362R4g5RA=@protonmail.com>
<DB6PR10MB1832F6395C1E6337FD896235A6CA0@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: Sat, 20 Jul 2019 11:48:36 +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: Sat, 20 Jul 2019 11:07:23 -0000
Good morning Kenshiro,
>
> >>>=C2=A0For example, if you are capable of disrupting a coin such that i=
ts value is very likely to drop, you can buy short options as leverage.
> Suppose you hold a large stake of coins and know you control a significan=
t fraction, enough that a censorship attack by you will be so disruptive th=
at the coin price will drop.
> You take out a short contract with the contract price at the "hopium" lev=
el others have (say 10% higher), buying enough options that you can cover t=
he current price of your owned stake, plus some more options.
> Suppose you buy, a number of options equal to twice your stake.
>
> Thank you for the explanation, I understand it now. But what percent of B=
TC trades are short options? If everyone is doing short options, the attack=
is very dangerous as you say, but if only a small percent of trades is don=
e in short options, then it's not a big problem.=C2=A0
It is immaterial, because this is just *one* possible economic attack.
Further leverage can always be had as Bitcoin does not exist in isolation.
>
> And this type of attack could also be done in PoW by evil miners. It's on=
ly one step more, they have to purchase a lot of BTC before the attack, buy=
many short options and execute the attack. Purchasing 50% of BTC is a prob=
lem because of the price, but that's the same for PoW or PoS.
Miners cannot feasibly take over 50% of energy sources in the world.
>
> >>>=C2=A0Let's suppose there are two big whales in your coin.
> Each of them owns 50% of the total staked value.
> Let's say "wait many blocks" parameter is 100 blocks.
>
> >>>One whale puts all his coin in a single UTXO.
> The other has distributed his stake in 100,000 different UTXOs.
>
> I think there is a misunderstanding here, you forgot to divide the 50% st=
aking weight of the evil whale by 100.000.
No, you have a misunderstanding of your ***own*** system.
You forgot that you indicated that a staking UTXO is banned from adding a n=
ew block for "wait many blocks", as you indicated.
Thus it is immaterial that each tiny stake of the evil whale is tiny: only =
the tiny stakes of the evil whale are in play during the time that the sing=
ular big UTXO by the honest whale is banned.
Thus it has 100% of the stake during those 100 blocks.
The honest whale gets 1 block (with very high probability) and then the evi=
l whale gets the rest of the blocks for 100 blocks.
?Now again, consider that the situation indicates that there are in fact on=
ly two actual stakers, each of whom have 50% of the staked funds, thus ther=
e are no other stakers (even though the evil whale appears to be multiple s=
eparate stakers) because 50% + 50% =3D 100%.
I did indicate "each of them owns 50% of the total staked value", did I not=
?
The rest of your counterargument ***completely forgets*** this, so I will i=
gnore it.
A whale composed of many tiny fishes is still a whale.
It is immaterial that there may exist many small stakers who individually c=
an overpower a tiny stake of the evil whale: the evil whale will still domi=
nate during those times that the honest whale is banned because of your add=
itional rule that "a staker who creates a block is banned from creating ano=
ther block for many blocks": the evil whale simply dominates from having ma=
ny tiny stakes, each of which can be banned with little effect on the actua=
l power of the evil whale over the coin.
> >>>=C2=A0We already know that miners are setting up mines at locations wh=
ere energy is being wasted (e.g. oil well gas flares, putting up solar pane=
ls instead of just letting sunshine pointlessly heat up their roofs, etc.),=
and channeling the wasted energy into productive activity.
>
> I'm sure a big percent of mining will be done in this way, but if there i=
s still dirty energy like nuclear energy or others is because we can't get =
all the energy we need from clean sources (and that's excluding bitcoin min=
ing). So even being very optimistic about bitcoin mining, it will steal cle=
an energy sources from other human needs which will make us keep using dirt=
y energy. So PoW makes use dirty energy sources in a direct or indirect way=
.
It is immaterial: what matters is the economics.
Dirty energy is dirty because it causes damage to the economy by creating s=
ickness and preventing people from surviving long lives and producing for t=
he economy, destroys ecology and reduces biodiversity (and many products ar=
e derived from the variety of lifeforms available) and so on.
Thus, all energy uses will inevitably move towards cleaner energy sources a=
s competition arises.
>
> >>>=C2=A0Thus, adding more rules is rarely the optimal thing to do.
>
> Proof of Stake is more complex than PoW, so you need to add a few more ru=
les. Of course the rules must be well designed and tested, but as I explain=
ed above there is no problem with the extra rule of giving a great increase=
in staking weight to coins together in a single UTXO, because there is wai=
t time for each staking deposit.
You have demonstrated no such thing, merely demonstrated your own willful i=
ncompetence in designing protocols.
I will no longer respond.
Regards,
ZmnSCPxj
|
