From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WY976-0003Sd-Dc for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 07:09:32 +0000 Received-SPF: pass (sog-mx-3.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; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WY975-0007gn-CE for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 07:09:32 +0000 Received: by mail-ob0-f179.google.com with SMTP id va2so3989341obc.10 for ; Thu, 10 Apr 2014 00:09:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.162.7 with SMTP id xw7mr12608392oeb.13.1397113766036; Thu, 10 Apr 2014 00:09:26 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Thu, 10 Apr 2014 00:09:25 -0700 (PDT) Received: by 10.76.96.180 with HTTP; Thu, 10 Apr 2014 00:09:25 -0700 (PDT) In-Reply-To: References: <53456B99.9010207@monetize.io> <00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com> <0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com> <534592E2.7040800@gmail.com> <5345986C.3040901@gmail.com> Date: Thu, 10 Apr 2014 09:09:25 +0200 X-Google-Sender-Auth: FgaWySiRQlPleWaIqqB5RBwXq78 Message-ID: From: Mike Hearn To: Wladimir Content-Type: multipart/alternative; boundary=047d7b33cd7cbc491104f6aae5a3 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WY975-0007gn-CE Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 07:09:32 -0000 --047d7b33cd7cbc491104f6aae5a3 Content-Type: text/plain; charset=UTF-8 It's an optimisation problem. Home environments are much more hostile than servers are due to things like virus scanners, wildly varying memory pressure as apps are started and shut down, highly asymmetrical upstream versus downstream bandwidth, complicated nat setups, people who only use laptops (which I think is most people these days) and so on. So I think the right way to go is to optimise the things that hurt server node operators like large memory and disk usage, and this will automatically make it more pleasant to run on the desktop as well. If at some point all the low hanging fruit for the server side is gone then improving things on the desktop would be the next place to go. But we have to be realistic. Desktop tower machines that are always on are dying and will not be coming back. Not a single person I know uses them anymore, they have been wiped out in favour of laptops. This is why, given the tiny size of the bitcoin core development team, I do not think it makes sense to spend precious coding hours chasing this goal. On 10 Apr 2014 08:51, "Wladimir" wrote: > On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn 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 > > --047d7b33cd7cbc491104f6aae5a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's an optimisation problem. Home environments are much= more hostile than servers are due to things like virus scanners, wildly va= rying memory pressure as apps are started and shut down, highly asymmetrica= l upstream versus downstream bandwidth,=C2=A0 complicated nat setups, peopl= e who only use laptops (which I think is most people these days) and so on.=

So I think the right way to go is to optimise the things tha= t hurt server node operators like large memory and disk=C2=A0 usage, and th= is will automatically make it more pleasant to run on the desktop as well. = If at some point all the low hanging fruit for the server side is gone then= improving things on the desktop would be the next place to go. But we have= to be realistic. Desktop tower machines that are always on are dying and w= ill not be coming back. Not a single person I know uses them anymore, they = have been wiped out in favour of laptops. This is why, given the tiny size = of the bitcoin core development team, I do not think it makes sense to spen= d precious coding hours chasing this goal.

On 10 Apr 2014 08:51, "Wladimir" <<= a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com> wrote:
On T= hu, Apr 10, 2014 at 8:38 AM, Mike Hearn <mike@plan99.net> wrot= e:

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.

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'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.

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.

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.
=C2=A0
Bitcoin Core'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.

Maybe the node shouldn't b= e controlled from the wallet at all, it could be a 'node control' 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't know why or when to install t= his, hence my suggestion to pack it with wallets...

Wladimir

--047d7b33cd7cbc491104f6aae5a3--