On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn <m...@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

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

Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
Bitcoin-development mailing list

Reply via email to