[Bitcoin-ml] Time to get agreement on new DAA for Bitcoin Cash

G. Andrew Stone g.andrew.stone at gmail.com
Mon Oct 30 16:50:34 UTC 2017


This is my work-in-progress analysis, posted early because of the sudden
ABC decision:

https://medium.com/@g.andrew.stone/tail-removal-block-validation-ae26fb436524

In the first part I analyze the proposed algorithms.  In the second I
propose that since all the algorithms can be exploited to some degree we
need to take a different approach.

One thing that I don't consider though is how much better the proposed DAAs
are verses the EDA.  So I have no opinion on whether we should switch to a
better DAA as a temporary measure.  However, I think that my analysis shows
that miners who move between blockchains can extract at least 5% additional
revenue at the expense of the "benevolent" miners who do not (within Neil
Booth's simulation anyway), and it took me just a couple of hours and very
simple algorithms to achieve that.  As I mentioned in my prior article,
draining value from benevolent miners is dangerous since benevolent mining
is required to generate at least a few blocks to trigger the DAA's to
decrease difficulty and the benevolent miners create the median block
confirmation time that is important for users.



On Mon, Oct 30, 2017 at 4:44 AM, Erik Beijnoff via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

>
> > On 30 Oct 2017, at 05:48, Jason Cox <jasonbradleycox at gmail.com> wrote:
> >
> > To add another question: From what I understand, the ABC Team is driving
> the DAA changes. Are the other teams (BU, XT, Classic) prepared to make the
> same changes? I'm assuming the patches are mostly compatible between these
> forks?
> >
>
> In the case of Bitcoin Segwit I think it’s safe to assume that
> traditionally changes have been pushed through in full by one single party
> controlling the agenda, namely Core. This is not the case with Bitcoin Cash.
>
> My take on it is that in Bitcoin Cash there are three steps to
> implementation in the network. 1). Developers propose changes,
> single-handedly or in coalitions. 2) Influential miners choose to adopt the
> proposed changes (or not). 3) The economic majority accepts or rejects the
> changes. If there is major disagreement somewhere in these three steps, you
> risk a split, dividing the conflicting interests which from that point will
> be diverging in different directions.
>
> This is pretty much the ideal governance form of Bitcoin if you ask me.
>
> It's also the reason that I’ve continued to nag about this specific issue
> for about a month or more; I’m trying to facilitate the process described
> above, or at least keep it moving.
>
> When it comes to your specific question - a pull request has been
> merged(?) into ABC that forces a decision at the 13th of November (for ABC
> users). Amaury Séchet of ABC has proposed a change to the DAA algorithm. I
> am not aware of wether this proposal or some other will be merged by ABC.
>
> It is my belief that in the case of the DAA, developer alignment to the
> proposal that is deemed to hold the most merit is the best way to move
> forward. I’m pretty sure that if one proposal is generally accepted, all
> teams would be happy to adopt it. If not, I think it will be difficult to
> get them to implement.
>
> /Erik
>
> _______________________________________________
> 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/20171030/d1a9d04d/attachment.html>


More information about the bitcoin-ml mailing list