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