Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPDDb-0004T4-2B for bitcoin-development@lists.sourceforge.net; Sat, 21 Feb 2015 16:47:51 +0000 Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPDDZ-0001BQ-Dv for bitcoin-development@lists.sourceforge.net; Sat, 21 Feb 2015 16:47:51 +0000 Received: by mail-wi0-f175.google.com with SMTP id r20so8853228wiv.2 for ; Sat, 21 Feb 2015 08:47:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.93.134 with SMTP id cu6mr5886643wjb.79.1424537263412; Sat, 21 Feb 2015 08:47:43 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.11 with HTTP; Sat, 21 Feb 2015 08:47:43 -0800 (PST) In-Reply-To: <54E8AC69.4000102@gmail.com> References: <54E8AC69.4000102@gmail.com> Date: Sat, 21 Feb 2015 17:47:43 +0100 X-Google-Sender-Auth: FEPxGaGsZgd5qUuki924ErgfEgc Message-ID: From: Mike Hearn To: Chris Pacia Content-Type: multipart/alternative; boundary=047d7bb7092c8e1ec0050f9bed38 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: 1YPDDZ-0001BQ-Dv Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bloom filtering, privacy 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: Sat, 21 Feb 2015 16:47:51 -0000 --047d7bb7092c8e1ec0050f9bed38 Content-Type: text/plain; charset=UTF-8 > > Adam seems to be making sense to me. Only querying a single node when an > address in my wallet matches the block filter seems to be pretty efficient. > No, I think it's less efficient (for the client). Quick sums: blocks with 1500 transactions in them are common today. But Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't seem implausible to reach that in the next 5-10 years, so 15,000 transactions. Each transaction has multiple elements we might want to match (addresses, keys, etc). Let's say the average tx contains 5 unique keys/elements. That's the base case of {1 input, 2 outputs} without address reuse, plus fudged up a bit for multi-sends then down a bit again for address reuse. 15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get: http://hur.st/bloomfilter?n=75000&p=0.001 131.63KB per block extra overhead. 144 blocks in a day, so that's 18mb of data per day's worth of sync to pull down over the network. If you don't start your wallet for a week that's 126 megabytes of data just to get started. Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I don't believe that even in five years mobiles will be pulling down and processing that much data within a few seconds, not even in developed countries. But like I said, I don't see why it matters. Anyone who is watching the wire close to you learns which transactions are yours, still, so it doesn't stop intelligence agencies. Anyone who is running a node learns which transactions in the requested block were yours and thus can follow the tx chain to learn which other transactions might be yours too, no different to today. If you connect to a single node and say "give me the transactions sending money to key A in block N", it doesn't matter if you then don't request block N+6 from the same peer - they know you will request it eventually anyway, just by virtue of the fact that one of the transactions they gave you was spent in that block. --047d7bb7092c8e1ec0050f9bed38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam seems to be mak= ing sense to me. Only querying a single node when an address in my wallet matches the block filter seems to be pretty efficient.

No, I think it&= #39;s less efficient (for the client).

Quick sums:= =C2=A0blocks with 1500 transactions in them are common today. But Bitcoin = is growing. Let's imagine a system 10x larger than today. Doesn't s= eem implausible to reach that in the next 5-10 years, so 15,000 transaction= s. Each transaction has multiple elements we might want to match (addresses= , keys, etc).=C2=A0

Let's say the average tx c= ontains 5 unique keys/elements. That's the base case of {1 input, 2 out= puts} without address reuse, plus fudged up a bit for multi-sends then down= a bit again for address reuse.

15,000*5=3D75,= 000 unique elements per block. With an FP rate of 0.1% we get:

131.63KB per block extra overhead.

144= blocks in a day, so that's 18mb of data per day's worth of sync to= pull down over the network. If you don't start your wallet for a week = that's 126 megabytes of data just=C2=A0to get started.

Affordable, yes (in the west). Fast enough to be competitive? Doub= tful. I don't believe that even in five years mobiles will be pulling d= own and processing that much data within a few seconds, not even in develop= ed countries.

But like I said, I don't see why= it matters. Anyone who is watching the wire close to you learns which tran= sactions are yours, still, so it doesn't stop intelligence agencies. An= yone who is running a node learns which transactions in the requested block= were yours and thus can follow the tx chain to learn which other transacti= ons might be yours too, no different to today. If you connect to a single n= ode and say "give me the transactions sending money to key A in block = N", it doesn't matter if you then don't request block N+6 from= the same peer - they know you will request it eventually anyway, just by v= irtue of the fact that one of the transactions they gave you was spent in t= hat block.


--047d7bb7092c8e1ec0050f9bed38--