Date: Wed, 11 Oct 2017 01:29:54 +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: <1885357.5164984.1507685394910@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <1885357.5164984.1507685394910.ref@mail.yahoo.com>
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for
	SegWit2x	fork? (reformatted text)
Precedence: list

I agree: a new difficulty algorithm starting from zero is inconceivably 
rushed. But it's also inconceivable to not have one ready in two months 
if my understanding of our current situation is correct. Is there any 
complaint or suggestion about this algorithm or the appropriate goals of 
an ideal difficulty algorithm? I feel like there is a discussion that needs 
to be hashed out before a draft BIP at the HF page, but I do not know 
where is best or who would be interested. If the community shows it is 
receptive and supportive I think I could get Karbowanek coin to put it 
into live action and solicit hash attacks. They are currently using a 
simpler N=17 like this since last November. They have tested all my 
attempted improvements the past few months, so they are familiar with all 
the in and outs. 

This particular coin split is looking different. Assuming users currently 
prefer SW, it still seems like miner support is going to convince enough 
users that SegWit2x is a worthy if not superior alternative. The result 
could be both coins oscillating with long delays, as long as the price is 
similar. As soon as it is not similar, maybe the loser will be in a death 
spiral, pushed to the margin like previous coins. This might be a bitcoin 
feature. But the 2016 window seems like it is too brutal. It seems like it 
will result in an accidental winner before the better coin can be 
determined by more rational means.