Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-we0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Wed, 16 May 2012 18:46:59 +0200
Message-ID: <CANEZrP1t-xhHqJ0xGQwxxx-ddtRh7jtn9Yhcau2prKNt+PZHgw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=0016e6d622c8644a6004c02a117d
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Precedence: list

--0016e6d622c8644a6004c02a117d
Content-Type: text/plain; charset=UTF-8

Thanks for getting this started.

With 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:

  https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285

Namely that you use a new protocol command to set a Bloom filter on a
connection. Only transactions matching that filter will appear in relayed
inventory. Blocks that are requested will arrive as a header plus
transaction/merkle branch pairs. Clients are expected to maintain and track
the block chain as per usual, but instead of downloading the whole chain
and then dropping the irrelevant transactions, that filtering is done
server side. By strengthening or weakening the Bloom filters you can choose
your preferred point on the privacy/bandwidth-usage spectrum. It is a
fairly simple change to the Satoshi and BitcoinJ codebases but 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 connection (you
can't trust pending transactions that way, but you can still trust
confirmed transactions).

The filters would be applied to each data block in each script rather than
having a specific knowledge of addresses. In this way you can select for
things like multisig outputs or outputs which don't use addresses / pubkeys
to authenticate.

I could write a BIP for this alternative protocol if somebody else wants to
implement it. I was going to wait until I had time to do both BIP and
implementation, but I think some simple optimizations to BitcoinJ can keep
its performance good enough for the short term.

--0016e6d622c8644a6004c02a117d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for getting this started.=C2=A0<div><br></div><div>With regards to t=
he specific proposal, I don&#39;t believe it&#39;s the best option and stil=
l plan to eventually implement the original design outlined more than a yea=
r ago in this thread:</div>
<div><br></div><div>=C2=A0=C2=A0<a href=3D"https://bitcointalk.org/index.ph=
p?topic=3D7972.msg116285#msg116285">https://bitcointalk.org/index.php?topic=
=3D7972.msg116285#msg116285</a></div><div><br></div><div>Namely that you us=
e a new protocol command to set a Bloom filter on a connection. Only transa=
ctions matching that filter will appear in relayed inventory. Blocks that a=
re requested will arrive as a header plus transaction/merkle branch pairs. =
Clients are expected to maintain and track the block chain as per usual, bu=
t instead of downloading the whole chain and then dropping the irrelevant t=
ransactions, that filtering is done server side. By strengthening or weaken=
ing the Bloom filters you can choose your preferred point on the privacy/ba=
ndwidth-usage spectrum. It is a fairly simple change to the Satoshi and Bit=
coinJ codebases but still allows clients to gain confidence in their balanc=
e by examining the chain, and this is true even in the presence of a hijack=
ed internet connection (you can&#39;t trust pending transactions that way, =
but you can still trust confirmed transactions).</div>
<div><br></div><div>The filters would be applied to each data block in each=
 script rather than having a specific knowledge of addresses. In this way y=
ou can select for things like multisig outputs or outputs which don&#39;t u=
se addresses / pubkeys to authenticate.</div>
<div><br></div><div>I could write a BIP for this alternative protocol if so=
mebody else wants to implement it. I was going to wait until I had time to =
do both BIP and implementation, but I think some simple optimizations to Bi=
tcoinJ can keep its performance good enough for the short term.</div>

--0016e6d622c8644a6004c02a117d--