From: Mike Hearn <mike@plan99•net>
To: Wladimir <laanwj@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Date: Thu, 10 Apr 2014 09:09:25 +0200 [thread overview]
Message-ID: <CANEZrP2hNmAg846v-6cS78uhmOvGMwq4A4wEHjS5cuQa3J744Q@mail.gmail.com> (raw)
In-Reply-To: <CA+s+GJDcGxa_ARPFAbsd54cFhgBn8WcqNrRs00TZJBrNmvq5jQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]
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" <laanwj@gmail•com> wrote:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 3388 bytes --]
next prev parent reply other threads:[~2014-04-10 7:09 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 15:29 Wladimir
2014-04-09 15:37 ` Tamas Blummer
2014-04-09 15:41 ` Natanael
2014-04-09 15:54 ` Gregory Maxwell
2014-04-09 16:09 ` Thomas Voegtlin
2014-04-09 19:25 ` Wladimir
2014-04-10 6:04 ` Tamas Blummer
2014-04-10 11:09 ` Wladimir
2014-04-10 11:29 ` Mike Hearn
2014-04-10 11:32 ` Pieter Wuille
2014-04-10 11:43 ` Peter Todd
2014-04-10 11:50 ` Gregory Maxwell
2014-04-10 11:54 ` Peter Todd
2014-04-10 17:30 ` Tier Nolan
2014-04-11 16:54 ` Gregory Maxwell
2014-05-04 21:11 ` Tier Nolan
2014-04-09 17:31 ` Wladimir
2014-04-09 15:42 ` Brian Hoffman
2014-04-09 15:57 ` Gregory Maxwell
2014-04-09 16:09 ` Tamas Blummer
2014-04-09 15:47 ` Mark Friedenbach
2014-04-09 16:27 ` Tamas Blummer
2014-04-09 17:46 ` Peter Todd
2014-04-09 17:50 ` Tamas Blummer
2014-04-09 18:00 ` Mike Hearn
2014-04-09 18:19 ` Wladimir
2014-04-09 18:35 ` Justus Ranvier
2014-04-09 18:46 ` Wladimir
2014-04-09 18:50 ` Gregory Maxwell
2014-04-09 18:58 ` Justus Ranvier
2014-04-09 19:33 ` Gregory Maxwell
2014-04-09 20:12 ` slush
2014-04-09 20:31 ` slush
2014-04-09 20:36 ` Mark Friedenbach
2014-04-09 21:04 ` Gregory Maxwell
2014-04-09 20:37 ` Wladimir
2014-04-09 20:35 ` Wladimir
2014-04-09 20:50 ` slush
2014-04-09 20:55 ` Laszlo Hanyecz
2014-04-10 6:38 ` Mike Hearn
2014-04-10 6:50 ` Wladimir
2014-04-10 7:09 ` Mike Hearn [this message]
2014-04-10 9:33 ` Peter Todd
2014-04-10 7:10 ` Tamas Blummer
2014-04-10 9:17 ` Mike Hearn
2014-04-10 9:39 ` Tamas Blummer
2014-04-10 10:40 ` Mike Hearn
2014-04-10 10:44 ` Tamas Blummer
2014-04-10 11:36 ` Peter Todd
2014-04-10 11:45 ` Mike Hearn
2014-04-10 11:52 ` Peter Todd
2014-04-10 9:47 ` Peter Todd
2014-04-09 18:04 ` Peter Todd
[not found] ` <CA+s+GJBpvqqu=XEojyekx5su+JfYLwz+zsbo8L0=5t6s-_b33w@mail.gmail.com>
2014-04-09 17:35 ` [Bitcoin-development] Fwd: " Wladimir
2014-04-09 16:03 ` [Bitcoin-development] " Peter Todd
2014-04-09 17:33 ` Alex Mizrahi
2014-04-09 17:38 ` Wladimir
2014-04-09 17:38 ` Peter Todd
2014-04-09 18:35 ` Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP2hNmAg846v-6cS78uhmOvGMwq4A4wEHjS5cuQa3J744Q@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox