[bitcoin-dev] New difficulty algorithm part 2

Scott Roberts zawy at yahoo.com
Wed Oct 11 14:50:20 UTC 2017


(This is new thread because I'm having trouble getting yahoo mail 

to use "reply-to", copy-pasting the subject did not work, and the 
list has not approved my gmail)
A hard fork in the near term is feasible only post-disaster (in my mind, 
that means Core failing from long transaction delays that destroys 
confidence and therefore price). A hard fork attempt to fix the situation 
will not work unless the difficulty is fixed to let price guide hash power 
instead of vice versa. We seem to be headed towards letting the tail wag 
the dog. BTC may find itself in the same position as BCH and all alts: the 
current difficulty algorithm is untenable and will require a fork. 

Current difficulty algorithm in presence of higher hashrate coin with 
the same POW: 
lower hashpower => wait times => lost confidence => lower price => defeat 

Difficulty algorithms that alts find absolutely necessary when there 
is a higher hash rate coin with the same POW: 
hodler faith => price => hashpower => survivable coin 

Alt experience time and time again is that Core will have to fork to a 
faster responding difficulty algorithm if it finds itself suddenly (and 
for the first time) with a lower hashrate. 


Mark Friedenbach wrote: 
> changing the difficulty adjustment algorithm doesn’t solve the underlying 
> issue, hashpower not being aligned with users’ (or owners') interests. 

I define "users" as those who it it for value transfer (including 
purchases) without concern for long-term value. If SegWit2x reduces fees 
per coin, then hashpower is being aligned with their short-term interests. 

It does not solve it, but it is a pre-requisite if the coin has a lower 
hashrate (BTC at end of November). A faster responding diffulty is a 
pre-requisite in minority hashrate coins for letting price (hodlers) 
dictate hashpower instead of vice versa. This is the experience of alts. 

ZmnSCPxj wrote: 
> Hodlers have much greater power in hardfork situations than miners 

Not when hodlers are more evenly split between coins. Miners will prefer 
the coin with higher transaction fees which will erode hodler confidence 
via longer delays. This means transaction fees will evolve to the highest 
that common marketplace users can accepet (they are not intereseted in 
hodler security), not the lowest technologically feasible fee that provides 
the greatest security. Large blocks reduce network security while giving 
the higher total transaction fees to miners even as it can reduce fees per 
coin for users. The mining "lobby" will always describe this as "best for 
users". Non-hodling users and miners logically prefer SegWit2x. 

ZmnSCPxj wrote: 
> BCH changed its difficulty algorithm, and it is often considered to be to 
its detriment due to sudden hashpower oscillations 

BCH has survived this long because they did NOT use the bitcoin difficulty 
algorithm. Granted, it is a bad design that included an asymmetry that has 
resulted in too many coins being issued. If they had inverted the decrease 
rule to create a symmetrically fast increase rule instead of keeping 
bitcoin's increase logic, they would be in much better shape, much better 
than the bitcoin difficulty algorithm. Making it symmetrical and fast would 
have resulted in more obvious fast oscillations, but this would have helped 
price discovery to settle the oscillations to an acceptable level that 
could stabilize the price by preventing too many coins from being issued. 

Oscillations require: 1) comparable price and 2) miners having the option 
to go back and forth to a larger coin. Bitcoin's long, jumping difficulty 
averaging window may destroy the minority hashrate coin faster in fewer 
oscillations thanks to a first-to-market effect more than reason. In 
persuit of higher total transacton fees, miners are deciding SegWit2x is 
"first-to-market" to cause Core to have long delays. This is not a 
conspiracy, but simply seeking profit. Since fees per coin can also be 
reduced, they can convince themselves and others that it is the best 
option. 

A shorter difficulty algorithm averaging window enables more, faster 
oscillations to enable better price discovery before a winner is chosen. 
The design I'm proposing should be close to the ideal.  For example, Mark 
Friedenbach suggested a difficulty adjustment every 18 blocks by averaging 
the past 36 blocks. If a coin using that has the minority hashrate, then it 
could quickly develop into a sudden influx from the majority change for 18 
blocks, then they exit back to the majority chain for 36 blocks before 
doing it again. They get 1/3 of the blocks at "zero excess cost" 
(difficulty will be 1/10 the correct value if they are 10x base hashrate) 
and then they will leave the constant miners with a higher difficulty for 
36 blocks (at 3.33x higher difficulty if the "attackers" are 10x the base 
hashrate). This forces constant miners to start copying them, amplifying 
the oscillations and delays of the minority hashrate coin. A rolling 
average window of any length does not theoretically prevent this, unless 
the window is short enough to be comparable to the time cost of switching 
coins, if there is a time cost. A say this because in testing I was able 
to design an attack algorithm that always gets 1/3 of the coins at "zero 
excess cost".  But a rolling average with a shorter window should make the 
"accidental collusion" of miners seeking profit more unlikely to occur. 
The reward function I've proposed appears to reduce it to 1/6 total coins 
obtainable at "zero excess cost", and similarly reduce oscillations and 
assist better price discovery.


More information about the bitcoin-dev mailing list