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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YsTg5-0003bI-CN
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 10:14:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.173 as permitted sender)
client-ip=209.85.216.173; envelope-from=tier.nolan@gmail.com;
helo=mail-qc0-f173.google.com;
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsTg4-0005nH-7q
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 10:14:13 +0000
Received: by qcbgu10 with SMTP id gu10so19483219qcb.2
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 03:14:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.21.166 with SMTP id 38mr1484283qkv.88.1431512046856; Wed,
13 May 2015 03:14:06 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 03:14:06 -0700 (PDT)
In-Reply-To: <55531E19.3090503@electrum.org>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<5551F376.4050008@electrum.org>
<CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
<555210AF.3090705@electrum.org>
<CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
<55531E19.3090503@electrum.org>
Date: Wed, 13 May 2015 11:14:06 +0100
Message-ID: <CAE-z3OXa8vk6Q1EBChoRYDOLKw--CXNXz4AokXCbVam_8LFFDg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1147efce0b8a960515f3df2e
X-Spam-Score: 2.5 (++)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-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
1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YsTg4-0005nH-7q
Subject: Re: [Bitcoin-development] Long-term mining incentives
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: Wed, 13 May 2015 10:14:13 -0000
--001a1147efce0b8a960515f3df2e
Content-Type: text/plain; charset=UTF-8
On Wed, May 13, 2015 at 10:49 AM, Thomas Voegtlin <thomasv@electrum.org>
wrote:
>
> The reason I am asking that is, there seems to be no consensus among
> core developers on how Bitcoin can work without miner subsidy. How it
> *will* work is another question.
>
The position seems to be that it will continue to work for the time being,
so there is still time for more research.
Proof of stake has problems with handling long term reversals. The main
proposal is to slightly weaken the security requirements.
With POW, a new node only needs to know the genesis block (and network
rules) to fully determine which of two chains is the strongest.
Penalties for abusing POS inherently create a time horizon. A suggested
POS security model would assume that a full node is a node that resyncs
with the network regularly (every N blocks). N would be depend on the
network rules of the coin.
The alternative is that 51% of the holders of coins at the genesis block
can rewrite the entire chain. The genesis block might not be the first
block, a POS coin might still use POW for minting.
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
--001a1147efce0b8a960515f3df2e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 13, 2015 at 10:49 AM, Thomas Voegtlin <span dir=3D"ltr"><<a href=
=3D"mailto:thomasv@electrum.org" target=3D"_blank">thomasv@electrum.org</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br=
>
The reason I am asking that is, there seems to be no consensus among<br>
core developers on how Bitcoin can work without miner subsidy. How it<br>
*will* work is another question.<br></blockquote><div><br></div><div>The po=
sition seems to be that it will continue to work for the time being, so the=
re is still time for more research.<br><br></div><div>Proof of stake has pr=
oblems with handling long term reversals.=C2=A0 The main proposal is to sli=
ghtly weaken the security requirements.<br><br></div><div>With POW, a new n=
ode only needs to know the genesis block (and network rules) to fully deter=
mine which of two chains is the strongest.<br><br></div><div>Penalties for =
abusing POS inherently create a time horizon.=C2=A0 A suggested POS securit=
y model would assume that a full node is a node that resyncs with the netwo=
rk regularly (every N blocks).=C2=A0=C2=A0=C2=A0 N would be depend on the n=
etwork rules of the coin.<br><br></div><div>The alternative is that 51% of =
the holders of coins at the genesis block can rewrite the entire chain.=C2=
=A0 The genesis block might not be the first block, a POS coin might still =
use POW for minting.<br></div><div><br><a href=3D"https://blog.ethereum.org=
/2014/11/25/proof-stake-learned-love-weak-subjectivity/">https://blog.ether=
eum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/</a> <br></di=
v></div></div></div>
--001a1147efce0b8a960515f3df2e--
|
