{"type":"rich","version":"1.0","author_name":"npub17w8rw3wtcr03zdsdjhmcj37w0g6l79gsspleltsznexdktv0qw0qd3nc05","author_url":"https://nostr.ae/npub17w8rw3wtcr03zdsdjhmcj37w0g6l79gsspleltsznexdktv0qw0qd3nc05","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-09\n📝 Original message:Jorge,\n\nWhy won't the attacker use asicboost too? (Please don't say because of\n\u003e patents)\n\u003e\n\u003e\nWe're assuming the ASIC optimization in my example is incompatible with\nASICBoost. But if the new optimization were compatible with ASICBoost,\nyou're right, the network would be in an equivalent situation whether\nASICBoost was banned or not.\n\nI want to point out again that overt ASICBoost can be used on the network\ntoday. My proposal is to bring ASICBoost usage out into the open vs hiding\nit. Banning ASICBoost via protocol changes is another issue completely.\n\nJimmy\n\n\n\u003e On 9 Apr 2017 12:26 am, \"Jimmy Song\" \u003cjaejoon at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Jorge,\n\u003e\u003e\n\u003e\u003e Suppose someone figures out an ASIC optimization that's completely\n\u003e\u003e unrelated that gives X% speed boost over your non-ASICBoosted\n\u003e\u003e implementation. If you ban ASICBoost, someone with this optimization can\n\u003e\u003e get 51% of the network by adding N machines with their new optimization. If\n\u003e\u003e you allow ASICBoost and assuming this gets a 20% speed boost over\n\u003e\u003e non-ASICBoosted hardware, someone with this optimization would need 1.2N\n\u003e\u003e machines to get 51%. The network in that sense is 20% stronger against this\n\u003e\u003e attack in terms of cost.\n\u003e\u003e\n\u003e\u003e Jimmy\n\u003e\u003e\n\u003e\u003e On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e To be more specific, why \"being higher will secure the Bitcoin network\n\u003e\u003e\u003e better against newer optimizations\"?\n\u003e\u003e\u003e Or, to be more clear, let's forget about future \"optimizations\", let's\n\u003e\u003e\u003e just think of an attacker. Does asicboost being used by all miners\n\u003e\u003e\u003e make the system more secure against an attacker? No, for the attacker\n\u003e\u003e\u003e can use asicboost too.\n\u003e\u003e\u003e What about the case when not all the miners are using asicboost? Then\n\u003e\u003e\u003e the attacker can actually get an advantage by suing asicboost.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sometimes people compare asicboost with the use of asics in general as\n\u003e\u003e\u003e both providing more security for the network and users. But I don't\n\u003e\u003e\u003e think this is accurate. The existence of sha256d asics makes an attack\n\u003e\u003e\u003e with general purpose computing hardware (or even more specialized\n\u003e\u003e\u003e architectures like gpgpu) much more expensive and unlikely. As an\n\u003e\u003e\u003e alternative the attacker can spend additional resources investing in\n\u003e\u003e\u003e asics himself (again, making many attacks more expensive and\n\u003e\u003e\u003e unlikely).\n\u003e\u003e\u003e\n\u003e\u003e\u003e But as far as I know, asicboost can be implemented with software\n\u003e\u003e\u003e running on general purpose hardware that integrates with regular\n\u003e\u003e\u003e sha256d asics. There is probably an advantage on having the asicboost\n\u003e\u003e\u003e implementation \"in the same box\" as the sha256d, yet again the\n\u003e\u003e\u003e attacker can invest in hardware with the competitive advantage from\n\u003e\u003e\u003e having asicboost more intergrated with the sha256d asics too.\n\u003e\u003e\u003e\n\u003e\u003e\u003e To reiterate, whether all miners use asicboost or only a subset of\n\u003e\u003e\u003e them, I remain unconvinced that provides any additional security to\n\u003e\u003e\u003e the network (to be more precise whether that makes \"tx history harder\n\u003e\u003e\u003e to rewrite\"), even if it results on the hashrate charts looking \"more\n\u003e\u003e\u003e secure\".\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e On 8 Apr 2017 5:06 am, \"Jimmy Song via bitcoin-dev\"\n\u003e\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Praxeology Guy,\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e Why would the actual end users of Bitcoin (the long term and short\n\u003e\u003e\u003e term\n\u003e\u003e\u003e \u003e\u003e owners of bitcoins) who run fully verifying nodes want to change\n\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e \u003e\u003e policy in order to make their money more vulnerable to 51% attack?\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Certainly, if only one company made use of the extra nonce space, they\n\u003e\u003e\u003e would\n\u003e\u003e\u003e \u003e have an advantage. But think of it this way, if some newer ASIC\n\u003e\u003e\u003e optimization\n\u003e\u003e\u003e \u003e comes up, would you rather have a non-ASICBoosted hash rate to defend\n\u003e\u003e\u003e with\n\u003e\u003e\u003e \u003e or an ASICBoosted hash rate? Certainly, the latter, being higher will\n\u003e\u003e\u003e secure\n\u003e\u003e\u003e \u003e the Bitcoin network better against newer optimizations.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Why?\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/f13e9088/attachment.html\u003e"}