From: greg misiorek <greg_not_so@hotmail.com>
To: Mark Friedenbach <mark@friedenbach.org>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] New difficulty algorithm needed for SegWit2x	fork?
	(reformatted text)
Thread-Index: AQHTQW5CruXuX0qbfUqcHokoBKEkraLc4wmM
Date: Tue, 10 Oct 2017 10:34:35 +0000
Message-ID: <BN6PR15MB17610E1A315F50BDD54D336CB1750@BN6PR15MB1761.namprd15.prod.outlook.com>
References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
	<1213518291.4328204.1507589852818@mail.yahoo.com>,
	<B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
In-Reply-To: <B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [zAayYn5iqXMr8JBcUKTC8BS14VuCCuFt]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2NAM03HT181;
	6:TYMk9Uj2CfJhiT88HUEdWVpTuoo3xeBI1EGWhpxNfssgGR6crJW0h9arpJyCFItwDY/Plhlt+27VZKHuQ8zuxN/sKZbWzp0Yq7ZxfRh2dslYrbPlD8rV3WY57pNrRGg7QQM5ukBQpmHZkw9ayBgotIpYhtLv2RnQunmq5wZBtjtyFOUft1mPPQj6hKiMsFNmMqGsWDx2enKj+MkL6oBtB7LmfRb/8iL8mH6IV3dwv7It0/cwdCU415/FQORfYCDY/Sr4gLvaCGhkJ2lu8AzLW6vIeyi+OHXLAoVQtdyxxTfEkj/CXAWCWDJK+h1dytcvEp3UVFMxu6Yk61l9BUABhg==;
	5:7JR86GdE6Ag20bjFVG7iw2djLHz+CLTQcmNbgX+d0kZBHNWV4PrDLvnKgpq7Rl7RAvnn8juU82PA5XTsXD7R9rHVkXYUBLf4aGYLXD1eRywiCRg6SMN7/kY4xVdjnGamqEjcw5DZsLSvLfB9OyDINg==;
	24:jJKz5LUc9HwTWT1HaF/Aw99PGRQU9rZr/KOIrqfMTpK4IitIzQVqTSsXsYFyz+8CrAiYog6O1169Hc+GN8u5AZ8quw1H7LzOFx++ofagBDo=;
	7:D0erkB3Z7qGdQcaZvwR4N9Yh7mmS2n8imWZfiCgb7SGg6d/HPXlEcsmBlam3cglJrvdsuigeiahyD7JzMpfDDgaRaKsRrkIkvWlrf8Y/in3TJqP76LzE2KPuvOYo8f7tkDe8POVQ96NUBCL2jp+S4ryK0gyKIC/AFnUTxhpY0X0IgPUIDRMidgtdi3EBwXuXE1NenRtOkHjIVjZ93QkvuPhKqM7qddU6ck5odX3vWo0=
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ab95229a-ff7f-4ca9-1421-08d50fca8094
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:BY2NAM03HT181; 
x-ms-traffictypediagnostic: BY2NAM03HT181:
authentication-results: outbound.protection.outlook.com; spf=skipped
	(originating message); dkim=none (message not signed) header.d=none;
	dmarc=none action=none header.from=hotmail.com;
x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);
	SRVR:BY2NAM03HT181; BCL:0; PCL:0;
	RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);
	SRVR:BY2NAM03HT181; 
x-forefront-prvs: 04569283F9
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:BY2NAM03HT181;
	H:BN6PR15MB1761.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BN6PR15MB17610E1A315F50BDD54D336CB1750BN6PR15MB1761namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 10:34:35.5604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT181
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE
	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: Tue, 10 Oct 2017 11:37:58 +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: Tue, 10 Oct 2017 10:34:38 -0000

--_000_BN6PR15MB17610E1A315F50BDD54D336CB1750BN6PR15MB1761namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Yes, I agree. Hard forks should be as much scrutinized by fellow bitcoiners=
, i.e. developers and holders and not only rushed by miners or some other i=
nvestment gurus, whose incentives are not entirely clear, to remain as dece=
ntralized as economically possible.

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Mark Friedenbach via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org>
Sent: Monday, October 9, 2017 10:19 PM
To: Scott Roberts; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x for=
k? (reformatted text)

The problem of fast acting but non vulnerable difficulty adjustment algorit=
hms is interesting. I would certainly like to see this space further explor=
ed, and even have some ideas myself.

However without commenting on the technical merits of this specific proposa=
l, I think it must be said upfront that the stated goal is not good. The la=
rgest technical concern (ignoring governance) over B2X is that it is a rush=
ed, poorly reviewed hard fork. Hard forks should not be rushed, and they sh=
ould receive more than the usual level of expert and community review.

I=92m that light, doing an even more rushed hard fork on an even newer idea=
 with even less review would be hypocritical at best. I would suggest refra=
ming as a hardfork wishlist research problem for the next properly planned =
hard fork, if one occurs. You might also find the hardfork research group a=
 more accommodating venue for this discussion:

