Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

[Scott Roberts via bitcoin-dev]

The current DA is only sufficient if the coin has the highest
hashpower. It's also just really slow.  If miners somehow stick with
SegWit2x despite the higher rewards in defecting back to bitcoin, then
bitcoin will have long block delays. High transaction fees will
probably help them defect back to us. But if SegWit2x manages to be
more comparable in price than BCH (despite the futures), hashpower
could very well oscillate back and forth between the two coins,
causing delays in both of them. The first one to hard fork to fix the
difficulty problem will have a large advantage, as evidenced by what
happens in alts.   In any event someday BTC may not be the biggest kid
on the block and will need a difficulty algorithm that alts would find
acceptable. Few alts use anything like BTC's because they are not able
to survive the resulting long delays.   I am recommending BTC
developers watch what happens as BCH goes live with a much better
algorithm, in case BTC needs to hard fork for the same reason and
needs a similar fix. Ignore the trolls.

On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe <crypt...@gmail.com> wrote:
> Is there an issue with the current difficulty adjustment algorithm? It's
> worked very well as far as I can tell. Introducing a new one seems pretty
> risky, what would the benefit be?
>
> On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"
> <bitcoin-dev@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
>> "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.
>> ___
>> 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

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

[Scott Roberts via bitcoin-dev]

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" <g...@xiph.org> wrote:

On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
<bitcoin-dev@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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Cash's new difficulty algorithm

[Scott Roberts via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 21

[Scott Roberts via bitcoin-dev]

> 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
 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,  a
> écrit :
>>
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev@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-requ...@lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-ow...@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 
>> To: Scott Roberts 
>> Cc: "bitcoin-dev@lists.linuxfoundation.org"
>> 
>> Subject: Re: [bitcoin-dev] New difficulty algorithm part 2
>> Message-ID:
>>
>> 

Re: [bitcoin-dev] New difficulty algorithm part 2

[Scott Roberts via bitcoin-dev]

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

Re: [bitcoin-dev] New difficulty algorithm part 2

[Scott Roberts via bitcoin-dev]

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.

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. You
seem to require hodlers to correctly identify and rely solely on good
developers. 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.

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? 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.  Therefore devs should seek
peaceful and sustainable forks of bitcoin. This will enable constant
value, security, and low transaction fees per coin transfer. Alts
aside, the current situation of discouraging forks forbids constant
value via limited quantity.  It also forces a choice between high
security and low fees.  Forks with a faster difficulty will be more
capable of retaining value.

Users, devs, hodlers, and miners are naturally aligned and at odds in
different ways. A flow chart of the checks and balances should enable
better development towards a self-controlling feedback system, but the
goals need to be known before it could be designed and implemented.
Hodlers say price increases is the goal. Users say efficient transfer
of value. Miners say fees (at least that's the end game after mining).
I'm with users despite trying to be the 1% (which reminds me of a book
about how people often vote based on feeling good about their morality
and concern for society as a whole, despite it being contrary to their
personal best interests if that vote wins.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Scott Roberts via bitcoin-dev]

Since there is no surviving argument in this thread contrary to my original
post, I'll begin work on a BIP.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] New difficulty algorithm part 2

[Scott Roberts via bitcoin-dev]

(This is new thread because I'm having trouble getting yahoo mail 

to use "reply-to", copy-pasting the subject did not work, and the 
list has not approved my gmail)
A hard fork in the near term is feasible only post-disaster (in my mind, 
that means Core failing from long transaction delays that destroys 
confidence and therefore price). A hard fork attempt to fix the situation 
will not work unless the difficulty is fixed to let price guide hash power 
instead of vice versa. We seem to be headed towards letting the tail wag 
the dog. BTC may find itself in the same position as BCH and all alts: the 
current difficulty algorithm is untenable and will require a fork. 

Current difficulty algorithm in presence of higher hashrate coin with 
the same POW: 
lower hashpower => wait times => lost confidence => lower price => defeat 

Difficulty algorithms that alts find absolutely necessary when there 
is a higher hash rate coin with the same POW: 
hodler faith => price => hashpower => survivable coin 

Alt experience time and time again is that Core will have to fork to a 
faster responding difficulty algorithm if it finds itself suddenly (and 
for the first time) with a lower hashrate. 


Mark Friedenbach wrote: 
> changing the difficulty adjustment algorithm doesn’t solve the underlying 
> issue, hashpower not being aligned with users’ (or owners') interests. 

I define "users" as those who it it for value transfer (including 
purchases) without concern for long-term value. If SegWit2x reduces fees 
per coin, then hashpower is being aligned with their short-term interests. 

It does not solve it, but it is a pre-requisite if the coin has a lower 
hashrate (BTC at end of November). A faster responding diffulty is a 
pre-requisite in minority hashrate coins for letting price (hodlers) 
dictate hashpower instead of vice versa. This is the experience of alts. 

ZmnSCPxj wrote: 
> Hodlers have much greater power in hardfork situations than miners 

Not when hodlers are more evenly split between coins. Miners will prefer 
the coin with higher transaction fees which will erode hodler confidence 
via longer delays. This means transaction fees will evolve to the highest 
that common marketplace users can accepet (they are not intereseted in 
hodler security), not the lowest technologically feasible fee that provides 
the greatest security. Large blocks reduce network security while giving 
the higher total transaction fees to miners even as it can reduce fees per 
coin for users. The mining "lobby" will always describe this as "best for 
users". Non-hodling users and miners logically prefer SegWit2x. 

ZmnSCPxj wrote: 
> BCH changed its difficulty algorithm, and it is often considered to be to 
its detriment due to sudden hashpower oscillations 

BCH has survived this long because they did NOT use the bitcoin difficulty 
algorithm. Granted, it is a bad design that included an asymmetry that has 
resulted in too many coins being issued. If they had inverted the decrease 
rule to create a symmetrically fast increase rule instead of keeping 
bitcoin's increase logic, they would be in much better shape, much better 
than the bitcoin difficulty algorithm. Making it symmetrical and fast would 
have resulted in more obvious fast oscillations, but this would have helped 
price discovery to settle the oscillations to an acceptable level that 
could stabilize the price by preventing too many coins from being issued. 

Oscillations require: 1) comparable price and 2) miners having the option 
to go back and forth to a larger coin. Bitcoin's long, jumping difficulty 
averaging window may destroy the minority hashrate coin faster in fewer 
oscillations thanks to a first-to-market effect more than reason. In 
persuit of higher total transacton fees, miners are deciding SegWit2x is 
"first-to-market" to cause Core to have long delays. This is not a 
conspiracy, but simply seeking profit. Since fees per coin can also be 
reduced, they can convince themselves and others that it is the best 
option. 

