(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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
