From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qetq8-00019K-HR for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 19:02:20 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qetq7-0001Nq-NS for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 19:02:20 +0000 Received: by wwf26 with SMTP id 26so1143056wwf.10 for ; Thu, 07 Jul 2011 12:02:13 -0700 (PDT) Received: by 10.227.178.203 with SMTP id bn11mr1025366wbb.51.1310065333572; Thu, 07 Jul 2011 12:02:13 -0700 (PDT) Received: from grissom.localnet ([91.84.15.31]) by mx.google.com with ESMTPS id o19sm2718680wbh.26.2011.07.07.12.02.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 12:02:09 -0700 (PDT) From: Andy Parkins To: bitcoin-development@lists.sourceforge.net Date: Thu, 7 Jul 2011 20:02:04 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.4; i686; ; ) References: <201107071049.48131.andyparkins@gmail.com> <201107071719.45416.andyparkins@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107072002.04793.andyparkins@gmail.com> X-Spam-Score: -1.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 (andyparkins[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service X-Headers-End: 1Qetq7-0001Nq-NS Subject: Re: [Bitcoin-development] Suggestion for enhancements to getblock 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: Thu, 07 Jul 2011 19:02:20 -0000 On Thursday 07 July 2011 17:44:48 Mike Hearn wrote: > > What I want to be able to do though is calculate a balance for an > > aribtrary address. Not every address; just the particular ones that > > the client is interested in. It's complete overkill to require the > > whole block chain just to calculate the balance of a few addresses. > > But what is that for? You said it's for a lightweight client to do > that when it receives a transaction, to verify that all the > dependencies are in blocks recursively. But why? There is no way for a client to know in advance whether any broadcast transaction contains a send to an address in its wallet. So every incoming transaction has to be examined. Then, there is no way to know if while you were offline any of the transactions in the blocks you missed contained transactions for an address in your wallet. Also, a feature I am interested in supporting is a split wallet -- where the private key is held elsewhere. I'd still want to be able to report the current balance in a particular address though. That address can be added at any time. Also, I would like to make some blockexplorer-like facilities available to lightweight clients. > > Not entirely. If I ask for "the block that contains transaction with > > hash 12345678abcd..." then when I get that full block, I can verify > > the merkle tree myself. > > Well, it's more efficient to just verify the merkle branch. But yes. We're only talking about one verifying one (or minimal numbers of) blocks; "efficient" isn't really going to matter much in that context. Also, if we're talking about a situation where we don't necessarily trust the remote, we've got to verify the whole block, not just the one transaction we're interested in, since we told the remote which one we were interested in when we requested it. > > I'm not entirely sure I see how a filter helps. If I've been offline > > for ten minutes then I need all the transactions pending in the last > > ten minutes. No amount of filtering makes that list any smaller. > > Why do you need all of them? You just care about the ones sending > coins to you, surely? Is the filter going to be filter-by-address then? I misunderstood in that case, I thought you were talking about filter-by-hash, which obviously tells you nothing about the contents of the transaction. > > That would be fine. My reason for suggesting using getblocks was that > > it didn't introduce a new command. > > IMHO it's fine to introduce new commands. They'll just be ignored by > old clients in any event. That's good to know. I'm trying to be circumspect in what my client does; I want to be 100% compatible, which means if I need a new feature, it's got to be in the official client first. I accept that this is all big talk, and there are plenty of people who start new clients and then give up; which might still happen to me. Andy -- Dr Andy Parkins andyparkins@gmail.com