<unnamed>

Public Key

npub164d4d9z50r3uzguvlmvwdsevs5t7w6y5hjfz72wkafp0wn72nvfq5znx9p

Profile Code

nprofile1qqsd2k6kj3283c7pywx0ak8xcvkg29l8dz2tey3098tw5shhfl9fkyspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrcsgev

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:07:31 CEST

- reply

📅 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>

2023-06-07 20:07:30 CEST

- reply

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

2023-06-07 20:06:53 CEST

- reply

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