Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CA+s+GJADNS6zy--sk3W3q21inuSB5jkkRku14vxLXDXKf=vkvw@mail.gmail.com>
References: <CAC1+kJNjcPkaHiR8mzofwXE4+4UX5nmxX5Q3rZv37v-K40p1Tw@mail.gmail.com>
	<CA+s+GJDVBQVu8yH9jLu_rQmk=dsJuMUctT-iK0zzOJRYgE8k9w@mail.gmail.com>
	<CAC1+kJOQ2uBo2peYKZJyPSQL6qzk6Yu-cF-tPs3GzVS6cAc53w@mail.gmail.com>
	<CANEZrP1bNs4ahMzd7AfSH3P39Cx1rkmCkjnOMOM9T2Anr5wVOw@mail.gmail.com>
	<CAC1+kJMn3p5H6A8GGiuF56d411zC4qsTomuy7A5e0+OQT78FGQ@mail.gmail.com>
	<CA+s+GJADNS6zy--sk3W3q21inuSB5jkkRku14vxLXDXKf=vkvw@mail.gmail.com>
Date: Tue, 24 Jun 2014 14:16:00 +0200
Message-ID: <CANEZrP0sT3KTPatwNFO5gjwShkGQt=h6PjX-3Df2U9oXa=3JUA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a81a03aea1904fc93ecbb
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Plans to separate wallet from core
Precedence: list

--047d7b3a81a03aea1904fc93ecbb
Content-Type: text/plain; charset=UTF-8

>
> Although Pieter and I disagree with regard to issue #4351, we agree on
> wanting to keep (or at least making) bitcoind as lean as possible.
> Maintaining extra indices for others doesn't fit in there - that's
> also why the address index patch was not merged. An 'index node' could
> be a different animal.


We definitely want to head in the direction of allowing a p2p node to be as
useful as possible within its resource constraints and optional advertising
of new (expensive) indexes is the way to go.

Sometimes I wonder if we should have an RPC or new socket based method
where additional programs could run along side Bitcoin Core and opt to
handle a subset of p2p commands. But then I think, that seems like a lot of
complexity for people who just want to help out the system, which I guess
is the bulk of our network now. Keeping their lives simple should have a
high priority. So a single unified program that just figures it out
automatically rather than expecting users to assemble a bag of parts seems
a goal worth striving for.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">Although Pieter and I disagree w=
ith regard to issue #4351, we agree on<br>
</div>
wanting to keep (or at least making) bitcoind as lean as possible.<br>
Maintaining extra indices for others doesn&#39;t fit in there - that&#39;s<=
br>
also why the address index patch was not merged. An &#39;index node&#39; co=
uld<br>
be a different animal.</blockquote><div><br></div><div>We definitely want t=
o head in the direction of allowing a p2p node to be as useful as possible =
within its resource constraints and optional advertising of new (expensive)=
 indexes is the way to go.</div>
<div><br></div><div>Sometimes I wonder if we should have an RPC or new sock=
et based method where additional programs could run along side Bitcoin Core=
 and opt to handle a subset of p2p commands. But then I think, that seems l=
ike a lot of complexity for people who just want to help out the system, wh=
ich I guess is the bulk of our network now. Keeping their lives simple shou=
ld have a high priority. So a single unified program that just figures it o=
ut automatically rather than expecting users to assemble a bag of parts see=
ms a goal worth striving for.=C2=A0</div>
</div></div></div>

--047d7b3a81a03aea1904fc93ecbb--