{"type":"rich","version":"1.0","author_name":"npub1zxeun2y8m59t0ehlhk9adtzvdxxw3ty44wq6mwx680lxyvr0kgnsnyx6t2","author_url":"https://nostr.ae/npub1zxeun2y8m59t0ehlhk9adtzvdxxw3ty44wq6mwx680lxyvr0kgnsnyx6t2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-07\n📝 Original message:It seems to me like some (maybe most) of the pressure is actually external\nfrom companies that might release something that dramatically increases\n\"adoption\" \u0026 transaction rates (and that the data on historic rate of\nadoption \u0026 slumps is somewhat disconnected from their interests in a quick\nroll-out)?\n\nIt seems like the question actually becomes what is our maximum acceptable\ncost (hardware capex \u0026 bandwidth \u0026 power opex) associated with running a\nfull node without hardware acceleration and with hardware acceleration\n(something which presumably \"doesn't exist\" yet)? Are we making the\nassumption that hardware acceleration for confirmation will become broadly\navailable and that the primary limiter will become anonymous bandwidth?\n\nExcuse my ignorance, but I imagine somebody must have already looked at\nconfirmation times vs. block size for various existing hardware platforms\n(like at least 3 or 4? maybe a minnowboard, old laptop, and modern desktop\nat least?)? Is there an easy way to setup bitcoind or some other script to\ntest this? (happy to help)\n\nRe Moore's law: yeah, some say stuff like 5nm may never happen. We're\nalready using EUV with plasma emitters, immersed reflective optics, and\ndouble-patterning... and in storage land switching to helium. Things may\nslow A LOT over the next couple decades and I'd guess that a quadratic\nincrease (both in storage \u0026 compute) probably isn't a safe assumption.\n\nOn Thu, May 7, 2015 at 11:46 AM, Btc Drak \u003cbtcdrak at gmail.com\u003e wrote:\n\n\u003e On Thu, May 7, 2015 at 7:40 PM, Gavin Costin \u003cslashdevnull at hotmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Can anyone opposed to this proposal articulate in plain english the worst\n\u003e\u003e case scenario(s) if it goes ahead?\n\u003e\u003e\n\u003e\u003e Some people in the conversation appear to be uncomfortable, perturbed,\n\u003e\u003e defensive etc about the proposal …. But I am not seeing specifics on why it\n\u003e\u003e is not a feasible plan.\n\u003e\u003e\n\u003e\n\u003e See this response:\n\u003e http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/6a87c722/attachment.html\u003e"}