rich1.0npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2phttps://nostr.ae/npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pnjumphttps://nostr.ae📅 Original date posted:2014-04-10 📝 Original message:On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn <mike at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/edc08ddf/attachment.html>