public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Scott Roberts <zawy@yahoo•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x	fork? (reformatted text)
Date: Wed, 11 Oct 2017 01:29:54 +0000 (UTC)	[thread overview]
Message-ID: <1885357.5164984.1507685394910@mail.yahoo.com> (raw)
In-Reply-To: <1885357.5164984.1507685394910.ref@mail.yahoo.com>

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.


       reply	other threads:[~2017-10-11  1:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1885357.5164984.1507685394910.ref@mail.yahoo.com>
2017-10-11  1:29 ` Scott Roberts [this message]
2017-10-12  8:51 Scott Roberts
     [not found] <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
2017-10-09 22:57 ` Scott Roberts
2017-10-10  2:19   ` Mark Friedenbach
2017-10-10  2:57     ` Ben Kloester
2017-10-10 10:34     ` greg misiorek
2017-10-11  1:44     ` Ben Kloester
2017-10-11  2:48       ` ZmnSCPxj
2017-10-11  4:08       ` Mark Friedenbach
2017-10-11 15:28         ` Moral Agent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1885357.5164984.1507685394910@mail.yahoo.com \
    --to=zawy@yahoo$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox