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 1SeuSj-0007mi-DU for bitcoin-development@lists.sourceforge.net; Wed, 13 Jun 2012 20:46:45 +0000 X-ACL-Warn: Received: from mail-lpp01m010-f47.google.com ([209.85.215.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SeuSi-0004ik-Dr for bitcoin-development@lists.sourceforge.net; Wed, 13 Jun 2012 20:46:45 +0000 Received: by lags15 with SMTP id s15so848767lag.34 for ; Wed, 13 Jun 2012 13:46:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=l7XRczKG5MFkW8WFja5YSa7dzzarREIZJFfPJdEchlw=; b=X0ld+C3QA/YY/QAsYg0m168AfM/dT5fHP1o8INf5aVPEtpC5vbSPtM96llniR99jpJ hZx6g5PX8lrlaXSgQnV3sNR8+pCHw9MjXaezfuIHaQKUWbho/Dmm8tQWkYjEeOHYtzzK fKXslVUWSibqZosei+s3FGFOw5Dq8Frhj1pNyHis6UxQYaFydNmqwUSng1PAHQgY1gl/ 9suzEZy5SzScErb0rwfDc7NW3AU3Oy9LTzn5zw8u3SVWM2iFbKz+M+oiUm3GHymvAvm+ 12AETxBYUP5RDg7MNGYdUscBdSY9uARtnGbxTrUsDyLLzDHwBXRGEnkoEtmW/BWQRLR3 awmg== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr25680193lab.51.1339620397719; Wed, 13 Jun 2012 13:46:37 -0700 (PDT) Received: by 10.114.19.70 with HTTP; Wed, 13 Jun 2012 13:46:37 -0700 (PDT) X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2] Date: Wed, 13 Jun 2012 16:46:37 -0400 Message-ID: From: Jeff Garzik To: Bitcoin Development Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnTJnbJGpUbwibwCq5OJmBKAIv6Finsvhf67d+IE2spAkyIfycamMDA8RsZOhJ9dlfWsmzt X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1SeuSi-0004ik-Dr Subject: [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: Wed, 13 Jun 2012 20:46:45 -0000 An IRC discussion today covered additional needs of lightweight clients. Here is a draft of proposed new P2P commands, and associated behavior changes. This is not meant to be a formal, detailed specification but rather rough picture of the preferred direction. ----- filterinit(false positive rate, number of elements): initialize per-connection bloom filter to the given parameters. if the parameters create a too-large table, the operation fails. returns a 'filterparams' message, with bloom filter construction details. filterload(data): input a serialized bloom filter table metadata and data. filterclear(): remove any filtering associated with current connection. filteradd(hash data): add a single hash to the bloom filter. WARNING: although easier to use, has privacy implications. filterload shrouds the hash list; filteradd does not. it is also less efficient to send a stream of filteradd's to the remote node. mempool(): list TX's in remote node's memory pool. ----- 'filterload' and 'filteradd' enable special behavior changes for 'mempool' and existing P2P commands, whereby only transactions matching the bloom filter will be announced to the connection, and only matching transactions will be sent inside serialized blocks. A lightweight ("SPV") client would issue 'filterload', sync up with blocks, then use 'mempool' to sync up to current TX's. The 'filterload' command also ensures that the client is only sent 'inv' messages etc. for the TX's it is probably interested in. The 'mempool' command is thought to be useful as a diagnostic, even if a bloom filter is not applied to its output. A bloom filter match would need to notice activity on existing coins (via CTxIn->prevout) and activity on a bitcoin address (via CTxOut). -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com