Nostr notes by

📅 Original date posted:2017-11-02 📝 Original ...

2023-06-07T18:07:31Z

In reply to nevent1q…e7gd
_________________________

📅 Original date posted:2017-11-02
📝 Original message:Whatever their failings from their previous code or their adversarial
nature, they got this code right and I'm only presenting it as a real and
excellent solution for the impending threat to bitcoin. As a big core fan,
I really wanted to delete the word Cash from my post because I was afraid
someone would turn this technical discussion into a political football.

On Nov 2, 2017 7:37 PM, "Gregory Maxwell" <greg at xiph.org> wrote:

On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> algorithm. Bitcoin itself might need to hard fork to employ a similar
> algorithm. It's about as good as they come because it followed the

This is the bitcoin development mailing list, not the "give free
review to the obviously defective proposals of adversarial competing
systems" mailing list. Your posting is off-topic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/64dbe338/attachment.html>;

📅 Original date posted:2017-11-02 📝 Original ...

2023-06-07T18:07:30Z

In reply to nevent1q…398f
_________________________

📅 Original date posted:2017-11-02
📝 Original message:Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
algorithm. Bitcoin itself might need to hard fork to employ a similar
algorithm. It's about as good as they come because it followed the
"simplest is best" route. Their averaging window is probably
significantly too long (N=144). It's:

next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)

They correctly did not use max(timestamp) - min(timestamp) in the
denominator like others do.

They've written the code and they're about to use it live, so Bitcoin
will have a clear, simple, and tested path if it suddenly needs to
hard fork due to having 20x delays for the next 2000 blocks (taking it
a year to get unstuck).

Details on it and the decision process:
https://www.bitcoinabc.org/november

It uses a nice median of 3 for the beginning and end of the window to
help alleviate bad timestamp problems. It's nice, helps a little, but
will also slow its response by 1 block. They also have 2x and 1/2
limits on the adjustment per block, which is a lot more than they will
ever need.

I recommend bitcoin consider using it and making it N=50 instead of 144.

I have seen that any attempts to modify the above with things like a
low pass filter, starting the window at MTP, or preventing negative
timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
limits on the timestamps are sufficient and well chosen, although
something a bit smaller than the +12 might have been better.

One of the contenders to the above is new and actually better, devised
by Degnr8 and they call it D622 or wt-144.It's a little better than
they realize. It's the only real improvement in difficulty algorithms
since the rolling average. It gives a linearly higher weight to the
more recent timestamps. Otherwise it is the same. Others have probably
come across it, but there is too much noise in difficulty algorithms
to find the good ones.

# Degnr8's D622 difficulty algorithm
# T=TargetTime, S=Solvetime
# modified by zawy
for i = 1 to N (from oldest to most recent block)
t += T[i] / D[i] * i
j += i
next i
next_D = j / t * T

I believe any modification to the above strict mathematical weighted
average will reduce it's effectiveness. It does not oscillate anymore
than regular algos and rises faster and drops faster, when needed.

📅 Original date posted:2017-10-13 📝 Original message:> ...

2023-06-07T18:07:09Z

In reply to nevent1q…wrkm
_________________________

📅 Original date posted:2017-10-13
📝 Original message:> ZmnSCPxj wrote
>> Mining infrastructure follows price.

Ilansky wrote:
> In the case of bitcoin, it is the price that follows mining infrastructures.

I generally agree with ZmnSCPxj that
good ideas => good devs => hodlers => price => mining

Except that each step is not an absolute, and can be biased by things
like miners who seek profit via fees and other means that are not good
for everyone else. Llansky's belief itself influences price away from
the ideal. Marketing "easy profits for hodlers!" and first-to-market
monopoly are other elements that influence price and thereby guide
mining away from good ideas (like a constant value currency). Then
price pulls in good devs that pulls in more mining. So it can snowball
into a monster.

We need not debate cause and effect since it's distant from the list's
goals. The relevance to me is that the biases away from ZmnSCPxj's
ideal are a reason a more responsive difficulty is needed.

Mining is for determining truth of the blockchain, not to make sure
there is only 1 blockchain. ZmnSCPxj indicates we should not do
anything that has more precision or speed in determining the correct
difficulty if it reduces Bitcoin's ability to be a monopoly. Not
coincidentally, the monopoly helps ensure hodlers become the new 1%. A
fork clone that uses the faster difficulty would attack BTC's slow
difficulty if it achieves a comparable price. All other things being
equal, it would lower BTC's value until it forks to fix the
difficulty.

