From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <20150601112634.GA27160@muck> Date: Mon, 1 Jun 2015 20:19:12 +0800 Message-ID: From: Pindar Wong To: Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
Two very valid and important points. Thank you for ma= king 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 W= ong 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 r= egardless
> > of their internet situation, nobody has any inherent "right&= quot; 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 outcom= peted 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 p= roviding
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 res= ult 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.
> >
> >
>=C2=A0 Let's agree to disagree on this point.

Note how that VPN, and likely VPS it's connected too, immediatel= y 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]@pet= ertodd.org
00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9

--047d7bd9131a73036b051773d509--