Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.178 as permitted sender)
	client-ip=209.85.213.178; envelope-from=laanwj@gmail.com;
	helo=mail-ig0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
	<CAADm4BCEFCiOpNzUThPPHUamP2256izU8pwD3nerLCxks0wENA@mail.gmail.com>
	<CAAS2fgTx40XSLhiygnJMrSbOC=iJ2YMVLNK7-AMt3ifvAHDZUA@mail.gmail.com>
	<E9BAD633-3B6A-4A2C-AA06-DB591973DF66@bitsofproof.com>
	<53456B99.9010207@monetize.io>
	<B2FEC170-7214-4E46-8830-153995870B62@bitsofproof.com>
	<00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com>
	<0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com>
	<CANEZrP2Q=TG+jejEVFFh5FhjzDDkySHNSTfwtKueLcHu=pB6Kw@mail.gmail.com>
	<CA+s+GJBRvDFgktTgW2sCvAVahrjxcGqfgHw0BVNPvwUupotVrg@mail.gmail.com>
	<534592E2.7040800@gmail.com>
	<CAAS2fgS3q6N9go-NSKdjLwgU_5bFwa8YE88DcjNYHQTwzPCn3Q@mail.gmail.com>
	<5345986C.3040901@gmail.com>
	<CAAS2fgQyXHNnBDKoUMd_=-=1irGJ6cFKwi59enLJvFJiWBv50A@mail.gmail.com>
	<CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com>
	<CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com>
Date: Thu, 10 Apr 2014 08:50:55 +0200
Message-ID: <CA+s+GJDcGxa_ARPFAbsd54cFhgBn8WcqNrRs00TZJBrNmvq5jQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e015384fe94116b04f6aaa354
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
	wallets
Precedence: list

--089e015384fe94116b04f6aaa354
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn <mike@plan99.net> wrote:

> I tend to agree with slush here - counting the IPs in addr broadcasts
> often gives a number like 100,000 vs just 10,000 for actually reachable
> nodes (or less). It seems like optimising the NAT tunneling code would
> help. Starting by adding more diagnostic stuff to the GUI. STUN support may
> also help.
>
> The main constraint with home devices is not IMHO their actual power but
> rather that a lot of people no longer keep computers switched on all the
> time. If you don't do that then spv with bundled Core can't help your
> security because the spv wallet would always be syncing from the p2p
> network for performance reasons.
>
I agree that there is a fundamental incompatibility in usage between
wallets and nodes. Wallets need to be online as little as possible, nodes
need to online as much as possible.

However, a full node background process could also be running if the wallet
is not open itself. Ffor example - by running as a system service.

Bitcoin Core's own wallet is also moving to SPV, so this means a general
solution is needed to get people to run a node when the wallet is not
running.

Maybe the node shouldn't be controlled from the wallet at all, it could be
a 'node control' user interface on its own (this is what -disablewallet
does currently). In this case, there is no need for packaging it with a
wallet The only drawback would be that initially, people wouldn't know why
or when to install this, hence my suggestion to pack it with wallets...

Wladimir

--089e015384fe94116b04f6aaa354
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">On T=
hu, Apr 10, 2014 at 8:38 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir=3D"ltr">I tend to agree with slush here - counting the IPs in addr b=
roadcasts often gives a number like 100,000 vs just 10,000 for actually rea=
chable nodes (or less). It seems like optimising the NAT tunneling code wou=
ld help. Starting by adding more diagnostic stuff to the GUI. STUN support =
may also help.</p>


<p dir=3D"ltr">The main constraint with home devices is not IMHO their actu=
al power but rather that a lot of people no longer keep computers switched =
on all the time. If you don&#39;t do that then spv with bundled Core can=
9;t help your security because the spv wallet would always be syncing from =
the p2p network for performance reasons.</p>
</blockquote><div>I agree that there is a fundamental incompatibility in us=
age between wallets and nodes. Wallets need to be online as little as possi=
ble, nodes need to online as much as possible.<br><br>However, a full node =
background process could also be running if the wallet is not open itself. =
Ffor example - by running as a system service.<br>
=C2=A0<br></div><div>Bitcoin Core&#39;s own wallet is also moving to SPV, s=
o this means a general solution is needed to get people to run a node when =
the wallet is not running.<br><br></div><div>Maybe the node shouldn&#39;t b=
e controlled from the wallet at all, it could be a &#39;node control&#39; u=
ser interface on its own (this is what -disablewallet does currently). In t=
his case, there is no need for packaging it with a wallet The only drawback=
 would be that initially, people wouldn&#39;t know why or when to install t=
his, hence my suggestion to pack it with wallets...<br>
</div><div><br>Wladimir<br></div></div><br></div></div>

--089e015384fe94116b04f6aaa354--