On Fri, Oct 13, 2017 at 8:27 AM, Ilan Oh via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Mining infrastructure follows price. If bitcoins were still trading at 1
>> USD per coin, nobody will build mining infrastructure to the same level as
>> today, with 5000 USD per coin.
>
> In the case of bitcoin, it is the price that follows mining infrastructures.
> The price is at 5000 because it is difficult to mine bitcoin not the other
> way around, like you mention it. Even with a fixed demand, price would go up
> as difficulty grow, the supply guide the market. There is a strong incentive
> to mine blindly as it is difficult to estimate for a miner where is the
> actual demand, with a start up currency without actual economic support.
> Indeed at the genesis of this "mining-price" cycle the incentive was to
> contribute to a network and create ones own supply, and not respond to a
> demand.
>
> Ilansky
>
> Le 13 oct. 2017 13:55, <bitcoin-dev-request at lists.linuxfoundation.org> a
> écrit :
>>
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>> bitcoin-dev-request at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: New difficulty algorithm part 2 (ZmnSCPxj)
>> 2. Re: New difficulty algorithm part 2 (Scott Roberts)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 13 Oct 2017 00:45:33 -0400
>> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> To: Scott Roberts <wordsgalore at gmail.com>
>> Cc: "bitcoin-dev at lists.linuxfoundation.org"
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] New difficulty algorithm part 2
>> Message-ID:
>>
>> <Hr8ORNHzR76wNhJHoagwXi2ewQ1qYSZScH0xeltVnqid2ljOowc2bj8-rkbdukpk9eyoPx1ReOZSUsNrcowRU9gL5UbKtblkQn2SUo06BHE=@protonmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Good morning,
>>
>> >ZmnSCPxj wrote:
>> >> Thus even if the unwanted chain provides 2 tokens as fee per block,
>> >> whereas the wanted chain provides 1 token as fee per block, if the
>> >> unwanted chain tokens are valued at 1/4 the wanted chain tokens, miners
>> >> will still prefer the wanted chain regardless.
>> >
>> >This is a good point I was not thinking about, but your math assumes
>> >1/2 price for a coin that can do 2x more transactions. Holders like
>> >Roger Ver have an interest in low price and more transactions. A coin
>> >with 2x more transactions, 22% lower price, and 22% lower fees per
>> >coin transferred will attract more merchants, customers, and miners
>> >(they get 50% more total fees) and this will in turn attract more
>> >hodlers and devs. This assumes it outweighs hodler security concerns.
>> >Merchants and customers, to the extent they are not long term hodlers,
>> >are not interested in price as much as stability, so they are somewhat
>> >at odds with hodlers.
>>
>> As of this moment, BT1 / BT2 price ratio in BitFinex is slightly higher
>> than 7 : 1. Twice the transaction rate cannot overcome this price ratio
>> difference. Even if you were to claim that the BitFinex data is off by a
>> factor of 3, twice the transaction rate still cannot overcome the price
>> ratio difference. Do you have stronger data than what is available on
>> BitFinex? If not, your assumptions are incorrect and all conclusions
>> suspect.
>>
>> >Bitcoin consensus truth is based on "might is right". Buyers and
>> >sellers of goods and services ("users") can shift some might to miners
>> >via fees, to the chagrin of hodlers who have more interest in security
>> >and price increases. Some hodlers think meeting user needs is the
>> >source of long term value. Others think mining infrastructure is.
>>
>> Mining infrastructure follows price. If bitcoins were still trading at 1
>> USD per coin, nobody will build mining infrastructure to the same level as
>> today, with 5000 USD per coin.
>>
>> Price will follow user needs, i.e. demand.
>>
>> >You
>> >seem to require hodlers to correctly identify and rely solely on good
>> >developers.
>>
>> For the very specific case of 2X, it is very easy to make this
>> identification. Even without understanding the work being done, one can
>> reasonably say that it is far more likely that a loose group of 100 or more
>> developers will contain a few good or excellent developers, than a group of
>> a few developers containing a similar number of good or excellent
>> developers.
>>
>> User needs will get met only on the chain that good developers work on.
>> Bitcoin today has too many limitations: viruses on Windows can steal all
>> your money, fee estimates consistently overestimate, fees rise during
>> spamming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible to
>> spend, cannot support dozens of thousands of transactions per second.
>> Rationally, long-term hodlers will select a chain with better developers who
>> are more likely to discover or innovate methods to reduce, eliminate, or
>> sidestep those limitations. Perhaps the balance will change in the future,
>> but it is certainly not the balance now, and thus any difficulty algorithm
>> change in response to the current situation will be premature, and far more
>> likely to cause disaster than avert one.
>>
>> >Whatever combination of these is the case, bad money can
>> >still drive out good, especially if the market determination is not
>> >efficient.
>> >
>> >A faster measurement of hashrate for difficulty enables the economic
>> >determination to be more efficient and correct. It prevents the
>> >biggest coin from bullying forks that have better ideas. Conversely,
>> >it prevents miners from switching to an inferior coin simply because
>> >it provides them with more "protection money" from fees that enables
>> >them to bully Bitcoin Core out of existence, even in the presence of a
>> >slightly larger hodler support.
>>
>> This requires that all chains follow the same difficulty adjustment: after
>> all, it is also entirely the possibility that 2X will be the lower-hashrate
>> coin in a few months, with the Core chain bullying them out of existence.
>> Perhaps you should cross-post your analysis to bitcoin-segwit2x also. After
>> all, the 2X developers should also want to have faster price discovery of
>> the true price of 2X, away from the unfavorable (incorrect?) pricing on
>> BitFinex.
>>
>> >Devs are a governing authority under the influence of users, hodlers,
>> >and miners. Miners are like banks lobbying government for higher total
>> >fees. Hodlers are the new 1%, holding 90% of the coin, lobbying both
>> >devs and users for security, but equally interested in price
>> >increases. Users are "the people" that devs need to protect against
>> >both hodlers and miners. They do not care about price as long as it is
>> >stable. They do not want to become the 99% owning 10% of the coin or
>> >have to pay unecessary fees merely for their coin to be the biggest
>> >bully on the block. A faster responding difficulty will take a lot of
>> >hot air out of the bully. It prevents miners from being able to
>> >dictate that only coins with high fees are allowed. They are less
>> >able to destroy small coins that have a fast defense.
>> >
>> >The 1% and banks would starve the people that feed them to death if
>> >they were allowed complete control of the government. Are hodlers and
>> >miners any wiser?
>>
>> Are developers any wiser, either?
>>
>> Then consider this wisdom: The fewer back-incompatible changes to a coin,
>> the better. Hardforks of any kind are an invitation to disaster and, at
>> this point, require massive coordination effort which cannot be feasibly
>> done within a month. Fast market determination can be done using off-chain
>> methods (such as on-exchange trades), and are generally robust against
>> temporary problems on-chain, although admittedly there is a counterparty
>> risk involved. The coin works, and in general there is usually very little
>> need to fix it, especially using dangerous hardforks.
>>
>> >Devs need to strive for an expansion of the coin
>> >quantity to keep value constant which is the foundation of the 5
>> >characteristics of an ideal currency.
>>
>> Is that your goal? This is a massive departure from the conception of
>> Bitcoin as having a fixed limit and effectively becoming deflationary. It
>> will also lead to massive economic distortions in favor of those who receive
>> newly-minted coins. I doubt any developer would want to have this property.
>>
>> Regards,
>> ZmnSCPxj
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171013/1afdebf0/attachment.html>;
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 13 Oct 2017 07:35:09 -0400
>> From: Scott Roberts <wordsgalore at gmail.com>
>> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> Cc: "bitcoin-dev at lists.linuxfoundation.org"
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] New difficulty algorithm part 2
>> Message-ID:
>>
>> <CADtTMvnrZp=JD4rkXQOZAPNS9BMNMqnTyfA65PRzZhWs+VxgHA at mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Yes, the current price ratio indicates there is no need for a new
>> difficulty algorithm. I do not desire to fork before a disaster, or to
>> otherwise employ a new difficulty before a fork is otherwise needed.
>>
>> A 2-week delay in difficulty response is a 2 week error in
>> measurement. Slow response generally means less intelligence.
>>
>> My goal is not to have a bunch of BTC clones that merchants and buyers
>> use equally, but to have a better difficulty algorithm in place to be
>> used in the next BTC "Core" fork. If not for the current situation,
>> then for future security.
>>
>> > This is a massive departure from the conception of Bitcoin as having a
>> > fixed limit and effectively becoming deflationary.
>>
>> You mean multiple forks is inflationary. The current limit in quantity
>> is deflationary because the use of the coin is rising faster than its
>> mining is producing (see velocity of money). Constant value is defined
>> as being neither. Bitcoin's deflationary quality created a massive
>> marketing advantage as well as paid the creator about million dollars
>> an hour. If it suddenly were able to be a constant value coin, its use
>> in the marketplace and as a real store of value would skyrocket and
>> the cries of "Ponzi scheme" would stop. The trick is in determining
>> constant value without a 3rd party such as an index of a basket of
>> commodities (which both Keynes and von Mises wanted, but was scuttled
>> by the U.S. at Bretton Woods).
>>
>> On Fri, Oct 13, 2017 at 12:45 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> wrote:
>> > Good morning,
>> >
>> >
>> >>ZmnSCPxj wrote:
>> >>> Thus even if the unwanted chain provides 2 tokens as fee per block,
>> >>> whereas the wanted chain provides 1 token as fee per block, if the
>> >>> unwanted chain tokens are valued at 1/4 the wanted chain tokens,
>> >>> miners
>> >>> will still prefer the wanted chain regardless.
>> >>
>> >>This is a good point I was not thinking about, but your math assumes
>> >>1/2 price for a coin that can do 2x more transactions. Holders like
>> >>Roger Ver have an interest in low price and more transactions. A coin
>> >>with 2x more transactions, 22% lower price, and 22% lower fees per
>> >>coin transferred will attract more merchants, customers, and miners
>> >>(they get 50% more total fees) and this will in turn attract more
>> >>hodlers and devs. This assumes it outweighs hodler security concerns.
>> >>Merchants and customers, to the extent they are not long term hodlers,
>> >>are not interested in price as much as stability, so they are somewhat
>> >>at odds with hodlers.
>> >
>> > As of this moment, BT1 / BT2 price ratio in BitFinex is slightly higher
>> > than
>> > 7 : 1. Twice the transaction rate cannot overcome this price ratio
>> > difference. Even if you were to claim that the BitFinex data is off by
>> > a
>> > factor of 3, twice the transaction rate still cannot overcome the price
>> > ratio difference. Do you have stronger data than what is available on
>> > BitFinex? If not, your assumptions are incorrect and all conclusions
>> > suspect.
>> >
>> >
>> >>Bitcoin consensus truth is based on "might is right". Buyers and
>> >>sellers of goods and services ("users") can shift some might to miners
>> >>via fees, to the chagrin of hodlers who have more interest in security
>> >>and price increases. Some hodlers think meeting user needs is the
>> >>source of long term value. Others think mining infrastructure is.
>> >
>> > Mining infrastructure follows price. If bitcoins were still trading at
>> > 1
>> > USD per coin, nobody will build mining infrastructure to the same level
>> > as
>> > today, with 5000 USD per coin.
>> >
>> > Price will follow user needs, i.e. demand.
>> >
>> >>You
>> >>seem to require hodlers to correctly identify and rely solely on good
>> >>developers.
>> >
>> > For the very specific case of 2X, it is very easy to make this
>> > identification. Even without understanding the work being done, one can
>> > reasonably say that it is far more likely that a loose group of 100 or
>> > more
>> > developers will contain a few good or excellent developers, than a group
>> > of
>> > a few developers containing a similar number of good or excellent
>> > developers.
>> >
>> > User needs will get met only on the chain that good developers work on.
>> > Bitcoin today has too many limitations: viruses on Windows can steal all
>> > your money, fee estimates consistently overestimate, fees rise during
>> > spamming attacks, easy to lose psuedonymity, tiny UTXOs are infeasible
>> > to
>> > spend, cannot support dozens of thousands of transactions per second.
>> > Rationally, long-term hodlers will select a chain with better developers
>> > who
>> > are more likely to discover or innovate methods to reduce, eliminate, or
>> > sidestep those limitations. Perhaps the balance will change in the
>> > future,
>> > but it is certainly not the balance now, and thus any difficulty
>> > algorithm
>> > change in response to the current situation will be premature, and far
>> > more
>> > likely to cause disaster than avert one.
>> >
>> >>Whatever combination of these is the case, bad money can
>> >>still drive out good, especially if the market determination is not
>> >>efficient.
>> >>
>> >>A faster measurement of hashrate for difficulty enables the economic
>> >>determination to be more efficient and correct. It prevents the
>> >>biggest coin from bullying forks that have better ideas. Conversely,
>> >>it prevents miners from switching to an inferior coin simply because
>> >>it provides them with more "protection money" from fees that enables
>> >>them to bully Bitcoin Core out of existence, even in the presence of a
>> >>slightly larger hodler support.
>> >
>> > This requires that all chains follow the same difficulty adjustment:
>> > after
>> > all, it is also entirely the possibility that 2X will be the
>> > lower-hashrate
>> > coin in a few months, with the Core chain bullying them out of
>> > existence.
>> > Perhaps you should cross-post your analysis to bitcoin-segwit2x also.
>> > After
>> > all, the 2X developers should also want to have faster price discovery
>> > of
>> > the true price of 2X, away from the unfavorable (incorrect?) pricing on
>> > BitFinex.
>> >
>> >>Devs are a governing authority under the influence of users, hodlers,
>> >>and miners. Miners are like banks lobbying government for higher total
>> >>fees. Hodlers are the new 1%, holding 90% of the coin, lobbying both
>> >>devs and users for security, but equally interested in price
>> >>increases. Users are "the people" that devs need to protect against
>> >>both hodlers and miners. They do not care about price as long as it is
>> >>stable. They do not want to become the 99% owning 10% of the coin or
>> >>have to pay unecessary fees merely for their coin to be the biggest
>> >>bully on the block. A faster responding difficulty will take a lot of
>> >>hot air out of the bully. It prevents miners from being able to
>> >>dictate that only coins with high fees are allowed. They are less
>> >>able to destroy small coins that have a fast defense.
>> >>
>> >>The 1% and banks would starve the people that feed them to death if
>> >>they were allowed complete control of the government. Are hodlers and
>> >>miners any wiser?
>> >
>> > Are developers any wiser, either?
>> >
>> > Then consider this wisdom: The fewer back-incompatible changes to a
>> > coin,
>> > the better. Hardforks of any kind are an invitation to disaster and, at
>> > this point, require massive coordination effort which cannot be feasibly
>> > done within a month. Fast market determination can be done using
>> > off-chain
>> > methods (such as on-exchange trades), and are generally robust against
>> > temporary problems on-chain, although admittedly there is a counterparty
>> > risk involved. The coin works, and in general there is usually very
>> > little
>> > need to fix it, especially using dangerous hardforks.
>> >
>> >>Devs need to strive for an expansion of the coin
>> >>quantity to keep value constant which is the foundation of the 5
>> >>characteristics of an ideal currency.
>> >
>> > Is that your goal? This is a massive departure from the conception of
>> > Bitcoin as having a fixed limit and effectively becoming deflationary.
>> > It
>> > will also lead to massive economic distortions in favor of those who
>> > receive
>> > newly-minted coins. I doubt any developer would want to have this
>> > property.
>> >
>> > Regards,
>> > ZmnSCPxj
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> End of bitcoin-dev Digest, Vol 29, Issue 21
>> *******************************************
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-10-09 📝 Original message:Sorry, ...

2023-06-07T18:06:53Z

In reply to nevent1q…l9ng
_________________________

📅 Original date posted:2017-10-09
📝 Original message: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 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 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 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.

=== Begin difficulty algorithm ===
# 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/231db5270acb2e673a641a1800be910ce345668a
#
# Keep negative solvetimes to correct bad timestamps.
# Do not be tempted to use:
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
# ST= Solvetime, TS = timestamp

# set constants until next hard fork:

T=600; # coin's TargetSolvetime
N=30; # Averaging window. Smoother than N=15, faster response than N=60.
X=5;
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
adjust = 1/(1+0.67/N); # keeps avg solvetime on track

# begin difficulty algorithm

avg_ST=0; avg_D=0;
for ( i=height; i > height-N; i--) { # go through N most recent blocks
avg_ST += (TS[i] - TS[i-1]) / N;
avg_D += D[i]/N;
}
avg_ST = T*limit if avg_ST > T*limit;
avg_ST = T/limit if avg_ST < T/limit;

next_D = 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 = coins per block

next_reward = BaseReward * avg_ST / T;

======= end algo ====

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