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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QelDd-0004BU-8q for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 09:50:01 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com; helo=mail-wy0-f175.google.com; Received: from mail-wy0-f175.google.com ([74.125.82.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QelDc-00064w-3x for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 09:50:01 +0000 Received: by wyg30 with SMTP id 30so757387wyg.34 for ; Thu, 07 Jul 2011 02:49:54 -0700 (PDT) Received: by 10.227.58.131 with SMTP id g3mr538519wbh.25.1310032193931; Thu, 07 Jul 2011 02:49:53 -0700 (PDT) Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178]) by mx.google.com with ESMTPS id fy9sm1691742wbb.59.2011.07.07.02.49.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 02:49:52 -0700 (PDT) From: Andy Parkins To: bitcoin-development@lists.sourceforge.net Date: Thu, 7 Jul 2011 10:49:47 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107071049.48131.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: 1QelDc-00064w-3x Subject: [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 09:50:01 -0000 Hello, This is a suggestion with a mind to the future. In particular, I'm slowly working on an alternative client and library (I know, everyone says that). I've got a feature that I'd like to have that would need a change in the protocol. It's a change that I think would improve the official client as well, so I'm bringing it up here. It's actually two changes; and both could be acheived by adding new commands to the protocol. I think that would be overkill though; as they fit quite nicely into an extended getblocks command. (1) The getblocks message is a list of inventory items (type MSG_BLOCK) being requested. Imagine this situation though. I am a light weight client. I store the block headers only. I am only interested in the history of my own wallet addresses. I receive a block broadcast with a transaction that sends coins to one of my addresses. That transaction references other transactions (of course), but I haven't stored any transactions. So; I want to request those transactions and ensure they are all valid and in blocks. I can't. I can request the transactions themselves; but I have no way of finding out what block they were in without downloading the entire full block chain myself. The thing is, a peer with the full block chain is able to do this instantly. Here then is my suggestion: getblocks should accept inventory items of type MSG_TX as well as MSG_BLOCK. When it finds a MSG_TX request, it shouldn't send the transaction (after all that is what the getdata message is for); instead it should return the block that contains that transaction. It's an alternative way of requesting a block -- by transaction in that block. It should be obvious then that it would be easy for a lightweight client to request the transaction chain transactions its interested in to create a list of relevant hashes for the history it's after; and then put those hashes in a getblocks request and have to look only at a few full blocks instead of the full block chain. (2) If you are offline when new transactions are broadcast, there is no way to know they are pending. Transactions that have been broadcast but not yet accepted into a block are never resent (nor should they be). But if I am on a mobile client say, or a light-weight, intermittently used client; I have no way of checking if a transaction sending coins to one of my addresses is pending. It should be possible to request the current pending transaction list. My sugestion then is that a special virtual block request be possible. The all zero block hash can never exist (it's used as the parent for the genesis block, so it had better not). If I send a getblocks that contains an all-zero hash, then the virtual block should be returned in a block message. That virtual block will list all the current pending transactions. Obviously there would be a problem that it's actual hash would not be zero; so it would have to be marked as the virtual block in some other way (perhaps a zero timestamp plus a zero parent hash, or similar). The combination of the above two protocol changes makes it possible for any client to have a large chunk of the facilities available in blockexplorer.com and the very useful http://bitcoincharts.com/bitcoin/ information. Andy -- Dr Andy Parkins andyparkins@gmail.com