Date: Wed, 11 Oct 2017 14:50:20 +0000 (UTC)
From: Scott Roberts <zawy@yahoo.com>
Reply-To: Scott Roberts <zawy@yahoo.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <1664384101.5473696.1507733420536@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <1664384101.5473696.1507733420536.ref@mail.yahoo.com>
Subject: [bitcoin-dev]  New difficulty algorithm part 2
Precedence: list

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

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

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

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

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


Mark Friedenbach wrote:=20
> changing the difficulty adjustment algorithm doesn=E2=80=99t solve the un=
derlying=20
> issue, hashpower not being aligned with users=E2=80=99 (or owners') inter=
ests.=20

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

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

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

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

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

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

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

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