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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Wd2ND-00068E-0b
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:58:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.41 as permitted sender)
client-ip=209.85.216.41; envelope-from=tier.nolan@gmail.com;
helo=mail-qa0-f41.google.com;
Received: from mail-qa0-f41.google.com ([209.85.216.41])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd2NB-0007Ac-Vb
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:58:22 +0000
Received: by mail-qa0-f41.google.com with SMTP id j5so1262266qaq.14
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 11:58:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.125.74 with SMTP id x10mr22343806qar.99.1398279496492;
Wed, 23 Apr 2014 11:58:16 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 11:58:16 -0700 (PDT)
In-Reply-To: <CANEZrP1dP3m79bUfgWqi3XZVgnKEW7KoKjBvYSwcQD785QZxGg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<5357D394.7010908@gmail.com>
<CANEZrP0dxAOWxg8Nu9LqV1SGE1C1WD2m+EPhg3sFCnFQQVv4kQ@mail.gmail.com>
<5357F634.2070300@gmail.com>
<CABsx9T12e7rbbza9XFi1EY20+0xciWXMiXrOHjTMdj=7Pzsrxw@mail.gmail.com>
<5357FD32.40200@gmail.com>
<CANEZrP3JV2sCK7-4P40wh9EXQfn2GCc3D=095wCo75Wh0LvMBQ@mail.gmail.com>
<535800C1.9060604@gmail.com> <20140423181545.GA5434@savin>
<53580452.3030705@gmail.com>
<CANEZrP1dP3m79bUfgWqi3XZVgnKEW7KoKjBvYSwcQD785QZxGg@mail.gmail.com>
Date: Wed, 23 Apr 2014 19:58:16 +0100
Message-ID: <CAE-z3OWmT8z=Mj7uYWBPt8yLKepesJnh3nA66p3ucRvk23n3_w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c30886af6a0904f7ba5038
X-Spam-Score: -0.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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1Wd2NB-0007Ac-Vb
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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, 23 Apr 2014 18:58:23 -0000
--001a11c30886af6a0904f7ba5038
Content-Type: text/plain; charset=UTF-8
Bitcoin has various checks and balances that help keep everything honest.
Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks
without anyone noticing that it had happened.
There are sites which monitor the blocks and estimate the percentage of the
blocks found by each pool.
In a way, bitcoin doesn't depend on the majority of miners following the
protocol, it depends on miners believing that a majority of the other
miners will follow the protocol.
If a miner has 5% of the hashing power and believes that the other 95% will
follow the protocol, then the system should be set up so that it is in that
miner's interests to follow the protocol too.
This is why soft forks work. The formal process convinces all the miners
that the new rules are locked in.
In a system where miners can vote to cancel coinbases, each pool has an
incentive to vote to reject everyone else's blocks.
Pools on the receiving end will be less profitable and lose customers.
It is possible that "predatory" pools would lose hashing power as miners
switch to other pools, in protest.
The proposal allows "established" pools to vote to disallow new entrants.
They could even justify it by saying that those pools haven't invested in
"anti-double spending" infrastructure.
The proposal doesn't suddenly give the majority the ability to do it, but
it isn't clear that making the process less disruptive is a good thing.
On Wed, Apr 23, 2014 at 7:37 PM, Mike Hearn <mike@plan99.net> wrote:
> If you want to try and argue that the development list is the wrong place
> to discuss development, please do so on another thread (or your blog).
> Let's keep this thread for discussion of the original proposal - ideally,
> discussed with the dryness that a topic as nerdy as distributed consensus
> algorithms deserves ;)
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--001a11c30886af6a0904f7ba5038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Bitcoin has various checks and balances tha=
t help keep everything honest.<br><br></div>Even if a pool had 60% of the h=
ashing power, they couldn't reverse 6 blocks without anyone noticing th=
at it had happened.<br>
<br></div>There are sites which monitor the blocks and estimate the percent=
age of the blocks found by each pool.<br><br></div><div></div><div>In a way=
, bitcoin doesn't depend on the majority of miners following the protoc=
ol, it depends on miners believing that a majority of the other miners will=
follow the protocol.<br>
<br></div><div>If a miner has 5% of the hashing power and believes that the=
other 95% will follow the protocol, then the system should be set up so th=
at it is in that miner's interests to follow the protocol too.<br><br>
</div><div>This is why soft forks work.=C2=A0 The formal process convinces =
all the miners that the new rules are locked in.<br></div><div><br></div><d=
iv>In a system where miners can vote to cancel coinbases, each pool has an =
incentive to vote to reject everyone else's blocks.<br>
<br></div><div>Pools on the receiving end will be less profitable and lose =
customers.<br><br></div><div>It is possible that "predatory" pool=
s would lose hashing power as miners switch to other pools, in protest.<br>
<br></div><div>The proposal allows "established" pools to vote to=
disallow new entrants.=C2=A0 They could even justify it by saying that tho=
se pools haven't invested in "anti-double spending" infrastru=
cture.<br>
<br></div><div>The proposal doesn't suddenly give the majority the abil=
ity to do it, but it isn't clear that making the process less disruptiv=
e is a good thing.<br></div><div><br></div></div><div class=3D"gmail_extra"=
>
<br><br><div class=3D"gmail_quote">On Wed, Apr 23, 2014 at 7:37 PM, Mike He=
arn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_bla=
nk">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr">If you want to try and argue that the development list is =
the wrong place to discuss development, please do so on another thread (or =
your blog). Let's keep this thread for discussion of the original propo=
sal - ideally, discussed with the dryness that a topic as nerdy as distribu=
ted consensus algorithms deserves ;)</div>
<br>-----------------------------------------------------------------------=
-------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a11c30886af6a0904f7ba5038--
|
