[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

Amaury Séchet deadalnix at gmail.com
Wed Oct 4 13:14:50 UTC 2017


The truth of the matter is that satoshi's way of adjusting the difficulty
is plain broken when you have more than one chain sharing the same hashing
infrastructure. The only reason it worked well so far for bitcoin is that
it is the only significant chain using SHA256 and it has dedicated hardware
to do so.

What changed isn't EDA or whatnot, it is that 2 chains are sharing the same
infrastructure for mining. This is not a new problem. Many altcoins are
facing this problem to a much greater extent than we are. Indeed, any coin
mined using GPUs effectively share the same hashing infrastructure with all
other GPU mined coins. The hashrate can migrate from one to the other as
profitability changes.

The #1 reason we went for the EDA mechanism is that many actors were
opposed to any change to the DAA at all, and EDA was the bare minimum
possible change that could ensure the chain's survival in face of a
hashrate drop at the fork point. Not because it is the best solution. Not
because it even is a good solution, because it is what people were ready to
accept. It is clear by now that more is required, and it would be a shame
to not leverage all the great work that people working on alts have done.
Some will call this copyright infringement, I on my side, call this science.

Among this body of work, zawy12's is the most interesting. He came up with
a solution that do not filter based on time, but on hashrate, which is a
significant improvement of the state of the art compared to previous
generation of solutions, which base themselves on time. In effect, because
difficulty is constant over a 2016 block windows in bitcoin, basing oneself
on time works. But if difficulty is adjusted every blocks, then the block
time in itself isn't a good proxy to estimate hashrate anymore.

I don't think there is any significant portion of the ecosystem left that
doesn't want to change the algorithm, so I don't see any reason to stay
with something EDA flavored. I don't think there is any reason to ignore
the research that has been done in the area either. I see a lot of reason
to not stick with what satoshi designed.



2017-10-04 12:35 GMT+02:00 Tom Zander via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org>:

> On Wednesday, 4 October 2017 00:43:44 CEST Shammah Chancellor wrote:
> > My goal was something simple to understand that changes difficulty both
> up
> > and down
> > without large jumps,
>
> I agree with that. Fixing the problem introduced by Deadalnix at the start
> of Bitcoin Cash. That is a goal all of us will get behind.
>
> > Like Shammah said I don't agree that we should be targeting miners or
> > their earnings;
>
> If you want to change the *ecnomic* incentives that underly the concepts we
> got from Satoshi, I personally need a LOT more than “I don’t agree”.
>
> Your (and deadalnix’s) proposals are drastic change to the economics of
> mining.
>
> Can we do minimal changes that just fix the issue that needs to be fixed
> instead?
>
> Maybe something like this;
>
> we keep the 2016 interval called the difficulty adjustment period.
> In this period the difficulty is set to a certain number based on the
> previous
> period. As it has always been.  This difficulty we call “base”.
> On top of that we have an EDA, just like deadalnix described. Its goal;
> difficulty can be adjusted downwards.
> On top of that we add a reverse-EDA. When blocks come too fast, difficulty
> goes up again, I suggest it should go up even more agressive than it went
> down.  Difficutly never goes above baseline.
>
> This is a minimal change that keeps all the economic incentives and removes
> the problem we have today with miners gaming the system.
>
> How does that sound?
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171004/34a548b4/attachment-0001.html>


More information about the bitcoin-ml mailing list