References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
	<CANEZrP1t-xhHqJ0xGQwxxx-ddtRh7jtn9Yhcau2prKNt+PZHgw@mail.gmail.com>
Message-ID: <1337189571.48816.YahooMailNeo@web121003.mail.ne1.yahoo.com>
Date: Wed, 16 May 2012 10:32:51 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CANEZrP1t-xhHqJ0xGQwxxx-ddtRh7jtn9Yhcau2prKNt+PZHgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

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 <mike@plan99.net>=0ATo: Amir Taaki <zgenjix@yahoo.com> =0ACc: "bitcoin-de=
velopment@lists.sourceforge.net" <bitcoin-development@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