<oembed><type>rich</type><version>1.0</version><author_name>npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0</author_name><author_url>https://nostr.ae/npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-07-04&#xA;📝 Original message:Just some general comments on this topic/discussion.&#xA;&#xA;I suspect that there exist no algorithms which cannot be done better in &#xA;an application-specific device than in a general purpose computer.  And &#xA;if there is such a thing, then it must necessarily perform best on one &#xA;specific platform, making that platform the de facto application &#xA;specific device.&#xA;&#xA;I&#39;m not sure how one would go about proving or disproving that, but it &#xA;seems very likely to be true.&#xA;&#xA;IO-bound is exactly the same as memory bound, for devices that have &#xA;enough memory.  20 GB is already trivial today, and you don&#39;t really get &#xA;into ask-the-wife-for-permission money until you cross 128 GB. The &#xA;exception would be if the IO was to an oracle outside of the device&#39;s &#xA;control, and artificially limited in throughput.  Such a centralized &#xA;oracle would be contrary to the goals usually stated by people thinking &#xA;about anti-ASIC designs, so there isn&#39;t much point.&#xA;&#xA;Keeping the algorithm simple, and ASIC-easy, has one other advantage.  &#xA;Just about anyone can sit down and design an ASIC for SHA, for example, &#xA;leading to diversity in the marketplace.  A harder algorithm can still &#xA;be made into an ASIC (or more generally into an ASD), but will require &#xA;more skilled designers, more expensive fabrication, etc.  This actually &#xA;concentrates the ASIC advantage into the hands of fewer people, which &#xA;again, is contrary to the stated goals.</html></oembed>