Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1StaI4-0002pA-7t for bitcoin-development@lists.sourceforge.net; Tue, 24 Jul 2012 08:16:24 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1StaHy-0003sD-Lj for bitcoin-development@lists.sourceforge.net; Tue, 24 Jul 2012 08:16:24 +0000 Received: by wibhm2 with SMTP id hm2so2781107wib.10 for ; Tue, 24 Jul 2012 01:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.101.72 with SMTP id a50mr7233144weg.210.1343117772496; Tue, 24 Jul 2012 01:16:12 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.19.13 with HTTP; Tue, 24 Jul 2012 01:16:12 -0700 (PDT) In-Reply-To: <500D0348.4010604@petersson.at> References: <1339766346.31489.49.camel@bmthinkpad> <1339771184.31489.53.camel@bmthinkpad> <1340132998.6065.7.camel@bmthinkpad> <500D0348.4010604@petersson.at> Date: Tue, 24 Jul 2012 10:16:12 +0200 X-Google-Sender-Auth: _NUc7QBP-ZTmBeNZxgojnToU_8I Message-ID: From: Mike Hearn To: Andreas Petersson Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.4 (-) 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 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.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1StaHy-0003sD-Lj Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients 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: Tue, 24 Jul 2012 08:16:24 -0000 > Really lightweight clients (like Bitcoincard), clients with shared > private keys (electrum-style), or brainwallets - will ask the following > question quite often to "supernodes": Given my public keys/addresses, > what is the list of unspent outputs. i think it would make sense to > include such a command, instead or in addition to the filterload/filterinit. Ultra-lightweight clients like Electrum or smart cards have a fundamentally different security model to SPV clients, which mean they cannot connect directly to the P2P network no matter what commands or db indexes are added. This seems to be a common point of confusion. Andreas brought up something similar in a chat yesterday. To connect to the P2P network, you MUST understand how to walk the block chain and handle re-orgs. This is not optional. The reason is that you are connected to random arbitrary nodes who can and maybe will lie to you. The block chain is a self-proving data structure, a node cannot lie about it or make you believe garbage unless they can outrun the rest of the miners combined. If all you're doing is asking a remote node to tell you about what coins are available, that node can simply say "guess what, you're a millionaire!" and you have no way to discover it's wrong. This can be dangerous in the case where you think you've received a payment but actually did not, eg, because your internet connection got tampered with in some way. SPV clients have the same issue for zero-confirmed transactions, but once you see confirmations at high speeds you can be pretty sure the network accepted the transaction. For clients that don't understand the block chain confirmations don't have any meaning. That's why Electrum requires a trusted server and connects to it via SSL. > And perhaps more severe: as far as i understand classic bloom filters, > the server has no method of indexing his data for the expected requests. It doesn't matter. CPU wise Bloom filtering of blocks is very cheap and can be trivially parallelised in the unlikely event it's necessary. The expensive part of serving a Bloom filtered chain to an SPV client is simply moving the disk head into the right position and waiting for the platter to rotate. Blocks are stored sequentially and modern hard disks transfer data once positioned at gigabit speeds so requesting 1 or 2000 blocks is not significantly different.