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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1R3rzF-00056L-2b
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 16:06:57 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=decker.christian@gmail.com;
helo=mail-ww0-f41.google.com;
Received: from mail-ww0-f41.google.com ([74.125.82.41])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R3rzC-0008Ix-Dc
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 16:06:57 +0000
Received: by wwf10 with SMTP id 10so4114891wwf.4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 14 Sep 2011 09:06:48 -0700 (PDT)
Received: by 10.227.156.72 with SMTP id v8mr2414208wbw.110.1316016408256; Wed,
14 Sep 2011 09:06:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.127.69 with HTTP; Wed, 14 Sep 2011 09:06:08 -0700 (PDT)
In-Reply-To: <201109141143.24165.luke@dashjr.org>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
<4E6F83C3.9020108@jerviss.org>
<CABsx9T0JvnOaBy+irHtnN1zMWP8FiDTn=kn-01ky+V2MW1suTg@mail.gmail.com>
<201109141143.24165.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 14 Sep 2011 18:06:08 +0200
Message-ID: <CALxbBHXnyioJzn=q5KD2fXeu3_JU+rUx5_pACppg7hP41xOwvg@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e65a0756885f5504ace8f29e
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
(decker.christian[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: 1R3rzC-0008Ix-Dc
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
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, 14 Sep 2011 16:06:57 -0000
--0016e65a0756885f5504ace8f29e
Content-Type: text/plain; charset=ISO-8859-1
Am I the only one to think putting pools at a disadvantage is actually
desirable?
Back when pools started to appear we all had huge reservations about putting
so much control into the hands of a few pool operators, but nowadays it
seems that having pool operators control a vast majority of the
computational power is desired.
I do like pools (I use them myself), but we should put the security of the
protocol in first place and then only think about individual players.
Always remember that the problems pool operators encounter are likely also
the ones of a potential attacker that tries to accumulate 50%+ of the
network power :-)
Regards,
Chris
On Wed, Sep 14, 2011 at 5:43 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:
> > The block timestamp rules currently give HOURS of wiggle-room for
> > timestamps. We can't change those rules without risking a chain split.
>
> And those hours of wiggle-room are not enough to cause a problem.
> The problem only comes in (AFAIK) when the existing rules are *not*
> enforced.
>
> > Assuming a majority of pools/miners adopt the "discourage blocks with
> > stale timestamps" rule, that should squash any incentive for cartels
> > to try to start playing with difficulty-- you would have to have 50+%
> > power to start, or you risk producing mostly orphan blocks.
>
> As this is against pools/miners' interests, and doesn't seem to solve any
> real
> problems, I'm going to discourage its adoption if it ever gets done.
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--0016e65a0756885f5504ace8f29e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am I the only one to think putting pools at a disadvantage is actually desi=
rable?<br>Back when pools started to appear we all had huge reservations ab=
out putting so much control into the hands of a few pool operators, but now=
adays it seems that having pool operators control a vast majority of the co=
mputational power is desired.<br>
I do like pools (I use them myself), but we should put the security of the =
protocol in first place and then only think about individual players.<br>Al=
ways remember that the problems pool operators encounter are likely also th=
e ones of a potential attacker that tries to accumulate 50%+ of the network=
power :-)<br>
<br>Regards,<br>Chris<br><div class=3D"gmail_quote">On Wed, Sep 14, 2011 at=
5:43 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org">=
luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wednesday, September 14, 2011 10:45:36 AM Gavin Andres=
en wrote:<br>
> The block timestamp rules currently give HOURS of wiggle-room for<br>
> timestamps. We can't change those rules without risking a chain sp=
lit.<br>
<br>
</div>And those hours of wiggle-room are not enough to cause a problem.<br>
The problem only comes in (AFAIK) when the existing rules are *not* enforce=
d.<br>
<div class=3D"im"><br>
> Assuming a majority of pools/miners adopt the "discourage blocks =
with<br>
> stale timestamps" rule, that should squash any incentive for cart=
els<br>
> to try to start playing with difficulty-- you would have to have 50+%<=
br>
> power to start, or you risk producing mostly orphan blocks.<br>
<br>
</div>As this is against pools/miners' interests, and doesn't seem =
to solve any real<br>
problems, I'm going to discourage its adoption if it ever gets done.<br=
>
<div><div></div><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA<br>
Learn about the latest advances in developing for the<br>
BlackBerry&reg; mobile platform with sessions, labs & more.<br>
See new tools and technologies. Register for BlackBerry&reg; DevCon tod=
ay!<br>
<a href=3D"http://p.sf.net/sfu/rim-devcon-copy1" target=3D"_blank">http://p=
.sf.net/sfu/rim-devcon-copy1</a><br>
_______________________________________________<br>
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>
</div></div></blockquote></div><br>
--0016e65a0756885f5504ace8f29e--
|
