Scott Roberts [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-11 📝 Original message:(This is new thread ...

📅 Original date posted:2017-10-11
📝 Original message:(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.