A shorter difficulty algorithm averaging window enables more, faster 
oscillations to enable better price discovery before a winner is chosen. 
The design I'm proposing should be close to the ideal.  For example, Mark 
Friedenbach suggested a difficulty adjustment every 18 blocks by averaging 
the past 36 blocks. If a coin using that has the minority hashrate, then it 
could quickly develop into a sudden influx from the majority change for 18 
blocks, then they exit back to the majority chain for 36 blocks before 
doing it again. They get 1/3 of the blocks at "zero excess cost" 
(difficulty will be 1/10 the correct value if they are 10x base hashrate) 
and then they will leave the constant miners with a higher difficulty for 
36 blocks (at 3.33x higher difficulty if the "attackers" are 10x the base 
hashrate). This forces constant miners to start copying them, amplifying 
the oscillations and delays of the minority hashrate coin. A 

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Scott Roberts via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Scott Roberts via bitcoin-dev]

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.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork?

[Scott Roberts via bitcoin-dev]

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, the 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 the 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# 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];# 
D=difficulty, ST= Solvetime, TS = timestamp, T=TargetSolveTime
# set constants until next hard fork:
T=600; N=30; # Averaging window. Smoother than N=15, faster response than 
N=60.X=5; # size of sudden hashrate changes expected as multiple of base 
hashrate.limit = X^(2/N); # limit rise and fall to protect against timestamp 
errors & manipulationadjust = 1/(1+0.67/N);  # keeps avg solvetime on track for 
small N.
# begin difficulty algorithm 
avg_ST=0; # avg SolveTimeavg_D=0;for ( i=height;  i > height-N;  i--) {  # go 
through N most recent blocks   avg_ST += (TS[i] - TS[i-1]) / N; # TS=timestamps 
  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 coin reward to protect against hash attacks.# 
Karbowanek coin suggested something similar.# After testing many ideas, I could 
not find anything better than the simplest idea below.# It was a 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 (MTP) 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.)
Small N windows like keep the correct median, but cause avg solvetime to be 
above the target. The "adjust" constant (empirically determined) fixes this, 
but it causes the median to be that same percentage too low, below the ideal 
Poisson median which is 0.693 of the mean. I was not able to find a fix to this 
that did not slow down the response to hashrate changes.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev