On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev wrote: >Hi ZmnSCPxj, > >Thanks for your reply. I'm on mobile so please excuse me for >top-posting. > >I'd like to sort these various points out. Maybe we won't finish the >whole >discussion, but maybe at least we can update wiki articles like >https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks with more >points or >a link to conversations like this. > >Everything is possible but some things take a lot of work. > >You mention ASICs becoming commoditized. I'd remind you that >eventually >there will be a public mathematical breaking of the algorithm, at which >point all ASICs will become obsolete regardless. Would you agree it >would >be better to prepare for this by planning algorithm change? > >You mention many coordinated hardforks. Would you agree that if we >came up >with a way of programmatically cycling the algorithm, that only one >hardfork work be needed? For example one could ask nodes to consent to >new >algorithm code written in a simple scripting language, and reject old >ones >slowly enough to provide for new research. > >You mention the cost of power as the major factor influencing >decentralized >mining. Would you agree that access to hardware that can do the mining >is >an equally large factor? Even without ASICs you would need the >physical >cycles. Including this factor helps us discuss the same set of >expected >situations. > >You describe improving electricity availability in expensive areas as a >way >to improve decentralization. Honestly this sounds out of place to me >and >I'm sorry if I've upset you by rehashing this old topic. I believe >this >list is for discussing the design of software, not international energy >infrastructure: what is the relation? There is a lot of power to >influence >behavior here but I thought the tools present are software design. > >On Sat, May 23, 2020, 9:12 PM ZmnSCPxj wrote: > >> Good morning Karl, >> >> > Hi, >> > >> > I'd like to revisit the discussion of the digest algorithm used in >> hashcash. >> > >> > I believe migrating to new hashing algorithms as a policy would >> significantly increase decentralization and hence security. >> >> Why do you believe so? >> >> My understanding is that there are effectively two strategies for >ensuring >> decentralization based on hash algorithm: >> >> * Keep changing the hash algorithm to prevent development of ASICs >and >> ensure commodity generic computation devices (GPUs) are the only >practical >> target. >> * Do not change the algorithm, to ensure that knowledge of how best >to >> implement an ASIC for the algorithm becomes spread out (through >corporate >> espionage, ASIC reverse-engineering, patent expiry, and sheer >engineering >> effort) and ASICs for the algorithm are as commoditized as GPUs. >> >> The former strategy has the following practical disadvantages: >> >> * Developing new hash algorithms is not cheap. >> The changes to the hashcash algorithm may need to occur faster than >the >> speed at which we can practically develop new, >cryptographically-secure >> hash algorithms. >> * It requires coordinated hardforks over the entire network at an >> alarmingly high rate. >> * It arguably puts too much power to the developers of the code. >> >> On the other hand, the latter strategy requires us only to survive an >> intermediate period where ASICs are developed, but not yet >commoditized; >> and during this intermediate period, the centralization pressure of >ASICs >> might not be more powerful than other centralization pressures >> >> -- >> >> Which brings us to another point. >> >> Non-ASIC-resistance is, by my understanding, a non-issue. >> >> Regardless of whether the most efficient available computing >substrate for >> the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner >earnings are >> determined by cost of power supply. >> >> Even if you imagine that changing the hashcash algorithm would make >CPUs >> practical again, you will still not run it on the CPU of a mobile, >because >> a mobile runs on battery, and charging a battery takes more power >than what >> you can extract from the battery afterwards, because thermodynamics. >> >> Similarly, geographic locations with significant costs of electrical >power >> will still not be practical places to start a mine, regardless if the >mine >> is composed of commodity server racks, commodity video cards, or >commodity >> ASICs. >> >> If you want to solve the issue of miner centralization, the real >solution >> is improving the efficiency of energy transfer to increase the areas >where >> cheap energy is available, not stopgap >change-the-algorithm-every-6-months. >> >> >> Regards, >> ZmnSCPxj >> >> >> > >> > I believe the impact on existing miners could be made pleasant by >> gradually moving the block reward from the previous hash to the next >(such >> that both are accepted with different rewards). An appropriate rate >could >> possibly be calculated from the difficulty. >> > >> > You could develop the frequency of introduction of new hashes such >that >> once present-day ASICs are effectively obsolete anyway due to >competition, >> new ones do not have time to develop. >> > >> > I'm interested in hearing thoughts and concerns. >> > >> > Karl Semich >> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev