Good morning Kari,

> 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?

Possibly, but then the reason for change is no longer to promote 
decentralization, would it?
It helps to be clear about what your goals are, because any chosen solution 
might not be the best way to fix it.
I admit that, if the problem were to be avoid the inevitable obsoletion of 
SHA-2, then this is the only solution, but that is not the problem you stated 
you were trying to solve in the first place.

> 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.

Even *with* a scripting language, the issue is still what code written in that 
language is accepted, and *how*.

Do miners vote on a new script describing the new hashing algorithm?
What would their incentive be to obsolete their existing hardware?
(using proof-of-work to lock in a hashing change feels very much like a 
chicken-and-egg problem: the censorship-resistance provided by Bitcoin is based 
on evicting any censors by overpowering their hashpower, but requires some 
method of measuring that hashpower: it seems unlikely that you can safely 
change the way hashpower is measured via a hashpower election)

Do nodes install particular scripts and impose a switchover schedule of some 
Then how is that different from a hardfork, especially for nodes that do not 
(notice that softforks allow nodes to remain non-updated, at degraded security, 
but still in sync with the rest of the network and capable of transacting with 

> 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.

No, because anyone who is capable of selling hardware, or the expertise to 
design and build it, can earn by taking advantage of their particular expertise.

Generally, such experts can saturate the locally-available energy sources, 
until local capacity has been saturated, and they can earn even more by selling 
extra hardware to entities located at other energy sources whose local 
capacities are not still underutilized, or expanding themselves to those 
Other entities might be in better position to take advantage of particular 
local details, and it may be more lucrative for the expert-at-building-hardware 
to just sell the hardware to them than to attempt to expand in places where 
they have little local expertise.

And expertise is easy to copy, it is only the initial expertise that is hard to 
create in the first place, once knowledge is written down it can be copied.

> 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.

I doubt there is any good software-only solution to the problem; the physical 
world remains the basis of the virtual one, and the virtual utterly dependent 
on the physical, and abstractions are always leaky (any non-toy software 
framework inevitably gains a way to query the operating system the application 
is running under, because abstractions inevitably leak): and energy, or the 
lack thereof, is the hardest to abstract away, which is the entire point of 
using proof-of-work as a reliable, unfakeable (i.e. difficult to virtualize) 
clock in the first place.

Still, feel free to try: perhaps you might succeed.


bitcoin-dev mailing list

Reply via email to