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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UzSDb-0001fh-31 for bitcoin-development@lists.sourceforge.net; Wed, 17 Jul 2013 13:56:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.173 as permitted sender) client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f173.google.com; Received: from mail-ob0-f173.google.com ([209.85.214.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UzSDZ-0001dZ-8z for bitcoin-development@lists.sourceforge.net; Wed, 17 Jul 2013 13:56:34 +0000 Received: by mail-ob0-f173.google.com with SMTP id wc20so2281421obb.18 for ; Wed, 17 Jul 2013 06:56:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.95.198 with SMTP id dm6mr8318118oeb.44.1374069387843; Wed, 17 Jul 2013 06:56:27 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Wed, 17 Jul 2013 06:56:27 -0700 (PDT) In-Reply-To: <09D346D7-7D3D-43E9-8B43-5FCE1F188D8E@bitsofproof.com> References: <09D346D7-7D3D-43E9-8B43-5FCE1F188D8E@bitsofproof.com> Date: Wed, 17 Jul 2013 15:56:27 +0200 X-Google-Sender-Auth: A6uuo19fTXo4a2EqV6NP6OxplXM Message-ID: From: Mike Hearn To: Tamas Blummer Content-Type: multipart/alternative; boundary=089e011606f4c25e6e04e1b5755d X-Spam-Score: -0.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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1UzSDZ-0001dZ-8z Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework) 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: Wed, 17 Jul 2013 13:56:35 -0000 --089e011606f4c25e6e04e1b5755d Content-Type: text/plain; charset=UTF-8 On Wed, Jul 17, 2013 at 2:37 PM, Tamas Blummer wrote: > A majority coalition of miner (pool operator) might even decide to change > block reward > rules if the rest of the network only verifies POW. > Which is why it's still vital that any "important" node in the economy uses full validation. A majority miner coalition could change the block reward and award themselves money which SPV clients would accept, however, the moment somebody tried to cash that money out via an exchange, or use it to purchase something from an online shop, or just see if it propagated across the P2P network effectively, they'd notice something had gone wrong. Of course it'd be in the news long before this happened .... SPV is really meant for nodes that go away and come back a lot, i.e. end user wallets. If you're a merchant it'd be dumb to run one unless you're on such a tight budget that your server resembles a powerful tablet. --089e011606f4c25e6e04e1b5755d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 2:37 PM, Tamas Blummer <tam= as@bitsofproof.com> wrote:
A m= ajority coalition of miner (pool operator) might even decide to change bloc= k reward
rules if the rest of the network only verifies POW.
<= /blockquote>

Which is why it's still vital that any = "important" node in the economy uses full validation.

A majority miner coalition could change the block reward and= award themselves money which SPV clients would accept, however, the moment= somebody tried to cash that money out via an exchange, or use it to purcha= se something from an online shop, or just see if it propagated across the P= 2P network effectively, they'd notice something had gone wrong. Of cour= se it'd be in the news long before this happened ....

SPV is really meant for nodes that go away and come bac= k a lot, i.e. end user wallets. If you're a merchant it'd be dumb t= o run one unless you're on such a tight budget that your server resembl= es a powerful tablet.
--089e011606f4c25e6e04e1b5755d--