https://bitcoinhardforkresearch.github.io/
Welcome - Bitcoin Hard Fork Research<https://bitcoinhardforkresearch.github=
.io/>
bitcoinhardforkresearch.github.io
Bitcoin Hard Fork Research This website will be updated with relevant ongoi=
ng information about Bitcoin hard fork research. Resources: BIP-MMHF, draft=
 patch last ...



On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org<mailto: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 there
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 relati=
ve
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 things
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 and
fall algorithm.

Solution:

Hard fork to implement a new difficulty algorithm that uses a simple rollin=
g
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) avera=
ging
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 wo=
rk 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/231db5270acb2e673a641a1800be=
910ce345668a
#
# 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=3D=
60.
X=3D5;
limit =3D X^(2/N); # limit rise and fall in case of timestamp manipulation
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 blocks
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<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--_000_BN6PR15MB17610E1A315F50BDD54D336CB1750BN6PR15MB1761namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p>Yes, I agree. Hard forks should be as much scrutinized by fellow bitcoin=
ers, i.e.&nbsp;developers and holders and not only rushed by miners or some=
 other investment gurus, whose incentives are not entirely clear,&nbsp;to r=
emain as decentralized as economically possible.</p>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Mark Friedenbach via bitcoin-dev
 &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Monday, October 9, 2017 10:19 PM<br>
<b>To:</b> Scott Roberts; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] New difficulty algorithm needed for SegWi=
t2x fork? (reformatted text)</font>
<div>&nbsp;</div>
</div>
<div>The problem of fast acting but non vulnerable difficulty adjustment al=
gorithms is interesting. I would certainly like to see this space further e=
xplored, and even have some ideas myself.
<div><br>
</div>
<div>However without commenting on the technical merits of this specific pr=
oposal, I think it must be said upfront that the stated goal is not good. T=
he largest technical concern (ignoring governance) over B2X is that it is a=
 rushed, poorly reviewed hard fork.
 Hard forks should not be rushed, and they should receive more than the usu=
al level of expert and community review.</div>
<div><br>
</div>
<div>I=92m that light, doing an even more rushed hard fork on an even newer=
 idea with even less review would be hypocritical at best. I would suggest =
reframing as a hardfork wishlist research problem for the next properly pla=
nned hard fork, if one occurs. You
 might also find the hardfork research group a more accommodating venue for=
 this discussion:</div>
<div><br>
</div>
<div><a href=3D"https://bitcoinhardforkresearch.github.io/" id=3D"LPlnk7183=
58" previewremoved=3D"true">https://bitcoinhardforkresearch.github.io/</a><=
/div>
<div id=3D"LPBorder_GT_15076314958830.5241211262795888" style=3D"margin-bot=
tom: 20px; overflow: auto; width: 100%; text-indent: 0px;">
<table id=3D"LPContainer_15076314958790.1486958078915679" role=3D"presentat=
ion" cellspacing=3D"0" style=3D"width: 90%; background-color: rgb(255, 255,=
 255); position: relative; overflow: auto; padding-top: 20px; padding-botto=
m: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); borde=
r-bottom: 1px dotted rgb(200, 200, 200);">
<tbody>
<tr valign=3D"top" style=3D"border-spacing: 0px;">
<td id=3D"TextCell_15076314958810.34293924738297044" colspan=3D"2" style=3D=
"vertical-align: top; position: relative; padding: 0px; display: table-cell=
;">
<div id=3D"LPRemovePreviewContainer_15076314958810.8710337524546536"></div>
<div id=3D"LPTitle_15076314958810.860963363444595" style=3D"top: 0px; color=
: rgb(0, 120, 215); font-weight: normal; font-size: 21px; font-family: wf_s=
egoe-ui_light, &quot;Segoe UI Light&quot;, &quot;Segoe WP Light&quot;, &quo=
t;Segoe UI&quot;, &quot;Segoe WP&quot;, Tahoma, Arial, sans-serif; line-hei=
ght: 21px;">
<a id=3D"LPUrlAnchor_15076314958810.18867922462871745" href=3D"https://bitc=
oinhardforkresearch.github.io/" target=3D"_blank" style=3D"text-decoration:=
 none;">Welcome - Bitcoin Hard Fork Research</a></div>
<div id=3D"LPMetadata_15076314958810.7550061268373927" style=3D"margin: 10p=
x 0px 16px; color: rgb(102, 102, 102); font-weight: normal; font-family: wf=
_segoe-ui_normal, &quot;Segoe UI&quot;, &quot;Segoe WP&quot;, Tahoma, Arial=
, sans-serif; font-size: 14px; line-height: 14px;">
bitcoinhardforkresearch.github.io</div>
<div id=3D"LPDescription_15076314958820.9338870209674" style=3D"display: bl=
ock; color: rgb(102, 102, 102); font-weight: normal; font-family: wf_segoe-=
ui_normal, &quot;Segoe UI&quot;, &quot;Segoe WP&quot;, Tahoma, Arial, sans-=
serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hid=
den;">
Bitcoin Hard Fork Research This website will be updated with relevant ongoi=
ng information about Bitcoin hard fork research. Resources: BIP-MMHF, draft=
 patch last ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<div>
