Re: [bitcoin-dev] hashcash-newhash - Ariel Lorenzo-Luaces

From: Ariel Lorenzo-Luaces <arielluaces@gmail•com>
To: Karl <gmkarl@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
Date: Sun, 24 May 2020 16:51:10 -0700	[thread overview]
Message-ID: <f74fc5a4-b09b-41d0-a3c4-7d6726cee016@gmail.com> (raw)
In-Reply-To: <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5798 bytes --]


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
>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 <ZmnSCPxj@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
>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

[-- Attachment #2: Type: text/html, Size: 2100 bytes --]