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 1SUi5r-0003ge-Nf for bitcoin-development@lists.sourceforge.net; Wed, 16 May 2012 17:32:59 +0000 X-ACL-Warn: Received: from nm17-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.58]) by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SUi5p-0003PZ-DN for bitcoin-development@lists.sourceforge.net; Wed, 16 May 2012 17:32:59 +0000 Received: from [98.138.90.49] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:32:51 -0000 Received: from [98.138.88.233] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:32:51 -0000 Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:32:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 851789.99765.bm@omp1033.mail.ne1.yahoo.com Received: (qmail 75948 invoked by uid 60001); 16 May 2012 17:32:51 -0000 X-YMail-OSG: .xqFlgkVM1kVvXnUgOahL8CYgIMDo7IcqcCBwMd9ckLFoyx r6AYW6E1GePVmCtfSO8PMy3POWEIvH9EPafGvxYxUKqOcaz8tKLewcyZLF58 Ac8MjuFeDwbSL1iSNQkrI44bQ0_xbSD2egOuELgrxZokmA1PuJu1ojK0UK3m y2eYorHa8C_ELeCq51hcWN2Y1uRzPLIhay61PNm_Rd9L5iMys4_Q6LEa_mgb gD2ICuwl2gtWvr8NA8aWhht3T2V6tu7G7vJfIf3phtig9s3K.L4AzWlQLTRt r4gxyKSkj954akQ3FORdQ8O8XPPnQWfgsq72SDYKiPUH5VU_jhPc12iMOutJ n7cT0zMmPHafBCZ2fVSlFti29zlUG5s0gocCHoyYKxJ_bXeUcKOm7IIpgNGk aEPqx8gpHomazEuDbiQYPgXcsUzYdUQysFsdLtju9cHRpth8p_O2IApH.GSQ AbKctW0yTu5n2eaDSVFtVre6y9jS3Ce3qbWCLI4fRFMy5bOmBjINE0iSLeKs 2FwoLCuIE Received: from [194.29.236.67] by web121003.mail.ne1.yahoo.com via HTTP; Wed, 16 May 2012 10:32:51 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <1337189571.48816.YahooMailNeo@web121003.mail.ne1.yahoo.com> Date: Wed, 16 May 2012 10:32:51 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.1 (/) 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 [98.138.91.58 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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 X-Headers-End: 1SUi5p-0003PZ-DN Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:32:59 -0000 A bloom filter seems like an interesting idea. However this proposal is con= cerned mainly with the initialisation stage, whereas this bloom filter is f= or pushed blocks.=0A=0AThis proposal still updates new transactions and blo= cks in the same way, and it's not inconceivable to later use a bloom filter= to make that part more efficient (although it's questionable if pushing th= is server side would be a good idea as it would now need to track an additi= onal client state).=0A=0A________________________________=0AFrom: Mike Hear= n =0ATo: Amir Taaki =0ACc: "bitcoin-de= velopment@lists.sourceforge.net" =0ASent: Wednesday, May 16, 2012 5:46 PM=0ASubject: Re: [Bitcoin-developm= ent] BIP 33 - Stratized Nodes=0A=0A=0AThanks for getting this started.=A0= =0A=0AWith regards to the specific proposal, I don't believe it's the best = option and still plan to eventually implement the original design outlined = more than a year ago in this thread:=0A=0Ahttps://bitcointalk.org/index.php= ?topic=3D7972.msg116285#msg116285=0A=0ANamely that you use a new protocol c= ommand to set a Bloom filter on a connection. Only transactions matching th= at filter will appear in relayed inventory. Blocks that are requested will = arrive as a header plus transaction/merkle branch pairs. Clients are expect= ed to maintain and track the block chain as per usual, but instead of downl= oading the whole chain and then dropping the irrelevant transactions, that = filtering is done server side. By strengthening or weakening the Bloom filt= ers you can choose your preferred point on the privacy/bandwidth-usage spec= trum. It is a fairly simple change to the Satoshi and BitcoinJ codebases bu= t still allows clients to gain confidence in their balance by examining the= chain, and this is true even in the presence of a hijacked internet connec= tion (you can't trust pending transactions that way, but you can still trus= t confirmed transactions).=0A=0AThe filters would be applied to each data b= lock in each script rather than having a specific knowledge of addresses. I= n this way you can select for things like multisig outputs or outputs which= don't use addresses / pubkeys to authenticate.=0A=0AI could write a BIP fo= r this alternative protocol if somebody else wants to implement it. I was g= oing to wait until I had time to do both BIP and implementation, but I thin= k some simple optimizations to BitcoinJ can keep its performance good enoug= h for the short term.=A0=A0