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
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
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
