path: root/70/fd8fd07454d2c1e673a50fd71fc2b61a59957f

Return-Path: <zawy@yahoo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C292ABDA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 Oct 2017 14:50:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from sonic313-19.consmr.mail.gq1.yahoo.com
	(sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 613E4F8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 Oct 2017 14:50:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1507733444; bh=OQeEXkOKGDBuJV7dMndvr87v8V+41L8tVcqMvIDBwyY=;
	h=Date:From:Reply-To:To:Subject:References:From:Subject;
	b=gC6bmzHoA1GQeBplmCVq0lwZrhHcw/1dInjNlPbJ/4SJ9h1UlfOywHHzVgdwZLa796rifR0JcThs4IBTA6eNASq8NiVVMHZpH4w68BX4de8H7xoH8drwrNPn72ZmU95eQh5qU17kVPxtK/YkKNnqYDSEWQMaZScHe2DxH7Ocut6mKmSHUCHx/31FJiPi+3YGyHKoJNDdZ1F0/DCM7lQl0FKYBLqJHndf7wLrl0B24jV/6C1OKKDY/3prmoTAbatrdWtAkQBiZupUrsfvfMyxJY+5/Gtmd+DQMInUcMvYd0UYb+di4rsCvSa73UTkxX4xchiDYgXAc1Vjc3nYwU6tXg==
X-YMail-OSG: UpEvh1IVM1msWbIvGt3_DJCll4LcM8u7k7kXySxahQgx2WwETdDfi2k2h2D2MlI
	8QwUEISvQVInXwgmgufFqcBhnK6Pij1dMtHw8veiLVApbCB.C6jGZ8lMsBv7e6J61q6jA.92pyBb
	mK1D_K.tCCBxZLkio7Y3GcjC6LBBWqtHMfGZPOdZuse1qN6okzjoIy.IM3bzxfRrIpOlRfzk0M6x
	H8wjGq4OvafXPZCIvouvWkBgdB.UFzP0uevJSbqan1GyH_tIYMmCVZ1DRC8E15b2Rt32WtSpnmsN
	J43odGOBDIkP89.dSX4ao2nibDsE2ybAkt6GGsudMDQoxsQFNAcSEAniVHWhcCC3URh9ZLF2C0tp
	T_S4MnXl0Y9akXLSaN49L1cC3c5ug_986de6ZTmg9kRqGXuVkOifNO694vBNaij05M615GbC2M7I
	f5LhwhzsFdps_tiLwGzrfHPu8CdPCbOk4
Received: from sonic.gate.mail.ne1.yahoo.com by
	sonic313.consmr.mail.gq1.yahoo.com with HTTP;
	Wed, 11 Oct 2017 14:50:44 +0000
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>
X-Mailer: WebService/1.1.10668 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64;
	x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100
	Safari/537.36
X-Spam-Status: No, score=1.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FORGED_MUA_MOZILLA,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,
	RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 11 Oct 2017 14:52:24 +0000
Subject: [bitcoin-dev]  New difficulty algorithm part 2
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 14:50:44 -0000

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