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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gacrux@gmail.com>) id 1WeEPo-0005SM-Ez
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Apr 2014 02:02:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=gacrux@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WeEPn-0007I6-A1
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Apr 2014 02:02:00 +0000
Received: by mail-ie0-f172.google.com with SMTP id at1so1876231iec.31
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 19:01:54 -0700 (PDT)
X-Received: by 10.50.112.167 with SMTP id ir7mr14801104igb.27.1398564113988;
Sat, 26 Apr 2014 19:01:53 -0700 (PDT)
Received: from [192.168.1.2] (60-240-212-53.tpgi.com.au. [60.240.212.53])
by mx.google.com with ESMTPSA id
rt10sm11343204igb.15.2014.04.26.19.01.52
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 26 Apr 2014 19:01:53 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <535C5BBF.30709@monetize.io>
References: <1398382335.20219.YahooMailNeo@web160503.mail.bf1.yahoo.com>
<20140425073334.GV3180@nl.grid.coop> <535C1980.7000505@monetize.io>
<bf916afe-6617-43c9-9738-486316ce308f@email.android.com>
<535C5BBF.30709@monetize.io>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Gareth Williams <gacrux@gmail.com>
Date: Sun, 27 Apr 2014 12:01:44 +1000
To: bitcoin-development@lists.sourceforge.net
Message-ID: <3b9c0704-32da-4b83-844f-7fa2d685f538@email.android.com>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gacrux[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WeEPn-0007I6-A1
Subject: Re: [Bitcoin-development] Proof-of-Stake branch?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 27 Apr 2014 02:02:00 -0000
Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof.
ie. the "coinbase confiscation" that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human judgement.
On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach <mark@monetize.io> wrote:
>That makes double-spends trivially easy: sign two blocks, withholding
>one. Then at a later point in time reveal the second signed block
>(demonstrating your own fraud) and force a reorg.
>
>On 04/26/2014 04:44 PM, Gareth Williams wrote:
>> What about using fraud proofs? Your coinbase only matures if nobody
>publishes proof that you signed a competing block.
>>
>> Then something is at least at stake. When it's your chance to sign a
>block, attempting to sign and publish more than one at the same height
>reliably punishes you (you effectively waste your chance and receive no
>reward.)
>>
>> I can't remember who I saw discussing this idea. Might have been
>Vitalik Buterin?
>>
>> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark@monetize.io>
>wrote:
>>> There's no need to be confrontational. I don't think anyone here
>>> objects
>>> to the basic concept of proof-of-stake. Some people, myself
>included,
>>> have proposed protocols which involve some sort of proof of stake
>>> mechanism, and the idea itself originated as a mechanism for
>>> eliminating
>>> checkpoints, something which is very much on topic and of concern to
>>> many here.
>>>
>>> The problems come when one tries to *replace* proof-of-work mining
>with
>>> proof-of-stake "mining." You encounter problems related to the fact
>>> that
>>> with proof-of-stake nothing is actually at stake. You are free to
>sign
>>> as many different forks as you wish, and worse have incentive to do
>so,
>>> because whatever fork does win, you want it to be yours. In the
>worst
>>> case this results in double-spends at will, and in the best case
>with
>>> any of the various proposed protections deployed, it merely reduces
>to
>>> proof-of-work as miners grind blocks until they find one that names
>>> them
>>> or one of their sock puppets as the signer of the next block.
>>>
>>> I sincerely doubt you will find a solution to this, as it appears to
>be
>>> a fundamental issue with proof-of-stake, in that it must leverage an
>>> existing mechanism for enforced scarcity (e.g. proof-of-work) in
>order
>>> to work in a consensus algorithm. Is there some solution that you
>have
>>> in mind for this?
>>>
>>> Mark
>>>
>>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>>> Do it. Someone will scream harm. The loudest voices screaming how
>it
>>> would
>>>> be harmful are doing the most harm.
>>>>
>>>> The only way to know is build it, and test it. If the network
>breaks,
>>> then
>>>> it is better we find out sooner rather than later.
>>>>
>>>> My only suggestion is call it 'bitstake' or something to clearly
>>> differentiate
>>>> it from Bitcoin. This also might be an interesting application of
>the
>>> side
>>>> chains concept Peter Todd has discussed.
>>>>
>>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>>>> Hello all.
>>>>>
>>>>> I understand that Proof-of-Stake as a replacement for
>Proof-of-Work
>>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>>> create a Bitcoin branch that provides a sandboxed testbed for
>>> researching the best PoS implementations. In the years to come,
>perhaps
>>> circumstances might arise, such as shifting of user opinion as to
>>> whether PoS should be moved from the prohibited list to the
>hard-fork
>>> list.
>>>>> -----
>>>>>
>>>>> A poll I conducted today on bitcointalk,
>>> https://bitcointalk.org/index.php?topic=581635.0 with an
>>> attention-grabbing title suggests some minority support for Bitcoin
>>> Proof-of-Stake. I invite any of you to critically comment on that
>>> thread.
>>>>>
>>>>> "Annual 10% bitcoin dividends can be ours if Proof-of-Stake full
>>> nodes outnumber existing Proof-of-Work full nodes by three-to-one.
>What
>>> is your choice?"
>>>>>
>>>>> "I do not care or do not know enough." - 5 (16.1%)
>>>>> "I would download and run the existing Proof-of-Work program to
>>> fight the change." - 14 (45.2%)
>>>>> "I would download and run the new Proof-of-Stake program to favor
>>> the change. " - 12 (38.7%)
>>>>> Total Voters: 31
>>>>> -----
>>>>>
>>>>> Before I branch the source code and learn the proper way of doing
>>> things in this community, I ask you simply if creating the branch is
>>> harmful? My goal is to develop, test and document PoS, while
>exploring
>>> its vulnerabilities and fixing them in a transparent fashion.
>>>>>
>>>>> Thanks for taking a bit of your time to read this message.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>------------------------------------------------------------------------------
>>> Start Your Social Network Today - Download eXo Platform
>>> Build your Enterprise Intranet with eXo Platform Software
>>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>>> http://p.sf.net/sfu/ExoPlatform
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>------------------------------------------------------------------------------
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|