From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wsret-0003Nx-IZ for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 10:46:03 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.195]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wsres-0001Mm-0V for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 10:46:03 +0000 Received: from netbook (c31-67.i07-8.onvol.net [92.251.31.67]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MdJxT-1XAnsW1w1b-00I5u3; Fri, 06 Jun 2014 06:45:52 -0400 Received: by netbook (Postfix, from userid 1000) id 1AD762E50DD; Fri, 6 Jun 2014 12:45:45 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Fri, 6 Jun 2014 12:45:43 +0200 Date: Fri, 6 Jun 2014 12:45:43 +0200 From: Adam Back To: Peter Todd Message-ID: <20140606104543.GA31085@netbook.cypherspace.org> References: <20140606081933.GA29458@savin> <20140606084852.GA30247@netbook.cypherspace.org> <20140606090441.GA19256@savin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20140606090441.GA19256@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:140606:pete@petertodd.org::K9fXyyVWf4SDgQqU:0000000000000000000 00000000000000000000000032h4 X-Hashcash: 1:20:140606:bitcoin-development@lists.sourceforge.net::jv8bOEjsAwvPF O7m:000000000000000000001hC1 X-Hashcash: 1:20:140606:gmaxwell@gmail.com::sEqudymqk9pibwcg:0000000000000000000 0000000000000000000000004S4p X-Hashcash: 1:20:140606:adam@cypherspace.org::KXswWufdw6O8i3GM:00000000000000000 00000000000000000000000002Gx X-Provags-ID: V02:K0:wv2JYSWEG8DSRF075xyeBrV1X0IXVLLWDqdJuCooSy8 zi0ZNiODeb4iP/RjC1nDgPj4Fl46Ai8G6kkd+NvJcItVa0JMmq GYPQnOelfFRaUAxeT2sYXbB42MTB8OjbOB+xmBvo4S2ml2kWwH EJwYoUkdv+lszcIsrfsDnKmpD8GtoWyyRxv8hOLhQuDBeFvk3H v0I8i5i8CYkyRv2L/fEaYm9jzU1VtGjHaJgx603CW0WIZUPC36 ObDlU5I42BEzZWDN1wsKkBx0thDXMIcr4nWhJSpTt7Ze2T+Po5 uzmD1ZazC2YkVg+aj9KUIadA3Hd0RLukEyIn1n3QHPGDJJw5F0 P74T53zgP+kSNYmemR15+72AK8KplY0yOSFbTVoKG X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.195 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information X-Headers-End: 1Wsres-0001Mm-0V Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] NODE_BLOOM service bit 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: Fri, 06 Jun 2014 10:46:03 -0000 On Fri, Jun 06, 2014 at 05:04:41AM -0400, Peter Todd wrote: >On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote: >> Prefix filters offer questionable privacy tradeoffs in my opinion. Same >> problem as with stealth address proposed use of prefixes. > >That's assuming you're doing the proposed prefix brute forcing As I recall prefix brute forcing was a bit twiddle saving, ie searching for EDH key that has the users public prefix. That does not improve privacy over an explicit prefix, it saves a byte or so at the expense of average 128 EDH exchanges to send and provides also some probably relatively ineffective plausible deniability by enabling the transaction to be indistinguishable from some other (not very common) types of transaction. >don't do that they have privacy equal or better than bloom filters, but >with better scalability. either its full node only where prefixes are not used, which is less scalable than bloom; or prefixes are used explicitly or implicitly (brute-force) and either way privacy is weakened by the extra correlation hook provided by elimination from the network graph of payments with mismatched prefixes. >In particular that better scalability lets you efficiently query multiple >servers for blockchain data, only giving up info on a subset of the >addresses in your wallet to each server. This can be a significant >improvement to bloom filters if your attacker is running logging nodes to >try to, say, deanonymize CoinJoin transactions. We need to consider the two types of privacy involved. Privacy from the full node an SPV client is relying on to find its payments, vs privacy from analysis of the public transaction graph. The latter is more damaging. Better to design for privacy against future analysis of public info, than privacy by argument to select non-hostile nodes. Tor has changed recently to account for the fact that chosing fresh random nodes is actually worse. ie you have a probability of identity/address identification per route/node, and repeatedly selecting routes/nodes just cumulatively increases the chance you'll be identified. Better to pick a random node, identify it and stick to it and hope you chose well. >Now if you want to come up with something better and write code, please >do! I'm sure the math exists; what doesn't exist is robust and well >tested code in multiple languages. Maybe other simpler, but yes there was the proof of concept that the math exists in the form of the weil pairing. https://bitcointalk.org/index.php?topic=431756.new But what problem are we trying to solve here? Is it an immediate problem? Maybe better to figure out a more privacy compatible solution which will take longer, than let coding drive protocol. Adam