{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-10\n📝 Original message:It's an optimisation problem. Home environments are much more hostile than\nservers are due to things like virus scanners, wildly varying memory\npressure as apps are started and shut down, highly asymmetrical upstream\nversus downstream bandwidth,  complicated nat setups, people who only use\nlaptops (which I think is most people these days) and so on.\n\nSo I think the right way to go is to optimise the things that hurt server\nnode operators like large memory and disk  usage, and this will\nautomatically make it more pleasant to run on the desktop as well. If at\nsome point all the low hanging fruit for the server side is gone then\nimproving things on the desktop would be the next place to go. But we have\nto be realistic. Desktop tower machines that are always on are dying and\nwill not be coming back. Not a single person I know uses them anymore, they\nhave been wiped out in favour of laptops. This is why, given the tiny size\nof the bitcoin core development team, I do not think it makes sense to\nspend precious coding hours chasing this goal.\nOn 10 Apr 2014 08:51, \"Wladimir\" \u003claanwj at gmail.com\u003e wrote:\n\n\u003e On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\n\u003e\u003e I tend to agree with slush here - counting the IPs in addr broadcasts\n\u003e\u003e often gives a number like 100,000 vs just 10,000 for actually reachable\n\u003e\u003e nodes (or less). It seems like optimising the NAT tunneling code would\n\u003e\u003e help. Starting by adding more diagnostic stuff to the GUI. STUN support may\n\u003e\u003e also help.\n\u003e\u003e\n\u003e\u003e The main constraint with home devices is not IMHO their actual power but\n\u003e\u003e rather that a lot of people no longer keep computers switched on all the\n\u003e\u003e time. If you don't do that then spv with bundled Core can't help your\n\u003e\u003e security because the spv wallet would always be syncing from the p2p\n\u003e\u003e network for performance reasons.\n\u003e\u003e\n\u003e I agree that there is a fundamental incompatibility in usage between\n\u003e wallets and nodes. Wallets need to be online as little as possible, nodes\n\u003e need to online as much as possible.\n\u003e\n\u003e However, a full node background process could also be running if the\n\u003e wallet is not open itself. Ffor example - by running as a system service.\n\u003e\n\u003e Bitcoin Core's own wallet is also moving to SPV, so this means a general\n\u003e solution is needed to get people to run a node when the wallet is not\n\u003e running.\n\u003e\n\u003e Maybe the node shouldn't be controlled from the wallet at all, it could be\n\u003e a 'node control' user interface on its own (this is what -disablewallet\n\u003e does currently). In this case, there is no need for packaging it with a\n\u003e wallet The only drawback would be that initially, people wouldn't know why\n\u003e or when to install this, hence my suggestion to pack it with wallets...\n\u003e\n\u003e Wladimir\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/8d12e844/attachment.html\u003e"}