On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>Hi ZmnSCPxj,
>Thanks for your reply.  I'm on mobile so please excuse me for
>I'd like to sort these various points out.  Maybe we won't finish the
>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
>there will be a public mathematical breaking of the algorithm, at which
>point all ASICs will become obsolete regardless.  Would you agree it
>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
>algorithm code written in a simple scripting language, and reject old
>slowly enough to provide for new research.
>You mention the cost of power as the major factor influencing
>mining.  Would you agree that access to hardware that can do the mining
>an equally large factor?  Even without ASICs you would need the
>cycles.  Including this factor helps us discuss the same set of
>You describe improving electricity availability in expensive areas as a
>to improve decentralization.  Honestly this sounds out of place to me
>I'm sorry if I've upset you by rehashing this old topic.  I believe
>list is for discussing the design of software, not international energy
>infrastructure: what is the relation?  There is a lot of power to
>behavior here but I thought the tools present are software design.
>On Sat, May 23, 2020, 9:12 PM ZmnSCPxj <zmnsc...@protonmail.com> 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
>> decentralization based on hash algorithm:
>> * Keep changing the hash algorithm to prevent development of ASICs
>> ensure commodity generic computation devices (GPUs) are the only
>> target.
>> * Do not change the algorithm, to ensure that knowledge of how best
>> implement an ASIC for the algorithm becomes spread out (through
>> espionage, ASIC reverse-engineering, patent expiry, and sheer
>> 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
>> speed at which we can practically develop new,
>> 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
>> and during this intermediate period, the centralization pressure of
>> 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
>> practical again, you will still not run it on the CPU of a mobile,
>> 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
>> will still not be practical places to start a mine, regardless if the
>> is composed of commodity server racks, commodity video cards, or
>> ASICs.
>> If you want to solve the issue of miner centralization, the real
>> is improving the efficiency of energy transfer to increase the areas
>> cheap energy is available, not stopgap
>> 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
>> that both are accepted with different rewards).  An appropriate rate
>> possibly be calculated from the difficulty.
>> >
>> > You could develop the frequency of introduction of new hashes such
>> once present-day ASICs are effectively obsolete anyway due to
>> new ones do not have time to develop.
>> >
>> > I'm interested in hearing thoughts and concerns.
>> >
>> > Karl Semich
>bitcoin-dev mailing list
bitcoin-dev mailing list

Reply via email to