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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pindar.wong@gmail.com>) id 1YzOga-0001dg-PO
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 12:19:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.50 as permitted sender)
client-ip=74.125.82.50; envelope-from=pindar.wong@gmail.com;
helo=mail-wg0-f50.google.com;
Received: from mail-wg0-f50.google.com ([74.125.82.50])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzOgZ-0000qj-AK
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 12:19:20 +0000
Received: by wgbgq6 with SMTP id gq6so112728659wgb.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 05:19:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.195.13.1 with SMTP id eu1mr41132389wjd.131.1433161153313;
Mon, 01 Jun 2015 05:19:13 -0700 (PDT)
Received: by 10.194.156.226 with HTTP; Mon, 1 Jun 2015 05:19:12 -0700 (PDT)
In-Reply-To: <20150601112634.GA27160@muck>
References: <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
<CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com>
<CABsx9T2L5bi-c63-KqSifOMeNayUWSPo0_Hx8VjMR_4=kC3ixg@mail.gmail.com>
<CAE28kUT61qYxqV0mOqw5Dan=eMiCvnG2SnsAeWzOWTxwLydyeQ@mail.gmail.com>
<CABsx9T2hfpts5y_M6PdDcxmq9Q2smesJ0Nmp9a9iyPD_MoPC9g@mail.gmail.com>
<CAE28kUTZV3YsaSCX2d5YwLetnf=f+bOWGrwxLXdZFywTZ=+Pjg@mail.gmail.com>
<CALC81CNq-GK5q6R4bmgHL5_Ej2+cZrtQMMLVmuhvMxkZokM3hQ@mail.gmail.com>
<CAE28kUQr+kUPak67tcNQGGscUXtJiD1LiXfjdD8_LMUWyVdR5w@mail.gmail.com>
<CANEZrP12WAcUOJp5UYg4pfWL7_4WiAHWWZAoaxAb5xB+qAP4Xg@mail.gmail.com>
<CAM7BtUou9xfesF7srHQ1vVDUoArmWQvifcDwsXPFdh7NfgC1wA@mail.gmail.com>
<20150601112634.GA27160@muck>
Date: Mon, 1 Jun 2015 20:19:12 +0800
Message-ID: <CAM7BtUq_GexPBwhKiCpNbGBm-Y3y8pTRUWabt8rYQkwpKNRObg@mail.gmail.com>
From: Pindar Wong <pindar.wong@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bd9131a73036b051773d509
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
(pindar.wong[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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YzOgZ-0000qj-AK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
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: Mon, 01 Jun 2015 12:19:20 -0000
--047d7bd9131a73036b051773d509
Content-Type: text/plain; charset=UTF-8
Two very valid and important points. Thank you for making these
observations Peter.
p.
On Mon, Jun 1, 2015 at 7:26 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote:
> > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike@plan99.net> wrote:
> >
> > > Whilst it would be nice if miners in China can carry on forever
> regardless
> > > of their internet situation, nobody has any inherent "right" to mine if
> > > they can't do the job - if miners in China can't get the trivial
> amounts of
> > > bandwidth required through their firewall and end up being outcompeted
> then
> > > OK, too bad, we'll have to carry on without them.
> > >
> >
> > I'd rather think of mining as a responsibility than a right per se, but
> > you're right in so far as it's competitive and self-correcting.
>
> It's important to remember that the service Bitcoin miners are providing
> us is *not* transaction validation, but rather decentralization.
> Validation is something every full node does already; there's no
> shortage of it. What's tricky is designing a Bitcoin protocol that
> creates the appropriate incentives for mining to remain decentralized,
> so we get good value for the large amount of money being sent to miners.
>
> I've often likened this task to building a robot to go to the grocery
> store to buy milk for you. If that robot doesn't have a nose, before
> long store owners are going to realise it can't tell the difference
> between unspoilt and spoilt milk, and you're going to get ripped off
> paying for a bunch of spoiled milk.
>
> Designing a Bitcoin protocol where we expect "competition" to result in
> smaller miners in more geographically decentralized places to get
> outcompeted by larger miners who are more geographically centralized
> gets us bad value for our money. Sure it's "self-correcting", but not in
> a way that we want.
>
> > > But I'm not sure why it should be a big deal. They can always run a
> node
> > > on a server in Taiwan and connect the hardware to it via a VPN or so.
> > >
> > >
> > Let's agree to disagree on this point.
>
> Note how that VPN, and likely VPS it's connected too, immediately adds
> another one or two points of failure to the whole system. Not only does
> this decrease reliability, it also decreases security by making attacks
> significantly easier - VPS security is orders of magnitude worse than
> the security of physical hardware.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9
>
--047d7bd9131a73036b051773d509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Two very valid and important points. Thank you for ma=
king these observations Peter.<br><br></div>p.<br><br><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Mon, Jun 1, 2015 at 7:26 PM, Peter =
Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"=
_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar W=
ong wrote:<br>
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <<a href=3D"mailto:mike@=
plan99.net">mike@plan99.net</a>> wrote:<br>
><br>
> > Whilst it would be nice if miners in China can carry on forever r=
egardless<br>
> > of their internet situation, nobody has any inherent "right&=
quot; to mine if<br>
> > they can't do the job - if miners in China can't get the =
trivial amounts of<br>
> > bandwidth required through their firewall and end up being outcom=
peted then<br>
> > OK, too bad, we'll have to carry on without them.<br>
> ><br>
><br>
> I'd rather think of mining as a responsibility than a right per se=
, but<br>
> you're right in so far as it's competitive and self-correcting=
.<br>
<br>
</span>It's important to remember that the service Bitcoin miners are p=
roviding<br>
us is *not* transaction validation, but rather decentralization.<br>
Validation is something every full node does already; there's no<br>
shortage of it. What's tricky is designing a Bitcoin protocol that<br>
creates the appropriate incentives for mining to remain decentralized,<br>
so we get good value for the large amount of money being sent to miners.<br=
>
<br>
I've often likened this task to building a robot to go to the grocery<b=
r>
store to buy milk for you. If that robot doesn't have a nose, before<br=
>
long store owners are going to realise it can't tell the difference<br>
between unspoilt and spoilt milk, and you're going to get ripped off<br=
>
paying for a bunch of spoiled milk.<br>
<br>
Designing a Bitcoin protocol where we expect "competition" to res=
ult in<br>
smaller miners in more geographically decentralized places to get<br>
outcompeted by larger miners who are more geographically centralized<br>
gets us bad value for our money. Sure it's "self-correcting",=
but not in<br>
a way that we want.<br>
<span class=3D""><br>
> > But I'm not sure why it should be a big deal. They can always=
run a node<br>
> > on a server in Taiwan and connect the hardware to it via a VPN or=
so.<br>
> ><br>
> ><br>
>=C2=A0 Let's agree to disagree on this point.<br>
<br>
</span>Note how that VPN, and likely VPS it's connected too, immediatel=
y adds<br>
another one or two points of failure to the whole system. Not only does<br>
this decrease reliability, it also decreases security by making attacks<br>
significantly easier - VPS security is orders of magnitude worse than<br>
the security of physical hardware.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9<br>
</font></span></blockquote></div><br></div></div>
--047d7bd9131a73036b051773d509--
|