<div><br>
On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div><span>Sorry, my previous email did not have the plain text I intended.=
</span><br>
<span></span><br>
<span>Background: </span><br>
<span></span><br>
<span>The bitcoin difficulty algorithm does not seem to be a good one. If t=
here </span>
<br>
<span>is a fork due to miners seeking maximum profit without due regard to =
</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 initia=
lly go
</span><br>
<span>towards using SegWit2x, BTC would face 10x delays in confirmations </=
span><br>
<span>until the next difficulty adjustment, negatively affecting its price =
relative
</span><br>
<span>to BTC1, causing further delays from even more miner abandonment </sp=
an><br>
<span>(until the next adjustment). The 10% miners remaining on BTC do not <=
/span>
<br>
<span>inevitably lose by staying to endure 10x delays because they have 10x=
 </span>
<br>
<span>less competition, and the same situation applies to BTC1 miners. If t=
he </span>
<br>
<span>prices are the same and stable, all seems well for everyone, other th=
ings </span>
<br>
<span>aside. But if the BTC price does not fall to reflect the decreased ha=
shrate,
</span><br>
<span>he situation seems to be a big problem for both coins: BTC1 miners wi=
ll </span>
<br>
<span>jump back to BTC when the difficulty adjustment occurs, initiating a =
</span>
<br>
<span>potentially never-ending oscillation between the two coins, potential=
ly </span>
<br>
<span>worse than what BCH is experiencing. &nbsp;They will not issue coins =
too fast </span>
<br>
<span>like BCH because that is a side effect of the asymmetry in BCH's rise=
 and </span>
<br>
<span>fall algorithm. </span><br>
<span></span><br>
<span>Solution: </span><br>
<span></span><br>
<span>Hard fork to implement a new difficulty algorithm that uses a simple =
rolling
</span><br>
<span>average with a much smaller window. &nbsp;Many small coins have done =
this as </span>
<br>
<span>a way to stop big miners from coming on and then suddenly leaving, le=
aving </span>
<br>
<span>constant miners stuck with a high difficulty for the rest of a (long)=
 averaging
</span><br>
<span>window. &nbsp;Even better, adjust the reward based on recent solvetim=
es to </span>
<br>
<span>motivate more mining (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 rea=
l time.
</span><br>
<span></span><br>
<span>I recommend the following for Bitcoin, as fast, simple, and better th=
an any
</span><br>
<span>other difficulty algorithm I'm aware of. &nbsp;This is the result of =
a lot of work the
</span><br>
<span>past year. </span><br>
<span></span><br>
<span>=3D=3D=3D Begin difficulty algorithm =3D=3D=3D </span><br>
<span># Zawy v6 difficulty algorithm (modified for bitcoin) </span><br>
<span># Unmodified Zawy v6 for alt coins: </span><br>
<span># <a href=3D"http://zawy1.blogspot.com/2017/07/best-difficulty-algori=
thm-zawy-v1b.html">
http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-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/231db5270ac=
b2e673a641a1800be910ce345668a">
https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be91=
0ce345668a</a>
</span><br>
<span># </span><br>
<span># Keep negative solvetimes to correct bad timestamps. </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>
<span># 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=3D600; # coin's TargetSolvetime </span><br>
<span>N=3D30; # Averaging window. Smoother than N=3D15, faster response tha=
n N=3D60. </span>
<br>
<span>X=3D5; </span><br>
<span>limit =3D X^(2/N); # limit rise and fall in case of timestamp manipul=
ation </span>
<br>
<span>adjust =3D 1/(1&#43;0.67/N); &nbsp;# keeps avg solvetime on track </s=
pan><br>
<span></span><br>
<span># begin difficulty algorithm </span><br>
<span></span><br>
<span>avg_ST=3D0; avg_D=3D0; </span><br>
<span>for ( i=3Dheight; &nbsp;i &gt; height-N; &nbsp;i--) { &nbsp;# go thro=
ugh N most recent blocks </span>
<br>
<span>avg_ST &#43;=3D (TS[i] - TS[i-1]) / N; </span><br>
<span>avg_D &#43;=3D D[i]/N; </span><br>
<span>} </span><br>
<span>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 Olsen suggested changing reward to protect against hash attacks=
. </span>
<br>
<span># Karbowanek coin suggested something similar. </span><br>
<span># I could not find anything better than the simplest idea below. </sp=
an><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>
<span>next_reward =3D BaseReward * avg_ST / T; </span><br>
<span></span><br>
<span>=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 corrected in th=
e next
</span><br>
<span>block. Otherwise, one would need to do like Zcash and cause a 5-block=
 </span>
<br>
<span>delay in the response by resorting to the median of past 11 blocks (M=
PT) </span>
<br>
<span>as the most recent timestamp, offsetting the timestamps from their </=
span><br>
<span>corresponding difficulties by 5 blocks. (it does not cause an averagi=
ng </span>
<br>
<span>problem, but it does cause a 5-block delay in the response.)</span><b=
r>
<span>_______________________________________________</span><br>
<span>bitcoin-dev mailing list</span><br>
<span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a></span><br>
<span><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></s=
pan><br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_BN6PR15MB17610E1A315F50BDD54D336CB1750BN6PR15MB1761namp_--