path: root/15/3912d76bec44affb28c29f2ec89229f0460153

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AD2C8BDF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 Oct 2017 15:28:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
	[209.85.218.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDFC53FA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 Oct 2017 15:28:09 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id v9so3671618oif.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 Oct 2017 08:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=bspFNT/WyelcEcA4DdOmSUmb0eR2EzGNbK/ZiHjbVJY=;
	b=ekiLwEciEhO31Rb+5Litn3DQz73kbQLXW8B5xz3otgn83zcfCvfY572DUKsyGE0eKN
	ZF8vWyRZwSnax0jDnv6al7B/p+eqwvQ+4aREl/CRYgiPJIJnm+66awFlPQG6QpzpfSiD
	h5paWaKCTu9ZLGq0g2PgE2XerNVdHMGKohxAM/rB9G4tG0EiyiIF+Jr6MoFaEpg/HHMQ
	EymBdz5xfF+P4oRm8DS2hyTRxxBMlOTq0//XrQaDyKDLCR5ocTtKX0gFxAF9Qft1wNeP
	6aESb8gb67jDrW4gonYPnHse5xcdwjvtlWPR/oFtq4e+sGpmv/Grc3ucxYyM4oPX6di3
	tVUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=bspFNT/WyelcEcA4DdOmSUmb0eR2EzGNbK/ZiHjbVJY=;
	b=Z/kgbmQyyO24hwbdeqBOnbgvQovIvd5CNMr4qRFX6YsMvSHZLNpTm3N4tddvbTZCbG
	N0TcQeSsWycjPIR2qhUbdx7m7DWIz8c/WLVSEnTlS8Iz6uh/ZTV+luJ0D4bHptJl4k0N
	r0+euIQD7BKc/PbRJLR85CBfbkB9DDUJf3ECeJbIMfqRweBeigkVzAbiQzF6Vd+mxSD+
	MxyACUrd9IDCUuSc617PsZFmEYgOrBNLU9XHZHTrld3rmvkE3KqtPp+jptS7QLb3CzwW
	shrdkGvB1Trnb2gnzyBBTe1bdQB6op7Ot+KNvnyXAazeBgdK5I9lf348wyDPtRfZ7BaU
	S24g==
X-Gm-Message-State: AMCzsaVoPiWWekPYLqIYmxdXofHihMcAeS3tGAFFwK1PkscSzLAOO/4S
	nEGxHhCuzuGlyznqdGYLHVAyyrdn0FsOpqRmjHkzuxir
X-Google-Smtp-Source: AOwi7QCby/HRFrpHa8+9jDQJ+JZzmRCbPQpnczD0IJIuQX+VP6YnDKw77O7p6h5knFaGyPWOcl5mz8oL8c2nZj6Fck4=
X-Received: by 10.202.208.93 with SMTP id h90mr3630oig.436.1507735688913; Wed,
	11 Oct 2017 08:28:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.68.169 with HTTP; Wed, 11 Oct 2017 08:28:08 -0700 (PDT)
In-Reply-To: <B8421BF5-C87F-472B-9292-C910C7CF5047@friedenbach.org>
References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
	<1213518291.4328204.1507589852818@mail.yahoo.com>
	<B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
	<CANgJ=T827Z=epjFvhSGNg32X3mXH3XyMNcvuXSLYjf369X1gjA@mail.gmail.com>
	<B8421BF5-C87F-472B-9292-C910C7CF5047@friedenbach.org>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Wed, 11 Oct 2017 11:28:08 -0400
Message-ID: <CACiOHGxHzW42XzS+C=3OKsgbf=+XqtYgri8feRGsH28i2UaDCA@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114483262726ae055b4712dd"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 11 Oct 2017 15:29:41 +0000
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x
 fork? (reformatted text)
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 15:28:11 -0000

--001a114483262726ae055b4712dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>Instead of there being one altcoin fighting to take hashpower from
bitcoin, there=E2=80=99d now be 2

Yes, there would be 2. One of which would (in the scenario we are
discussing) be producing blocks excruciatingly slowly but be the same in
all other aspects.

>changing the difficulty adjustment algorithm doesn=E2=80=99t solve the und=
erlying
issue=E2=80=94hashpower not being aligned with users=E2=80=99 (or even its =
owners=E2=80=99)
interests

I disagree. Changing the difficulty adjustment algorithm could improve the
functionality of a chain, which could be an important prerequisite to using
and trading the tokens on the chain. This property could help keep the
price of the token high, which is what pressures hashpower to align with
user interests.

>And so yes, *if* this incentive problem can=E2=80=99t be solved, and the u=
naltered
bitcoin chain dies from disuse after suffering a hashpower attack,
especially a centrally and/or purposefully instigated one, then bitcoin
would be failed a failed project.

IF the incentive problem could not be resolved then Bitcoin would be a
failed project.

But here is a bit of good news.

Bitcoin has developers!

And those developers can publish a contingency plan!

And that contingency plan can be an emergency hard fork to a different
retarget algorithm.

And that emergency hard fork can gain consensus if it is broadly preferred
over the status quo.

If 90% of the hash power follows NYA, blocks are going to take 100 minutes
until difficulty adjusts after 4.5 months.

That is quite a handicap, even for a honey badger. Emergency hard fork
carries a risk, but depending on the scenario in November, it could be a
risk worth taking.

One more thing. If miners think they are going to succeed in starving the
legacy chain to death, they might be more likely to try. If they get a
credible signal that the legacy chain will react by changing the retarget
function and thereby be more likely to survive, they might feel less
committed to a strategy of starving the legacy chain. This could be
especially true if they are giving up profit for what they fervently hope
will be a short period of time.

On Wed, Oct 11, 2017 at 12:08 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You phrase the question as if =E2=80=9Cdeploying a hard fork to bitcoin=
=E2=80=9D would
> protect the bitcoin chain from the attack. But that=E2=80=99s not what ha=
ppens. If
> you are hard forking from the perspective of deployed nodes, you are an
> different ledger, regardless of circumstance or who did it. Instead of
> there being one altcoin fighting to take hashpower from bitcoin, there=E2=
=80=99d
> now be 2. It is not at all obvious to me that this would be a better
> outcome.
>
> If that isn=E2=80=99t reason enough, changing the difficulty adjustment a=
lgorithm
> doesn=E2=80=99t solve the underlying issue=E2=80=94hashpower not being al=
igned with users=E2=80=99
> (or even its owners=E2=80=99) interests. Propose a fix to the underlying =
cause and
> that might be worth considering, if it passes peer review. But without th=
at
> you=E2=80=99d just be making the state of affairs arguably worse.
>
> And so yes, *if* this incentive problem can=E2=80=99t be solved, and the =
unaltered
> bitcoin chain dies from disuse after suffering a hashpower attack,
> especially a centrally and/or purposefully instigated one, then bitcoin
> would be failed a failed project.
>
> The thesis (and value proposition) of bitcoin is that a particular
> category of economic incentives can be used to solve the problem of
> creating a secure trustess ledger. If those incentives failed, then he
> thesis of bitcoin would have been experimentally falsified, yes. Maybe th=
e
> incentives can be made better to save the project, but we=E2=80=99d have =
to fix the
> source of the problem not the symptoms.
>
> On Oct 10, 2017, at 6:44 PM, Ben Kloester <benkloester@gmail.com> wrote:
>
> Mark, this seems an awful lot like an answer of "no", to my question "Is
> there a contingency plan in the case that the incumbent chain following t=
he
> Bitcoin Core consensus rules comes under 51% attack?" - is this a correct
> interpretation?
>
> In fact, beyond a no, it seems like a "no, and I disagree with the idea o=
f
> creating one".
>
> So if Bitcoin comes under successful 51%, the project, in your vision, ha=
s
> simply failed?
>
> *Ben Kloester*
>
> On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The problem of fast acting but non vulnerable difficulty adjustment
>> algorithms is interesting. I would certainly like to see this space furt=
her
>> explored, and even have some ideas myself.
>>
>> However without commenting on the technical merits of this specific
>> proposal, I think it must be said upfront that the stated goal is not go=
od.
>> The largest technical concern (ignoring governance) over B2X is that it =
is
>> a rushed, poorly reviewed hard fork. Hard forks should not be rushed, an=
d
>> they should receive more than the usual level of expert and community
>> review.
>>
>> I=E2=80=99m that light, doing an even more rushed hard fork on an even n=
ewer idea
>> with even less review would be hypocritical at best. I would suggest
>> reframing as a hardfork wishlist research problem for the next properly
>> planned hard fork, if one occurs. You might also find the hardfork resea=
rch
>> group a more accommodating venue for this discussion:
>>
>> https://bitcoinhardforkresearch.github.io/
>>
>> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Sorry, my previous email did not have the plain text I intended.
>>
>> Background:
>>
>> The bitcoin difficulty algorithm does not seem to be a good one. If ther=
e
>> is a fork due to miners seeking maximum profit without due regard to
>> security, users, and nodes, the "better" coin could end up being the
>> minority chain. If 90% of hashrate is really going to at least initially
>> go
>> towards using SegWit2x, BTC would face 10x delays in confirmations
>> until the next difficulty adjustment, negatively affecting its price
>> relative
>> to BTC1, causing further delays from even more miner abandonment
>> (until the next adjustment). The 10% miners remaining on BTC do not
>> inevitably lose by staying to endure 10x delays because they have 10x
>> less competition, and the same situation applies to BTC1 miners. If the
>> prices are the same and stable, all seems well for everyone, other thing=
s
>> aside. But if the BTC price does not fall to reflect the decreased
>> hashrate,
>> he situation seems to be a big problem for both coins: BTC1 miners will
>> jump back to BTC when the difficulty adjustment occurs, initiating a
>> potentially never-ending oscillation between the two coins, potentially
>> worse than what BCH is experiencing.  They will not issue coins too fast
>> like BCH because that is a side effect of the asymmetry in BCH's rise an=
d
>> fall algorithm.
>>
>> Solution:
>>
>> Hard fork to implement a new difficulty algorithm that uses a simple
>> rolling
>> average with a much smaller window.  Many small coins have done this as
>> a way to stop big miners from coming on and then suddenly leaving,
>> leaving
>> constant miners stuck with a high difficulty for the rest of a (long)
>> averaging
>> window.  Even better, adjust the reward based on recent solvetimes to
>> motivate more mining (or less) if the solvetimes are too slow (or too
>> fast).
>> This will keep keep coin issuance rate perfectly on schedule with real
>> time.
>>
>> I recommend the following for Bitcoin, as fast, simple, and better than
>> any
>> other difficulty algorithm I'm aware of.  This is the result of a lot of
>> work the
>> past year.
>>
>> =3D=3D=3D Begin difficulty algorithm =3D=3D=3D
>> # Zawy v6 difficulty algorithm (modified for bitcoin)
>> # Unmodified Zawy v6 for alt coins:
>> # http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-
>> zawy-v1b.html
>> # All my failed attempts at something better:
>> # https://github.com/seredat/karbowanec/commit/231db5270acb2e6
>> 73a641a1800be910ce345668a
>> #
>> # Keep negative solvetimes to correct bad timestamps.
>> # Do not be tempted to use:
>> # next_D =3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
>> # ST=3D Solvetime, TS =3D timestamp
>>
>> # set constants until next hard fork:
>>
>> T=3D600; # coin's TargetSolvetime
>> N=3D30; # Averaging window. Smoother than N=3D15, faster response than N=
=3D60.
>> X=3D5;
>> limit =3D X^(2/N); # limit rise and fall in case of timestamp manipulati=
on
>> adjust =3D 1/(1+0.67/N);  # keeps avg solvetime on track
>>
>> # begin difficulty algorithm
>>
>> avg_ST=3D0; avg_D=3D0;
>> for ( i=3Dheight;  i > height-N;  i--) {  # go through N most recent blo=
cks
>> avg_ST +=3D (TS[i] - TS[i-1]) / N;
>> avg_D +=3D D[i]/N;
>> }
>> avg_ST =3D T*limit if avg_ST > T*limit;
>> avg_ST =3D T/limit if avg_ST < T/limit;
>>
>> next_D =3D avg_D * T / avg_ST * adjust;
>>
>> # Tim Olsen suggested changing reward to protect against hash attacks.
>> # Karbowanek coin suggested something similar.
>> # I could not find anything better than the simplest idea below.
>> # It was a great surprise that coin issuance rate came out perfect.
>> # BaseReward =3D coins per block
>>
>> next_reward =3D BaseReward * avg_ST / T;
>>
>> =3D=3D=3D=3D=3D=3D=3D end algo =3D=3D=3D=3D
>>
>> Due to the limit and keeping negative solvetimes in a true average,
>> timestamp errors resulting in negative solvetimes are corrected in the
>> next
>> block. Otherwise, one would need to do like Zcash and cause a 5-block
>> delay in the response by resorting to the median of past 11 blocks (MPT)
>> as the most recent timestamp, offsetting the timestamps from their
>> corresponding difficulties by 5 blocks. (it does not cause an averaging
>> problem, but it does cause a 5-block delay in the response.)
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a114483262726ae055b4712dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span class=3D"gmail-im" style=3D"font-size:12.8px">&gt;<s=
pan style=3D"font-size:12.8px">Instead of there being one altcoin fighting =
to take hashpower from bitcoin, there=E2=80=99d now be 2</span><div><span s=
tyle=3D"font-size:12.8px"><br></span></div></span><div style=3D"font-size:1=
2.8px"><span style=3D"font-size:12.8px">Yes, there would be 2. One of which=
 would (in the scenario we are discussing) be producing blocks excruciating=
ly slowly but be the same in all other aspects.</span></div><span class=3D"=
gmail-im" style=3D"font-size:12.8px"><div><span style=3D"font-size:12.8px">=
<br></span></div><div><span style=3D"font-size:12.8px">&gt;</span><span sty=
le=3D"font-size:12.8px">changing the difficulty adjustment algorithm doesn=
=E2=80=99t solve the underlying issue=E2=80=94hashpower not being aligned w=
ith users=E2=80=99 (or even its owners=E2=80=99) interests</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div></span><div style=3D"fon=
t-size:12.8px"><span style=3D"font-size:12.8px">I disagree. Changing the di=
fficulty adjustment algorithm could improve the functionality of a chain, w=
hich could be an important prerequisite to using and trading the tokens on =
the chain. This property could help keep the price of the token high, which=
 is what pressures hashpower to align with user interests.</span></div><spa=
n class=3D"gmail-im" style=3D"font-size:12.8px"><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">&gt;</spa=
n><span style=3D"font-size:12.8px">And so yes, *if* this incentive problem =
can=E2=80=99t be solved, and the unaltered bitcoin chain dies from disuse a=
fter suffering a hashpower attack, especially a centrally and/or purposeful=
ly instigated one, then bitcoin would be failed a failed project.</span></d=
iv><div><span style=3D"font-size:12.8px"><br></span></div></span><div style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">IF the incentive pro=
blem could not be resolved then Bitcoin would be a failed project.</span></=
div><div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></=
span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"=
>But here is a bit of good news.</span></div><div style=3D"font-size:12.8px=
"><span style=3D"font-size:12.8px"><br></span></div><div style=3D"font-size=
:12.8px"><span style=3D"font-size:12.8px">Bitcoin has developers!<br><br></=
span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"=
>And those=C2=A0</span><span style=3D"font-size:12.8px">developers can publ=
ish a contingency plan!</span></div><div style=3D"font-size:12.8px"><span s=
tyle=3D"font-size:12.8px"><br></span></div><div style=3D"font-size:12.8px">=
<span style=3D"font-size:12.8px">And that contingency plan can be an emerge=
ncy hard fork to a different retarget algorithm.</span></div><div style=3D"=
font-size:12.8px"><span style=3D"font-size:12.8px"><br></span></div><div st=
yle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">And that emergenc=
y hard fork can gain consensus if it is broadly preferred over the status q=
uo.</span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:12=
.8px"><br></span></div><div style=3D"font-size:12.8px"><span style=3D"font-=
size:12.8px">If 90% of the hash power follows NYA, blocks are going to take=
 100 minutes until difficulty adjusts after 4.5 months.</span></div><div st=
yle=3D"font-size:12.8px"><span style=3D"font-size:12.8px"><br></span></div>=
<div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">That is qu=
ite a handicap, even for a honey badger. Emergency hard fork carries a risk=
, but depending on the scenario in November, it could be a risk worth takin=
g.</span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:12.=
8px"><br></span></div><div><span style=3D"font-size:12.8px">One more thing.=
 If miners think they are going to succeed in starving the legacy chain to =
death, they might be more likely to try. If they get a credible signal that=
 the legacy chain will react by changing the retarget function and thereby =
be more likely to survive, they might feel less committed=C2=A0to a strateg=
y of starving the legacy chain. This could be especially true if they are g=
iving up profit for what they fervently hope will be a short period of time=
.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Wed, Oct 11, 2017 at 12:08 AM, Mark Friedenbach via bitcoin-dev <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">You phrase the questi=
on as if =E2=80=9Cdeploying a hard fork to bitcoin=E2=80=9D would protect t=
he bitcoin chain from the attack. But that=E2=80=99s not what happens. If y=
ou are hard forking from the perspective of deployed nodes, you are an diff=
erent ledger, regardless of circumstance or who did it. Instead of there be=
ing one altcoin fighting to take hashpower from bitcoin, there=E2=80=99d no=
w be 2. It is not at all obvious to me that this would be a better outcome.=
<div><br></div><div>If that isn=E2=80=99t reason enough, changing the diffi=
culty adjustment algorithm doesn=E2=80=99t solve the underlying issue=E2=80=
=94hashpower not being aligned with users=E2=80=99 (or even its owners=E2=
=80=99) interests. Propose a fix to the underlying cause and that might be =
worth considering, if it passes peer review. But without that you=E2=80=99d=
 just be making the state of affairs arguably worse.</div><div><br></div><d=
iv>And so yes, *if* this incentive problem can=E2=80=99t be solved, and the=
 unaltered bitcoin chain dies from disuse after suffering a hashpower attac=
k, especially a centrally and/or purposefully instigated one, then bitcoin =
would be failed a failed project.</div><div><br></div><div>The thesis (and =
value proposition) of bitcoin is that a particular category of economic inc=
entives can be used to solve the problem of creating a secure trustess ledg=
er. If those incentives failed, then he thesis of bitcoin would have been e=
xperimentally falsified, yes. Maybe the incentives can be made better to sa=
ve the project, but we=E2=80=99d have to fix the source of the problem not =
the symptoms.</div><div><div class=3D"h5"><div><div><br>On Oct 10, 2017, at=
 6:44 PM, Ben Kloester &lt;<a href=3D"mailto:benkloester@gmail.com" target=
=3D"_blank">benkloester@gmail.com</a>&gt; wrote:<br><br></div><blockquote t=
ype=3D"cite"><div><div dir=3D"ltr">Mark, this seems an awful lot like an an=
swer of &quot;no&quot;, to my question &quot;<span style=3D"font-size:12.8p=
x">Is there a contingency plan in the case that the incumbent chain followi=
ng the Bitcoin Core consensus rules comes under 51% attack?&quot; - is this=
 a correct interpretation?</span><div><span style=3D"font-size:12.8px"><br>=
</span></div><div><span style=3D"font-size:12.8px">In fact, beyond a no, it=
 seems like a &quot;no, and I disagree with the idea of creating one&quot;.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">So if Bitcoin comes under successful 51%, th=
e project, in your vision, has simply failed?</span></div></div><div class=
=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"m_-188287717660038446=
6gmail_signature" data-smartmail=3D"gmail_signature"><p><b>Ben Kloester</b>=
<br><span style=3D"font-size:10.0pt;color:#595959"></span></p></div></div>
<br><div class=3D"gmail_quote">On 10 October 2017 at 13:19, Mark Friedenbac=
h via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundat=
ion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"auto">The problem of fast acting but non vulnerable difficulty adjustment =
algorithms is interesting. I would certainly like to see this space further=
 explored, and even have some ideas myself.<div><br></div><div>However with=
out commenting on the technical merits of this specific proposal, I think i=
t must be said upfront that the stated goal is not good. The largest techni=
cal concern (ignoring governance) over B2X is that it is a rushed, poorly r=
eviewed hard fork. Hard forks should not be rushed, and they should receive=
 more than the usual level of expert and community review.</div><div><br></=
div><div>I=E2=80=99m that light, doing an even more rushed hard fork on an =
even newer idea with even less review would be hypocritical at best. I woul=
d suggest reframing as a hardfork wishlist research problem for the next pr=
operly planned hard fork, if one occurs. You might also find the hardfork r=
esearch group a more accommodating venue for this discussion:</div><div><br=
></div><div><a href=3D"https://bitcoinhardforkresearch.github.io/" target=
=3D"_blank">https://bitcoinhardforkresearc<wbr>h.github.io/</a></div><div><=
div class=3D"m_-1882877176600384466h5"><div><div><br>On Oct 9, 2017, at 3:5=
7 PM, Scott Roberts via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>t=
ion.org</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><span>So=
rry, my previous email did not have the plain text I intended.</span><br><s=
pan></span><br><span>Background: </span><br><span></span><br><span>The bitc=
oin difficulty algorithm does not seem to be a good one. If there </span><b=
r><span>is a fork due to miners seeking maximum profit without due regard t=
o </span><br><span>security, users, and nodes, the &quot;better&quot; coin =
could end up being the </span><br><span>minority chain. If 90% of hashrate =
is really going to at least initially go </span><br><span>towards using Seg=
Wit2x, BTC would face 10x delays in confirmations </span><br><span>until th=
e next difficulty adjustment, negatively affecting its price relative </spa=
n><br><span>to BTC1, causing further delays from even more miner abandonmen=
t </span><br><span>(until the next adjustment). The 10% miners remaining on=
 BTC do not </span><br><span>inevitably lose by staying to endure 10x delay=
s because they have 10x </span><br><span>less competition, and the same sit=
uation applies to BTC1 miners. If the </span><br><span>prices are the same =
and stable, all seems well for everyone, other things </span><br><span>asid=
e. But if the BTC price does not fall to reflect the decreased hashrate, </=
span><br><span>he situation seems to be a big problem for both coins: BTC1 =
miners will </span><br><span>jump back to BTC when the difficulty adjustmen=
t occurs, initiating a </span><br><span>potentially never-ending oscillatio=
n between the two coins, potentially </span><br><span>worse than what BCH i=
s experiencing.=C2=A0 They will not issue coins too fast </span><br><span>l=
ike BCH because that is a side effect of the asymmetry in BCH&#39;s rise an=
d </span><br><span>fall algorithm. </span><br><span></span><br><span>Soluti=
on: </span><br><span></span><br><span>Hard fork to implement a new difficul=
ty algorithm that uses a simple rolling </span><br><span>average with a muc=
h smaller window.=C2=A0 Many small coins have done this as </span><br><span=
>a way to stop big miners from coming on and then suddenly leaving, leaving=
 </span><br><span>constant miners stuck with a high difficulty for the rest=
 of a (long) averaging </span><br><span>window.=C2=A0 Even better, adjust t=
he reward based on recent solvetimes to </span><br><span>motivate more mini=
ng (or less) if the solvetimes are too slow (or too fast). </span><br><span=
>This will keep keep coin issuance rate perfectly on schedule with real tim=
e. </span><br><span></span><br><span>I recommend the following for Bitcoin,=
 as fast, simple, and better than any </span><br><span>other difficulty alg=
orithm I&#39;m aware of.=C2=A0 This is the result of a lot of work the </sp=
an><br><span>past year. </span><br><span></span><br><span>=3D=3D=3D Begin d=
ifficulty algorithm =3D=3D=3D </span><br><span># Zawy v6 difficulty algorit=
hm (modified for bitcoin) </span><br><span># Unmodified Zawy v6 for alt coi=
ns: </span><br><span># <a href=3D"http://zawy1.blogspot.com/2017/07/best-di=
fficulty-algorithm-zawy-v1b.html" target=3D"_blank">http://zawy1.blogspot.c=
om/2017<wbr>/07/best-difficulty-algorithm-<wbr>zawy-v1b.html</a> </span><br=
><span># All my failed attempts at something better: </span><br><span># <a =
href=3D"https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a=
1800be910ce345668a" target=3D"_blank">https://github.com/seredat/kar<wbr>bo=
wanec/commit/231db5270acb2e6<wbr>73a641a1800be910ce345668a</a> </span><br><=
span># </span><br><span># Keep negative solvetimes to correct bad timestamp=
s. </span><br><span># Do not be tempted to use: </span><br><span># next_D =
=3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; </span><br><sp=
an># ST=3D Solvetime, TS =3D timestamp </span><br><span></span><br><span># =
set constants until next hard fork: </span><br><span></span><br><span>T=3D6=
00; # coin&#39;s TargetSolvetime </span><br><span>N=3D30; # Averaging windo=
w. Smoother than N=3D15, faster response than N=3D60. </span><br><span>X=3D=
5; </span><br><span>limit =3D X^(2/N); # limit rise and fall in case of tim=
estamp manipulation </span><br><span>adjust =3D 1/(1+0.67/N); =C2=A0# keeps=
 avg solvetime on track </span><br><span></span><br><span># begin difficult=
y algorithm </span><br><span></span><br><span>avg_ST=3D0; avg_D=3D0; </span=
><br><span>for ( i=3Dheight; =C2=A0i &gt; height-N; =C2=A0i--) { =C2=A0# go=
 through N most recent blocks </span><br><span>avg_ST +=3D (TS[i] - TS[i-1]=
) / N; </span><br><span>avg_D +=3D D[i]/N; </span><br><span>} </span><br><s=
pan>avg_ST =3D T*limit if avg_ST &gt; T*limit; </span><br><span>avg_ST =3D =
T/limit if avg_ST &lt; T/limit; </span><br><span></span><br><span>next_D =
=3D avg_D * T / avg_ST * adjust; </span><br><span></span><br><span># Tim Ol=
sen suggested changing reward to protect against hash attacks. </span><br><=
span># Karbowanek coin suggested something similar. </span><br><span># I co=
uld not find anything better than the simplest idea below. </span><br><span=
># It was a great surprise that coin issuance rate came out perfect. </span=
><br><span># BaseReward =3D coins per block </span><br><span></span><br><sp=
an>next_reward =3D BaseReward * avg_ST / T; </span><br><span></span><br><sp=
an>=3D=3D=3D=3D=3D=3D=3D end algo =3D=3D=3D=3D </span><br><span></span><br>=
<span>Due to the limit and keeping negative solvetimes in a true average, <=
/span><br><span>timestamp errors resulting in negative solvetimes are corre=
cted in the next </span><br><span>block. Otherwise, one would need to do li=
ke Zcash and cause a 5-block </span><br><span>delay in the response by reso=
rting to the median of past 11 blocks (MPT) </span><br><span>as the most re=
cent timestamp, offsetting the timestamps from their </span><br><span>corre=
sponding difficulties by 5 blocks. (it does not cause an averaging </span><=
br><span>problem, but it does cause a 5-block delay in the response.)</span=
><br><span>______________________________<wbr>_________________</span><br><=
span>bitcoin-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
t<wbr>ion.org</a></span><br><span><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoun=
dation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a></span><br></div></blo=
ckquote></div></div></div></div><br>______________________________<wbr>____=
_____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div></div></div></div><br>____________________________=
__<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a114483262726ae055b4712dd--