BUIPxxx: Reject past-drift correcting DAAs

[Jonathan Silverblood]

BUIPxxx: Reject past-drift correcting DAAs
Submitted by: Jonathan Silverblood
Date: 2020/07/29


Summary
The purpose of this BUIP is to reject any DAA alternative implementation that corrects for past drift, including the Grasberg algorithm, for the Bitcoin Unlimited node software.


Proposals
I propose that Bitcoin Unlimited takes a firm public stance against and rejects any DAA correcting for past drift, including the Grasberg proposal.


Motivation
Correcting for past drift, by necessity, causes future blocks to be produced at a slower rate. This has significant negative impact for the ecosystem and will further discourage developers from building on Bitcoin Cash, as well as making current user experience issues, such as the unconfirmed transaction limit, more likely to scare away users.


Background
For the 2020 november upgrade of Bitcoin Cash, it has been proposed that the difficulty adjustement algorithm should be improved to solve urgent oscillation issues. There are multiple proposed solutions that meet this criteria and one of them is the Grasberg algorithm that additionally tries to correct for past-drift.

edit 29 Aug 2020 - removed number as this BUIP is withdrawn due to the ABC drfit-correcting proposal being withdrawn.

 

[Griffith]

Let us assume that ABC stays consistent with their historical NIH behaviour and moves forward with their untested DAA. This vote is analogous to a vote to fork from ABC. Is that correct @Jonathan Silverblood ?

 

[Jonathan Silverblood]

Let us assume that ABC stays consistent with their historical NIH behaviour and moves forward with their untested DAA. This vote is analogous to a vote to fork from ABC. Is that correct @Jonathan Silverblood ?

Yes.

 

[torusJKL]

I don't like that BU has started these "reject xyz" BUIPs instead of proposing a solution and let the miners decide what to run.

BU stands for unlimited options not for limiting their user base.

 

[Jonathan Silverblood]

I don't like that BU has started these "reject xyz" BUIPs instead of proposing a solution and let the miners decide what to run.

BU stands for unlimited options not for limiting their user base.

I'm confident someone will make a proposal for a a specific solution, but my intent here is to allow BU to make any choice other than one that damages BU's goal of furthering the peer to peer cash agenda.

This proposal does not care where a final proposal comes from, and it doesn't care who puts it forward nor does it care how it solves the problem - it only cares about the fact that correcting for past drift is damaging to the ecosystem BU is trying to foster and allows BUs member to put that specific trait to a vote.

 

[Griffith]

I'm confident someone will make a proposal for a a specific solution, but my intent here is to allow BU to make any choice other than one that damages BU's goal of furthering the peer to peer cash agenda.

This proposal does not care where a final proposal comes from, and it doesn't care who puts it forward nor does it care how it solves the problem - it only cares about the fact that correcting for past drift is damaging to the ecosystem BU is trying to foster and allows BUs member to put that specific trait to a vote.

Since your fail to specify ASERT as a solution, are you saying you do not think this is a solution? Or were you leaving the solution intentionally vague so that it is still under the realm of "The Developer"'s responsibilities to accept the right one as long as it does not have a drift correction?

 

[Jonathan Silverblood]

Since your fail to specify ASERT as a solution, are you saying you do not think this is a solution? Or were you leaving the solution intentionally vague so that it is still under the realm of "The Developer"'s responsibilities to accept the right one as long as it does not have a drift correction?

I left it intentionally open for "The Developer" (BU as a whole, really), to implement any solution they see fit, or none, as long as they don't implement drift correction in the DAA.

 

[Jonathan Silverblood]

There is significant discussion on this on reddit, so for those who feel that they need to know more, I would recommend reading this:

 

[Tom Zander]

As I wrote elsewhere, I understand the wish from Jonathan here, but it makes sense to stop a moment and wonder.

First, if anyone other than Amaury would have proposed this, we would not be taking this approach. Instead, we'd ask them to give some rationale, some reasoning and even some proof of this being a good idea.

I would more like to ask BU to instead (re)confirm that they will pick a DAA based on merit.

This is different than rejecting a DAA based on a misfeature. Which is implied, but is not the same from a political point of view. Afterall, if this goes to vote and passes then Amaury would have a real thing to point at to say the selection of the DAA wasn't done evidence based, but a member vote picked it... This is fine for BU, not so much for BCH.

Thanks for reading.

 

[Griffith]

First, if anyone other than Amaury would have proposed this, we would not be taking this approach. Instead, we'd ask them to give some rationale, some reasoning and even some proof of this being a good idea.

AFAIK these things have been asked for by the community but amaury has not provided them. Instead, he contradicted some of his own previous talking points and asked people to run their own tests or trust his results (that he has not shared) that his idea is good.

I am not sure what else we are supposed to do?

This is different than rejecting a DAA based on a misfeature. Which is implied, but is not the same from a political point of view.

Are you requesting that the phrasing of the BUIP be reworded? If not, It is unclear (to me) what you are suggesting be changed.

 

[torusJKL]

The issue with these "reject xyz" BUIPs is that if accepted BU is saying that it doesn't believe in PoW but wants to force a change by "might" of brand and repository.

Very similar to Bitcoin Core IMO and that is a dangerous path to go down.

 

[Jonathan Silverblood]

@solex Given that ABC today announced that they will be running aserti3-2d, and that the other node implementations put out a joint statement for the same, I see no reason for this BUIP anymore. Can I withdraw it?

 

[solex]

@Jonathan Silverblood
Certainly, but perhaps we should leave this until we see the first release of ABC 0.22 as the contents is so unpredictable.

 

[solex]

This BUIP has its number removed as it is withdrawn.