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
|
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 1AB6CEA5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 23:00:13 +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 CE1FD886
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 23:00:10 +0000 (UTC)
Date: Tue, 16 Jul 2019 23:00:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1563318008;
bh=3V4Wdr+aB+mt0BUbgPSMMVCXiBawTjTxkR54I0jua0Y=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=bc96g9Us+CwBq5qfzWhTEfX7M8itJv54usc5jqv1TkWb1nzXO9z2bAgvlGIcgflka
wjqkPlMZRQ1cek9XZ+TRPPC7valY12NepSZQP9ov4+ECf1RBH37ItITUaA4W4tlvCi
AL12SNF9B3s/K4GVGKixVEheBhI841xkO0m/VusI=
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: <Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
In-Reply-To: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@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 07:52:04 +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: Tue, 16 Jul 2019 23:00:13 -0000
Good morning Kenshiro,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
> Hi,
>
> After studying several Proof of Stake implementations I think it's not on=
ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite att=
acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen=
ts are required:
Under the trust-minimization and uncensorability requirements that Bitcoin =
has, nothing is more efficient than proof-of-work.
The very idea of proof-of-stake labors under the assumption that unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get something for nothing.
Please re-examine your assumptions.
> - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul=
d include a hardcoded checkpoint with the hash of the current block height =
in that moment. This simple measure protects the blockchain up to the last =
checkpoint, and prevents any Long-Range attack.
While this is a developer list and made up of developers who would be quite=
incentivized to agree to such a setup, note that this effectively trusts t=
he developers.
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le it, but I believe your "hardcoded checkpoints" cannot be disabled, much =
less disabled-by-default.
> This extra rule could be connecting to a block explorer to download the h=
ash of the current block height, or ask some trusted source like a friend a=
nd enter the hash manually. After being fully updated, the user can always =
check that he is in the correct chain checking with a block explorer.
Under the trust-minimization requirement of Bitcoin this is simply not acce=
ptable.
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
algorithm.
>
> Someone could have 99% of the coins and still would be unable to use the =
coins to do any history rewrite attack. The attacker could only slow down t=
he network not creating his blocks, or censor transactions in his blocks.
History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor=
on the creation of new blocks.
Censorship attacks cannot be prevented except by ensuring that no single en=
tity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlik=
ely to keep a transaction out of the blockchain, and in particular that no =
entity can make a short-ranged history rewrite if a censored transaction *d=
oes* get into the blockchain from the efforts of another block producer.
This is trivial under proof-of-work, and is the cost we accept in order to =
achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some sin=
gle entity controls >51% of stakeable coins, and thus has no way to protect=
against censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.
Depending on the PoS implementation, stake-grinding may allow a 49% staker =
to achieve 51% and thereby the ability to censor transactions.
Regards,
ZmnSCPxj
|
